When we set out to write Bakudanjin (bah-koo-dawn-jeen), we were looking for a project that we could realistically finish within three months. Our previous title had died due to lack of interest and an incredibly long development cycle with little game play to show for it. Bakudanjin was supposed to be a summer project while school was out; something we could knock out quickly and easily. The game was based on an admittedly unoriginal concept. The game borrows much of its game play from Hudson Softs classic Bomberman. In fact, the name Bakudanjin is rather mangled Japanese literally meaning (the) people of bomb. However, we felt that our previous project had failed because of a lack of focused design, and by basing our game play off of an proven game mechanic, we hoped to avoid making the same mistake twice.
We kept our development pipeline simple. While I wrote the game code with CodeWarrior, our artists Genki and Sean created the games original graphics. Genki did most of the character animation, and his primary tool was the old Mac program, Aldus Superpaint. We utilized Superpaint over more complex editors like Photoshop mostly for its palette manipulation and painting tools. Sean, who created most of the level art, also used Superpaint almost exclusively. Andrew, our musician, built us several tracks using the PC programs CakewalkPro Audio 8 and CoolEdit, along with the arsenal of samplers and keyboards he keeps in his studio. Most of the game code was written on a PowerComputing 225 PowerTower Pro, while the art was done using Apples 7600 range machines and Wacom art tablets. While we were familiar with various third-party sprite systems available on the market (SAT, SpriteWorld, etc), we decided to build our own animation and map systems. We built the map editor into the application, and this unity allowed us to include the tool with the final version of the product. When we began development, Apples Game Sprocket technology was still in its infancy, so we elected to write our input and drawing systems ourselves. This actually turned out to be a good solution in the long run, as we were able to tune our game to run as fast as possible.
Things What Went Right
1. Realistic goals
From the beginning, we had our sights set on our desired features and their estimated development time. Though Bakudanjin ended up taking almost two years to complete, this was mostly because of school and other interruptions. Looking back on the work we put into the project, I think we could have realistically finished in under six months if we had been able to devote more time to development. Our focus on design saved us several times from feature creep. We did add a few extra game modes and game play devices along the way, but we quickly discarded many ideas that seemed too difficult or time consuming.
2. First playable finished early
When we began developing Bakudanjin, we concentrated on the core game engine features first. As a result, we had a first playable build after only two weeks of development! In this time not only had the animation engine come together, two character sprites, some basic level tiles, and an enemy were completed as well. Being able to test our game out this early in the development cycle was invaluable; we were able to identify design problems and control issues almost immediately. Building an early prototype also forced us to build a level editor, which also turned out to be extremely beneficial.
3. Level design as a puzzle
Though Bakudanjin is all about blowing up the enemies, we built each world such that puzzles could be constructed out of the levels themselves. We also added three different playable characters, each with his own attributes. We tried very hard to design levels that would be easy for some characters and hard for others, thus creating different experience for each playable character. For example, the Soldier character, who is the fastest character in the game, has the ability to avoid quicksand. However, this ability is only useful in the first game world, making later levels more difficult.
4. Targeting low-end machines
When we began Bakudanjin in 1997, we decided that our game should run on even the lowest of low-end Macs. We used my old Centris 660av, a 25mhz 68040 machine, as the most basic system that needed to be able to run our game at 30 fps. Though this required a lot of optimization of the drawing code late in development, we were able to attain our goal. As a result, our game can be enjoyed by a much larger audience than many other titles, and it drove us to write clean and efficient code. Though 68k support is much less of an issue today, I am still quite glad we made the decision to support lower-end machines. Bakudanjin was developed before Apple released CarbonLib and the Carbon Dater program, and is consequently not OS X compliant. However, converting the code base to Carbon would be fairly easy, and we are considering a patch to make Bakudanjin OS X native.
5. Multilingual support
Though it was rather last minute, we decided to include support for Japanese as well as English for the Bakudanjin user interface. Our goal was to make our game as accessible as possible, and we knew that a lot of gamers in Japan might be interested in our title. While support for Japanese did not extend past a few translated menus and dialog boxes, we did translate the entire manual, and saw several Japanese registrations as a direct result. Surprisingly, more than half of all our registrations to date have been from Europe, and in our next title we will definitely include some kind of support for European languages.
Things What Went Wrong
1. Writing games in our free time
Bakudanjin was developed while we were all in school, and as a result took an incredibly long time to finish. This was particularly frustrating because we had a playable game from the very start of the project. However, we realized that if we did not meet our design goals the game would not be nearly as fun, so we continued to work in our spare time. Hobby programming is quite a challenge when free time is scarce, and in our case our development time suffered immensely.
2. Unclear distribution goals
We originally decided to press Bakudanjin on CD and sell it via our web site, and some of our initial design decisions were based on this plan. Our musician built five awesome tracks for our game from scratch, and delivered them to us as 40~50MB WAV files. I wrote audio CD player code with the full intention of burning CDs with the music as audio tracks. However, it became clear towards the end of development that a CD would not be feasible. As a result, we were stuck with five high quality musical tracks that took up one hundred times more disk space than the actual game. We considered compression techniques such as MP3, but our low-end target platform was too slow to decode and play such formats on the fly. In the end, we decided to distribute via the web and were forced to use only 10 seconds from the main theme.
3. Being a clone
Though we learned a lot and produced a great game, Bakudanjin will forever be thought of as a Bomberman clone. Borrowing a simple mechanic has been done before, and we were hardly the first to be inspired by Hudsons great game. However, many doors were closed to us because our game too closely resembled other titles out there. One magazine even refused to run a short segment about us, siting recent problems providing software that had similarities to programs currently available on the market. Though we believe that Bakudanjin is an original work, we found that Bakudanjins concept was not unique enough to break out of clone status.
If you are a developer thinking of building a game based on an established game play mechanic or look, be aware that your games sales may suffer because customers will not consider your product original enough. On the other hand, it is much harder to create a fun game design from scratch than it is to borrow features from established titles, and there is a market for new versions of old games. Witness Ambrosia; the majority of their titles are not based on original game play designs. Nevertheless, they continue to produce high quality games and generate lots of revenue. In Bakudanjin, we attempted to balance classic Bomberman game play with original characters and game play modes we added. I think we were fairly successful, though in hindsight there are several things we could have done better.
All in all, developing Bakudanjin was a great experience. Though not everything worked out as we had planned, we all learned an incredible amount by building the game from scratch. We have been selling Bakudanjin for almost two years now, and have been successful with a wide audience of men and women of all ages. One customers comment in particular made the entire experience worth all the time and effort we put into it, and reminded me why I got into game programming to begin with: My boys will be very excited! They love the game and we are constantly greeting each other with the noises that are derived from the game. In our next project, an as-yet-unannounced adventure RPG, we hope to avoid some of the challenges we faced with Bakudanjin by focusing on design and the strengths of our previous projects. Our next game uses a top scrolling tile engine and a highly customizable sprite interaction system, and we hope to release our tools with the game. It is our goal to continue to produce games that are fun and appealing to people from all walks of life.
||Game: Bakudanjin (1.5 MB)
Developer: Dream Dawn
Team size: 4
Released date: October 1999
Project length: Two Years
Critical applications: CodeWarrior 9 Gold, Aldus Superpaint, Photoshop, Cakewalk 8, SoundEdit 16