by Howard Wen
Tank Blasting Online for 10 Years and Counting
Those who were around during the arcade gaming scene of the early 80s may recall Atari's Battlezone, a first-person tank shoot-'em-up that rendered the game field and enemy tanks in wire-frame vector graphics. BZFlag is its cranked-up successor. Whereas the Atari classic was a single-player contest, BZFlag allows multiple, networked players to drive tanks across a battlefield littered with obstacles and blast away at each other.
The eponymous flags appear throughout the environment. By running over them, a player's tank can acquire a new advantage over others for a few moments: increased speed, the ability to jump, and more destructive firepower — to name just a few (there are a lot of tank upgrades available in this game). Other flags, however, can hobble the player's tank: for example, making it larger so it's an easier target to hit, disabling the tank's radar system, or slowing its speed. This game play — tanks hunting and firing at each other, while snatching flags — gets intense and addictive.
BZFlag's 3D graphics are relatively simple (a visual aesthetic perhaps the next step up from the computer graphic settings of the movie Tron) but showcase a clean, unpretentious design while including some dynamic lighting effects. The game uses OpenGL, and, thus, has been ported to several platforms over the years, including Linux, Windows, Mac OS X, Solaris, Irix, and FreeBSD. Its source code is released under the GNU Lesser General Public License.
Figure 1. Dimmed gamefield lights show off dynamic lighting effects
From 3D Demo to Game
BZFlag dates back to 1993, when its creator, Chris Schoeneman, was a graduate student at Cornell's computer graphics program. Today, the 34-year-old works for Pixar in Emeryville, California. During his time at Cornell, Schoeneman found it surprising that "few of the students wrote interactive 2D/3D graphics tools, even though such tools would've assisted development of their algorithms. Another grad student and I decided that the primary reason was the difficulty of writing such tools, given the software libraries available to them. We set out to address that by wrapping the existing libraries in a more programmer-friendly library."
This particular library, called WM, was heavily based on SGI's IrisGL. To convince his fellow students to use it, Schoeneman wrote small demo programs to show how easy it was to create an interactive 2D/3D tool. One such tool allowed the user to spin a 3D model with a mouse.
Another demo became the precursor to BZFlag, allowing the user to move throughout a simple 3D-graphic environment. Schoeneman never finished this demo, but another Cornell student suggested that he turn it into a game. So he added tank models for the player to control, incorporated code where the tanks could be made to shoot one another on a LAN, and named the result BZ.
Figure 2. The point, of course, is combat
Unsurprisingly, playing games was a popular activity at the Cornell computer graphics lab. BZ quickly grew beyond its simple game play. "We added team bases and flags, and named the new capture-the-flag-style game BZFlag," says Schoeneman. And when the Cornell students got bored of these features, he invented the concept of "superflags" (the flags that grant the player's tank special abilities, or cripples it). Originally, there were only four kinds of superflags. Then other students added several more varieties. "We even had a white board dedicated to a list of potential superflag additions," recalls Schoeneman. "That was around mid-1993, and the BZFlag game play has remained substantially the same ever since."
An Ever-Evolving Network
The original BZFlag code was written in C for HP-UX workstations. It used WM, which ran on top of X11 and HP's proprietary graphics library, Starbase. The modern-day version of BZFlag was rewritten in C++, using OpenGL, for the SGI platform. Later, it was ported to Linux and Windows.
During its Cornell years, choosing the best networking model for BZFlag was a challenge. Schoeneman experimented with the peer-to-peer method, which initially worked well — there were no shared resources to manage, since each player tracked his own position and tank shots. But when the flags were added to the game play, each peer had to compete with other peers for scarce system resources. Several possibilities were considered, and a modified solution combining peer-to-peer with the client-server model was put in place. "That was split into a client-server model, for operations that the server had to know about or mediate, and a peer-to-peer model, for things that the server didn't need to know, mainly the player position updates, which made up the bulk of the network bandwidth," explains Schoeneman.
This split client-server/peer-to-peer model had to be abandoned, because the peer-to-peer data used multicasting, and the present-day Internet doesn't have the infrastructure to support this just yet. "That's a shame," says Schoeneman, "since it greatly reduces the required bandwidth."
BZFlag was originally designed to be played on a LAN. When the code was updated to take on real-time Internet play, it wasn't entirely ready for it. Latency remains a serious problem, and the game is vulnerable to cheating, which is widespread on BZFlag servers.
"BZFlag was designed for a trusted LAN environment. Playing over the Internet is quite different and cheating has always plagued the game. Much effort has been spent lately to do server-side cheat protection, and we have made significant headway," says Schoeneman. "We plan to do some larger protocol changes soon that will break the long-standing backwards compatibility. The primary reason for those changes is to reduce cheating."
Longevity and Relevance
One upcoming anti-cheating mechanism is a community karma system to encourage good behavior. While stopping cheating and fixing network lag are high priorities, Schoeneman hints at the possibility of new features that would enhance game play: a split-screen view to show multiple local players on screen, improved AI for the robot-controlled tanks to make off-network play more challenging, and support for large game maps.
The developers plan to release version 1.10.x in the near future. This release will not be compatible with existing versions. In trade, it will feature improved networking, more configurability, and much-improved bot AI, along with bug fixes and new flags. The BZFlag Changelog has more details.
While BZFlag has been around for over 10 years, the development and online gaming scene for it still remain strong. It's a level of relevance that most commercially produced games cannot maintain. "It's a fun game, easy to get started on, but with a lot of unexpected depth," Schoeneman reflects on the longevity of his college creation from many years ago. "That's what keeps the players playing. Volunteer developers tend to be players. Otherwise, they wouldn't be volunteering, and a primary motivation for improving the game is to have more fun playing it."
The Developers Speak
While Chris Schoeneman remains the creator of BZFlag, Tim Riker, a 40-year-old software developer in Allen, Texas is the present maintainer of BZFlag. Back when he worked for Caldera, he packaged BZFlag for the OpenLinux distro. Both developers recently agreed to an interview with the O'Reilly Network.
O'Reilly Network: Cheating has been a persistent problem with BZFlag. So, in order to prevent cheating, what are the technical things that you would advise every programmer who's developing a networked game to keep in mind? What are the dos and don'ts?
Tim Riker: Hiding things is an option for non-free games. If you go that route, there are a lot more options.
For an open source game, the server should make any important decisions, and ensure that every message the client sends is valid. A useful paper on some aspects of this was just handed to me.
With BZFlag, I would like to see a karma system that allows the players to rank each other with a trust value, and then have the karma server calculate a "community aggregate trust value." Then a server admin can set server permissions based on this rank. This would use a system similar to the Advogato project.
Chris Schoeneman: People cheat, especially when they are, or believe themselves to be, anonymous. And some people will go through a lot of trouble to cheat. So a networked game should attack cheating a number of ways.
Start by defining what cheating is: it's not following the rules. These violations are detected by some agent: an administrator, a player, a client, or the server. An administrator, who can kick off cheaters, can deal with cheating, but administrators typically can't monitor the game 24/7. Players and clients are powerless to do anything about a violation, unless they have administrator privileges, either individually — in which case, they're administrators — or collectively. Collective schemes usually involve voting and are susceptible to vote rigging, which is another form of cheating.
That leaves the server to detect cheating. All clients are suspect. No client can get more information than it needs to present the state of the game world to its player. The client cannot be trusted to only ask for what it needs. The client cannot be trusted to only do what the rules say it can. Therefore, the server must determine what information the client needs and what actions the client can take. The client is reduced to indicating what actions it wants to do and reacting to permission or denial from the server.
Obviously, illegal actions clearly indicate cheating. Actions at the limit of legality may indicate cheating. Sometimes network lag makes it difficult to be certain an action is, or is not, legal, so some tolerance is called for. Perfect play is another indication of cheating, even if it's within the rules, because it typically means computer-assisted play [via] bots. Since bots can be programmed to make mistakes, detecting them can be hard. Make the cheat detector flexible, so new bots can be handled.
Another approach to prevent cheating is to make it less worthwhile for the cheater. One possibility is to require players to sign up for cryptographically secure credentials. Players must use those credentials to play, and if that player is caught cheating by a server or administrator, those credentials are forever banned. The issue then is to prevent cheaters from acquiring as many credentials as they want. Unfortunately, that's a difficult problem, too. A side benefit of credentials is that players cannot masquerade as other players or steal their screen names.
ORN: What makes a good networked game, as opposed to a bad one?
TR: Network games are popular because, in general, people have similar abilities to one another. AI players strive to get close to this same level, but another human has the ability by default.
It is important to keep this level. Different hardware and network bandwidth make this a challenge. BZFlag has done well with this because the game play is so simple that hardware and bandwidth do not have an overwhelming impact.
CS: Playability makes a game good, whether it's a networked game or not. If it's not fun and playable without fancy graphics and sound, it's unlikely to be much better with them. Playing against other people can potentially turn a mildly entertaining game into something much better, but only if interacting with other players adds something to the game play, either directly or by fostering community.
Networked games are automatically more interesting when players can communicate via text or voice, because talking is a compelling activity. All network games should allow player communication. Private channels make it easy for collaboration and conspiracy, themselves interesting activities. But don't forget to allow players to block messages from all players, particular players, or all but particular players. Sometimes little kids play these games, [so] parents want to filter foul language. That's easiest to do by blocking all incoming messages.
ORN: What sorts of contributions to BZFlag from outsiders willing to volunteer their skills would be appreciated?
CS: Artwork. Just because good graphics don't make a good game doesn't mean a good game should have bad graphics.
Figure 3. The graphics are simple but effective
TR: Patches are always welcome. Network improvements, cheat protection, and the karma system are my top priorities, but anything that improves the game is more than welcome. The current i18n support is ASCII-only and needs a new font renderer in the client. This would allow true Unicode support in the client. I'd really like to see that added.
I agree with Chris that better artwork would be nice. The current HUD removes all of the images but we are working on a new HUD interface that might get added soon.
ORN: What advice do you have for those who might want to modify the BZFlag code to help improve it or create new games (or applications) with it? Or advice in developing online multiplayer games under the free software format?
CS: There are great tools and libraries out there for building a game; use them. Don't reinvent the wheel, and you'll have a lot more time for writing the parts unique to your game and tuning it for the best game play. BZFlag does not teach that lesson, but then it's over 10 years old and predates much of the aforementioned tools and libraries. BZFlag is also not very well suited for making new games.
TR: I think the BZFlag engine is not the best choice to start with for other games today. I'd encourage looking around at other game engines. BZFlag's strength is simple game play and cross-platform support. I plan to keep it that way as long as I'm the maintainer.
ORN: For you as a programmer, or game designer, what have been some of the lessons you've personally learned as you worked on BZFlag?
CS: The original version of BZFlag, nee BZ, was unplayable. Some game parameters, especially the size of the playing field and the speed of shots, had to be changed significantly. After a whole lot of play testing, we had the game tweaked just right, with a balance between offensive and defensive actions. When we added new flag types, we always made game balance a primary concern.
Other Gaming Articles by Howard Wen
GBA Programming with DevKit Advance -- Emulation has opened up game programming to realms of hobbyists. While it's possible to build amazing games on all sorts of obsolete platforms, it's also possible to build them on modern ones, including the GameBoy Advance. Howard Wen explores DevKit Advance and interviews its lead developers.
NeL: The Software Behind the Next Great MMORPG? -- Several people have theorized that the best mix of open source and gaming is to release the engine's source code while keeping the art, levels, and music restricted. Nevrax is doing just that with their upcoming Ryzom game. NeL, the engine code, is an actively-developed open source project. Howard Wen examines the company and the project and talks with a founder and a lead developer.
Inside ScummVM: Classic Adventure Engine Overhaul -- The short list of quintessential adventure games includes several picks from LucasArts' stable. While the genre might be fading, the ScummVM project is reviving classic games such as the Maniac Mansion and Monkey Island series. Howard Wen interviews the developers behind the ScummVM project.
On the other hand, cool graphics was always a side show, generally unimportant, though often fun to code. That's a lesson many game designers learn the hard way, if they learn it at all: if a game's no fun without fancy graphics, then no amount of fancy graphics is going to make it fun.
Another lesson is the sad one that given the opportunity to cheat or otherwise spoil another person's good time anonymously, a lot of people will answer the call.
TR: It's the largest open source project I lead. I do contribute to many others. Leading a project often means making public decisions that are not popular with everybody. I've learned to be tactful. I've learned the benefits of encouraging outside involvement and steering the direction as it progresses, rather than mandating things at the start.
ORN: Do you still play the game today? Are you pretty good at it? And any game-playing tips?
TR: I do still play, but not as often as I'd like. I can hold my own, but I'm nowhere near the top.
CS: I do. I like to think I'm pretty good. If I focus, I usually have a positive score even on the servers with the tough players. I don't like to camp, so I don't normally get huge positive scores. For tips, I suggest that players focus on learning how to dodge bullets.
Return to the Linux DevCenter.