Jump to content
Site Stability Read more... ×
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Dr Electron Post Mortem

Sign in to follow this  


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 :

Level Attack

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.

Time Attack

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:

  1. Communication

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

  1. Gameplay

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.

  1. Turn
    Around Times

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

  1. Data

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.

  1. Usage
    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.

  1. Engine

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.

went wrong:

not always bright light when you're in game development, so here are
the things that went wrong.

  1. Personal

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

  1. Game
    Design Doc

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.

In the
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.

  1. Graphic

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
software engineer.

  1. Data
    Format Documentation

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.

  1. Graphic

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.

So we
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.


3 month (mainly in spare time for Dude Development)

costs: ~1000$

of developers:
1 programmer, 1 graphic artist, 1 project manager,
1 music and sound effect composer, 4 beta testers

Development development enviroment:

  • Intel
    2.8 ghz, 1 gig Ram, 120 gig harddrive, ATI 9800 pro, onboard sound

  • AMD
    1.2 ghz, 512 mb Ram, 60 gig harddrive, Nvidia GF3, SB sound card

  • Intel
    Celeron 700 mhz, 256 mb Ram, 40 gig harddrive, Nvidia GF4 MX, SB
    sound card

  • 3.3
    mbit ADSL internet connection

  • Visual
    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

  • AMD
    3.2 gghz, 256 mb ram 80 gig hdd, GeForce 5200FX, onboard sound

  • Maxtor
    external drive, 80 gb for daily backup

  • P3
    666 Mhz, 512 mb ram, 40 gb hdd, S3, onboard sound as fileserver

  • 1
    mbit ADSL internet connection

  • Visual
    C++.net 2003, cvs, PhotoshopCS, Eclipse

Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!