It’s the year 2000, and I’m still working on the virtual mall. The original plan called for lining up deals with distributors, or retailers, or existing online storefronts. I think the idea was that John Business would rent virtual storefronts to people who wanted to sell goods in our mall. I’m guessing those deals have been hard to come by, since it’s been ages since I’ve been given pictures of new stores and products to translate into 3D. At the start of the project I made a couple of demonstration stores, and I haven’t been given any real ones since then.
The lack of new content has given us some breathing room in the timetable. It’s been weeks since Roger – my boss and also a pretty good friend – stopped by my cubicle with a question or request from the people representing John Business, which means I have time to spend on other projects.
Security Through Obscurity
Roger really likes my work and has often wanted to get me the source code for our software. The coders guard the source jealously. Roger – being an executive of the company – technically has access to the source, but only in the sense that he has access to the machine where the source is hosted. He could drive an hour to downtown Boston to our hosting company, go through the layers of biometric securityWhich all seems pretty Star Trek here in 2000. and look directly at the machine in question, but he has no idea where the files are stored, what they look like, or how to access them.
Whenever he asks, the coders always reply with, “Why would you need that?”
In their defense, we still partly rely on a dash of security through obscurity for our software. We already have a problem with kids hacking the clientNote that in this case “client” means the software used by the kids at home. We’re not talking about a business client in the sense of a person who is a customer. Stupid confusing computer terminology. to cheat at the user-made games. Rules like gravity and surface collision are enforced entirely on the client side, and so enterprising young hackers are able to fly and noclipFly through walls. at will. This issue is really important to all of those teenagers using our software as a platform for game development. They hate designing puzzles, mazes, and other challenges, only to have hackers circumvent the rules. Hackers are usually more interested in attention than “winning” the game, so when they cheat they often look for ways to ruin the game for other people. They cause confusion and complaints and generally make the software a little less fun for everyone else.
There are layers of security to detect cheating, and counter-hacks to hide it, and security checks to counter the hacks, and hacks to counter the checks. This is a long-running game of cat-and-mouse and the developers hate it because they feel (correctly) that it’s a losing battle and a waste of their time. The coders know that obscurity makes for lousy security, but for various technical reasons it’s the only option available to us. A proper fix would take years and multiply the hardware requirements of our lightweight server by orders of magnitude.
The Server is Blind and Dumb
Right now the server is pretty dumb. The advantage is that you can host thousands of worlds on a single Linux box. Hosting a world is a lot like hosting a single webpage. Adding more doesn’t really increase the server load. It’s number of users, not the number of worlds, that creates load problems. And if you’re lucky enough to have so many people that a single machine can’t handle them, then you’re making enough money to spin up a second machine to help balance the load.
The server is technically “blind”. It knows where the objects are and where the users are, and it broadcasts this information to everyone. It knows there’s an object called “light_pole” at such-and-such a location, rotated to such-and-such a position, and that it’s owned by user so-and-so. But it has no clue how big a light_pole is, what it’s shaped like, what parts of it might be solid, what parts might be visible, or what all of these scripts attached to it might do. It also doesn’t know what users “look like”. It knows user Shamus is at location A and heading B using character model C, but it has no idea how big C is or what it’s shaped like.
As a result, when you’re playing the game, your own computer is in charge of making sure you don’t cheat. This is the same problem developers run into with DRM: The user has complete control over their computer, and so if you try to restrict them using that same computer then they will be able to circumvent your will. The only way to put the rules beyond the user’s ability to tamper is to have them enforced by the server.
If you wanted the server to enforce rules like collision, then it would need to be able to download and analyze all of those thousands of 3D models. That would mean keeping all of that geometry in memory, and performing expensive collision-checking on all of it. That task is actually pretty heavy duty. When an area is really complicated, your mid-range PC can actually slow down just checking collision for your character alone. What if the server had to do collision checks for every user against every nearby object for every one of the hundreds of worlds it was hosting? Centralized processing solutions for distributed users is something that does not scale well, particularly on the computers of 1999.
This is made harder by the fact that our engine accepts a lot of user-made content that can’t use normal optimizing tricks. Some models might contain huge numbers of polygons. These models can’t be guaranteed to be enclosed solids, which means there are certain geometric shortcuts that are available to typical videogames but not to us. These models are often built by inexperienced users who don’t understand common optimizing techniques. Worse, the whole system to parse 3D models is handled by our graphics engine, which can’t be ported to Linux, which is the preferred platform for hosting our server.
Every time someone talks about stopping cheating, the coders begin listing all the costs associated with doing things the “Right Way” and the bosses capitulate before the coders are halfway done. It’s not an impossible problem to solve, but it’s so cost prohibitive that it may as well be.
The point is that making the client a pain in the ass to tamper with is the best anyone can do to combat cheating. The coders just want to avoid things that would oblige them to spend even more time fighting this losing battle, such as having the source code leak out into the wild.
Roger doesn’t know source code from Vogon poetry, but he’s adamant that he wants a copy of the source anyway. “What if both of you get hit by a bus?” he tells the coders. “We need access in case something happens to you.”
One day Roger walks by my cubicle and drops a freshly-burned CD on my desk. It’s the source code for our “3D Browser” – the client. He doesn’t have any requests and there’s no reason I need this, but he knows exactly what he’s doing. Over the next few days, he conspicuously doesn’t have any work for me to do.
Once I get it to compile I go to work on it.
One of the problems with our software is that it was originally conceived and written in 1994. That’s the same year Doom II was released. Those early versions of the software were built on graphical systems that are now woefully out of date. Depending on how you count, the world of consumer graphics has been revolutionized three or four times since then. Most game developers are free to throw out their graphics engine when they feel it’s gotten too old, because they build each new game from scratch. But our world has been running almost non-stop since it opened to the public in June of 1995. There’s never been a point where we could throw out the old content and make a clean break. Most of our content is user-created these days, so there’s no way to wipe the slate clean without causing a revolt.
We’re still using primitive 1994 lighting and rendering techniques. We can only have one global directional light source for an entire world, and it has to be full brightness and pure white. There’s no specular lighting or environment maps. No fog. No control over the clipping plane. No additive blending to create effects like fire. No mip maps. No shadows whatsoever, not even ultra-primitive blob shadows like games have been using for years.
The thing is, our software should technically be capable of a lot of these things. Last year our programmers spent about nine months upgrading us to the latest version of Renderware, our graphics engineThis is the same graphics engine as Grand Theft Auto III, which will come out next year.. It was our first upgrade since 1995. It was such a huge leap that huge parts of the software had to be re-written to accommodate the newer ways of doing things. This meant we spent about nine months stagnating, not giving users any new features to play with. Once the upgrade was over, there was a huge backlog of features and fixes that everyone needed. It’s been a year, and we’re still dealing with the fallout of that nine-month bottleneck.
Worse, all of that work was just to get it working and backwards-compatible with all of those years of content. The program looks basically the same as it did five years agoThe only visible difference I can remember is that if you have a graphics card you’ll now automatically get texture filtering, where stretched textures will be smoothed out rather than giving you ridiculously oversized pixels. Which is nice.. The only change is that it can now use a graphics accelerator if the user has one.
To rub salt in the wound, Renderware was just bought outToday it’s owned by EA. and we will never get another update for it. We just spent most of last year upgrading our program into a graphical dead end. If we’d only known, we could have gone with another engineOr if anyone had asked me, I would have advocated for dumping the middleware and using OpenGL directly. The way we used it, Renderware wound up being little more than an ungainly wrapper for OpenGL.. This will come back to bite us over the next decade.
In the meantime, our graphics engine supposedly offers us a bunch of new effects that we’re not using.
Now that I have the client source, I mess around with some of these new graphical features. I add fog. I add some lighting effects. I create a demo to show off what it might look like if we gave users control over the global light source. I add some basic modern touches like footstep sounds. After a few days, it makes for a dynamite demo. Mixed with some solid art, our client starts looking more like a modern-ish game and less like a leftover from 1996.
Fog is the big attention-getter. We’ve always struggled with draw distance. If you allow the user to see too far, then all of that distant detail will drive their framerate into single digits. You can make the draw distance smaller, but then you have problems with pop-in, where large objects suddenly appear nearby as they enter your view radius. Here in the year 2000, the preferred way of coping with this problem is to use fog. Our software didn’t use fog, which means we had to split the difference between terrible framerate and terrible pop-in.
With fog, you can hide all of that ugly pop-in behind thick fog and the lack of visibility feels like an atmospheric effect rather than an ugly limitation. It’s not a perfect solution and it isn’t applicable in all cases, but it really is a massive improvement over what we’ve been doing.
This demo causes quite a stir in the company. The special build I made gets passed around and everyone has a moment of surprise when they see the client running with my enhanced effects in place. This produced the effect that Roger desired, which is that all the various factions in the company unite and start asking, “Hey, why don’t we add all this cool stuff?”
Roland, our lead programmer, is put on the spot. This makes him look bad. I’ve had the code for three days and I’ve just blown everyone away with a graphics demo. The assumption is that these features are trivial and that it’s just three days of programming to make it all work.
Technically the contents of The List™ have already been decided and the new build is still a few months away, but in response to what I’ve done we have some impromptu feature meetings that quickly escalate into regular feature meetings, and from there to an overhaul to The List™ that will incorporate my changes. Roland is put out by this. He spends much of the meeting on the defensive, patiently explaining that he’s not against any of these new features, but he insists that they will take time to add. I pretend to stay aloof during this discussion but secretly I’m cheering the whole process on.
Today, I’m the Bad Guy
This is pretty unfair to Roland. See, I’ve done the easy part. It’s only a few lines of code to enable fog. But you don’t want all worlds to be foggy all the time with the same color of fog at the same density. The work isn’t just to enable fog, but to turn it into a useful feature. This means adding a whole new section to the interface for controlling all the properties of fog. These properties must be sent to the server, stored, and then re-broadcast to all users. This means changes to the interface, the client, the server, and a few of the utility programs people use to manage their worlds. It means testing fog in different environments and solving various visual artifacts.
Worse, the introduction of fog introduces a bunch of new questions that need to be answered. For example, the software will display a user’s name over their head, just like in an MMO. But now we come to the question: Should this name be obscured by fog, or should it always be rendered at full visibility? You can devise various situations where you might really want one or the other, depending on how the world is used. The reflexive answer from the bosses is always “make it an option”, but that means more changes to the interface, the client, the server, the tools. Keep in mind that this is just one question of many, and if we answer every question with “make it an option” we can easily make a huge load of work for ourselves. Having lots of options is good, but only if the options are useful, cover the most likely use cases, and are properly documented. It’s easy to overwhelm the user with useless dialog boxes.
Does fog work on all systems? In the same way? What about people without graphics cards? Do some systems have glitches? How do we handle the fixed image drawn on the horizonThink of those hills you’d see in the distance in DOOM, that would scroll sideways as you turned your head. This is basically the same thing. It looked AMAZING in 1993 but looks pretty dated today.? Should that be fogged? Or drawn in full brightness? Or hidden? Or make it yet another option?
It takes ten minutes to enable fog, but it takes days of experimentation and test builds to turn it into a properly useful feature. I knocked everyone’s socks off with this demo, and now people are expecting miracles from Roland because I made it look easy.
I admit I’m being a weasel right now. In my defense, I’ve long been advocating for graphical upgrades, but those features never made it onto The List™ because nobody really appreciated what an enormous difference they would make until they saw the demo. If this is what it takes to show people how awesome our software could look, then I need to do this if I don’t want our visuals to continue to languish for another half a decade. I’m not trying to make Roland look bad, I’m just trying to get people to care about visuals. People won’t allocate time in the schedule for something that “will look really cool, trust me”. You have to show them what they’re going to get.
Also, I’ve wanted to be part of the coding staff for years, and this seems like my chance to get management to take me seriously. I’ve written a lot of incredibly useful tools over the years, but you can’t really show off your skills by making tools that only technical people can understand and appreciate.
And deep down, I’m hoping I can do some coding because I’m going mad working on the virtual mall and I’d rather do basically anything else.
 Which all seems pretty Star Trek here in 2000.
 Note that in this case “client” means the software used by the kids at home. We’re not talking about a business client in the sense of a person who is a customer. Stupid confusing computer terminology.
 Fly through walls.
 This is the same graphics engine as Grand Theft Auto III, which will come out next year.
 The only visible difference I can remember is that if you have a graphics card you’ll now automatically get texture filtering, where stretched textures will be smoothed out rather than giving you ridiculously oversized pixels. Which is nice.
 Today it’s owned by EA.
 Or if anyone had asked me, I would have advocated for dumping the middleware and using OpenGL directly. The way we used it, Renderware wound up being little more than an ungainly wrapper for OpenGL.
 Think of those hills you’d see in the distance in DOOM, that would scroll sideways as you turned your head. This is basically the same thing. It looked AMAZING in 1993 but looks pretty dated today.
Artless in Alderaan
People were so worried about the boring gameplay of The Old Republic they overlooked just how boring and amateur the art is.
The Best of 2014
My picks for what was important, awesome, or worth talking about in 2014.
PC Gaming Golden Age
It's not a legend. It was real. There was a time before DLC. Before DRM. Before crappy ports. It was glorious.
A programming project where I set out to make a gigantic and complex world from simple data.
A Star is Born
Remember the superhero MMO from 2009? Neither does anyone else. It was dumb. So dumb I was compelled to write this.