A small engine to make games fast
When I started, the main goal was just the reunite the tools (drawing, input handling, file loading, console, physics, sound management, monetization, etc), but soon it become necessary a management of all these tools. There was several implementations of the same solution and sometimes one is better then another, so I had to create a Bridge Pattern to conciliate all them together. Which was not a walk in the park! Different features, pipelines, event handling, sync, etc made my work a headache.
Not just that, several libraries when working with each other require some level of communication between them. That was the point that my simple library became an engine.
I learned a lot making the GameLib Engine. I’ve made several researches about game engines, saw the source code of several tools, engines and libraries and learned how they work and they should work to integrate with my little engine.
I used here the technique called Test Driven Development, which you code based on several tests and test them everytime you make a new feature. This ensures that your tool/library/software still works after the changes. This technique proved to be very useful and time saver, since I detected each bug right when it was inserted into the code. Very often I use the Test Driven Development, specially when I’m creating frameworks.
To make the things more real, I’ve created (with a help of two other guys) a game to prove that the engine was working: Hex-B, the only product made on GameLib ever published.
Why you never heard about GameLib? Simple: the goal in my life is to create games, not engines. I soon realized that I couldn’t compete with great engines like FlashPunk, Citrus, Flixel and PushButton. Actually, what I was is to use the engines, not make them. No regreats, I’m sure I’m a better programer today because of this project.