How the cross-platform, custom game engine integrates in the big picture

 

While designing and developing the game engine, it became somewhat necessary to start drawing some pictures to help get a bit of visualization going on.  This picture here shows, hopefully, that the engine itself is merely a component in the "bigger picture" of how a bunch of code and logic fit together to finally and actually be able to make a real game product.

Because the engine is C (read here for the reasons why it is C), the source code should be written such that we can take the C files over to platform x, compile it, and it just works.  In theory that sounds great, but in practice it isn't quite that simple.  As long as I can separate out the cross-platform code from the platform specific code, then all will be [mostly] well.  Fortunately, this design also lends flexibility in how we go about implementing those platform specific things while allowing the vast majority of the engine to be compiled, more or less, as is across multiple platforms.

The top part of the this picture shows the various Operating Systems we plan to support.  Each, of course, has their own considerations that don't play well with other OS's though -- so we had to split those "platform specifics" away from the "core" of the game engine.  By decoupling them, we can make lots of upgrades, fixes, and what not to the core and have it be fixed instantly across all platforms.  We can also write the platform specific parts once and never really need to change it once it works.

The Platform Specifics are:

• compiled 3rd party libraries (static or dynamic, depending on the platform/license)
• windowing code (hey, they all speak differently with their host OS!)
• device data gathering about hardware capacities
• core input handling
• opengl setup
• utility things, like figuring out storage paths, how to talk to file system
• platform specific scripts, batch files for windows, bash for the others

The Game Engine then is:

• Lots of header files for 3rd party libraries
• Lots of loading data routines
• Lots of math, geometry, collision detection routines
• Random number generator
• Lots of graphics functions
• Lots of utility functions (think buffering files, writing strings in binary, delay functions, etc)
• Generalized/abstracted input handling
• Generalized/abstracted sound output handling
• Logging functions
• Networking code
• Physics
• Vector stuff
• Matrix stuff
• Time/Date handling
• String handling
• Memory handling
• Specialized data support for game data files
• Embedded Lua script engine
• Everything else not platform specific

The Game Core is:

• Art, sound, data loading/destroying
• Game objects
• Actors
• Artificial Intelligence
• Player input response
• Game networking
• Game physics (in addition or by compliment to the game engine's)
• Everything else that makes the game

Once all of these things are combined and compiled/linked together, the actual game can be spit out and run on any of the supported platforms!  It is quite exciting to see our Windows version work near flawlessly on iOS or OSX just by pulling down the game core code, compiling, and it works... yea, sometimes there are hitches, but these are usually quick to fix as they are general oversights.

It was also quite breath-taking to see a "windows game" work on Linux almost without a hitch also.