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.