After briefly testing PushButton Engine I knew it was how I wanted to develop future games and so set about writing my own game engine based upon it, this way I would know exactly how everything worked and could customise it to my tastes.
The first version borrowed a lot from PushButton but was a lot simpler. I used it to develop Dalek Supremacy and really enjoyed using components, to go back to inheritance would be horrible. One thing I did find annoying however was that I was constantly using lookups to gain access to other components, whilst this is good for maintaining loose coupling, the code seemed a little unnecessary, all my entities had a spatial component and a render component that both had to look each other up to access each other, which was quite verbose but also slow.
So when it was time to start on my next game; Nightmare High: Truth Specs, I decided to make some changes. I had been studying the Unity api and how things worked in there, it seemed like all the game objects or entities had direct access to the basic components such as the transform/spatial component. I decided to ditch some of the loose coupling for fast performance and easier development and renamed a few of the components to be more inline with Unity.
I finished Nightmare High with v0.2 of my engine and was very pleased, things went even smoother than they did with Dalek Supremacy, it still needs a lot of optimisation and a bit of bug testing but it would be cool to open source it and hopefully get some input from other people. For now, however, my most recent interest is Haxe so I am in the process of porting it over.
Currently, the engine consists of the following core classes:
- Entity Manager – contains a list of the entities and used for entity lookups.
- Process Manager – updates the list of “updated components”.
- Render Manager – renders the render components.
- Collision Manager – handles the collision between collider components – using a quad tree for broad-phase and SAT for narrow-phase. (Great article by Metanet on the subject: http://www.metanetsoftware.com/technique/tutorialA.html)
- Entity – a container that holds a list of its components.
- Render Component – handles sprite-sheet rendering (and to be removed MovieClip rendering).
- Transform Component – contains all the spacial information about the entity.
- Collider component – contains the collision info.
- Updated Component – a based class that updated component extend
- Component – a base class for all components
There are other classes, such as those used for different parts of the collision detection and some custom components I have built like a Tilemap component, a Health component but the above are the core or the engine.
I love creating games using components, for a while I started really getting too wrapped up in how I was coding, too much design pattern and best practices. Whilst they all have their time and place, I am finding that by creating a little bit more freedom and flexibility within my code, making games can be a lot more fun, and with components if I want a new feature to a game, I just knock up another component and add it, no worrying about reverse engineering the inheritance system.
I plan to continue my work on the engine and hopefully release it after another iteration so stay tuned. In the meantime I should mention the Ember Framework by Tom Davies. It is more of a framework than a game engine (I don’t believe there is any built-in collision detector or other game specific stuff) but seems very well engineered. Here is Tom giving a demo of Ember at the London Flash Meet up: