Strategic Introductions: Web Games

by Shannon Appelcline

January 23, 2003 — For three weeks now I've been overviewing strategy games: looking at how they differ from RPGs; what types of components they have; and what types of gameplay they feature.

However, as has always been the case, the purpose of this column is to bridge the old and the new — to see how lessons learned in traditional mediums can help us in the design of online games. The obvious online cousin to the tabletop strategy game is the web strategy game, and that's what I'm going to be specifically discussing this week. I hope to offer a good explanation of what a web game is, to look a bit at its history, and finally to provide some solid insight into how web games are built.

Defining Web Games

Defining a web game is pretty easy: a web game is an online game played through your web browser. Technically, that means it's built in HTML, though it probably takes advantage of various web-related dynamic languages, such as Perl, PHP, Java, JavaScript, and ActiveX.

Technically, all of the current Skotos games are web games. You go online to play them, access them from the browser, and various dynamic screens are popped up within HTML envelopes. Yahoo!s games, which include Hearts, Poker, and lots of other fairly traditional card games are web games too. Some web games are single player, while others are multiplayer. Some are puzzles, others are traditional gambling, and others are "adventure" games, often similar in flavor to the old choose-your-own-adventure game books.

Though some of what I say this week will apply to all of those genres within the web game medium I'm going to concentrate on one genre specifically: the multiplayer strategy game genre within the web game medium. This can include space combat games like Skotos' own Galactic Emperor: Hegemony. It can include fairly traditional war games where you're moving lots of units around a board made of tiles or hexes, like some of the online Risk games floating around. It can include fairly abstract resource management and conflict games like Archmage. It can even include tamaguchi-like pet games which seem to center around raising up various pets or monsters.

And, theoretically, it can encompass all of the types of gameplay that I discussed last week, in Designing Strategy: The Gameplay. Multiplayer strategic web games are a genre that is as big as its tabletop brethren.

The History of Web Games

Web games have developed, I believe, via two branches of game design: play by mail games and early online games.

Play by mail games came first. They started appearing... some time ago... in the guise of chess games that were played via the post. It was a pretty primitive start, with each player having a copy of the board, and making one move at a time. Games could take months or years. Other tabletop strategy games were also adopted to the play by mail medium, the best known among them being Diplomacy. But it was always a case of trying to fit square pegs into round holes — straight adaptations from one medium to another rarely work that well.

1970 was when original play-by-mail games started to appear. Flying Buffalo, one of the few companies still managing PBMs, was in there from the start with "Nuclear Destruction", a simple war game. Rick Loomis, the founder of Flying Buffalo, likes to use the slogan "We Created the Play by Mail industry", because he was the first to actually start maintaining and moderating PBMs as a full-time job (in 1972).

PBMs offered some nice advantages over traditional tabletop games:

• You could play even if you didn't have enough local players.
• You could potentially have 100s of players in a game.
• You could use a computer for moderation.

Rick caught onto the last fact pretty quickly. 25 years before web games, in 1970, he was already renting computer time to resolve turns. Around 1972 he bought his own Raytheon 704 computer, perhaps the first computer purchased exclusively for game usage.

With the advent of original PBM games being produced by professional companies, you suddenly had people taking advantage of the particular strengths and weaknesses of the medium — including figuring out how to get dozens or hundreds of people involved in a game when they were all geographically and chronologically separated.

In the years since 1970, PBM has both grown and waned. Flying Buffalo came out with their popular Starweb PBM in the mid 1970s, a game that is still running today. I remember many, many ads for a Lord of the Rings PBM in the mid 1980s. Many other companies have moved into the PBM industry, some successfully, some not. In addition, as PBM games have evolved they've moved from simple text in the 1970s to simple dot-matrix graphics in the 1980s to fully graphical laser-printed turns in the 1990s.

Since the breakout of the Internet in the mid 1990s, many people have used the web for PBM games (calling them PBeMs). Only a few PBeMs are as sophisticated as the original PBM games, and generally I find them to be yet another example of not using the strengths of a medium... because the strength of the web is clearly some level of real-time interaction, combined with some graphical UI — both things missing from PBeMs.

At the same time as the PBMs were growing and changing in the 1980s and 1990s, a global Internet was slowing coming into being. It was originally hosted primarily by educational facilities, and thus it's not too surprising that from the start the Internet included games, many of them multiplayer.

I played lots of them when I was in college from 1989 to 1993. Netrek was a fun space combat game where you faced off with 15 opponents in tournaments to rule the galaxy. Griljor, a game that never really caught my attention, allowed you to bop around a user-generated map and blow up other players with any number of silly weapons. Xconq was a simple, brightly colored war game of conquest. Over in the commercial world you had games like Compuserve's Air Warrior, a game of flying and teamwork, and their MegaWars, an economic and space combat game which ran from 1983 to 1998.

But, none of these really fired up the attention of thousands of engineers (as opposed to players) in the way that web games have. In fact, I'd say that only two types of games from before the web era every really made it out there to be hacked on by hundreds of programmers in hundreds of venues: MUDs and rogue-like games.

MUDs have, of course, been a constant topic in this column. They're text-based multiplayer roleplaying games, either centering on achievement (traditional MUDs) or socialization (traditional MUSHes). There are hundreds or thousands of MUDs and MUSHes, including three at Skotos.

Rogue-like games are mostly single-player dungeon crawl games. There are a few multiplayer variants nowadays, and in some games you have the opportunity to stumble upon the corpses of past adventurers, but overall the multiplayer experience is quite limited. Like MUDs, rogue-like games are text-based, though in this case the text characters are used to draw maps of dungeons (where "#"s might be corridors, "."s room interiors, "U" demons, "@" your player, "V" vampires, etc). They're entirely achievement-based, which makes sense because there isn't much opportunity for socialization in a single-player game. There are perhaps hundreds of rogue-like games. Ones I've played include: rogue, hack, nethack, ularn, omega, moria, angband, zangband, and T.O.M.E. (a few of which are actually installed on my home machine right now and were played as recently as a couple of nights ago).

Overall I'd say that older online games never really hit the big time, attracting hundreds of developers working together (or apart) because of two issues: interface and output. (And, MUDS and rogue-like games did attract those developers because they managed to deal with some of these same issues.)

Interface is the question of how easy it is to play a game: what commands you have to type in, how you can use your mouse, etc. The graphical games that I played, from netrek to griljor, all got bogged down by having to develop complex (usually unique) interfaces related to the way that mice worked on a particular machine type. On the other hand MUDs and rogues were able to get away with simple text commands for rogue-like games (e.g., "f" to fire an arrow, "s" to search, "a" to aim a wand, etc) and simple text imperatives for MUDs (e.g., "get axe", "kill monster"). They're not necessarily intuitive, but at least they're somewhat simple and expandable and work on all machines.

Output is the question of what you display to your players. Again, I think the graphical games were limited by the fact that their outputs were unique and complex. Compare that to the simple approach that MUDs and rogues used: displaying text.

And thus we move on to web games, which probably started to evolve as early as 1993, but didn't really start to appear in any complexity until 1995 or 1996 when the web really started to blossom and dynamic CGIs were becoming more stable and easily understandable.

Web games offered developers an existing interface (via HTML forms) and an existing output mechanism (via the web pages themselves). Suddenly it became easy for hundreds of developers to work together in understandable ways, and they didn't have to redevelop the wheel every time they made a game (as the developers of netrek and xconq and griljor and all the rest did). And so we began to see a true proliferation of amateur and professional web games alikes... a proliferation that still exists to this day.

Of course by opening up the world of web games, we've opened up a new medium with its own rules. Just considering our evolutionary tree, for example, we can realize that in PBMs turns were usually biweekly, while in online games they were mostly instant or constant. Web games are now finding a happy medium between the two: not as constant as online twitch-games, but not as infrequent as the old PBMs.

We'll get more into the strengths and weaknesses of web games in the weeks to come, but first, let's finish up this week's column by really dissecting how they're built.

The Parts of a Web Games

A web game is generally a collection of three or four parts, as I've outlined in the diagram below:

The most important bit is the game server. It's typically written in either Perl or PHP and is where you keep all of your core logic about how the game works. "Server" is actually a somewhat misleading name, because it really amounts to a program that gets run every time a player hits the web page (which is to say it doesn't stay in memory, nor run when players aren't around).

Because a web game server isn't memory resident it needs to store state (what's going on) in some way, either to a database or data files. Many people call this the "back end".

Generally, databases are the way to go, because you can link together lots of different information in interesting ways. They usually take some CPU oomph to do that work, but are well within the capabilities of modern computers and also well worth the cost. Some professional web game designers look toward expensive database options such as Oracle or Sybase. In my opinion MySQL, which is a free alternative, does the job just as well.

Data files (or flat files) should only be an option if you're always going to write out your data and look it up in pretty much the same way. And, it should be kept in mind that data files are generally untrustworthy. You have to jump through hoops to make sure multiple players don't munge your data files by writing to them at the same time, for example — something that a database would have taken care of without problem.

On the front end, your game server needs to integrate a web server. In fact, a game server tends to dynamically writes web pages based on the state of the game, who's viewing it, what info they're requesting, etc. Although very integral, a web server is also larger invisible to a web game designer. It does its job, but mostly it's just there to ask as a standard I/O interface, and a game designer expects it to work correctly if he hands it correct HTML code.

(Technically the web server talks to a web client, but I've maintained them as one entity in my diagram, because they jointly do the task of correctly displaying HTML code to the user.)

Out in the client, a web designer can choose to take advantage of DHTML or HTML Plug-ins if he desires, though they're entirely optional.

DHTML expands HTML by letting pages dynamically react to user input — such as when a user picks a specific entry from a list or even when he mouses over an individual graphic. I've used Javascript DHTML to do things like calculate distances in Hegemony and to allow users to move around panels before committing them at my.skotos.net.

HTML Plug-ins allow for more complex input and output than is possible with HTML alone. For example, ActiveX is what we use at Skotos for our scrolling text displays in our games. Java is what we use for our star maps in Hegemony; the maps are fully graphical and can be dynamically resized or asked to display different information... all things that wouldn't work within the pure HTML paradigm where you have to recommit a page whenever you want a notable change. (Flash is another HTML plug-in which could be programmed for this type of work, but I haven't seen it used that much yet for multiplayer games.)

An Aside on Architecture

It's worth taking a moment here to note a cool feature of web games: their platform independence.

As you might recall, when I talked about the earliest online games, I mentioned that you had to do work figuring out how to accept input from that particular machine's mouse. Likewise, if you had a graphical game, you had to figure out how to put pixels on that individual machine's monitor.

There were some attempts to make this more universal. For example the popular UNIX windowing system, "X Windows", provided a couple of toolkits that let you write graphical interfaces and output that worked on just about any X-enabled UNIX box. But what about Macintoshes? Or Microsoft Windows machines?

Web games (theoretically) make your front-end work fairly universal. If you program your game server to output correct HTML, it should work on any modern browser. Likewise, Java and Flash have both been developed for a lot of different platforms, and (theoretically) the same code works the same anywhere. (ActiveX only works on PCs, and that may be one of many reasons not to use it, more of which I'll cover in a bit.)

I say theoretically a lot because things never work exactly like this. HTML will work differently on different machines because:

1. Some browsers don't support all the modern standards.
2. Some browsers support extensions that only work for them.
3. Some browsers will display broken HTML that will fail on other browsers.

However you can avoid most of these problems if you just write correct HTML, and you don't use non-standard extensions unless they're actually in use by most modern browsers.

There's also always a question of what qualifies as a "modern browser". Personally, I set that mark at somewhere between 2-5%. When there are fewer people than 2-5% of a site's total users using a specific older browser, according to my web stats, I stop worrying about making sure all my code backdates to it.

Java (and presumably Flash) is a harder question because it's not standardized like it's supposed to be. I frequently run a nice Java app on one machine, then have it crash horribly on another. You just have to test, see if it works on a number of different platforms, and debug if it doesn't.

Currently, I tend to test my web game on the following platforms: IE 6 for Windows; Mozilla 1.2 for Windows; IE 5.2 for Mac; Mozilla 1.2 for Mac. The Mozillas are pretty close to Netscape 7, but I also keep the actual Netscape release around, as well as Netscape 4.8, so that I can test those if I get specific complaints.

Moving to the back-end, there's not as much concern regarding platform independence here, because you get to pick what your game is running on, not your players. I tend to prefer UNIX or LINUX systems, because they're very stable server platforms, but I know that PHP and Perl also have incarnations available on a variety of PC platforms.

A Diversion on Languages

I've talked about quite a few different languages. It might be a bit intimidating. At heart, though, all you really need to build a web game is a solid understanding of HTML and either PHP or Perl.

Personally, I prefer Perl, because it places the emphasis on the way the code's algorithms are shaped, and only generates web pages as a side effect. On the other hand, PHP is much more tightly integrated with the HTML paradigm, and if you're coming in to web games without much coding experience, that might be a better option.

Interface with databases is built in to both Perl and PHP, so you don't have to worry about really understanding their intricacies (though you do inevitably need to understand the SQL-like query languages that your database supports). Equally, access to files is integrated into both Perl and PHP, but as I said, not recommended for data storage.

On the front end you can include Java, Javascript, ActiveX, or Flash if you so desire, but you can make a fine web game without any of them. Personally, I find little bits of Javascript good for improving back and forth on web forms, because you can instantly show results when players input information. I find Java useful for complex graphic displays which need to be able to respond to user input. Neither ActiveX or Flash are currently on my list of languages to use. I find ActiveX too arcane to use and very hard to program, and I feel like Flash is too unproven in the web game arena.

Your mileage may vary.

Closing It Up

So, why the diversion on the ecology of a web game?

Even if this week's column doesn't cause any of you to run out and start programming the next GE: Hegemony or Archmage, I at least wanted to show what it all looks likes and thus provide a good baseline for my discussions in coming weeks.

I have lots more to say on strategy, but I'll also be constantly looking into how strategic theories can be used to develop online computer games, and that'll go back to the framework and history that I've outlined in today's column.

I'll see you in 7 when I talk about the heart of strategy games: decisions.

Recent Discussions on Trials, Triumphs & Trivialities: