Feature Wishlist

This blog is mostly about the development of a game engine. And, first things first, a game engine needs to have a feature wishlist! This list can be anything that you want your engine to use/achieve really...there's no problem "shooting for the starts" so to speak.  Reality may set in later, it's true. But for now, anything's possible...right? :)

Therefore, without further ado, here is my wishlist for the Qi Game Engine:

1. Multi-threaded
• The engine should adapt to any number of cores in order to keep up with the processors of today and tomorrow. Gone are the days when computing advances were had through faster processors. Just look at the PS4/XBox One. The only way to get great performance out of these machines is to embrace parallel programming.
2. Modular
• Extensibility is an important part of a game engine. No developer is going to want to use an engine that they can't easily modify for their own purposes. Therefore the engine should be designed in a modular way which allows for parts to easily be swapped in and out.
3. Multi-platform
• With the latest generation of consoles, being multi-platform isn't as challenging as it's been in the past (they're basically just customized PCs). The main thing to think about here is avoiding anything that is platform-specific (system calls, defines, etc.) in your high-level code. If you must do anything that is system-specific, do it at the lowest possible level of the engine so that it can easily be abstracted into a generic class for use by your higher levels.
4. Scriptable
• The importance of scripting cannot be overrated. Modern games are too complex and need many people working on different parts of it simultaneously. These people often come in the form of artists/designers who may not have the necessary skills for full-blown C++. Therefore, integration with a simple scripting language is important for wide use. Additionally, scripting can be used to rapidly prototype gameplay ideas without having to rebuild parts of the engine, reload a level, restart the game, etc. 
5. Use of existing libraries
• Building an engine is a monumental task, especially when undertaken alone. Therefore, it will be beneficial to use some third-party software for parts of the engine that you're not ready to implement yourself. Don't know much about animation? Use a third-party animation library. Don't know much about physics? Use a third-party physics library. And so on and so forth. If our modular design is achieved, it should be fairly straightforward to strip out a third-party library later on and replace it with your own implementation once you're ready.
6. Get up and running quickly
• Nobody wants to work with an engine that's hard to setup. Likewise, nobody wants to work with an engine that's easy to setup incorrectly. There should be a simple application framework for using the engine that addresses both of these issues.
7. Avoid long recompiles
• Building the engine for the first time (once feature complete) will probably be slow. There will be hundreds of files full of thousands of lines of code to get through. However, after that first build every other build should be fast (no more than a couple of minutes in the worst case). This can be achieved through a few means:
• Partition your code into libraries
• Libraries allow for simple encapsulation of similar code into one place. Editing any code within a library will cause just that specific library to be rebuilt and re-linked with the rest of the engine.
• Dynamic libraries can be an even better idea...they avoid the compile-time re-linking and can be rebuilt/reloaded while the engine is still running.
• Keep as much code as you can out of header files. I understand that at times it's convenient to put code all in one place (especially if it's relatively small). However, any changes to the code in the header file will usually trigger a re-compile of every module which includes the header. That could be multiple libraries all over the place.

That'll do well for now. Note that this wishlist is very high level. Really, you can just think of it as a quick set of ideas to keep coming back to while working on the engine code itself. Always you should be striving to achieve the goals laid out in this list!

Next up I'll be introducing a small series about the core library for Qi. This will include parts of code that you'll need to have before anything else in engine.