My game

[Ian Crawford <icrawfor@uoguelph.ca>]

Here are some early specs on the game I'm designing:

The game will be an action/adventure game.  The player will control a super spy
James Bond type character (good or evil) with all the toys.  All the rest will
depend on the levels you play.

The game will implement character profiling.  Players will be able to customize
their character's appearance (snapshot and some limited 3D model 
customizations), history, inventory, arsenal, and some personal attributes.
Ideally the game will validate the profile such that no one will be able to
carry 17 million uzi clips or 400 pounds of first-aid supplies.

Different modes of transportation are good.  I see running, swimming (with and 
without scuba gear), flying (jet pack, parachute, hang gliding...), driving...
maybe even space travel.

Multiplayer support will depend on the design of the level.  The level can be
competitive (head to head), cooperative (a spy team), or some combination of the
two (teams competing head to head in a capture the flag type scenario).  

Levels can be sequential.  That is, several levels can make up a complete story.
Entry into the next level depends on the completion of the previous level 
(ideally stored in the character profile).  The game will have a mechanism to 
automatically load the next level in a sequence like this.

The levels will be unpausable.  In single player, you will be able to save your
game at any time, but action won't stop while you browse your inventory or
communicate with the boss.

The viewpoint will be configurable.  You may choose a first or third person
view.  In third person, the behaviour of the camera will be configurable and
easy to change (like, with a single keystroke).  In first person, the virtual
aspect ratio of the viewing area will also be configurable (i.e., you will have 
the option of seeing things as they are or distorting everything to give you 
more virtual peripheral vision).

Communication will be a big part of the multiplayer game.  Compressed live 
audio data and ASCII data may be sent from player to player.  All communications
(especially audio) will be optimized for low bandwidth connections with the goal
being effective 4- or 5-way communication over a 33.6 modem (this may be
re-evaluated as time goes by depending mostly on how many people are still
limited to a 33.6 Kbps network connection when the game is completed).

An observer role may be assumed.  Even if you're not playing, you can connect to
server and fly around invisibly (even through walls) to see what's going on at
any particular point.

I do not favour the use of a game SDK.  I'm not overly impressed with what is
currently available, though I may reference the code from existing kits when
designing some aspects of the game (namely, the sound server and implementations
for input devices.  I may even examine an existing network protocol.).

The game will be developed for the 2.1.* kernel series, not 2.0.*.  The 
reasoning behind this is that by the time the game is out, everyone will be 
using Linux 2.2 (or maybe 2.4, 3.0, 143.8...).  On the same note, the game will 
use OpenGL 1.2 (implemented by Mesa 3.0, another work still in development) to 
keep up with technology.

Since Mesa is so flexible, the game will have a full screen version with the 
help of Glide, as well as a windowed X version.  Hardware support will be 
implemented as required.

The game will be client/server based.  I haven't given the protocol much thought.
I think I will see what has already been done and take it from there.

The game will use two types of models.  A "skin and bones" type of model will be
used for people and other structures that have a continuous surface.  The other
type will have a hierarchical tree of parts that are transformed via matrix
operations (translate, rotate, scale).  This type model will come in handy for 
things like buildings and vehicles.

The game will aim for physical perfection!

That's it for now.  Any feedback (feel free to be thorough) would be
fantastic.

Later,
Ian