As most of you readers know, I am in the middle of writing an engine for our SpaceRock Miners game. Not only that, but a generic engine that can be used for other games as well, including platformers, puzzle games, virtually any 2D games. The engine is going to be open-source and based on some other engines and libraries such as multimedia and input engines (Allegro, SDL, SFML) and a 2D physics engine (Box2D, the best one).
I was architecting the engine (HLGE, that stands for Higher Level Game Engine) and was pretty satisfied with it as it was. But, as I started to code it, I decided to actually study the subject more formally; got a book on architecture of game engines, found some resources online, read some articles... In the end, I learned a lot more than I expected. I should never had underestimated my own ignorance on the subject; never underestimate your own ignorance!
I really should have studied the creation of game engines sooner. That "create games, not engines" phrase is somewhat to blame; creating engines is a part of creating games, whether people want it or not. It opened my mind to possibilities that I failed to think of. Some stuff I read made me feel really stupid, while others I wasn't so far off. Of course, I got the basics right, but why being sufficient if you could be awesome? Don't you agree?
That's why, as stated on my last post, I basically discarded my first project, its architecture and any code I already had. Just so you guys understand, this hobby project has been on for months before I even thought of creating this blog, who'd say registered it; that's a lot of work out the window. It was a tough decision, but I had to do it, I would hate to work on an engine while knowing its architecture was flawed.
Now, back to the drawing board, I'm back to the basics. Designing interfaces for every system on it, thinking of the tools i'll need, all that. Repeating this process is fun, I'll tell you; imagining all the possibilities again, but I must not let myself drift too much. If I don't take care, I'll end up spending months just thinking about it and architecting it and never get to implement it.
As changes, I can list some that I think are pertinent.
And an endless list of changes that wouldn't make sense to put in here since the previous wasn't even public yet.
- I won't be using XML anymore
- I plan on using YAML now; if you know of a possible alternative, comment it please.
- I'll introduce the concept of Time Line
- This is a major change that was incompatible with my previous architecture. With this we'll be able to create effects like, for example, slow-motion without having to output even a single command to the physics simulation.
- Improved "views" system
- I'm completely remaking the views system in a way that will allow us to change between game states way easier than before. My previous design was exactly the same I used on my first C++ game (what, as you can imagine, is pretty amateur).
- Improved sprite rendering
- A little extra memory in exchange for a faster rendering and shorter sprite loading times. Partially related to the "Locking Surfaces/Bitmaps" concept.
- Create an abstraction layer for several problematic types such as time, angles, strings, so you don't need to think if it is on radians and seconds or degrees and milliseconds.
I hope to get this ready as soon as possible, but, given my usual coding speed, it can take pretty long. Worry Not! Meanwhile, go to gamedev.net, work on a simple game project using a good framework such as LÖVE2D.
I'll try not to decide to start over again!
Over and Out.