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:
If 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 problems.
Although 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.
- Turn Around Times
What 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.
Another 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).
- Data Management
This 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.
- Usage of Bug Tracking Software
Half 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 developer.
The 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".
The system of our choice was Mantis.
One 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.
The 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.
What went wrong:
It's not always bright light when you're in game development, so here are the things that went wrong.
- Personal disposability
Being 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.
This 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.
Mainly 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 time.
- Game Design Doc
After 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.
- Graphic Assets
We 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.
That 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.
Doing the graphics by myself is not really the solution - I'm a software engineer.
- Data Format Documentation
Another 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.
- Graphic cards
Both 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.
After 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.
The 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.
For 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.
Development time: 3 month (mainly in spare time for Dude Development)
Development costs: ~1000$
Number of developers: 1 programmer, 1 graphic artist, 1 project manager, 1 music and sound effect composer, 4 beta testers
Dude 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
Black Mouse Entertainment development environment:
Intel 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