Project of the Month, June 2003

MegaMek

The SourceForge.net team loves games. Our favorites are online, net-based games that offer the ability to battle friends and foes from all over from world. SourceForge.net's June project of the month, MegaMek, is a Java based networkable game for 2 or more players. It's a strategic game that features brains over fast reflexes. The Software, licensed under the GPL, has enjoyed a position in the top 25 SF.net most active projects since it's founding in February 2002. With new features being added daily, MegaMek is a project to keep an eye on.

Project Name: MegaMek
Founded / Started:
It was started around February of 2001. The first release on SourceForge.net, under the GPL was a year later, on 02-18-02.

URL: http://megamek.sourceforge.net
Project page: http://sourceforge.net/projects/megamek/

Description of project
MegaMek is an unofficial, online version of the Classic BattleTech board game. The BattleTech board game is a hex-based war-game, involving 30-foot-tall humanoid robots firing at each other with dozens of different weapons.

Trove info:
Multiplatform Java game

How did you get started?
I was talking over instant messenger with some of my old gaming buddies who no longer live around me, and we got around to discussing how nice it would be to play some of our favorite games together online. I decided to start up a little project that would let us to play Battletech against each other. I worked on it for about a year, on and off, before uploading it to SourceForge.net. There, over the course of a few months, it really took off.

What is the intended audience?
Our audience is the niche market of tabletop BattleTech players. It turns out that MegaMek has converted some non-players into fans.

What does MegaMek do?
MegaMek is a program that allows players of the BattleTech board game to play their game across the Internet. There have been several similar attempts to make BattleTech computer-friendly in the past, from 'hotseat' Amiga to dice bots in IRC to WebRPG. This is the most successful of which I am aware, since it combines Internet interfacing with automated rules checking and status tracking under a single program and GUI.

What makes MegaMek unique?
There have been several similar attempts in the past to make BattleTech computer-friendly, from 'hot seat' [where players take turns at the computer] Amiga play to dice bots in IRC to WebRPG. However, this is the most successful adaptation I am aware of, since it combines Internet play with automated rules-checking and status tracking in a single program.

How many people do you believe are using your software?
It's getting harder to track individual users now that we do weekly development builds, but one of the releases last year had just over 10,000 downloads. These days, the weekly development builds get 400-500 downloads.

Do you need anything special to play?
The code is written in Java and is targeted to run on Sun's JRE 1.1. If you have a Linux, Unix, or Mac OS X machine and a compatible JRE, grab the jar file and go. If you use Windows, make sure to install Microsoft's Java VM and the MegaMek executable. That's it.

What gave you an indication that your project was becoming successful?
The initial trickle of emails, either with bug reports, or just saying "this is so cool," that followed the first public release.

What has been your biggest surprise?
The amount of response from other fans. The SourceForge.net site does a great job of providing utilities for interface between developers and users. Users have provided vast amounts of feedback in bug reports, feature requests, and forums.

What has been your biggest challenge?
Trying to stay caught up under the steady stream of bug reports and feature requests. That's something that would completely impossible without the great tracking system supplied by SourceForge.net.

What are you most proud of?
I'm proud to have seen this project grow, and to see it receive the level of attention it has.

Why do you think your project has been so well received?
I think a lot of people have wanted a project like this for a long time, and regardless of its other merits, it's the project around that's at the level that it is. That said, we've done our best to make it easy and fun to play, and I think that's paid off.

Where do you see your project going?
Right now, we are trying to finish up implementing all the game rules in the master rulebook. That's the goal we've been working on for the project's lifetime so far. Past that, my ideas get a little hazier. I think I would like to work on better integration with the pen-and-paper board game. It would be nice to allow players to move fairly seamlessly from paper to online and back over the course of their campaigns.

How can others contribute?
The simplest (and perhaps the most enjoyable) is just to play the game! If, while you're playing, you come across something that doesn't agree with the official rules, or if you have a suggestion for improving the way the game does things, or even if you have something new that you'd like to see, post it on the SourceForge.net site. We have separate trackers for Bugs and Feature Requests. If you can code, or have artistic talents, or can write, there's something for you to do! In a nutshell, we're open to any contributions people have to offer. Code patches are accepted through the SourceForge.net tracker system, and any documentation or art could go through there as well. Good bug reports are also extremely helpful.

Do you work on the Open Source project full-time, or do you have another job?
We all still have other jobs.

If you work on the Open Source code part-time, how much time would you say you spend, per week, on the project?
Ben:
Between five and twenty hours per week

James:
I spend 4-6 hours a week

Helge:
Around ten to fifteen hours per week

Derek:
I spend an average of five hours per week

How do you coordinate the project? Make assignments? Assign bugs? Perform regression testing?
At the present, everything depends on the developers being proactive, assigning themselves bugs and submitting patches. We have occasional "what I'd like to work on" threads in the developers forums to get an idea of each other's schedules. As for testing, we could use some improvement in that area. Many patches go through with only light review, and testing is left to the users of the weekly development builds. Luckily, they're a fairly forgiving bunch. For those that don't want to be our guinea pigs, we provide stable releases every few months.

What is your development environment like?
Ben:
I have an aging 800 MHz PC. I'm using the Sun Java SDK to compile and package the code. During the course of the project, I've gone through a number of IDEs and debuggers. Right now I'm using Sun's Forte for Java, but I'm not completely happy with that, so you could say that I'm still looking.

James:
My own personal computer is an old Gateway Pentium Pro 200 that's running Red Hat v5.1. I've installed Sun's JDK v1.3.1, but MegaMek is targeted at a v1.1 JRE, so I don't use most of the environment's best features (like Collections or Swing components). I'm an emacs man myself (no flames, please), and debugging is a matter of adding System.err.println statements and playing the game.

Derek:
I tend to use the old-fashioned method: I make changes using a text editor and use the normal runtime environment to debug my changes. My primary machine is getting a little out of date at only 600 MHz and 128 MB of RAM, but I will probably keep it around for compatibility testing when I upgrade.

Helge:
Win2K, 2000+ Athlon, 512MB RAM, JBuilder 7.

If you could change one thing about the project, what would it be?
Ben:
To tell the truth, when I started the project, I just sat down and began programming, designing only for features I could see myself implementing in the near term. Now that the project has implemented all of those first features and is expanding, some parts of the design are still holding up, while it's been necessary to revise others. To give an example, when the project first started, it was only possible to target other units on the battlefield. Now, as we add some of the more complex optional rules, such as starting fires or artillery strikes, we've had to revise the definition of what is "targettable" to include points on the battlefield as well. So, if I were to do one thing differently, I'd consider every optional rule and even some of the unofficial rules when creating my initial design.

James:
I'd get the project funded through a private grant so I could quit my day job and work on MegaMek full time. [Grins.]

Derek:
I would make a replay system to allow detailed visual analysis of past games using the game log file. I doubt many people would use it other than myself, and it would hurt the "the fish was *this* big" stories if people had to prove them.

What's on your project wish list?
Right now, we are in sight of having all of the rules in the master rulebook implemented. That, above other things, has been the light on the horizon for me, and the thing I want most for the project.

Milestones

  • Full implementation of the "Level 1" or basic BattleTech rules for BattleMechs.
  • Added an AI bot to support solo play.
  • Added ability to create and load scenarios.
  • Implementation of Tanks.
  • Implementation of Infantry and Battle Armor squads.
  • Added ability to save and load units (and track ammo use and damage).
  • Added ability to save the game at any time.

More projects of the month


Project Name: MegaMek

Background of leader:

Name: Ben MazurBen Mazur
Occupation: Freelance web developer and graphic designer
Location: Toledo, Ohio (USA)

Background of key developers:

James Damour

Age: 33
Occupation: IT consultant
Education: BS Mathematics, Rensselaer Polytechnic Institute
Location: Albany, New York (USA)

Name: Helge RichterHelge Richter
Age: 24
Occupation: Student
Location: Lindenfels, Germany

L. Derek Evans
Occupation: RF Test Engineer

Why did you place the project on SF.net?
Well you can't beat the price-feature ratio. But seriously, I think the community of open source developers on SF is fantastic.

How has SF.net helped you?
Ben:
The triumvirate of hosting/CVS/bug tracking is completely indispensable. It's also terrific to get the kind of visibility, and to so virtually "close" to so many other great open source projects.

James:
The shared code repository that can be accessed by a web browser, the bug and request trackers, and the forums have all be extremely helpful in coordinating the project and communicating with the players. If SourceForge.net didn't already exist, we'd have to invent it. I believe that it has become an indispensable resource for the Open Source Software community.

Derek:
SourceForge.net has provided extremely useful tools for developer-user interface. It is very easy for users to provide suggestions, fixes, bug reports, and general feedback. These tools have allowed most of the current developers to cross over from being users.

What is the number one benefit of SF.net to your project?
The tracking system. I'm not a naturally organized person, so without the tracking system, 50-80% of the bug reports, feature requests and patches would get lost in my email.