Doug Kavendek - Portfolio

Bumfight

Bumfight
Title Bumfight 2
Started Spring 2005
Status Ongoing
Platforms Windows, Unix, others
Created For Personal
Executable v0.00.11 (Win32) (4.1 MB)
09.pngMy ridiculous menu, trash can test, blood, and rising lava. Yes, Fight is spelled wrong

Technically, this is the sequel to the first Bumfight (Source, EXE), made in QBASIC a while back, which was turn-based, looked awful, but was actually somewhat fun. To be honest, that game was created on a whim after finding the site Bumfights, and my friends and I were amused by some of the images displayed there. We never actually watched the videos which are offered, because the actual fighting seemed more exploitative than amusing, and so the games we have made with a similar name (note the lack of an 's' in the game title) are not affiliated, or even really based off of the videos.

For the first game, my friend Michael Yawn and I came up with the rules and idea, and I made it in a whirlwind of coding. More recently, we realized that I had a bit more graphical coding and real-time interface experience, and so decided to create a real-time side-scrolling version. We dove into this, with Michael creating some great sprites while I created a basic platformer engine. Almost everything was made from scratch, from the sprite rendering to the physics, because I felt it would be good experience. There are countless 2D game engines out there, but I wanted to really see how it all worked myself.

11.pngThis game isn't for everyone

It turned out that I did not quite know what I was doing in the physics department. We wanted to make the game have a networked multiplayer, but I soon found that my physics code was just not running consistently on different computers. This stalled our work for quite a while, while I tried in vain to come up with a home-brewed solution. However, after finding this article, I was able to resolve the issue, while realizing there was a lot more to physics simulations than I had originally thought.

After getting past the physics, the game really took off. My friend Robert Yawn started helping out, and with him we made the code multi-platform by using SDL for many of the system calls. I created my own font engine, animation controller, input handler (with programmable bindings and joystick support), weather effects, and even a binning system similar to the one used in my flocking simulator in order to deal with inter-projectile collisions more efficiently. I also implemented a console and basic menu system, along with a simple single-computer hot-seat multiplayer mode using splitscreening.

08.pngNifty water effects

Although the game looks fairly low resolution, it actually is running at around 1024x768, and is just refusing to linearly filter any of the images, so they retain their pixel structure. This gives me the added ability of creating a higher resolution overlay system, without sacrificing the look of the game. Also, when splitscreening, players will be able to increase the virtual resolution of their viewports, so that they will still be able to see as much as they normally would, which is a slight sacrifice of the feel of the game in favor of better playability.

Currently, this game is still in production. We have finalized the feature-base, and all that remains is implementing our design -- not really a small task. At the time of this writing though, most of the major features have been implemented, and so to simplify our current goals, we have to iron out a large number of issues, finish creating the content such as player sprites, backgrounds, and sounds, implement the networking code, and create a simple map editor. A major hurdle right now is that I have come up with much better ways to do everything, and so feel extremely limited by the framework I have already made. If further development is to continue, I will have to rewrite quite a few of the modules, because they are currently held together with the programming equivalent of spit and chewing gum. I plan to integrate the new interface framework with this existing code to make things easier.


04.pngThe game can handle lots of projectiles
02.pngWater, weather, and lots of debris
06.pngTwice the gore when splitscreened
05.pngSpinning objects and rudimentary rain.
13.pngThe dangers of spikes
07.pngTesting projectile trails with the Mario fireball