For some time now, I’ve had the urge to make a game engine, nothing too fancy and not really with a view to release it to the public, just something to both help me make games faster and to improve my programming skills by making it.

So, when I finished LibCT 2.0, I decided that I’d start work on a small 2D, cross-platform engine: Ragnarok Engine. I decided on making a 2D engine because, well, I quite like 2D games, I like making them too so that’s a good start. Secondly, my graphics programming skills are limited and I don’t want to (at this time) dive into the rabbit-hole that comes from attempting to write a decently performing 3D graphics engine. I decided it would be cross platform because I actually like some of the things it imposes, I like that the code will be compiled on different compilers that give different warnings, I like having to section-off the low-level, platform specific code, to me this forces me to make the code better, now obviously I always try to get the code that good but we’ve all been at the point where we just write a quick hack to get something working and say we’ll go back and fix it later, but later never comes.

Since the engine will be cross platform I decided to write the renderer in OpenGL, I may decide to add a DirectX renderer in the future, but for now I’ll just stick with one API. The development plan for this engine is pretty simple, I intend this to be an engine for me to use, so it may not be suitable for people who are just beginning to code, it aims to make common things simple, and un-common things possible. I will generally use the most basic implementation of something (for example, the sprite renderer) until it becomes a problem, then I’ll improve it, this is so that the engine can develop on all fronts at a similar pace, and thus I can start using it to make games with sooner (I feel you never really appreciate an API until you’re forced to use it).

So far, I have some of the basic libraries fleshed out, maths, graphics, scene. The scene library is the most recent one, it exists to provide scene-graph functionality, in the form of nodes. The current plan is for the nodes to have properties that can be set through an editor, that will run along-side the game allowing for the easy creation of scenes which can be loaded at run-time.

Thinking about the editor led me down an interesting path, the editor will know about certain property types, floats, ints, vectors, colours etc. and be able to edit the properties of any node. The game-code will create it’s own nodes, perhaps one for the player or enemies. The editor should know about these nodes too so they can be placed in the scene, which leads to an issue, originally the editor was going to be part of the engine, and the game-code would merely link to the engine libraries, however, if this were to be the case the editor wouldn’t know about any game-specific node-types. Now, I could make the game-code compile to a .dll and tell the editor to load that at run-time, which may work, but I’d prefer not to use .dlls, and telling the editor which .dll to use could end up slightly messy.

The solution to this problem seems to be to compile the game-code into a lib, and have, in the same solution as the game-code, all the engine libraries including the editor, and have one project that links all those libraries into an executable, then to run the editor you can launch the executable with a certain command-line argument. This solves the problem nicely, the editor knows about the game-specific nodes and we avoid .dlls. The only problem here is that this leads to each game having it’s own editor, however, I decided to turn this into a strength.

Whilst it is the engine that parses the command line arguments and decides if it’s the editor or a normal game that needs to be run, I passed the creation of the editor to the application, which is the class all games will sub-class, this virtual function allows the game to create a custom-editor, derived from the base editor, that may contain things not useful or wanted in all game editors, but of great use for that specific game.

The only down-side to this that I can currently see (note I’ve not even begun to implement it) is that it makes setting up a new game kinda complex, but since it’s only me doing it, and I can most likely script it, I think it’s a decent trade-off.