2012/08/06

miniDooM: Code Foundation

The very first thing I got to do, before I began mucking about with sprites and assets, was set up a basic Java program structure unto which to build the project.

All too often, program development is begun in what I see as the development equivalent of "In medias res", solutions are devised for specific parts of the problem, without consideration for the whole, and thus later need to be stitched together, resulting in a precariously cohesive monstrosity. A Franken-program, we could say.

In Game Development this usually happens because it is very tempting to quickly code the screen rendering routines, the input listeners, and quickly draw something that moves, and move it around.
The the rest is added to this hastily created infrastructure, and before the developer realizes it, the program has developed quirks of such a caliber it is scary to even think about ironing them out.

To avoid this, and because I kind of get off on program architecture, I've devoted the initial week of D4K's miniDooM's development to organizing things. The current architecture might vary, but I'm confident parts can be altered without having too great an impact on the rest of the program.



The overall design goals are the following:


  • Modularity: A given when using Object-Oriented programming, but in this case more so. A major point of the whole development is to create a base framework from which to develop game ideas. For that reason, there should be flexibility to change key components.

    I've approached this issue with a plug-in mentality, parts of the program, or modules, are designed with a common interface, and managed by a central program core, which redirects module Input/Output as needed. If, for example, I want to change the game logic, the design is meant to allow me to swap Logic modules around seamlessly.


  • Independence: Dependencies are the bane of programming. They are extremely useful tools, indeed, but as they grow in complexity, the bring their own flaws and problems into whatever program is using them. Thus, I am of the opinion that approaches should attempt to be as dependency-free as possible. This is doubly true if you are aiming for multi-platform development (as I am).

    Now, keep in mind that I'm not objective here, I've worked a lot in embedded development, having to deal with the impossibility of using dependencies, so it's my personal mindset, but I still think it is a healthy approach to not expect some magic library to do the job for you.

    Also, there's the ages old adage "You must learn to crawl before you can walk". I personally don't feel comfortable using something I don't, to some degree, understand. That's why I think it is also healthy to, at least once, try to do everything by hand.

    As far as D4K miniDooM goes, the dependency independence means that there is an special namespace (System) where I'm dumping all the system specific callbacks, thus resulting in an interface the inner modules plug into.

    As an example, instead of adding code directly to the keyboard listeners, I just redirect keyboard input to the inner Input Manager, using my own format, thus if I were to change the external system dependencies, it would seamlessly plug in to my structure.

    All this, of course, has a performance cost, but that's a bridge that'll be crossed in the far off future.

    Finally, since an important objective is to be able to eventually port the project into C++. I also aim to have language independence, that is, I resort as little as possible to java internal dependencies, and even wrap them in my own structures when needed. This has proven interesting, since tearing the java libraries apart has actually resulted in new implementations that work much better.

    For example, I re-implemented the Stack class, discarding all the extra features the standard implementation inherited, and focusing exclusively on my needs. This is a bit like reinventing the wheel, but also means I have a firm grasp of how this base element works for when I have to debug or port it.



So, with the basic structure set, I'm now delving into implementing the supporting modules. Currently I'm finishing up the system display interface, which handles screen resolutions and drawing to the screen. And since user input is already done, the next step will be to start implementing a basic Logic module and get some results.

So yes, after all the basics are done, now I can remorselessly go for the quick gratification of having a little something move about the screen.

More on that when it's done!

No comments:

Post a Comment