Electron Post Mortem
In Dr. Electron you have to create molecules by putting atoms with 1 to 4 electrons onto the playfield. You have to connect the atoms by aligning the electrons so that they face each other. This will create an link between the two atoms. Once all atoms are linked and no electron remains unlinked, a molecule has been created and will disappear from the playfield.
There are two game modes :
In this mode you can play until you hit one of the end criteria (no more place on the board or no more place in the new atom tube). Every n points you will go up one level which speeds up the atom generation.
In the Time Attack mode a given number of atoms has to be eliminated. Once you have succeeded to eliminate them, you get into the next level.
After 5 levels you unlock a bonus level.
Dr. Electron has been published by Black Mouse Entertainment, an online publishing company created by Frank Lucht and programmed by Dude Development, an independant game developer created by Stefan Maton. The music and sound effects have been done by Task4, a company created by Haiko Ruttmann.
What went well:
you read the list about the people who were involved into the
development of this game, you see that we are all industry veterans.
We have already worked together on multiple titles. The result was
that we had a very clear idea about how to communicate between us and
how requests had to be done. It was also clear who would be the
central person to whom we had to report our progress and our
Dr. Electron has some similarities with old arcade style games such
as "Atomino" and "Atomix" the gameplay has
been reworked to give the game a faster paced style of playing. The
way the game had to be played was quite clear from start on so we
didn't have to change too much on that. The only thing we changed was
the way the player could replay the bonus levels which now is a
simple button click away instead of a cryptic passwort to enter.
went quite well was the turn around times between the moment we took
a decision and the moment that decision took effect. A very good
example of this are point 4 and 5 of "What went well".
Shortly after we decided to use those methods, it was implemented.
example for the good turn around times were the speed at which bugs
have been reported by beta testers and the confirmation that the bug
has been eliminated. This was in most cases done in one day (which
isn't that bad for an independant developer who isn't in direct
contact with the beta testers).
is one of the things that went extremely well. Almost everything is
accessible from outside the game. The entire gui is layed out in XML
files which made it very easy to quickly adjust the position of
certain gui elements. Other things that are layed out in the XML
files are the animation sequences, the sound and some basic rules
such as the points you get for the atoms and molecules.
of Bug Tracking Software
time into the development of the game, it occured to us that it would
be preferable to have some kind of bug tracking software running on a
central server. This helped us quite a lot it reducing the turn
around times since the bugs could be entered into the tracking system
by the beta testers. An email was instantly send to the responsible
bug tracking software has also been used to track the request for new
features. They were added into the system and once they have been
implemented, the "bug" has been "fixed".
system of our choice was Mantis.
major plus was the usage of the Alternative Realities Engine
developed by Dude Development. We were able to create the base
skeleton of the game within 2 hours and the first playable version
was available in 2 days. Since the engine is quite complete, tasks
such as reading XMLs or playing sounds or setting up the graphic
enviroment was easy.
gui engine used in the game has proved to be very good. It was easy
to add new elements such as animated bitmaps or to make enhancements
to the current elements available.
not always bright light when you're in game development, so here are
the things that went wrong.
an independant developer almost always means that you need another
source of income to feed your family if you don't yet have a strong
list of titles which sell. This is the case for Stefan. He's got a
family to feed and although he has a long time background in game
development, he hasn't yet a independant game portfolio which would
permit him to live only by that. So he had to spend his time between
his day job, his family and the development of the game.
fact lead to a slip in the time schedule and expanded development
time. As an independent developer and publisher starting business the
limited personal disposability was not really unforeseen. But I
had'nt expected that the development time would be so much longer.
the last part was hard to fix specially in the last weeks before
master when the work time snipped off the main part of the family
the first game design doc has been set up, everyone thought that the
information we needed to develop the game were available. But it
showed up that some aspects just weren't included such as the gui
layout and the information needed for the in between level screens.
course of time you tend to be lazy while updating the design doc.
There are many excuses to 'I date it up tomorrow, cause....' but none
which are really bullet-proof reasons. This is a major issue after
finishing this project where I as a publisher have to improve.
had quite some problems to find a graphic artist for this game. It
wasn't a problem to pay for the assets but appearently the graphic
artists who were interested in the project finally couldn't help us
out because they had some major troubles with their machines. So,
Frank had to do the graphics by himself.
was an unforeseen point. It lead to a major delay and put me into
serious trouble. My fault was that I did'nt pulled the emergency
brake much earlier. It's quite hard to find good and solid graphic
artists and I think that will it be for the future projects.
the graphics by myself is not really the solution - I'm a
problem we had was the fact that we had a powerful data format but no
documentation for it. This resulted in unnecessary turn arounds due
to questions that had to be asked. Although most of the used tags had
an example in the xml files, some syntax formats weren't obvious.
Black Mouse Entertainment and Dude Development are small start up
companies. As a matter of that, both companies don't have enough
money to spend on the different graphic cards and driver combinations
possible on the market. Even though we have tested the game on
different hardware (different Nvidia and ATI hardware), we couldn't
afford buying cards we didn't have already.
got some feedback from clients where the menu graphics were
distorted. We are working on the problem but as you know : If you
can't reproduce it, it's hard to fix it.
all the development of Dr Electron has been quite smooth. We had an
early alpha version of the game which was quite playable and which
helped us to determine if the game was worth continuing.
team has worked very well together and the collaboration of Black
Mouse Entertainment and Dude Development didn't end in a fiasco as it
often happens during the stressing crunch time.
me as the publisher, producer and project lead is the result that I
have a game that is really fun. Many things I have learned. Some of
them were bad and I'll have to improve myself. Some of them were good
and over-all the project was a success.
time: 3 month (mainly in spare time for Dude Development)
of developers: 1 programmer, 1 graphic artist, 1 project manager,
1 music and sound effect composer, 4 beta testers
Development development enviroment:
2.8 ghz, 1 gig Ram, 120 gig harddrive, ATI 9800 pro, onboard sound
1.2 ghz, 512 mb Ram, 60 gig harddrive, Nvidia GF3, SB sound card
Celeron 700 mhz, 256 mb Ram, 40 gig harddrive, Nvidia GF4 MX, SB
mbit ADSL internet connection
Studio.net 2002, Visual Assist X, Perforce, ACDSee, Paint Shop Pro
Mouse Entertainment development environment:
P4 2.5 ghz, 256 mb ram, 60 gig hdd, GeForce4 MX 440, onboard sound
3.2 gghz, 256 mb ram 80 gig hdd, GeForce 5200FX, onboard sound
external drive, 80 gb for daily backup
666 Mhz, 512 mb ram, 40 gb hdd, S3, onboard sound as fileserver
mbit ADSL internet connection
C++.net 2003, cvs, PhotoshopCS, Eclipse