Pre-Christmas Update

I'm getting ready to nosedive into studying for finals, so development is likely to slow down a bit in the coming weeks.  Christmas vacation (if studying for finals counts as "vacation") may impair progress even further.  In the spirit of both Christmas and intellectual reflection, I thought now would be a good time to pause and look at where we are, and where we need to be going.


Where we Are
As of today, we have a very detailed story, which Kacey is transcribing into something more pleasing to read than a bunch of notes and IM logs.  The idea is to publish a history of the Project Orbit universe in periodic updates.  Eventually, this will be compiled into a single volume and published on the game's wiki in time for the first public release.

As much as we appreciate ninjas and robots, it's time
to throw our own models in the mix.

It may seem strange to put this much effort into a background story for an RTS game.  After all, strategy games with good stories are about a frequent as adult films with good plots.


But having an intuitive sense of the universe goes a long way towards understanding what the game is about, and what your units can do.  Labels, unit models, avatars, and voices are descriptive and guiding, but only if they stand on firm ground.  Kacey's work on the plot is to gameplay design as concept art is to 3D modelling.


Brian has shifted gears and is working on a model for a human infantryman.  Right now, all of our testing is being done with stock OGRE models.  As satisfying as it is to see game logic unfold, it all feels a bit pointless when the models and terrain are foreign-- it's like we're not really working on our own game.

We'll soon have our own models, at which point we'll post some screen shots and video clips of our progress.


Where we are Going
If I were to sum up our 6-month plan in a single phrase, it would be "steady as she goes."  Our first milestone is still to have our units on our terrain demonstrating basic movement.  Shortly thereafter, we'd like to see some simple combat animations and logic.  I originally made predicted that this milestone would be reached by the new year, but that's looking increasingly unlikely.  But not to worry!  We'll try to have it by Valentine's day so that you can show your girlfriend how awesome we are.


On a more technical level, this is where we are.  I've set up a very basic game engine which implements the Model View Controller design pattern via message passing.  Of course, I took a couple of shortcuts in order to take advantage of some handy features in the OGRE API.  For example, OGRE implements a buffered input system with callback functions being implemented directly in the game loop.  This is handy because it avoids having to publicly broadcast messages to all listeners when we know that only the player controller listener is interested in those messages.  So instead, we call the relevant member function directly from the game loop.



So as of 12/19/2011, progress continues and things generally seem to work again.


For a ragtag group of amateurs, this ain't bad...

Towards full Component Design

I was wrong.


Or shortsighted, or optimistic, or simply inexperienced.  In any case, we're working towards a more complete component-based system for our game objects.


If you recall the post from a few weeks ago, I was of the opinion that game objects could be implemented in terms of multiple inheritance.  This was good because it avoided the added complexity of managing various component objects.  What we didn't foresee was that this actually made things more complicated in certain cases.


Here's a really simple one, to illustrate.  Let's say we're creating a unit similar to the StarCraft II Viking.  The Viking is a unit whose distinguishing feature is that it is an aircraft capable of transforming into a ground-roaming mech.  As such, it must incorporate code to handle movement in the air and movement on the ground.


At first glance this seems not to cause any problems.  Being naive, we go ahead and have class Viking_clone inherit from class Walker and class Flyer, but now we have a problem!  Which move() function gets called?

The Viking from StarcCraft II

One solution is to name them separately -- perhaps fly() and walk() -- but that hasn't really solved anything.  All we've done is spread the problem out in the codebase.  Now, anytime we have code that tells a game object to move, it has to check which type of object it is and call the corresponding method.  To make matters worse, if we later decide to add another type of unit, say a boat, we have to edit code throughout the project to accommodate this new type of object.


On a more formal level, what we've done is violate the golden rule of game design:  keep things separate.  Module A should not care about how module B's internal structure.  It should instead interact with a constant and stable interface.


To get back to the Viking Problem, one solution is to implement a metaclass such as this:

class vikingClone:
    def __init__(self):
        self.vclone_air = vclone_air()
        self.vclone_grnd = vlcone_grnd()
        self.active = self.vclone_air
        
    def go(self):
        self.active.move()
        self.syncAG()
        
    def syncAG:
        ...

All we've done is create two separate classes, Viking_clone_air and Viking_clone_ground, each with its own methods.  To move the unit, the one would just call the appropriate method from the metaclass, which in turn calls the corresponding method from self.active.


From there, it's just a matter of calling a function that updates the non-active version of the Viking object.


If you're following my logic, you can see how this is only a short step away from full-blown component management.  To be sure, this would be a great refactoring solution if we had already coded up the vast majority of unit-related stuff, but it's still hackish and wasteful.  We don't need two copies of the Viking clone's health or attack function, for example.


What we're doing instead is managing all aspects of the object's behavior by assigning component objects.  The metaclass will only house the information which is completely unique to the unit:  health, for example.


Also, this potentially allows us to save memory by destroying the unused movement-type object:  if the Viking clone is walking, we destroy the instance of class Flyer.  Of course, this has to be weighed against the cost of initializing a new object every time the unit changes configuration or the complexity of using a pool of objects, but the point is we now have options.


So there it is, I stand corrected.  The good news is that the problem became apparent pretty early on, so we haven't wasted too much time.  The whole process of implementing components has been relatively pain free as well.



I'm currently working on an input management class along with the ground movement class.  The latter is nearly done!

Development Milestones

I have put together a list of development milestones.

This list is essentially a chronological road map with narrowly defined objectives to help track progress.  The idea is to have something concrete to work towards, and to be able to quantify our progress on the basis of "steps completed."


It's not the most rigorous scheduling approach in the world, and to be honest the release dates will probably move around a lot, but we figure it's good for our work ethic.


The first milestone will be an unimpressive (but necessary) proof-of-concept for our game engine.  Colloquially, we're calling this the environmental proof-of-concept, and it will implement the following:

• Moving a single entity across a plane with obstacles
• Line-of-sight (a.k.a. Fog of War)
• 1 v 1 combat

Our second milestone will simply build on this:

• Move multiple entities
• Rudimentary micromanagement
• n vs. n combat

From there, we're going to attempt to implement the full scale of the environment, economics, advanced micro-macro managment, etc... But more on those parts later in the months to come.

Be sure to check the roadmap tag for all updates concerning the development timeline.  For now, we're hoping to have the first environmental proof-of-concept ready by mid January.

Introducing the Sigmoid Studios Logo!

Reddit's /r/picrequests page is awesome.

A few days ago I made a post asking for a bit of help with logo design.  Two people responded very quickly, each with their own take on the Sigmoid Studios logo.

I decided to use crisd6506's design, because the graphical style reminded me of the pixel art from the games I grew up with.  Spending a large portion of one's childhood in the 90's has a lasting effect it seems...

In any case, the logo is pictured here.  I asked crisd if he had a website I could link to, and he replied in the negative.  He did mention, however, that he has a rusted virtual coin jar he likes to wave around.

On behalf of Sigmoid Studios, thank you so much for your help, crisd!  May the upvotes and karma be plentiful!

The other design, as it turns out, will be used for Project Orbit.  More on that later, but suffice to say it really fits the project name.