Week 2: Engine Design Plans

This week we had a class on modularity. The class was enlightening and got me thinking more about the design of our engine for this year.

Last year our 'engine' - if it can even be called that - was fairly modular compared to what we had done before but that's not saying much. The components weren't exactly designed well in and of themselves, but most could be dragged and dropped into another project and be used there (although there was some dependencies on the math libraries). Our biggest problem was actually that it was difficult to manage all the code. We didn't implement any managers. We didn't really allow for communication between systems and so code that should have been encapsulated within a manager class ended up all over the place. We also had no tools, which made designing levels and particle systems difficult as they were had to be hard coded, and everything always had to be recompiled.

Bottom line is development tools were non-existent last year in our engine. The code was messy and difficult to manage, and even though our game turned out fine, it really could have gone more smoothly.

Based on the design of the game described in my previous post, the lower level functions such as the physics, graphics, animation, collision, artificial intelligence, audio, input systems and the core gameplay mechanics will be built into the engine itself.

The game modes will all be done using scripts which will allow us to quickly test game modes and re-balance them without having to recompile the engine. I also hope that our development tools will include at the very least a level editor, a particle designer and a menu creator.