<\/div>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.<\/span> 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. <\/p>\n Whenever he asks, the coders always reply with, “Why would you need that?” <\/p>\n In their defense, we still partly rely on a dash of security through obscurity<\/a> 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.<\/span> 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.<\/span> at will. This issue is really<\/em> 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.<\/p>\n 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<\/em> 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<\/em> and multiply the hardware requirements of our lightweight server by orders of magnitude. <\/p>\n 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. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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<\/a>, particularly on the computers of 1999. <\/p>\n 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. <\/p>\n 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.<\/p>\n 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.<\/p>\n 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.”<\/p>\n 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.<\/p>\n Once I get it to compile I go to work on it. <\/p>\n 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<\/a>. 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.<\/p>\n 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<\/a> or environment maps<\/a>. No fog. No control over the clipping plane. No additive blending<\/a> to create effects like fire. No mip maps<\/a>. No shadows whatsoever, not even ultra-primitive blob shadows like games have been using for years.<\/p>\n 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.<\/span>. 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<\/em> dealing with the fallout of that nine-month bottleneck.<\/p>\n 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.<\/span>. The only change is that it can now use a graphics accelerator if the user has one. <\/p>\nThe Server is Blind and Dumb<\/h3>\n
<\/div><\/a>
<\/div><\/a>I’m In.<\/h3>\n
<\/div>
<\/div>
<\/div><\/a>
<\/div>
<\/div>