Slashdot Mirror

Remember Netrek? The developers released source code so people could make custom clients. Great, but how did they solve client-side cheats? Simple -- release a "blessed" binary build of any specific Netrek client, and allow servers to choose what clients they allow ("cyborg" (compiled by anyone) or "blessed"). It uses a cryptographic hash/key or something similar (details here).

I think this would work for Blizzard and BNetD as well (Blizzard releases their own build of bnetd, with CD key checking, etc). Of course, this would require relicensing bnetd under a license that allows binary-only distribution (BSD, MIT, etc).

Is this likely to happen with Vivendi at the helm? Probably not...

If you've never written a client-server game at all, you might check out Netrek for some basic ideas. It isn't massive, but it is client-server, and it's where I learned most of the important things I know about network programming in general (and I do, in fact, get paid to write network code for games now.) Quake or Quake 2 source are probably also good things to look at, though I haven't seen their code personally.

None of those solve the major problems you're really asking about though: how to decide who gets to know about what. Worldforge is the only open source project I can think of to point you to in that area. Perhaps some MUDs might be useful as well, but they tend to be based on rooms, not areas, which doesn't translate well at all to most other games.

Probably the biggest problem is avoiding N^2 operations as much as possible. At some level, there's no way around it: N players in an area generate events that have to be propagated back out to N (or at least N-1) players. This obiously makes scaling to arbitrarily large populations difficult. On the other hand, if you can guarantee a set maximum number of players in an area/server/whatever, you can target that maximum and not worry about it a whole lot.

A slashdot post isn't really the right medium to answer this question. There aren't any quick and easy answers, you need to figure out what makes sense for your game on your own. I've spent a large portion of the last year thinking about these problems myself, and I wish you the best of luck on it. I'm having a blast myself, but it's also the most challenging work I've ever done.

I am interested in hearing your reasons for using C#. That's actually somewhat shocking, but maybe it's just ignorance on my part. I can't imagine why you'd want to bet the farm on such an immature system, regardless of the strengths you've perceived in it. What does it do for you that C++ doesn't, and is it really worth it?

• I'm also having trouble imagining the demanding weenies you describe. The Baton Rouge LUG is small, but most of the people there were NOT like this.

Take the blinkers off. Most users of any given system aren't dedicated and civic minded. They just want to use it.

An example. When I was at university, my computer science class got bitten by the Netrek bug. We had at least a dozen dedicated (league) players, plus hangers on from other classes, playing it in DEC workstations. Of that group (say 20), only one of us (me) had even compiled the client, let alone developed it and fed back into the community. Out of a computer science class, putting in countless hours playing a game competitively, not one other person could be bothered even trying to tweak the client. They just wanted to play.

Games players - players - are not typical hackers (in the good sense, a lot of them are script kiddies). That's the point under discussion here, not your cozy ivory towered LUG.

• The open community ought to dedicate itself to creating something original,

Look over at sourceforge and you'll find pots of games. Most of them die before they flower. I'd suggest it's because the developers would rather work on a clone of something that they already know that they'll like. Sad, but perhaps if that's what open source is good at, maybe that's what we "should" keep doing rather than creating a lot of still born half implemented ideas.

On the other hand... have a look at Netrek. That borrowed the names and some gfx/sfx from Star Trek, but the idea and implementation was truly original. In fact, commercial games can learn a lot from looking at the Netrek client/server model, and a good game of Netrek is still more fun than a barrel full of monkeys.

Try it. Games programming will challenge you like you wouldn't believe. You'll sink or you'll swim, but if you last six months then you'll never fear another computer problem, ever.

As an aside, I went to one lecture in the second half of my senior CompSci year; it turned out to be a pre-exam revision lecture for a course I hadn't done. It was OK though, because I fell asleep, having been up all night hacking Netrek.

So, I got a sucky degree (British 2.2) but I learned to work with a real world project, made up of various standards of contributions, I learned a little graphics, a little input, a little maths, and a lot of network. I learned that an RSA authentication scheme is practically unbreakable, but easily duped. It got me a handle that I'm still using ten years later. It got me my first job, as a games programmer, where again I had to learn a little of everything. That got me the experience that I needed to make up for my degree.

So, sure, give it a try. If nothing else, it'll fast track your decision about whether computers are for you.

• I don't want to discourage you too much, but designing a game with graphics and everything is a huge task

Listen to this man. I spent a few happy years hacking Netrek, but when I actually tried to do a Master's thesis on an AI 'bot for it, I found that I had time to write the software, or to do the thesis, but not both. And that was on a small, well defined subset of a very mature 2D game, with no display component to worry about!

Further to that, I didn't learn my lesson and spent a frantic couple of years as a commercial games developer. It was a vertical learning curve, and the pressure and expectations were immense. I just wasn't good enough, and got out. Since then, I have coasted through a couple of corporate code monkey, using no more than half of the potential that I was expected to show every day as a games developer.

So hear this clearly: writing games is hard. Anyone who tells you otherwise is a producer, an armchair expert, or a psycho uber geek. ;)

Well worth reading, thank for that.

• I know the network code for Quake3 inside out (well, I re-wrote it) [...] I wish I had the source to this to help fix it because I want to play!

I hear you, buddy. The AO developers will be trembling, shambling wrecks by now. They're probably beyond even caring about what they're doing. They really should take Graeme up on his offer.

• TCP should be used for some stuff and UDP for other stuff, this is common in online games (such as netTrek).

Yay Netrek!. But it's a stonker of a point. Netrek dealt with these issues ten years ago. Jeez, AO guys, you only had to ask.

I say appalling advisedly.

I'd be the first to say that network architecture of a MPOG ("Massively" is meaningless without context or quantification) is a complex beastie, and very tricky to get right first time.

But this mistake has been made over and over again. There is a great article about the screw ups made in X Wing vs TIE fighter, that explains why you need to send some (most) traffic by UDP. My god, Netrek worked through all this ten years ago.

Something about playing Netrek all night.

You do the Hokey Pokey and you turn yourself around! That's what It's all About!

Why is that game so addictive?


HI Mom!

I have a separate rant about letting clients know information that they shouldn't, and about letting clients decide what the state of the game is; I will spare you.

Feel free to mod this down if you want to moderators, but netrek is a really good game, and paradise2000, tap (aka xyzzy) is the best client I have found. Check it out www.netrek.org

With a text-to-speech system, you can get voice output without having to worry about bandwith issues, poor quality sound, or people without a microphone.

With Netrek's RCD macro system, it's pretty nifty the things you can do. For example, a player who is in a base is hurt, and pushes a single key for generic distress, causing everyone on their team to get a message like:
F0->FED Help(SB)! 0% shd, 50% dmg, 70% fuel, WTEMP! 9 armies!
But your client will speak, "Base hurt, weapon temped", because all those numbers are a pain to listen to. Later the base is ok, so he pushes the same key.
F0->FED Help(SB)! 99% shd, 0% dmg, 99% fuel, 1 army!
Now the client just speaks, "Base is ok". The macros can have "if" statements based on the relevant values, e.g. if(damage>50) "hurt" else "is ok". It's a lot faster to just push a key than to say the relevant information. And if you don't have all the noise, you don't lose text communication with your teammates.

BTW, if it wasn't obvious, this is a shameless plug.

• I'm a pretty nifty UT player, and I *often* get accused of cheating cuz I can run up the walls with the teleporter (and other stunts). You try to calm people down by saying you're not cheating,

It's sad, isn't it? Back in the day, I used to be a fairly nifty netrek player. Whenever I found myself smacking an Ensign Bozo around too much, I would take the time to take him aside and show him how to do what I'd just done to him. I made a friend, he learned how to not suck as much, and we both got more out of the game.

Nostalgia isn't what it used to be, but I now find myself totally turned off by Quake clones. The lame network model allows cheating, the time to reach your performance peak is days rather than months (then it's just down to learning maps), and there seems to only be three kinds of players:

• Long time clued players.
• Cheating lamers.
• Clueless fodder who're just passing through.

There seems to be very little encouragement or education, just frantic frag fests and irritating boasting. By making these games too easy to play, and too easy to hack, we're effectively throwing our doors open and hanging out a sign saying "Bozos welcome!"

• I'm betting someone can figure out how to design a game that prevents see-through walls from working

It's not that hard. The server just needs to be more aggressive in culling the network information that it's sending. All solved years ago.

• cheating in any form in a multiplayer game is not only rude and unfair, but you _will_ be found out

Not in my experience. Plus, play well enough, and you get accused of borging anyway. There is very little trust in Quakish games, and that comes down to them not being aggressive enough in culling network data and fixing the problem at the server. A PPK binary authentication scheme wouldn't go amiss either. See Netrek for an example of how to do it right.

• All the games need to do is perform more computation on the server, to avoid sending "forbidden knowledge" to the clients

Absolultely. I'm constantly surprised by how lame the network models are for commercial games. It's not as though they're breaking new ground: netrek had a rock solid model close to fifteen years ago. The server pared the sent information down to the absolute minimum, so there was very little that a hacked client could do to gain any kind of advantage.

For example, cloaked ships appeared on the strategic display as "??"; you could hack the client to show their actual designation and to draw them on the tactical display, but the server would still only be sending (incorrect) position information very infrequently, with no heading or speed info, so all you really got was a vague idea of where they were.

• Nothing is really traveling back

Is this true? I'd get spectators to send location information then only send updates on what I knew they could see. But then I'm living in the past.

I remember playing Netrek, or maybe one of it's predecssors, back in the 80's: it was networked with a "chat" interface.

Best date I could find on their web site was version 1.3 circa '95.

• The problem with Quake bots as an AI challenge is that you can give them perfect aim

Yup, that's the problem with most client/server games; they trust the client way too much. Don't get me started on peer to peer.

Contrast with netrek, where having perfect aim can actually be a liability. Bot and borg clients would fire perfect vector torp streams every time - only to have their human target dodge gracefully out of the way every time.

• It would be fun to load up Starcraft and go on BNet and start a game with someone and see if your computer program can beat them. Or even just playing your own AI to train it.

A lot of quake bots were written to do just that, and netrek used to be a great platform for competitive AI's before it got left behind in the last ice age. ;)

I have been playing a game called netrek for about 6 years now, and I still have yet to come across anything better.

Netrek is something like 16 years old, with roots back to Empire (which is even older), but it is still by far the best game I have ever played. You pretty much need 1024x768, but I was happily playing for several years with a 4 or 5 color client (prettier ones do exist).

It's not just a game, it's a sport. It's an art in that it takes years to master. These are two things I have not been able to say about any other game.

Description of netrek ripped from FAQ: Netrek is a 16-player two-dimensional graphical real-time battle simulation with a Star Trek theme. A game is divided into two teams of 8 players (or fewer), who dogfight each other and attempt to conquer each other's planets.

Netrek is the probably the first video game which can accurately be described as a "sport." It has more in common with basketball than with arcade games or Quake. Its vast and expanding array of tactics and strategies allows for many different play styles; the best players are the ones who think fastest, not necessarily the ones who twitch most effectively. It can be enjoyed as a twitch game, since the dogfighting system is extremely robust, but the things that really set Netrek apart from other video games are the team and strategic aspects. Team play is dynamic and varied, with roles constantly changing as the game state changes. Strategic play is explored in organized league games; after 6+ years of league play, strategies are still being invented and refined.

--

Since it's free, you can check it out at this URL: http://www.netrek.org

One reason it is such a masterpiece is that it was built and fine tuned by gamers for gamers, and not driven by the desire to soak $$$ from a mass-market (10-15 y.o. flash and trash goobers). Netrek demands a lot of intelligence, skill, and attention span - things that not just everyone has a lot of, and therefore doesn't make a lot of money.

Mawen

If you don't believe me, try downloading my Netrek client Paradise-2000 and running the static glibc2.1 binary on a system with an older libc. Hostname lookups won't work. The problem is that glibc2.1's resolve code tries to access the dynamic library /lib/libnss_files.so.2, which doesn't exist on pre-glibc2.1 systems. Since this library isn't dynamically linked, it doesn't show up in the output of ldd, you can't statically link it when you compile the program. Rather, the /lib/libnss_* libraries are loaded with dlopen().

So I'm forced to compile three separate static versions of my program, and that doesn't even count glibc2.2 which I'm not using yet.

Another problem with static linking is one of efficiency. A statically linked program has it's own copy of the libc (huge) in the executable. Besides making the executable huge if you want to download it, it uses a ton of extra memory. Instead of using the copy of libc that is probably already in memory and shared with the processes you have running, the statically linked program needs to load its own private copy of the libc code into memory, which won't get shared with any other program. The result is the memory needs of your system would double or more if every binary you had was statically linked.

Netrek had a similar problem with this untill they integreted RSA into the clients. basically if you wanted to play on one the servers with it enabled you had to play with one of the pre-compiled binaries with RSA built in(called blessed clients). if the server didn't force RSA authentication, then you could compile and play with your own clients and use cheats (these were called borg clients).

It didn't take long before almost all non-practice servers were using this RSA authentication.

You also fail to notice another important benefit. By hosting the server-side software, they control the security on their end. Character information will be stored on the server, not the client. This will making cheating much more challenging. They will also be providing server space and bandwidth. The server and bandwidth requirements for a on-line games grow exponentially with the number of players. Hosting a 16 player Netrek game is one thing. Hosting an EverCrack server requires a lot more resources. IMHO this is a great pricing model for the GPL.

More accurately, it will become impossible to prevent client side cheating. However, it was always impossible to prevent client side cheating, the best you could do is make it very hard to do. All it takes is one skilled hacker to develop the cheat and release it to the world. Ultimately, if it's possible to cheat and the sort of people who like to cheat like your game, they will cheat.

Every game developer should strive to reducing cheating. To reduce cheating based on hacking the client, you simply move information off the client and onto the server. However, this makes writing the game harder. In some cases, it's not really possible to move everying important off of the client. In these cases you simply have to rely on security through obscurity to make it hard to cheat, and shuffle things around between releases so any given cheat doesn't stay valid for too long.

Developing such a product completely open source means you can't rely on this. But this doesn't mean you can't develop a fun game. There are at least four solutions that will work for many different types of games.

1. Build a culture around the game that dislikes cheating, perhaps by making cheating relatively useless. Plenty of MUSHes have no strict rules, and player who wants can give himself piles of money and huge attributes. The more serious players will simply ignore anyone who twinks himself this way and enjoy themselves.
2. Build a game where important information simply isn't available to the clients. Obviously this is hard, but in many cases it's possible. RPGs lend themselves to this state. The server only trusts it's own numbers, so you can't give yourself infinite power. Rapid targetting isn't very important, so computer aided targetting isn't very useful (in fact, it could be explicitly added to the client as a feature). At the generally slow pace of an RPG, knowing what's immediately behind a wall using transparency or model mangling isn't that useful.
3. Build a game where modifying the client is part of the game. Obviously the appeal of this will be limited to fairly geeky people.
4. Use a blessed binaries approach like Netrek. The source is all open, but to play on "secure" servers, you need to use a binary provided by trusted developers.

NeTrek solves this problem by only allowing "blessed" clients. My understanding is that these client are digitally signed somehow to prove that they are a compile of a non-cheating client.

Apart from being one of the earlier internet games, Netrek remains one of the few true team-strategy games. Pitting up to eight players against eight (thought I believe there can be 32 in it these days) for three or four hour long battles, Netrek demands the most from it's players. The playing curve is even longer than Quake - it can take 30 hours of practice, before you can even remotely hold your own against good players...but two poor players can sometimes beat one good one. Over the years, the game has been rebalanced to perfection. I urge everyone to download it, and give it a go!

We used to joke about netrek being a network testing tool - it was one of the first real-time multiplayer Net games.

Those were the days (even if Australia did get thrashed by CMU playing with 750ms satellite lag on an Australian server).

Danny (ICMP Redirect).

However, Things would not be as easy, and some things would be lost. The internet has inspired many newer people to get interested in computers. This can be good (they decide they like what they see, and try to make it better.) or bad. (They don't understand or don't like it and try to destroy it.)

Can we stop it? No. Should we stop it? No. Should we try to make it better? Yes. If it turns out badly, should we quit? No. Educate yourself, I personally want to read the bill, not an interpretation, because it may not or it may do something I like/dislike. For example, according to the US constitution, do they have to be 18 years old? No. (read it, it only says they should not be abridged for 18+ year olds)

btw: Netrek, a very good 16 player space combat game, has a good website at www.netrek.org

I've read a lot of articles about the worth/unworth of playing games. Why must they be so homogenous? Why always the first-person and the third-person shooters? What about the muds, Civilization, and my two favorites for many years, Netrek and Core War. Those games are a diverse set that look nothing like each other. Don't just say "games are great" or "games are mind-numbing." It's like saying "books are bad" because you didn't like the last one that you read. Please consider that a computer is a programmable machine that can perform more than one kind of task.

Ah, I remember fondly the days of running netrek on a crappy black and white Mac, drooling at the graphics...

...and it looks like it has only gotten better.
---
pb Reply or e-mail; don't vaguely moderate.

Netrek's homepage is here, not here.

Disclaimer: I don't know details about netrek authentication, everything I say is mostly based on what I read and common sense.

Oh I get it! So the authorized client's source is different from the publically available source (the difference being the key). Well IMHO that doesn't count, because it's not /totally/ open source...

It is open source, except that the private keys aren't made public. What more do you want? You could plug in your own keys, only the servers wouldn't accept it as a trusted authentication (well, start your own server with your own trusted keys list).

Unfortunately, it's still security through obscurity.

Having everything except for the private keys is not security by obscurity. You have the code, you have the algorithms. There's nothing obscured. By your definition all cryptography would be security by obscurity.

Somebody will disassemble the binary and find the keys, then plug them into a modified client.

This shouldn't be that easy. I think there could be a few tricks to avoid including it in the clear (mostly making it dependend on the rest of the code so that it really authenticates the binary and not the key alone).

Info on Netrek in general can be found on the Netrek Continuum.

You're thinking of Netrek. Some Quake players came into the Netrek Newsgroup asking nicely for help on how to secure the game.

I don't know where this led, but I'm sure all the trek players would be curious to see if there was ever any success.

Netrek uses rsa client authentication--the source for the client and the server is completely open, so anyone can write custom hacks into them. However, most of the public servers have a list of "blessed" client keys. So if you want to play on one of these servers (there are some non-authenticating ones), you need to (a) obtain the source to generate an rsa key--this is currently just to comply with export restrictions--and (b) submit the key to a volunteer key maintainer.

The cool thing is that most of the discussion about what's "borgish" (non-kosher robot features) and what isn't is public; there is no central governing body which decides what goes and what doesn't, it's all done through public scrutiny.

Either way, it's a problem that is going to have to be addressed. In anybody is interested, a once very popular networked game that had cheating troubles, netrek, solved it by compiling official, or "Blessed" binaries for different platforms. Using RSA encryption, they would encrypt a bunch of different client keys using an encryption algorythm. Upon connection with a server that had client checking enabled, the server would request client verification. I'm sure you could find more detailed information at The Netrek Homepage at www.netrek.org. (Now that's a site I'd like to see slashdotted. It ain't Quake, but you win through "Genocide," or taking over all the enemie's planets. :) )

GT will decide on linux support for games based on financial reasons. Sending them annoying(pleasant or not) emails won't change their minds.

Buying a game just to support an OS is a waste of your money. Not buying a game out of protest will hurt you more than anyone.

There are plenty of free games out there. Netrek ( http://www.netrek.org ) is about as good as a net game can be as far real-time strategy and teamwork go.

Anon Twink

Undoubtedly, some people would bend or break the rules of the game, either just for the joy of hacking,or in an attempt to gain skills or items in the game that are beyond their current means.

Of course, people have found ways around that, but more or less all serious games are played with "legal" clients.

/ol

But now the point: BSD is boring

Explain. I run Linux as a firewall. It must therefore be boring according to your definition.

I have been using Linux regularly since the 0.99.14x days--only briefly around 0.77 (I can't recall exactly). I will be trying out FreeBSD on my next system withing a month or two. What programs will I NOT be able to run with FreeBSD?

I have two favorite games: Netrek and AOE. The first can be played on most UNIX systems. The second runs just as well under FreeBSD as it does Linux: not at all.

You are entitled to your opinions, but please give evidence when you come down so roughly on something.