After some preliminary experience building GORE, I have a game plan for Splintered Core’s engine. Roadmap, I mean.

Here’s how the development would look like.

Barebone engine + editor

The barebone engine contains these modules:

  1. Scene manager
  2. Resource manager
  3. Base scene class
  4. Base entity/sprite class
  5. Base renderable class
  6. Extensible editor with plugin architecture

The scene manager basically holds a list of scenes. A title screen is a scene; an options screen is a scene; a loading screen is a scene, etc. Each screen’s ID is held in a linked list inside the scene manager, and each ID points to a scene definition file (a simple INI file detailing what resources to load for that scene, and what class to load too). More than one scene can exist in memory at one time though.

The resource manager is a singleton that always exist in memory. It loads tilesets, images, video files, audio files and manages their lifetime and existence. This means that once a scene is removed from memory, resources related to that particular scene will need to be automatically freed by the resource manager.

The base scene class is just a simple abstract class that MUST be extended by the application. Nothing much to talk about this one, just that it should contain all the necessary functions that the scene manager will call.

The base entity/sprite class is a base class that contains all the functions and properties necessary in an game entity. Anything in the game can be an entity: units, player characters, menu items, buttons, etc.

The base renderable is a base class for all renderables in the scene. Think of it as this way: a renderable is a class while an entity is an instance (object) of the class. For example, a pac-ghost renderable is loaded into memory, and when the scene starts, 5 pac-ghost entities are spawned, each with a different color and different AI routine. Renderables are manufactured and tracked by the resource manager.

The extensible editor is an application built with the Qt framework, and uses the game engine to display a scene in its viewport. The editor should be used written in a portable language I guess – not really confirmed on this one yet.

Title Scene, Loading Scene and GUI framework

Next up are:

  1. Title scene
  2. Loading scene
  3. GUI framework

The title scene first plays a couple of videos (can be modified through the scene definition file) and then settles down on a menu. Each menu item leads to the loading of another scene, or drills down deeper into the title scene’s sub-scenes.

The loading scene is just a screen with a progress bar that gets the resource manager to load a bunch of resources needed for the particular scene. Nothing biggie here.

The GUI framework should be a simplified utility module that provides all the necessary GUI elements to any scene, including: buttons; dropdowns; text-boxes; etc. This would probably take the most time to implement, but the payoff is enormous.

2D Isometric Scene and 3D models

I expect the isometric scene to be one hell of a bitch to code. Since I have no experience with coding isometric engines, I expect to take a very long time just to get things right. Not to mention that I’m trying to combine both 2D background tiles and 3D models.

This is the part where I would really appreciate additional coders helping me out. There are so many things to do here:

  1. Isometric grid render code (with proper tiling)
  2. Camera code with global offsets, mouse-to-coord transformations, global-to-local and local-to-global transformations, etc
  3. Camera culling
  4. 3d character model loading
  5. z-order management between the 3d character and 2d objects
  6. Skeletal animation code

There should be more, but that’s the list of todos off my head as of now.

Scene editor

Once the render code is in, it’s time to go flexible. Time to code in the capability to edit a scene in the editor, with the complete scene loading/saving routines.

  1. Scene loading/saving
  2. Tiling system
  3. Alpha mask brush on terrain transition tiles
  4. Entity property editor
  5. 3d model preview
  6. Tileset viewer

All these needs to be done before serious artwork can be pumped into the game. At this stage, although everything is static, and there’s no code to load worlds and such, it’s a huge milestone as the contracted artists can utilize the editor to start testing out their artwork. This should cut down a lot of to-and-fro time between me and the art team.

That’s all for the first tech demo. I expect all these to take at least 4 months of intensive work.