mirror of
https://github.com/ENSL/NS.git
synced 2024-12-12 13:42:49 +00:00
342 lines
14 KiB
Text
342 lines
14 KiB
Text
|
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.
|