Birthing Pains of Video Game Development

Gentle readers, come along and endure the birthing pains of video game development. This blog will chronicle the lessons learned while building my (currently) personal 3d video game engine I've titled "The Elpis Engine", as well as any video games that will arise as I move forward.

Now, I've been developing Elpis for a little while in my spare time, so my posts won't exactly be a pure start-to-finish operation. Although, it is early enough in the development stages that I could simply list what it can do and everyone would be caught up.

The engine itself revolves around a combination of a component-based entity system and a type of subsystem architecture. Essentially, everything in the game is a generic 'entity' or 'object' with swappable features and the subsystems manage these features. For example, the player character is an entity and it has a 3d model 'feature' or 'component' and the Renderer subsystem loads and draws this feature for our entity.

The system depends on the Havok physics engine, which has been implemented to some minimal extent and I plan to explore this here when I get around to implementing more physics. The engine is written in C++, Lua and uses the DirectX 9 api for rendering. Shaders are in HLSL.

The current capabilities of Elpis:

• Loading a DirectX model file (.x file)
• Loading Havok rigid bodies and associating them to the loaded model
• Applying basic physics to rigid bodies (gravity, collision, velocity, friction)
• Handle user input and translate to events that the system recognizes and listens for
• Binding systems and entities between C++ and Lua, thus it has scripting capabilities
• Simple Rendering for the loaded x files, currently on the fixed function pipeline
• Loading, configuring and rendering complex, customizable, animate-able and skin-able GUI elements
• Loads from XML into Lua where it is configured with event handlers and properties, C++ handles the drawing and event passing.
• Seemingly powerful design, though only a rotatable ship helm and animated treasure chest buttons have been developed at this point. (Pirate themed testing... problem?)
• Explore the scene using a quaternion based fly camera
• Generating and rendering terrain from a heightmap, on the programmable pipeline

So, Elpis has some features and a framework to build upon.  Surely that isn't enough to build a game, right?

Probably right! But before I list all the features I want to implement, I'll mention that I do have a game planned for this engine (Yay! Project scope!). I shan't cross the borders of the requirements for this game... at least, not at first.

AND THUS, I shall implement the following features next (likely in this order):

• Support for a large world (currently aiming for 40km² lands, without loading points)
• Shifting co-ordinate space periodically to avoid floating point errors
• Massive, divided terrain
• Entity streaming
• Terrain Physics (well...heightfield collision anyway)

Of course, there will be more features and posts detailing the parts that are interesting. My next post, however, will be of a non-technical topic that I feel is important to talk about: TIME MANAGEMENT! WHOOO! Who's pumped?!