News Team Current issue History Online Support Download Forum @Pouet

01 - 02 - SE - 03 - 04 - 05 - 06 - 07 - 08 - 09 - 10 - 11 - 12 - 13 - 14

Alive 9

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

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.


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


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

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.


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

The exception screen was invaluable to us in tracking down many nasty crash bugs
in our productions.


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.


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 :)


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.


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

Alive 9