Name: David Groves Location: London Posts: 9 http://www.poddle.net -------------------------------------------------------------------------------- This is a simple list of things that would DRAMATICALLY increase the chances of a game becoming a popular online game. Some of these things are easier to implement that others, but you will notice the most popular games like counterstrike already have most of these features. Of course, if you design a really shite game, none of the rest of the article is going to be of any use to you whatsoever. Good netcode. Good examples, Quakeworld + Qizmo. Low bandwidth, consistent, little warpyness, relatively kind on packetloss and high latency (which are impossible to deal with), doesn't excessively trust the client. Bad examples, Quake3, unplayable on ISDN, certain CS versions, trusted the client far too much, making for trivial exploits. Trust me game developers, hire Zibbo and Perkele (zibbo@udpsoft.com) to sort out your netcode, I doubt you will regret it. Include a 'competition' mode WITH the game. The best examples of this are kteams for Quakeworld, or OSP for Quake3. This allows organised teams of people to play easier. Notably CS hasn't done this. Perhaps if they did, the competitive scene in it would be even larger than it is. Multilevel admin support. Administrator privileges on a server shouldn't be all or nothing. Almost all games ship with it like this at the moment, with the 'rcon' system. I don't want to give some people administrator rights to kick idiots, and maybe change the map if its a 20v20 map and 4 people are playing, and also give them the rights to shutdown the server, and maybe poke around on the computer its hosted on (rcon dir in Q3 springs to mind). Voicecomms. Integrate voicecomms into your games. That is the ONLY way that public servers are going to see voicecomms in use, and that is the ONLY way that you will see real teamplay on public servers. I'd really like to see a project get going to write a BSD licensed bit of code for windows clients, and windows/*nix servers that just allows this to be a "bolt on" job for game developers. Anyone also interested in doing this, please mail me. This also lets you impose things, like stopping dead players from talking to players. This is GOOD. Remember the dedicated lamer clans will cheat by using an external voicecomms programs anyway, but this at least helps. Be LAN friendly. Yes, this is mainly you blizzard. Always allow people to just type in an IP address to connect to another server. Some large lan events VLAN networks into several segments, mainly for management reasons, and to limit exploits (accidental, like lan clients running DHCP servers, or intentional). Since most "broadcast" methods of finding games won't cross these boundaries, just let people type in IP addresses or hostnames somewhere please. Also, and Tribes2 and Dynamix are being shouted at here, don't make assumptions based on the netmask about clients being on LAN or the Internet, thanks. Be mod friendly. Keep a non-profit EULA if you want, but release mod tools for your game. Go the undocumented route if you want. Just look at halflife and counterstrike to see the benefits this can bring. Well played id software for making this common in the first place. Cheats. We know it's not possible to make a cheat free game when you have to put any trust in the client at all, and we know its not possible to make a playable game if you don't put at least some trust in the client. But it is possible to make the cheaters life harder by releasing constant patches that just make them have to work harder with a disassembler to insert the correct hooks, or crack the appropriate part of the network code. Maybe the right answer to this is a patch a day, with the compile run through an object code obfuscator with a different seed each day. This does need a good update mechanism though, see below, and may well be fatally flawed if the obfuscator is predictable. This combined with normal bugfixing patches that change the code logic should at least make things very difficult though. Patches. As mentioned above, if you are going to have frequent patches, you need a good auto update mechanism. You also need a good non-auto update mechanism. Heres why. Without a good auto update system, people won't have the latest version, and having to patch up to play deters the casual gamer. Without a good non-auto update people, it is hard for people without internet connectivity, or temporally without internet connectivity (ie. at a lan), to update. Ideally the auto update mechanism for the clients is just to ask them if they want to update, and then for it to just work. It should be fast too, so maybe keep deltas from every version to the latest version on your update server, rather than patching through 30 versions to get to the latest. Ideally the non-auto update mechanism should be a single patch that takes any version to the latest version. It's less of an issue if this has to go through every revision to get to it though. Server patching. Nobody seems to have done auto-server patching yet. Lots of people do auto-client patching. This to me seems equally important. See the section on patch security though. Maybe with FPS like games you can check for an update at a map change, and with other games, maybe have them all shutdown for update at a specific time (and broadcast warnings about it before it happens, like unix computers being shutdown). Ideally, be like irssi, the IRC client (www.irssi.org), and don't need to be shutdown at all, (but don't be like irssi and get your configure script trojaned :). Server browsing. Either do it right, or leave it to someone else, don't do a half assed job. A good example of an in game server browser is UT. A bad example is Quake3. A good example of leave it to someone else is Quakeworld (and the then Quakespy). GUID's. Being able to see other players GUID's, (usually a hash on the CD key) is important. Particularly if like most FPS games you don't have accounts to get names. This lets you see if the person you are playing is REALLY the person they claim to be, and stops people pretending to be someone else and behaving like a lamer to get a bad reputation for that person. Secure updates. Please sign your updates in a secure manner. You have an excellent method of distributing your key, just put it on the CD that the game comes on. CD key authentication. This is needed to prevent piracy, and thats good. The client --> CD key hash --> server --> authserver is the correct approach though. Also, PLEASE make your auth servers reliable, nothing pisses people off more than being unable to play a game because you or your ISP have ed up. (Hello Blizzard !). *nix servers. Don't be like Medal of Honour. Lots of server admins like to run *nix servers. Why take a game based on the Q3 engine that has a wonderful linux port, and just break it. Please design your games so at least the server can run on linux. Ideally have it able to run on as much as possible. I'm not sure of the current state of cross-compiling, but this seems to be an ideal way to get out other platforms too. Imagine a IBM Bigass S/390, or a Sun E15k system running 19247819741 of your servers, doesn't that appeal ? No backdoors. Just NO backdoors. Bad id software. Fix your bugs. A crash bug needs a patch, no matter how rare the crash is. Example of unfixed crash bugs in games are Quake1, and the teleporter at the start of e4m8 (RJ onto the right hand side of it). A blatant exploit bug that allows people to spoil the game also needs quick fixing. CnC renegade and the beacon your own base even though friendly fire is off if you quit the game after dropping the beacon bug, this BADLY needs fixing. Listen to the community. Anything the game lets you do shouldn't be classed as cheating. I'm thinking mainly counterstrike here. In counterstrike, some people decided to make standing on each others heads to make a tower of players to boost someone up to a normally unaccessible place against the 'local rules'. Imo, if the game allows you to do it, it isn't cheating. If this is to be considered cheating, the game should be patched to stop it. Also, some bugs are GOOD. Remember rocket jumping wasn't planned in Quake1, it was an 'incidental feature'. Neither was bunnyhopping in Quakeworld. In my opinion both of these add to the game. If you ARE going to change something because you don't like it, but missed it in QC, do it EARLY. Bad examples of this were the removal of bunnyhopping from Counterstrike, and the removal of through floors damage in Quake3, both of which should have been done FAR earlier than they were (or just plain left alone). The same applies to graphics settings. RTCW is a good example of the 'right' approach to this, but I don't like the way punkbuster and it allow different server operators to declare different standards. This leads to situations like in Quakeworld, where different countries play different rules, which leads to all kinds of problems in international play. This isn't like Amercian Baseball, and the designated hitter rule, this is like different numbers of players on each teams, totally different maps, and differences in your ability to hurt your teammates or not. Nothing is wrong with having softcore modes and hardcore modes, as long as its clear that the competitive players should be using the hardcore mode, and you are only changing the rules between modes, not things like the physics or the map layout. ie. this shouldn't be vanilla Quake3 and CPMA Quake3, which I would class as different (although similar) games. Dedicated servers. Please work hard at optimising these so they need as little memory and CPU as possible. This will make the people that host your servers happy. I really am quite stunned when I see the amount of resources say Quake3 consumes compared to Quakeworld. I can understand it from the clients and flashy graphics point of view, but I'm not sure why they require it on the server side too. Dedicated server hooks. I would love to see a standard API for controlling programs to interface with dedicated servers, to add bans, shut them down, change the mode they are running in etc ... At the very least, please make your win32 servers simple console apps, and not have rubbish wrappers around them to make them look pretty (or at least have a runtime flag that gets rid of that rubbish). This makes manually hooking into your server far easier. Also, if you write a *nix dedicated server that needs X, you should be shot. (I've forgotten which developer did this). Dedicated servers that don't require the game to run. This allows ISP's and the like that wouldn't go and buy the game to run the server. Halfife GOOD, Quake3 BAD. Console. id software introduced the console, and the console was good. However, the console should only be a quick way for experienced people to operate things. You shouldn't ever need to drop to the console for anything. Every single graphics tweak, sound tweak or whatever that the game developers consider "legal" should be in the menus somewhere, preferably with a tooltip or other explanation saying what they do. Also, please use the standard console key, and don't need people to run the program with some fiddly command line option to get at it. International keyboard support. This is getting better, but Quake1 had a total disregard for it, as did Allegiance (a MS game that died due to several bits of mismanagement that reading this webpage may have solved). Portable settings. A player should be able to save all his settings in one file, and be able to load all these settings on another computer. He should have to fart about with what settings are in the autoexec config, and what are in playername.cfg, and what are in the mods directory config.cfg etc ... It should be a simple option to "save all my settings". Of course some things like mouse drivers affecting sensitivity are impossible to deal with, but you should make your best effort at this. Autodownloading of custom content. Without this custom content doesn't get used. It's pretty much as simple as that. Ideally have a field that is part of the custom content that is "download locations", and have the client fetch (by http or ftp) from these locations if possible in preference to fetching directly from the server (to save on bandwidth on the server). If this isn't possible, have a tuneable parameter as to how much bandwidth the server will use for providing custom content to clients (don't have it default to something far too low, like Quake3 does). Multicast spectator tools. Like HLTV. Ideally actually using proper multicasting when the internet in general is up to it. These are essential if you want your game to get a good following as a 'spectator sport', in addition to having people play it. Possibly have the viewer for this not require the game, so people can download it, watch championship level games, and want to buy the game to play it themselves. Like the Tennis effect in the UK everytime Wimbledon is on the TV, for the month afterwards, all the public courts are full, tennis racquets sell 50% of year round sales at this time, and then everyone forgets it till next year. Demo recording. It should be easy to record demos from a players point of view, of what they did that game, for later playback. Ideally, the server should also be able to record server side demos of what every player did in the entire game. Please look at compressing these demos as tightly as possible, look at the file size differences in .qwd and .qwz in Quakeworld/Qizmo for an example of what happens when you don't.