Core and subsystems overview

I think it's time I started talking about the specifics of the current Derange design, so I think I'll start from the core.

The Derange core -or kernel if you prefer-, is divided into the Core class and a few derivations of the SubSystem class, each dealing with specific areas of functionality. They need to be accessed by the rest of the engine all the time, as they do the "lower level" stuff, making things shorter to develop and easier to maintain afterward.

Some of them also encapsulate the functionality of some of the third-party components I use. That way, if I ever decide to switch to a different component to do the same task, I keep the original subsystem interface, and just adapt the inner workings.

The core can be configured by modifying the configuration file, which is an XML file with things like desired screen resolution, rendering options, resource locations, etc. When instanced, it instructs each subsystem to initialize itself and in turn, shutdown. More importantly, it starts the game loop.

Here are some subsystems and a brief description of what they're supposed to do:

• Input: Provides access to any available input devices. Right now it's basically an OIS wrapper.
• Resources: Allows to access and keep track of game resources like meshes, material scripts, textures, shaders, XML files, locations, actors, etc. It should do so in an efficient way -for example caching or sharing resources across requests-, so that if it's asked for a specific resource multiple times, it only gets loaded once.
  
• Video: Provides means to change how things are rendered, and it also creates the Ogre3D render window. Keeps the game loop running until exit is requested.
  
• Scripting: Allows to execute Lua scripts, which tell the engine what to do.
  
• Scene: Allows to create, access, destroy and keep track of all the game objects that interact in a single scene. It also notifies them when they should be updated.

click to enlarge

As you can see in this class diagram, all subsystem classes inherit from the Subsystem class, which implements the Singleton design pattern. This is because it only makes sense to have one instance of each subsystem. Additionally, the Subsystem class has access to the engine configuration, as specified in the XML file.

All classes in Derange derive either directly or indirectly from the CoreObject class. This way if I need to introduce any changes that should be applied to every single class, like for example keeping a count of instances and amount of memory used, I can do it from a single place.

So, when an instance of the Core class is created, it creates an instance of each subsystem class. Then it starts the game loop. And when it's done, it destroys the instances it created. Each subsystem is responsible for both initializing itself and cleaning after its own mess upon shutdown.

As Derange keeps growing, I'll most definitely add at least a couple more subsystems (for example one to handle all audio), but at this stage those should be enough.

I might disclose details on how each subsystem works soon, but I think I'll take a few days to tidy them up a little. As I was writing this post, I noticed some really dumb design mistakes that I previously overlooked.

So how am I going to do this?

Ok, so you now know why I'm making this. It would only be fair to tell you how I plan to do it, or at least how I think I'm going to.

Derange is being fully written in Visual C++ 2008. This was not a very easy decision to make, since I had never written anything in that language before. I'm very comfortable developing in C# and .NET, since I've been using those at work for a long time now. I love how tidy, flexible and powerful they are. However, there are some important drawbacks to using them for game development, as I found out:

• Ogre3D is written using VC++. Even though there are ports to use it with other languages, they will always be behind schedule when releasing updates, and there might be bugs in the porting process.
• .NET code is executed in a virtual machine, which is of course much more resource intensive and slower than plain old native code.
• I think most of the game development resources out there are targeted to the C++ developer, and being one in a learning process, this was quite important.
• I understand VC++ is the industry standard when it comes to game development.

Usually I like to plan development prior to get my hands on it, and have the big picture in mind to identify any possible design flaws before they become a problem that's hard to fix. Given the size of this project (Don't forget I'm the only one working on it) and that I'm still learning, that didn't sound realistic at all, as I can only anticipate what's coming up to a certain point. So I decided I would design and redesign as needed, on the fly, as I see fit.

This means that I might end up completely rewriting entire sections of code. Many times. And actually, I already have by now. I believe each code component should be as modular, reusable, and decoupled from other components as I can make it to be, so that when I need to take a different approach with something, there's not so much I need to change.

Before getting into game specific tasks like handling entities, animation, conversations, etc., I decided to focus on the "skeleton" of the engine. Things like basic engine initialization, handling input, resources and events in general, running Lua scripts and the like. I think this really needs to be dealt with first, because everything else I code will depend on how the skeleton is laid out. If it's not flexible enough, there will come a time when I have to redesign it, and probably rewrite most of the code that depends on it. Which would of course make me shit bricks and is not acceptable in any way.

I redesigned this skeleton many many times back when I started, and it still needs a little tidying, but by now I'm fairly comfortable with its general design. I'll get into the specifics and some diagrams in the following posts.

I don't plan on reinventing any wheels, so I also chose some free, open source, third party tools for some specific tasks. (I might add more or switch to different ones in the way)

• Lua: A scripting language widely used for game development, it's what makes a specific game "drive" the engine.
  
• LuaBind: Binds VC++ classes to Lua classes, making them available from scripts.
  
• Xerces C: Allows to read, write, and validate XML data.
  
• OgreMax: Imports scenes created in 3DStudio Max into Ogre3D.
  
• OIS: Handles input devices like keyboards, mice, gamepads, etc.

After the skeleton was mature enough, I started focusing on the actual game objects and their functionality. Things that can move, animate, walk a given route, talk, interact, and much more. Some examples of game objects would be cameras, lights, actors, particle systems, and the player himself.

So the plan up to this point is to keep polishing this skeleton as it becomes necessary, developing more game objects and testing them in a sandbox scene where I can see all their functions in action. I'll be deciding the order in which to implement this functionality on the fly, most probably based on whatever I feel like doing next at each point. :)

So that's it for now. I'll give more details on how the current design looks like in the following posts.

Introduction: Why I made this blog

I have wanted to develop games since I was a child.

I actually made a couple of horrible games back when I had a Commodore 64 using a Basic compiler and some Assembly (and I wasn't even 12 yet!), but never had any experience developing games for PC before, let alone working in a 3D environment. On the other hand, I have always been a quick learner, specially when it came to software development, so I figured I might as well give it a try.

In most tutorials I've read for newbie game developers you're advised to start very small, maybe just a Pacman or Tetris clone until you get a hold of the basics. However, I've always been very ambitious (and stubborn) when starting projects, so I figured a good way to learn the works was to make a reusable engine and deal with all topics at once instead of separately. Time will tell if this was a wise decision. :)

The first thing I noticed is that learning how to render 3D graphics seemed like way too much to study by myself considering I have a day job, a daughter, and -hopefully- a life, which doesn't leave me with THAT much spare time. And even if I did, I would have to constantly update the render code so that it stays fresh, which would be too much work for me alone.

So I decided to focus only on the game logic, and leave the rendering to a third-party engine. This is when Ogre3D comes in. Ogre3D is a free open source 3D rendering engine with a very big community using it, and I've already seen it in action in "Ankh", by Deck13 Interactive, so I knew it was mature enough to handle the kind of job I needed.

I play lots of games, and have particularly enjoyed point-and-click adventure games ever since Maniac Mansion came out on the C-64. So, considering they're not so resource intensive and dependent on cutting edge graphics, I decided that my engine would be tailored to make adventure games.

This engine is called Derange, and has already been in development for several months, making quite a slow progress as my spare time allowed. This will be its development diary.

This blog does NOT intend to teach ANYONE how to develop a game engine. Actually, I've never developed one. I'm just learning how to do it by practice.

So don't forget, I just made it because I wanted to:

• Keep track of the development -and learning- process somewhere, for my personal archiving purposes. Might be nice to have some day if I finish it.
  
• Allow anyone that might be interested in it to follow the progress.
• Get feedback. Remember, I'm learning, so it's very possible that I pick a completely fucked up way to do things, and feedback helps me get back in track before it's too late.

And who knows, it might even help a fellow newbie in a similar quest.

Hope you enjoy it!