Background

"Wsoft Bomberman" (wbomb) was a simple 2D clone of the Super Bomberman games on SNES. The goals behind this game was to create a solid game engine that could be used for other 2D tile based games, and to help game development beginners to get a handle for things. We would then add network support and possibly AI controlled bombermen.

The games final build is available here: http://www-personal.umich.edu/~dratti/WBombFinal.zip

If you decide to muck around with the source code, or are interested in seeing how objects are handled, a small tutorial is available here: http://wsoftbomberman.sourceforge.net/Part1.html

What went right

Solid OO game framework

I still believe the code for wbomb was well designed and thought-out (except for AI and networking: see below). It was flexible, clear, and worked well. New Game Objects could be created almost effortlessly. Collision detection, AI, and rendering were all done behind the scenes. The game's logic was defined by individual objects behavior. You could essentially change the entire game just by creating some new objects and giving them slightly different behavior.

Cool music

The music for wbomb was really catchy =) Thanks Nate.

What went wrong

Overwhelming

Although the code itself is straightforward and easy to read, the project was still overwhelming to most beginners. Goings from an EECS project with half a dozen project files, to over 50 .cpp/.h files including windows code and directX stuff seemed to be too overwhelming. Even with tutorials and examples, it was still very hard to get a feel for how this whole thing came together; which was one of the goals of the entire project.

There was also a lot of people on the bomberman team. Many were beginners wanting to learn. Trying to assign "jobs" to them all was probably a mistake. If I was to lead this project all over again, I would introduce each part of the project separately from scratch, with detailed explanations of how things worked. This would give beginners a better feel for what everything does, even if they don't know exactly how it all works.

Network play

Network play was simply postponed to the end. We had a vague plan for how it would fit it, but now looking back I realize network code should have been built in from the start.

AI

We lacked proper data structures for doing AI. We needed a better way to represent the world as a whole, so that a computer controlled unit could easily view the "whole picture". Issuing commands to AI players was trivial, but making them behave according to every object on the screen (bombs, other players, power ups, blocks, etc) proved to be difficult to be done in real-time with our framework.

The Autolists Design Pattern found in Game Programming Gems 3 would have been very helpful in this case. Being able to quickly fetch a list of all bomb objects, all powerup objects, etc would have solved the majority of these problems. Another Data structure to represent a snapshot of the game world's tiles move ability would have been trivial to implement and would have made the AI much easier to write.

Conclusion

Bomberman was still a very fun game to write. I met some really cool people through it, and even though its not that impressive to see in action (besides music of course) I'd still say it turned out well. Hopefully a few people learned a few tricks or gained a slightly better grasp on game development.

Note: views and opinions expressed in this article are the author's and are not necessarily those of Wolverine Soft.