flipCode - Tech File - Peter White [an error occurred while processing this directive]
Peter White
Click the name for some bio info

E-Mail: po.white2@ukonline.co.uk


   06/10/1999, Introduction


Well, here is my tech-file - a place I hope (nay, intend) to fill with ramblings and thoughts about my various game projects. FlipCode is absolutely bursting at the seams with 3d info, so I'll try and discuss other topics of game programming.

At the moment I'm working on an Asteroids style game. The graphics are in the style of Total Annihilation (3d models in an otherwise ordinary 2d game). This game will feature dynamic lighting, proper physically-correct collision detection, multiplayer features and a scripting engine. One day it will be the ultimate in 2d space combat (well, maybe). I've just been programming the game's console, so I'll talk about that for now.

The game console - a concept introduced in Quake so it must be good :). Seriously, though, there are lots of uses for the console. The most important, for me, are to help with debugging and to make the game more customisable. Look at Quake's console, for example. With ReaperBots you control how hard they are using the console - you *could* provide a nice menu, but that isn't as flexible. On the debugging and testing side, a console lets you test features of the game without having to write masses of user interface code. For example, you've just written the network code and don't want to write a menu for connecting to servers or finding servers just yet - you can use the console to connect!

I wanted to take my game console further than Quake's though by emphasising the object oriented nature of the internal game structure in the console. To do this, I introduced the idea of a 'package' for a group of commands. The base package class looks a bit like: 

  class BPackage
  {
  public:
      virtual void Call( char *func, int argc, char **argv ) = 0;
      char *name;
  };
A pretty exciting class, as I'm sure you'll agree. Packages are added to the console as the game proceeds. All console commands take the following form:

  package.function ...

  eg, cd.play 2

So when the console receives a command to execute it checks the package part of the command name with all packages currently attached to the console. If it finds a match it calls the relevant package's Call() member function passing the 'function' part of the command name and the argument list (just like the call to main(), but argv[0] is the first argument to the function).

This allows commands such as:

  cd.play 2
  game.quit
  net.connect 192.168.1.1
  server.start

To make it slightly easier to use, though, I made it 'self documenting'. I've spent ages sitting at the Quake console trying to remember exactly what the command I want is. With the Asteroids console I could have added a standard 'help' function to each package, so if you typed:

  package.help

  eg, cd.help

You'd get a friendly help message giving you pointers to functions that package supports. Using the cd player example again, the "cd.help" command might produce something like:

  >cd.help
  CD Player Package
  Supports commands: play, stop, eject

You see that and decide that you want to play a cd. So you try "cd.play", which produces.

  >cd.play
  Call as cd.play

So you try "cd.play 2" and the second track of the cd is played. This was quite good, but I decided that it could be even more intuitive (you could expand the help a bit, but that isn't very hard at all). If you detect a special case where just the name of the package is given, you can Call() the 'default' package function, which is just a null terminated string. In pseudo-code: 

  if( command==just package )
  {
      BPackage *package = FindPackage(command);
      package->Call( "", 0, NULL );
  }
Hope that makes sense. This lets you just type "cd" and get a list of all of the package functions that are supported - it's functionally equivalent to the "cd.help" command described above.

That's the basics of my console. If anyone's interested I can seperate the console from the other 10000 lines of Asteroids code and post the source for a console demo. Be warned though. The Asteroids project is also an exercise in using as much of the C++ language as possible :).

Aarrrghhh! There's so much to talk about: the network code; the way I've got the code working with several platforms; the 'parameter sheets' to make the GUI really simple. It'll all have to wait for another time though.

Feel free to e-mail me about anything to do with Asteroids or anything else!

Peter (po.white2@ukonline.co.uk)





  • 06/30/1999 - No Subject
  • 06/10/1999 - Introduction
    • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]