The 1998 developer interview

In 1998, during the closed beta of the first Wulfram, Scott Keur interviewed the development team for the Multiplayer Online Games Directory. This page summarizes it. Read the original on the Internet Archive capture from July 3, 1998.

Note

The interview is about Wulfram, the predecessor of Wulfram II, before its release. Statements of plans and design intent are historical context, not evidence of how Wulfram II or its servers behaved. W1 lead

The team

Three people built the game: programmers Bernt Habermeier and Jonathan Blow, and artist and 3D modeler Rick Keagy. Habermeier and Blow met as Computer Science undergraduates at Berkeley. At the time of the interview the game had been in production for about two years, largely self-funded.

How it was built

• The game was written in a restricted subset of C++, with about 2,500 lines of Pentium-optimized assembly for texture mapping. Every assembly routine also had a C version, which kept the code portable.
• The whole codebase was around 150,000 lines. That count included the editors and support tools, which were built into the game itself. The Wulfram II client likewise still contains editor and debugging paths; see the cutting room floor.
• It ran on Windows 95 and NT, Linux, Solaris and other Unix systems, with native 3Dfx Glide support for faster rendering.

Design ideas

• Teamwork over power-ups. No weapon is strictly better than another, and every tank starts with the Autocannon and Pulse Cannon. The team that coordinates wins.
• Built for lag. The Autocannon is instant-hit with a wide firing cone, so players on slow modems don’t have to lead targets. Several weapons are fire-and-forget.
• Combos. The most effective play chains weapons, for example a Thumper’s disorienting spin followed by a guided missile.
• Pacing. Moments of intense battle alternate with quieter time to plan.
• Few, distinct vehicles. The team deliberately avoided light, medium and heavy variants of the same tank. Future vehicles were meant to be different in kind: a Harrier-like aircraft and player-controlled capital ships were floated as ideas.

Scale

• 32 players per game, with no hard technical limit; server CPU cost was the constraint.
• A standard map was about 31 square kilometers (5.6 km on a side), with about 12 arenas planned and an in-game map editor.
• No distance fog, so distant battles stay visible through the zoom scope.

Server rules mentioned

These are statements by the developers about the first Wulfram. They are the closest thing to developer testimony about server rules, but they predate Wulfram II. W1 lead

• Friendly fire was a server variable, chosen by whoever ran the server.
• Switching teams would not be allowed while teams were balanced.
• Clan support was planned, including clan logos on tanks and “challenge” games restricting who could join each team, as opposed to open “pickup” games.

Distribution and the future

The game was to be hosted on TEN (Total Entertainment Network), which had helped with QA and partly funded development; the contract allowed other services after an exclusivity period. Longer-term ideas included larger battles, new unit types such as a heavy missile silo, gun turret, portal and listening “bug”, terraforming units, mission-based team communication, and a persistent galaxy of planets to fight over.

Open questions

• Which of the planned units and features shipped in Wulfram II, and which remained plans?
• Did Wulfram II keep the balanced-teams switching rule and a server-side friendly-fire setting?