MODERN GAMES DEVELOPMENT
The games industry has long been the aspirational destination of many sceners,
and for an increasing number that dream has become a reality. The games business
is now littered with many demo coders, for some it's become a resting home, the
scene boots are hung up. But for those who continue their double life as mild
mannered playstation coders by day and ST scene superstars by night, there is
much to be learned from the day job.
Although modern consoles offer hardware and technical possibilities far out of
the reach of the humble ST, there are still valuable development techniques that
can be equally applied to building atari games as making the next xbox
blockbuster.
Since commercial game development on atari machines died some 10 years ago,
games have been a precious and rare commodity. This is not down to a lack of
interest in games or a lack of desire to create games. Many game projects have
been anounced in that time period - the sad fact is that a very small minority
of those projects reach completion.
So what are the common reasons behind the failure of game projects? And can we
learn anything from the techniques employed in the games industry?
Let's first examing a typical life cycle of ST games development.
1. The basic game idea is arrived at. This is often a conversion or an
enhancement of an existing idea.
2. The basics of the game engine are coded.
3. Graphist painted art is incorporated to replace the 'programmer art'.
4. Game engine is enhanced/optimised/bugfixed.
The majority of games falter at the 4th step. Many don't even make it past the
first step.
So let's breakdown the various aspects of game development and try to apply some
industry style techniques to them.
CODE
----
It's important that you don't attempt to reinvent the wheel with every new game
project. Writing a set of libraries will give an excellent starting point for
all projects.
Libraries should contain generic modular components that can form the basis of
your games. Systems that should be in your libraries include file systems, input
(joysticks/keyboard/jag pads etc), depacking routs, graphics routines and maths
functions. The more comprehensive your library, the less you have to code for
each successive project.
It is very important to structure your code in a modular way and have the least
dependency between modules as possible. This means its easy to share components
between projects, and add/remove/optimise components with the minimum of code
change.
TOOLS
-----
Tools are an essential part of game creation. Every game needs data that might
not be created in the optimimum format in your content creation package.
Sprites, texture maps, maps, tables - you will generally want to convert this to
an in-game format that is optimised both for size and processing.
Whilst you can load your assets in a non game ready format and convert them in
the game, this will generally waste disk space, memory and also make you game
slower to load. Having a set of command line tools to do this processing is an
advantage.
You can then create a batch file to process all your data to make a single build
process for the entire game. It is important to make this process easily
accessible to all people involved in the game's development. That way, graphists
who are painting sprites can run the build batch file and create the in game
data, and thus see edits to their graphics in game without having to wait for a
programmer to deliver a new build of the game.
BUGTRACKING
-----------
Games development often seems more an exercise in bug removal that actual
coding. It's impossible to understate the amount of time that actually goes into
debugging a game. It is imperative that you have a good system for tracking the
discovery and fixing of bugs.
The secret of a good bug tracking system is to present as much information as
possible with each bug.
The bug info should contain the build number of the game, what system it was
found on (tos version, memory size, details of any accelerators etc). It should
provide detailed steps on how to reproduce the bug.
An exception screen is another useful tool for the bug killer. To create this,
you should take over the exception vectors (bus error, address error, illegal
instruction etc). When an exception is caught, you can display a screen showing
a register and stack dump and program counter offest from the start of the text
segment.
The exception screen was invaluable to us in tracking down many nasty crash bugs
in our productions.
COMMUNICATION
-------------
Having good inter-team communication can be the difference between a success or
failure. If your group all live in the same town, this should be no problem, but
most demo crews have members scattered over their native country if not over
several countries.
We have used mailgroups to communicate between the team. Each project that we
are working on has its own mailgroup, and everyone involved in that project
(including developers & testers) are subscribed to the group.
Yahoogroups provides a useful mailgroup service and it has the advantage of
including filehosting and a simple database in the package.
Everytime a new build in uploaded, a mail would be sent to the mailgroup
detailing all the changes and bugfixes in the game, that way everyone involved
was completely up to speed on the title's progress.
SOURCE/ASSET CONTROL
--------------------
A common horror story amongst non-commercial developers is "my hard drive got
corrupt and i lost all my sources!" Backup strategies are essential to avoid
such issues and a good source control system can help here as well as giving you
many other advantages.
We use a web based CVS system to hold all our source code, data and executables.
If someone loses a hard-drive, there is a backup. If a bug is made, we can
easily "roll back" to an earlier version of the source.
CVS also makes distribution of the game to the development team very easy - any
team member can log onto the server and download the latest code and data.
CVS is something that we have only recently added to our development process and
it's more than proved it's worth :)
MOTIVATION
----------
The #1 enemy of the hobbiest games developer is motivation, or more the lack of
it. Failing motivation is probably the top killer of games projects. Lack of
communication amongst the team, difficult to fix bugs, lack of progress in the
project and limited access to new builds are all factors that can sap
motivation. Using some of the ideas and strategies laid out in this document can
help to avoid those issues and keep motivation levels high.
FINAL THOUGHTS
--------------
There are few projects more satisfying than creating a really good fun game.
It's a real shame that we don't see more of these titles reach fruition. Few
realise the actual difficulties involved in building such a title. If you don't
have a carefully thought out development process, your chances of completing
such a project are virtually zero.
With a bit more time spent determining 'how' the game will be built, not merely
'what' it is, you can be well on your way to creating the next hit and more
people can answer the classic "Did you play atari today?" with a resounding
"Hell YEAH!".
Good Luck!
Pink / RG
|
