A Walk in the Dark A look in to the mind of an RPG designer


The Story of PainRift

The following story was posted by me on my former PlanetHalfLife website. Reposting it her not only for nostalgia's sake, but I think the lessons learned here could be helpful others.

According to the Wayback Machine, this story was posted on October 8th, 1999... which is a lifetime ago. Reading through it you can tell it's extremely dated - it references things like GameSpy, PingTool and ICQ - so it may not make much sense unless you lived in that era.

Two anecdotes about PainRift that aren't mentoned below.

1) The AirFist

The image to the right is a rare glimpse of one of the single best weapons ever: the AirFist. It was a "weapon" that fired nothing more than compressed air. You would walk in to a room and when you let it rip everything that wasn't nailed down - players, pickups, grenades, rockets - would get blown all over the place. It was spectacularly fun to use nothing but that weapon, and I became particularly adept at blowing rockets back towards anyone who fired them at me.

There were also AirFist rockets and AirFist grenades. Picture a rocket flying through the air that would emit a blast of air every second, carving a swath of destruction as it flew.

A spectacular amount of code went in to supporting the AirFist, and it remains one of my proudest achievements in gaming ever.

1) The Release Party

The day PainRift was released, we decided to have a "release party" of sorts. We hosted our own server in a colocation facility I was working at at the time (and it wound up being the first time I ever saturated a T-1), and all the team members logged on minutes before the link was posted on FilePlanet.

And we waited.

Ten minutes after the link went live, two players joined the server. To this day I don't know who they were, but they were both people who just downloaded the game, have never played it, don't know a thing about it and have just joined a server along with eight members of the team that made the game. I remember thinking to myself "this should be interesting"...

And then the carnage began.

These two anonymous, inexperienced gamers proceeded to trounce the development team - myself included - in the most spectacularly humiliating way possible. In our own game. I even resorted to activating developer mode cheats... and it didn't help. The second any team member spawned, we were smacked with a grenade or launched in to orbit thanks to the AirFist.

And as quickly as they showed up, they disconnected. The development team didn't know what to do; was this a flaw in the game's design or did we simply suck? The world will never know.

A full write-up of the mod is actually still available on PlanetQuake. If you look hard enough, you can still even download it via FTP!

Anyway, just wanted to keep it around in my own special way.

 -=O=-

Posted on Mach III Enterprises website, formerly hosted by PlanetHalfLife, circa October 8th, 1999

About a year or so ago (on or about when Quake II 3.17 was released), I joined a group called Razor Entertainment that was in the process of planning a Total Conversion called "Fracture". The plans were pretty extensive to say the least, the magnitude of which would have taken an extremely long time to complete, so we had to trim it down considerably. From that spawned the initial design of "PainRift".

Well, working on a Total or Partial Conversion is a daunting task in itself, a task that takes much more involvement than most normal people have available. I became the lead programmer, and was really eager to get this thing working in the best possible way, but I’ll admit I didn’t have all the time available to make it the best that it could be. Others in the group apparently had less time to offer, and pretty soon members started leaving. At the end of Razor, there were four of us remaining from the original group.

But we did not want to see PainRift die. Through contacts others made, we joined up with RMD Software, which are some of the most talented people I’ve ever had the privilege to work with. They created maps and models faster than I could implement the coding for them, and pretty soon we had a playable version with all the bells and whistles. It looked great!

Everyone in the group was extremely pleased with the beauty of the final result, and eager to get it out to the world before the Quake fever dies out (as if it ever could). So everyone in RMD stated they wanted it released by a certain date, regardless. I wasn’t particularly pleased with this notion, because I felt it wasn’t ready, but since I thought everyone else had tested it thoroughly enough to feel comfortable about it, I’d done my job.

But there are a lot of things we failed to consider:

  • We never thoroughly tested it on a server. I had a server running with it, and it ran great on a LAN. But most of the RMD personnel are in Australia whereas I am in Miami, and let’s face it: you can’t get more geographically distant than that, and the pings were terrible. I saw the massive amounts of "overflow" errors on the server, and worked frantically to reduce the amount of bandwidth generated, but I could not readily reproduce the problem on a LAN. At 600+ ping to Australia, I wasn’t expecting miracles. We should have put several servers out there to test its stability, and because we didn’t you all very well know that PainRift crashes extremely frequently.
  • We did not have any plans for a Linux port; we never realized the flood of requests that would come of it. PainRift was designed using what I called my "DLL API", which allowed multiple DLLs to be loaded like plug-ins in to PainRift. The code for this was extremely Windows proprietary, and I had no knowledge of dynamic libraries in Linux (actually, I don’t even OWN Linux), but at the time of release it wasn’t really an issue.
  • We did not have any plans for "bots". I was working on a bot of my own, but the demand for bots such as the Eraser far outweighed anything I would accomplish.
  • We never provided extensive server configuration. People were expecting configuration options like Lithium and similar products.
  • We never tested it with GameSpy and PingTool, and some of you may recall that it didn’t work at all with it. I discovered a sort of bug that would cause GameSpy to fail if you define too many server "cvar"s in Quake! How was I supposed to know that?
  • The initial release’s "uninstall" option would uninstall Quake II as well. I’d gotten several E-Mails from people stating that they were extremely pissed because, and I quote, "…now I have to go buy it and RETURN it again!"
  • We advertised it way too much, considering all the above problems. When we said "it’s available", everyone got a hold of it and discovered the problems too easily.
  • It was NOT labeled a Beta. With all the above things missed, it's a Beta by definition, isn't it? Of course, labeling it a Beta would lower the expectations of the public, and in not doing so the public expected a flawless product. When they didn't get one, they went ballistic.

So, after the initial release of PainRift, I was flooded with at least 100 E-Mails a day stating all the above problems. I tried as best as I could to fix all of them, to reduce the bandwidth, etc… The GameSpy problem took me a week to figure out… It was simply too much. The release was a disaster.

So came v1.01, v1.02, and the last one v1.03. As these versions progressed, I began to hear less and less from the members of RMD. Eventually, all communication stopped, and I was kind of at a loss as to what’s going on. They seemed upset at me that the release was such a disaster, but I was the only one that felt uncomfortable about it in the first place. Since they weren’t communicating with me, and I was basically getting no praises or "thank you"s from anyone, I figured what’s the point in continuing it? If the rest of the group isn’t going to appreciate the work that went in to the project, and realize that this is not the way to release any type of product, I discontinued development and support for it.

So, what's to be learned?

  • Don't set your goals unreachable. If you have one programmer, don't make 20 different monsters each with unique AI (unless the programmer is a self-made millionaire). Remember that for each monster or weapon, there comes a lot of code, models, sounds, and testing.
  • Test it THOROUGHLY. Put it on more than one server. Test it on a local LAN and cross-country if you can. Test it with more than three total people. Test the stupidest things you can think of. That's what Beta Testing is all about: don't test things you expect to work, test the things that most normal people wouldn't try. Example: a major bug in early PainRift was that the server crashed when two rockets collided in mid-air. You wouldn't think of that, would you?
  • If you think your product is ready to be distributed, it's probably not. If you think it's ready for release, add at least 2-3 weeks, and continue working on it and testing it.
  • Whatever you release, even if you have tested it thoroughly, always label it a Beta. This may not be good for marketing, but it gives you a margin for error. People expect a non-Beta product to be flawless; no program ever is when it's first released.
  • When you release, make sure your group has available time for the next two weeks after that. If your mod looks fantastic, but there is some catastrophic bug in it that is unacceptable by the masses, it must be fixed immediately. Expect to be fixing stuff thoroughly for the next two weeks. Also, if you can't fix everything that is to be fixed, make the public see that you're doing everything humanly possible. If they still insist, remind them it's a "Beta"...
  • Stay in communication with your colleagues. ICQ is a must these days, and IRC is highly recommended. If you can, schedule an IRC meeting at least once a week to make sure who's doing what.
  • Make sure everybody's doing something. If there are people in the group that aren't producing as they should, it degrades the performance of the entire group. Don't be afraid to tell someone to take a hike and find someone else; the time spent explaining a new person what to do is much less than trying to get a useless person to perform.

Tnx & Rgds…

David Flor, a.k.a. Nighthawk
Lead Programmer, PainRift Development Team
President, Mach III Enterprises

Comments () Trackbacks (0)

No comments yet.


Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

No trackbacks yet.