Architecture for multi player gaming

I am currently looking into costs for a new company where there will be a large number of disparate groups playing against one another either over a wireless network at a single location or over a WAN (or a mix of the two). What is the best platform to develop on - currently i am assuming PC? (I want to keep hardware costs down but also licensing costs) Ideally i want to be able to develop a game that will playable either in a client server environment (if there are enough clients to warrant a server) or else peer to peer where each game resides on its own client should a particular installation only require one or two machines.

Is this possible or do i need to make a decision now?

Who is Participating?
str_ekConnect With a Mentor Commented:
the eaziest way to pick up a scheme is to sum up the communication needed to work it up in schemes you consider worthy

in my opinion, c-s is the most sensible solution... with p-p you get synchro problem, and with rapid action ( p-p is great for i.e. chees ;)) it'll impact state integrity...

you can experiment with c-s with serwers comunicating each-other like in a node network... most of p-p pros, and almost c-s integrity ;)

it all depends  on your game thou... bandwidth usage and/or world update frewency etc. may exclude p-p and hybrid
sunnycoderConnect With a Mentor Commented:
Hi lz7cjc,

What kind of games are you looking at? From your description, it seems that web based games or flash games which need only a broswer to be installed at the client are a reasonable compromise for all your contraints.

Obviously this restrains the complexity and the effects that you have in your game.

If you can detail a bit more on the game itself, may be we can help with an architecture

lz7cjcAuthor Commented:
thanks Sunncoder - the games will need to be graphically rich- they will be simulations similar to Tour de France on the XBox and Bass Fishing on the game boy advanced...  
there will also need to be the ability to save previous performance  - a little like the ghost in Mario Kart time trials that shows how you are doing compared to the record time.

I reckon there will be a fair amount of processing required - web based games won't offer enough umph!


Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

str_ek more or less says it ...
If it is going to be real real multiplayer like you have several ppl joining in and leaving like say 30 or more cars racing, then Client Server is the way to go ...

If you have far more entries or tournament kind of stuff, an hierarchical client-server might be the way to go.

If you are going to have something like scrabble or connect 4 peer-to-peer will be a better way.

The exact specifics will depend on the game and its intended use.

Are you bothered about licensing cost borne by clients too ? If yes, then consider developing a game in Linux ... It might not be most fancy but if coded well, (like quake) you can get almost as good performace as windows.
lz7cjcAuthor Commented:
thank you both - as you may well have gathered i am not a game developer ... so would you mind explaining to me what a "scheme" is and "state integrity" in this context...

also how is that XBox Live allows good multiplayer gaming - surely this is peer to peer since there is no central server - btw the example of 30 players driving 30 cars is a good one .. this is the sort of thing I am looking to develop with different people joining and leaving at different times and having the facility to also see how their current performance relates to previous performance.

is it possible to develop a game that can be played in both a peer to peer and C/S environment at the same time depending on the demands of the individual installation

... i am keen on developing within a Linux environment - if there isn't a performance hit
>is it possible to develop a game that can be played in both a peer to peer and C/S environment at the
>same time depending on the demands of the individual installation
It is possible but means more work ... alternatively, you can designate one of the peers as a server ... lesser work and similar performance

>... i am keen on developing within a Linux environment - if there isn't a performance hit
Linux does not have the kind of support or following as windows but if you can program well, it is possible to make just as good games there too ...

Scheme means literally the scheme you use for your game play  .... There will be multiple ways of doing a thing ... the steps involved form different schemes.

After every move, your game will have some sort of state ... say in a racing game, driver number 5 just over took driver number 4. The state of the game has changed and this should be uniformly updated at all the sites ... This is the state integrity requirement ... All players should see the same game state. If player 1 sees himself as winner of the race and player 5 also sees himself as winner of the race just because there was synchronization problem between them then state integrity was compromised
true... xboxlive games are generaly p-p based, and there is only a sort of lobby for gameplay anoncements ( well... you need to hnow who you're supposed to connect, whos plaing etc... those info are to be known to everyone, so that if i dont know any of players address i can get this info anyway!)... that brings a lot of problem with state integrity, cos ther is no way to check if the computed state (computed form all peers queries, incoming with different speed, fragemntation etc. ) is the same as the state computet by peers for this exact moment of time.... you can ask your peers what was there state for a specyfic moment, but it takes a lot of bandwidth, cos you need to know all the states (all complete world states from all peers) ... it simply sux, this approach is costy, hard to code etc. and when you code it right you wake up and say geee... i just made p-p to simulate c-s behavior ;)

most sensible approach is to forget about synchro and make the system as disortion-proof as possible... you wan't get insurace that all the players are plaing the same game ( well it may differ a bit in interpretation, meddages will come in warious moments), but it's eazier to implement

for example : you can force time synchro of all peers in the wery begginig of the game, then you can limit communication (except non-vital) to messages descrybing changes of speed vectors (of all moveable elements).... then you can timestamp every message with an exact time the change is to be applayed ( cos of network latency it will be somewhere in the past) ... that way you can reconstruct an _exact_ trace for every player up to last message, as i said it'll be somtime in the past, so the present state is unknown.. in general games cope with this problem using simple state extrapolation... ie. if a player is driving stedily with a speed vector a we siply calculate car possition on speed*time basis, when the player is turning right vector changes send by him will report more or less exact constant vector changes, you can apply an angle/time average just like a player did when he send you his messages.... the tricky part is that you must verify it all when "real" message comes, there is a great need for cancelabel messages like - player turning right just lagged, so he hits another car, bu then you get a messge form car he hit that it turned as well and it wasn't inthe place of crush, so you need to cancel the hit event... with a resonable mesae system and sensible banwidth it's the best you can get :)
davebytesConnect With a Mentor Commented:
xbox live is NOT peer to peer.  One of the clients acts as the server/host for the game.

Most modern game systems use a client-server architecture, even if only two players.  Easier to code for, easier to debug, easier to expand to more players.

some xbox games ( nowdays most of non-hit ones) uses p-p networking system

i.e. MotoGP (look at it's official forum

it's not an argumet pro p-p i'm still strongly recomending centralizaton it eliminates all p-p related problem i decribed earlier, and forces standarized precognition nodes (the real world state snapshots) for all clients
lz7cjcAuthor Commented:
this is all very useful - thanks for your input so far...
on the question of peer to peer vs C/S what happens if  there are groups of people playing in geographically disperse locations eg 3 in one place, 5 in a second and two in a third - could i have a local server in each location or would i be better off having a single server and then clients in each of the locations? would the latter work over ADSL 512k or would i need more bandwidth?
for a racing game it more then enough... only porb could be latency... (long distances = "satelite jumps" and it couses a significant lags ( i mean in as per medium, distanc earth-goestat i the prob)

let me give you another egzample...
remeber quakeworld - the very net-proformance oriented quake flawor worked c-s , it was a good choice, cos' of dynamic nature of the game... bu when quakeworld scene developed, and various worldwide online tounaments emerged the game was haveing a seriuos problem ... there was just a little to much to send, if the quantity of information could be reduced less packets would be send, and less packets means shorter latency of etire message ( cos of dynamic routing nature... networks nowdays are all based on packet commutation!)...

this problem was solved by proxy servers (like qizmo) they stripped uwanted info and compressed data  transfered between proxy and proxy client , this way overal preformance increased, a player haveing a proxy somwhere "near" the server was achieving grater preformance than player connecting directly

it's not what you seek, but it might be inspiration :) haveing a master server and network-limited ones connected to it will be more efecient (but much harder to code!!!), haveing an eazy to debug plain protocol will be usefull, but lagging, and haveing the same plain protocol compressed within every complete "state frame" will help it out :)

well what can i say more...
just make a good analysis of what you need to tell other players, and ho wfrequent .. sum-up bytes and then decide if there is any need for ladder c-s if possible - stay at c-s level, and have a few weeks more of your life ;)
bcladdConnect With a Mentor Commented:
Actually, MotoGP is both client/server and peer to peer (sessions are mainted by a designated host). Take a look at a postmortem discussion by the programmer: 


There are competing resource limitations in a game. Using a C/S architecture, the bandwidth and CPU of the server machine are likely to be the limiting factor. Many games use optimistic physics calculations on the clients: when a move is made, assume the world looks like the client thinks and start moving; if the server corrects our interpretation of the move, apply the fixup. Notice that a non-local entity has all moves come from the server so the latency between another client moving and my seeing it is two hits to the wire.

In p2p, everybody keeps their own view of the world (a complete view) and (effecitively) all input is replicated to all participants. This makes the client bandwidth a limiting factor (I have to see all other participants moves). This design is prone to abuse if you can't assure the integrity of clients (full world knowledge means a client could give me too much power: x-ray vision and radar hacks exist in many games that share too much information with clients).

The client/server architecture does not require a separate computer for the server (look at UT2K3/4, for example) though low-end PCs will be crippled by either rendering OR serving so asking one to do both is a recipe for an unsatisfying experience.

The idea of hierarchical servers, or a distributed server, is interesting. Maintining data integrity in replicated data is difficult. Games with distant "geographies" in the game (Everquest tend to use clusters of cooperating servers because there are limited "interface" areas where both servers must be interested in things and the rest of the gameworld is partitioned between the servers. Consider a "mainland" server and an "ocean" server. They only have to worry about items that pass through the "beach" and, with good level design, players won't spend a lot of time on the beach. They will move through on their way somewhere else.

str_ek has it right that the hard part of communication in any of these architectures is limiting the data to the interesting data. Read the MotoGP post mortem for some hard won insights (yeah, some are Xbox Live! specific but most network comments are not and the ones saying that networking (or setting up the connection) is as much a UI problem as anything else is really, really insightful. Using state machines is a bit obvious but some of the others are good to keep in mind). Relavence of the data being sent is important to establish and the data should be compressed when possible (quatize values, for example).

Good luck,
lz7cjcAuthor Commented:
so it sounds like it is horses for courses and the key is getting the design right based on my key requirements - as in any software design process... and keep the amount of information i need to pass between geographically remote locations to a minimum in order to keep everyone in sync... is that about the size of it? now i can't work out who to award what points to since you have all been helpful... anyone got a problem with the following:
 str_ek: 100
sunnycoder: 50
davebytes: 50
bcladd: 50

thanks for your help on this - will no doubt be back with more questions soon!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.