Results 1 to 29 of 29

Thread: Good multiplayer game programming tutorials? (from beginner to advanced)

  1. #1
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default Good multiplayer game programming tutorials? (from beginner to advanced)

    I tried checking out gamedev.net and googling for multiplayer programming information, but after searching for while I decided to the easy way

    Do you guys have some links to multiplayer game programming? I've been doing this for a loooong time, but I think I might be blind to some better solutions and would like to get guidance on this.

    Any recommendations?

  2. #2
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    And forgot to add that I'm especially interested in combat (close-combat) situations. I'd like to hear efficient solutions on how to inform about attacks, special moves etc.

  3. #3
    Member
    Join Date
    Jun 2005
    Location
    Pretoria, South Africa
    Posts
    52

    Default

    Yeah, most multiplayer tutorials out there seem to stop at the "establish connection" milestone. Very few people seem to think what you actually send is important at all... Meanwhile that's probably the hardest part of the whole exercise.

    In any multiplayer game you've got three problems you need to solve: Timing, Identification and Determinism.

    Timing is simple to explain: If you don't have a unified, identically progressive time system on all connected machines, you have a problem. You need to be able to sync time to be able to identify when things happen in the game and when messages arrive. The simplest timing system to use is a turn-based one, where machines move in lock-step through the game according to whose turn it is at the moment. The most complex is a real-time system, for obvious reasons.

    Identification is all about being able to direct the correct data to the correct area in your game. You shouldn't need to worry about routing with most networking implementations, but you do need to come up with a way to uniquely identify each machine and have all other connected machines aware of that identification and "who they're talking to". You also need in-game identification to make sure you're sending info to/from the right objects. A grid-based identification system (as in chess) is the easiest to implement because it provides inherent identification via positional info. Once again, realtime games have the hardest time with identification because each object needs to be issued a unique (but synced!) identifier across all machines.

    Determinism is the predictability of your game. You only need to send as much info across the network as you need to ensure matching game states across the board. So a very deterministic game will only require small amounts of information (ie: the exact choices the user made, because these are the only points that difference can exist in the system) whilst a completely non-deterministic game will require all the info that describes a state to be sent, sometimes as often as every timestep! Things like creating lists of random numbers, broadcasting or re-seeding them in chunks and creating time-based lookups for random-equivalents are ways to help creating deterministic gameplay that doesn't look pre-determined... Determinism also helps in lag-elimination and prediction in realtime games, but that's a whole different level of implementation.

    Good luck. The key part of any multiplayer endeavour is to build the whole game with multiplayer's three problems (and their solutions in each case) in mind.

  4. #4
    Senior Member
    Join Date
    Aug 2004
    Posts
    443

    Default

    Unfortuanately, like most things related to games that don't have to do with graphics, there isn't much information out there on multiplayer programming.

    Brian Hook's Introduction to multiplayer programming and Quake 3 Networking model and both great high level resources. I would look into using a networking library like RakNet, ENet or OpenTNL, or at least looking at the source and tutorials to get some ideas about how to implement a UDP networking library. For a lower level guide to socket programming Beej's network programming. Googling client-side prediction and dead reckoning also might be useful.

    It sounds like you're making a fighting game. Although there is very little information on networking fighting games out there, I think you'd want to go with a RTS-like peer to peer lockstep model. The game runs at a certain number of turns per second and each turn players send their inputs and an acknowledgement to move to the next turn. Turns per second can vary depending on network latency, but you'd try to update at a decent rate. The game simulation runs independently on each player's machine. Latency is covered through a combination of client side prediction and clever animation. DOA4 on Xbox 360 seems to work this way. When there is network lag the game seems to run animation until there is a "decision" point where it pauses until you receive the other player's input.

    I've never implemented a networked fighting game or any kind of latency sensitive networked game, so take all my advice with a large grain of salt.

  5. #5
    Junior Member
    Join Date
    Jun 2005
    Location
    los angeles
    Posts
    10

    Default

    I agree, despite the pervasiveness of multiplayer game modes, information on network programming as it pertains to games is sorely lacking. That page on Brian Hook's site is probably the best overview I've read so far, thanks for the link.

    Speaking of which, does anyone know of any tools (software or hardware) that can simulate various types of connection quality issues, such variable latency, packet loss, disconnects, etc? I saw an ad for the KillerNic "gamers" network card and it had a feature that let you set the amount of latency (faking a higher ping). Ideally, I'd like to be able to reproduce typical WAN connection problems in a controlled LAN environment.
    Rasterwerks | Phosphor - multiplayer FPS in a web browser (beta)

  6. #6
    Senior Member
    Join Date
    Jul 2004
    Location
    Isle of Wight, UK
    Posts
    3,863

    Default

    We've built all that nasty stuff into our engine layer. You can set a few variables for packet loss percentages and stuff. I'd recommend this as it's the simplest way to do it, you keep a 100% speed connection if remote debugging, and its fine if you don't cheat. (Just throw that packet away, don't simulate it, ack it, anything. Just return false and ignore it).

    One key point to be aware of is that there's a big difference between 2 player and multi player modes, especially for peer-to-peer. If you're playing chess and the other guy disconnets, the games' over. If there are 4 guys playing something and someone quits, you need to tell everyone else about it and carry on. If he was the host, you should consider promoting someone else instead of this lame "the host has shut down, we're done here" cop out.

    For your first time out, get it working well with 2 players before adding the code to support >2. Staying "up" when one player leaves is actually quite a lot of the low-level work and for 2 players you can ignore it for a bit.

    We've got a fairly decent network layer in our engine, but I didn't read much theory about the high-level side before starting. When you sit down and think about it, the problems kinda present themselves and are nicely summarised above.

    Contrary to other opinons expressed above, I found it harder to do the low-level stuff tbh. Proxy issues, ICS, NAT punch-through and shared connections etc add a load of shit to your todo list once you try and deploy something in the real world and you find that only 10% of your audience can see each other.

    I'd recommend a very thin "introductions only" server model that clients log into to find players, and then the game launches peer-to-peer when some are found. There will be no in-game server induced latency and you can run the intro server on any box - it doesn't do any game processing so can be done from your own website if need be. This is extra hassle but it does solve lots of problems getting clients to see each other as the server collates all the IP addresses and passes them back out. The fact that the clients connection to this server is "outgoing" means you'll actually *get* an IP address at that point that can make it back through a firewall and all the other crap.
    Regards,
    Paul Johnson

    [Great BIG War Game: iOS | Android] [Great Little War Game: iOS | Android] [Fruit Blitz: iOS | Android] [Yachty Deluxe: iOS | Android]

  7. #7
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    Hi and thanks everybody for your assistance.

    I print & read some of the articles: Q3 model, AoE1-3 models, RakNet tips. I also tried to find some more articles and came up with these:
    - http://www.gamedev.net/reference/list.asp?categoryid=30 (gamedev network programming category)
    - http://www.gamedev.net/reference/art...rticle2319.asp (server optimization)
    - http://www.gamasutra.com/resource_gu...mbright_01.htm (states & object views)

    I also read some cubic splines & that sort of stuff.

    key findings
    I'm still amazed that there's so little articles in this area of programming! Majority of articles are somewhere around 5 to 10 years old - and maybe it's just me, but it looks like the fundamentals have not changed much (of course we now have more bandwidth available and stuff like that, but there's for example one dead reckoning article dated back to 1997). Basically the Q3 system (and use of states) is something that's applied in modern games and so is the stuff that was explained in the Age of Empires article.

    It strike to me that "big companies" aren't doing the networking in some "secret ways" (or they just don't share 'em ) - it looks like developers are using the same "basic" ideas (like defeating lag, using states etc.) and combining the stuff to make a good multiplayer experience.

    So far I didn't find many new things, but rather got convinced that I'm going in the right direction already.

    peer-to-peer?
    Brian Hook's article describes peer-to-peer as something where "client decides things" (like "did I hit the other player?")... but isn't that misleading? I mean... client can still "decide things", but the messages can go through server-client system (client tells server "I hit something" and then server tells other clients "who was hit").

    Isn't the basic idea behind peer-to-peer that "everybody tells everybody" and in server-client "everybody tells server who tells everybody". Neither system is NOT saying "who can decide things" (=where game logic can be run).

    Correct me if I'm wrong.

    MTU
    RakNet has some programming tips and the MTU was totally new to me (thanks again for sharing this articles!)

    It gave the following numbers:
    * 1500. The largest Ethernet packet size; it is also the default value. This is the typical setting for non-PPPoE, non-VPN connections. The default value for NETGEAR routers, adapters and switches.
    * 1492. The size PPPoE prefers.
    * 1472. Maximum size to use for pinging. (Bigger packets are fragmented.)
    * 1468. The size DHCP prefers.
    * 1460. Usable by AOL if you don't have large email attachments, etc.
    * 1430. The size VPN and PPTP prefer.
    * 1400. Maximum size for AOL DSL.
    * 576. Typical value to connect to dial-up ISPs. (Default)
    Basically this would suggest that 576 bytes would be the typical max packet size for dial-up users. I have wondered what the max packet sizes are and this info relieves my pain: I've wondered whether to send 40 byte or 100 byte packets as they get so big.

    I still have a question: do you know if bigger packets have greater odds to get dropped? I mean... if you send 10 packets containing 50 bytes each, or 10 packet containing 500 bytes have these bigger packets greater chance to not to arrive their destination?

    sharing my ideas
    Basically my game is sort of combination of RTS+FPS in terms of network programming. I don't need fast paced strikes or fast movement like in FPS games, but I will probably need bit faster updates than in RTS games. There will be something like 10-30 units fighting at screen (and none anywhere else).

    I'm not going to go into peer-to-peer things, but rather use server-client model. The basic network logic will be something like this:
    - server tells everybody where everybody is and what their status are (with possible exception)
    - client tells server where they are going, who they want to attack and what powers/special moves they want to launch

    That's basically it - I'm going to test what I'm doing with client movement: should server always check the real positions and let everybody know what's happening, or should the clients be able to move their OWN character right after they've clicked somewhere. I might do some sort of "lag calculation" and timestamp moves so that when ping is around 200-300 all units would start their movement same time.

  8. #8
    Senior Member
    Join Date
    Feb 2005
    Posts
    2,069

    Default

    Here is a high level (script level) discussion of network theory for games by Tim Sweeney (Unreal engine)

    http://unreal.epicgames.com/Network.htm

  9. #9
    Member
    Join Date
    Jul 2004
    Location
    Sweden
    Posts
    65
    Mikael Linusson
    Nordic Software for Entertainment
    http://www.nordicsoftware.se

  10. #10
    Senior Member
    Join Date
    Jul 2004
    Location
    Isle of Wight, UK
    Posts
    3,863

    Default

    Isn't the basic idea behind peer-to-peer that "everybody tells everybody" and in server-client "everybody tells server who tells everybody". Neither system is NOT saying "who can decide things" (=where game logic can be run).

    Correct me if I'm wrong.
    Well, you can do that of course, but it'd be easier just to do it p2p. The main reason for using a server is that clients give it all their inputs, the server itself resolves the frame, then all the clients render the results. In this way there is no room for games going out-of-sync, and less potential for hackers to cheat. The down-side is that hiding the increased round-trip latency is an even bigger issue which generally scales up you code still more. p2p is not always an option, but ime it's one you should take if available.
    Regards,
    Paul Johnson

    [Great BIG War Game: iOS | Android] [Great Little War Game: iOS | Android] [Fruit Blitz: iOS | Android] [Yachty Deluxe: iOS | Android]

  11. #11
    Junior Member
    Join Date
    Jun 2005
    Location
    los angeles
    Posts
    10

    Default

    Here's a good article on lag compensation:
    http://developer.valvesoftware.com/w...g_Compensation

    and an overview of Source's (Half-Life 2) networking model:
    http://developer.valvesoftware.com/w...yer_Networking
    Rasterwerks | Phosphor - multiplayer FPS in a web browser (beta)

  12. #12
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    Oh this is good stuff - thanks again. Let the printer sing!

    @Applewood: the problem with peer-to-peer is that increases the bandwidth requirements for clients - I'm not sure if modem users could handle that load very efficiently (at least in my case). Anyway - I'm not going to argue whether to use server/client or p2p - I'm using server-client already.

  13. #13
    Junior Member
    Join Date
    Jul 2006
    Posts
    7

    Default

    Is that for your game coming out in Q3 ?

    Marshall.

  14. #14

    Default

    Quote Originally Posted by Marshall View Post
    Is that for your game coming out in Q3 ?

    Marshall.
    I see you've read his business plan too. Maybe he changed to Q3 2007 ?

  15. #15
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    It's for the game that's mentioned in the article although the deadline was postponed couple of months ago. There's some major changes in the development (and I'm announcing them "soon" in my blog ("soon" being somewhere before the next ice age)).

    And feel free to start a new threads (or try some other threads) telling about my game deadlines, business plan, whatever... But please, I'd like to keep this thread on-topic: (high-level) multiplayer game programming resources.

    Thanks.

  16. #16
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    It's for the game that's mentioned in the article although the deadline was postponed couple of months ago. There's some major changes in the development (and I'm announcing them "soon" in my blog ("soon" being somewhere before the next ice age)).

    And feel free to start a new threads (or try some other threads) telling about my game deadlines, business plan, whatever... But please, I'd like to keep this thread on-topic: (high-level) multiplayer game programming resources.

    Thanks.

    ---

    Now... back to topic:

    Thanks again for the Unreal article - http://unreal.epicgames.com/Network.htm - looks like a decent resource (for anyone in doing multiplayer games)

  17. #17
    Moderator
    Join Date
    Nov 2004
    Posts
    2,896

    Default

    You could do worse than check out the "Massively multiplayer game programming" books.. Those with Thor Alexander. Seem to be reasonble.

    I'd also point you to the Tribes 2 network model paper the guys did for GDC a few years back.

    http://www.garagegames.com/articles/networking1/

    Multiplayer programming is definitely a fun little thing. Especially for physically simulated objects. I've still not seen a paper that actually does that subject justice.
    www.mindflock.com - social AI-based games

  18. #18
    Senior Member
    Join Date
    Aug 2004
    Posts
    443

    Default

    Quote Originally Posted by Polycount Productions View Post
    I mean... client can still "decide things", but the messages can go through server-client system (client tells server "I hit something" and then server tells other clients "who was hit").
    You can't do this without massive cheating in a client server model. In client-server, you want the server to decide everything. Anything the client decides (collision detection, hits, etc.) is just prediction and if the server tells a client it is wrong it has to correct itself. In peer-to-peer, each client is authoritative and runs their own personal version of the game on their computer. They can cheat, but in theory cheating won't ruin the game for other players because players are running a "correct" version of the game on their machine.

    The big problem you'd have with implementing a FPS style multiplayer model (with lots of prediction, throwing out packets, etc.) peer to peer is the game can quickly go out of sync because there aren't any discrete turns, this is why you need to do things in lockstep. If you're working on a FPS-RTS hybrid with 10-30 characters on screen client-server is the best way to go.

    That's basically it - I'm going to test what I'm doing with client movement: should server always check the real positions and let everybody know what's happening, or should the clients be able to move their OWN character right after they've clicked somewhere.
    The answer is both. The client starts moving their own character right after you click and also tells the server "I want to move here." Then the server decides where the client is going and sends that update to all clients. If the client side state is out of sync with the server update, you have to correct as smoothly as possible... If you have a RTS\Diablo style click on a location to move its a little bit more lag tolerant than using direct keyboard input. You can send the destination and clients can pathfind on their own. I would still have the server send regular position updates.

    Quote Originally Posted by Linusson
    This is a really good one that I forgot about.

    Quote Originally Posted by Applewood
    Contrary to other opinons expressed above, I found it harder to do the low-level stuff tbh. Proxy issues, ICS, NAT punch-through and shared connections etc add a load of shit to your todo list once you try and deploy something in the real world and you find that only 10% of your audience can see each other.
    These are all really nasty issues, but you also need a good high level architecture before you have to deal with them. Networking libraries like RakNet will take care of these low level problems for you, but high level stuff is tied to your game. Some pretty good info on NAT is available here. Check out the rest of the site for some other good articles on networking and game programming in general. He also has a NAT\match-making library called libintroduce.

    Lots of good advice and links. This is definitely one of the better technical threads on indiegamer.

  19. #19
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    Quote Originally Posted by zoombapup View Post
    You could do worse than check out the "Massively multiplayer game programming" books.. Those with Thor Alexander. Seem to be reasonble.
    Hmm... well, it was focused on Massively - which goes bit different zone. Your suggestion made me think if there's any other recommended books (about "multiplayer game programming"). I tried search at amazon.com... with varying results. No proper book was found.

    I'd also point you to the Tribes 2 network model paper the guys did for GDC a few years back.

    http://www.garagegames.com/articles/networking1/
    I checked it briefly. The concept of using bits to flag what to update seemed like a good idea.

    Multiplayer programming is definitely a fun little thing. Especially for physically simulated objects. I've still not seen a paper that actually does that subject justice.
    I bet the physics add another dimension into it. I have no plans to use network physics in this game. Only for visual purposes if any. The gaffer.org article seemed to get quite deep into this subject.

    @impossible:
    You can't do this without massive cheating in a client server model. In client-server, you want the server to decide everything. Anything the client decides (collision detection, hits, etc.) is just prediction and if the server tells a client it is wrong it has to correct itself. In peer-to-peer, each client is authoritative and runs their own personal version of the game on their computer. They can cheat, but in theory cheating won't ruin the game for other players because players are running a "correct" version of the game on their machine.
    At least if you program things in that way in client server model. Which is not always the case (like massively multiplayer movement might be given to clients or something like that).

    The big problem you'd have with implementing a FPS style multiplayer model (with lots of prediction, throwing out packets, etc.) peer to peer is the game can quickly go out of sync because there aren't any discrete turns, this is why you need to do things in lockstep. If you're working on a FPS-RTS hybrid with 10-30 characters on screen client-server is the best way to go.
    Luckily I won't need ultra-fast (like in FPS)...

    The answer is both. The client starts moving their own character right after you click and also tells the server "I want to move here." Then the server decides where the client is going and sends that update to all clients. If the client side state is out of sync with the server update, you have to correct as smoothly as possible... If you have a RTS\Diablo style click on a location to move its a little bit more lag tolerant than using direct keyboard input. You can send the destination and clients can pathfind on their own. I would still have the server send regular position updates.
    Yes. I sort of thought that this would be how it will be done. Server is the authority and I'm going to read carefully the articles that dealt with smooth movement. Destinations/waypoints will be sent... and regular position updates as well.

    Lots of good advice and links. This is definitely one of the better technical threads on indiegamer.
    I agree - great to see these comments/resources/links from everybody. This thread needs some sort of summary soon

  20. #20
    Senior Member
    Join Date
    Sep 2004
    Posts
    540

    Default

    what about books ? can anyone suggest good books on this matter (network, multiplayer games, MMO development )?
    Motorama! Riding can be tough indeed..
    www.motoramagame.com

    Fun Web Games for All!
    www.iplayallday.com

  21. #21
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    I would also like to hear recommended books.

    ---

    What about forums? Are there any "online multiplayer game programming" specific forums out there? So far I've seen network programming sections in some forums - it would be great to find a forum dedicated to network programming...

    ---
    Anyway, as I'm developing the game further, reading these articles I have developed a high level model for the server-client. I believe this reminds Quake 3 model + best practises of RakNet.

    EDIT: This code is to handle gameplay, it won't deal with checking connections, game times or other similar stuff

    Code:
    ***Client: 
    updateNetwork() {
       Receive object state
       Inform server "object state received"
       update object state
    }
    updateInput() {
       if mouseclick/keyhit
          send request to server asking to change object state
    }
    ***Server:
    receiveClientAskingChange() {
       if (change is okay)
          change object state
          flag object NOT SENT TO CLIENTS // clear for all clients
    }
    
    updateNetwork() {
       loop objects
          if (object flag is NOT SENT TO CLIENT) // test each client
              send state to client
    }
    
    clientReceivedObjectState() {
       flag object to SENT TO CLIENT // specific client
    }
    So basically the server would keep pushing object states to clients until each client informs "state received". As there won't be many changes in states (I believe there's only roughly 20-30 objects moving on screen, most of them being enemy units which will have waypoints/targets that are not updated much) I think this model could work very well.

    I would also bear in mind that:

    - no useless data would be sent (when object state changes I would only send what's really been changed (like position, target, health, action - sometimes it might be only action, sometimes only position+target)

    - only newest state would be sent (if there's quick changes in the action of the object, like "receive healing" and then another change "get hit by character", then only the last change would be handled). This could mean that if fighting gets really intense, it might be possible that with poor connections some client might not show all the animations (like "receive healing" animation / effects could be missed, as the "get hit by character" state would replace the old state. This would be only visual loss - clients would receive the latest health point / position changes from servers nevertheless. I might add some animation buffer in the future if it looks like too many animations/effects are missed - but so far I suppose this is a quite decent solution.

    - the biggest benefit from this approach would naturally be that it would be extremely easy to add new updates/effects to the character without need to touch much network code: if I need to have a new animation or effect, I can simply add constant RECEIVE_HEALING and let the server change user status to RECEIVE_HEALING, in the client's end client could see RECEIVE_HEALING and do appropriate animations/effects right away. I wouldn't need to have separate client code for "askHostForHealing", "receiveHealing" etc...

    - Bit flagging. I'm going to use some number bytes to tell about the object state changes. For example: 1000 would mean that only object position is changed. 1011 could mean that object position (X/Y/Z), health and weapon values needs to be updated. 2 bytes gives me 16 different change values - and 4 bytes would let me use 32 which should be more than enough.

    Little addition: by state I mean all the attributes and values of object. For example, player character has several attributes like "positionX, positionY, positionZ, health, action, actionModifier, weapon" and so on.
    Last edited by Game Producer; 10-20-2006 at 03:42 AM.

  22. #22
    Moderator
    Join Date
    Nov 2004
    Posts
    2,896

    Default

    Actually, there are some very useful general multiplayer programming articles in the "Massively multiplayer" books. Dont be scared by the name, plenty of good client-server oriented stuff in there too.

    In general, I think many of the "multiplayer game programming using X" kind of books arent really that useful.

    Your goal of not sending redundant data is a good one, but be aware that sometimes it is USEFUL to send data. Even if it is a simple ack/nack packet. This is because it helps keep firewalls and NAT's primed and maintains your "connection" in the list of connections.

    These days, programming multiplayer games is probably more about addressing NAT/Firewall issues than it is about game object state updates and latency etc.

    I'd definitely recommend using a low cost networking library and not rolling your own.
    www.mindflock.com - social AI-based games

  23. #23
    Moderator
    Join Date
    Jan 2006
    Location
    Finland
    Posts
    1,422

    Default

    Quote Originally Posted by zoombapup View Post
    Actually, there are some very useful general multiplayer programming articles in the "Massively multiplayer" books. Dont be scared by the name, plenty of good client-server oriented stuff in there too.

    In general, I think many of the "multiplayer game programming using X" kind of books arent really that useful.
    I bought "3D Game Programming All In One" (to help learning Torque) and it's shame that it doesn't go that deep into "logic" of network programming. There's plenty of ok stuff in that book (about general 3D programming).

    Now - give some good tips about those MM books

    Your goal of not sending redundant data is a good one, but be aware that sometimes it is USEFUL to send data. Even if it is a simple ack/nack packet. This is because it helps keep firewalls and NAT's primed and maintains your "connection" in the list of connections.
    Naturally! My model was intended for game logic - it does not deal with connections, game time or things like that. I forgot to mention...

    These days, programming multiplayer games is probably more about addressing NAT/Firewall issues than it is about game object state updates and latency etc.

    I'd definitely recommend using a low cost networking library and not rolling your own.
    I have purchased & been using one lib for a long time. It handles very well all the ugly low-level stuff for me. So far it handles NAT/Firewalls/Routers "well enough".

    Although NAT/firewalls can be tricky - and sometimes it's not in the hands of the network library to deal with them I remember some games by big corps "recommending switching off firewall when playing" (Not sure, but I believe EA's LOTR: Battle for Middle Earth mentions something like this - I might be wrong though)

  24. #24
    Senior Member
    Join Date
    Dec 2004
    Location
    Sweden
    Posts
    232

    Default

    I don't know what method your networking lib is using, but if I may be so bold as to suggest that you skim through the bottom of this blog post... I searched a bit for NAT traversal solutions, and this seemed to be the only way that would work in all(?) instances, and at the same time wouldn't require a complete proxy server.

    The basic idea is to use the stateless property of UDP in combination with a co-ordinating webserver which will ensure that both clients start the punch-through at almost the same time, and that they use matching ports etc. So, something external is needed; but nothing more than (for example) a PHP script.

    If I don't remember incorrectly, this would ensure better compatibility than STUN and simpler punch-through methods.

    [Edit: Right, sorry. There I was thinking in my DIY way again; forget this post - it's not applicable to indie developers who want to be productive.]
    Last edited by Karja; 10-20-2006 at 07:07 AM.
    http://www.wildhollow.com - Adventure/pet raising game
    http://www.spandexforce.com - Puzzle/RPG
    https://twitter.com/karja - Twitter

  25. #25
    Moderator
    Join Date
    Nov 2004
    Posts
    2,896

    Default

    One of the things that OpenTNL offers for instance, is exactly the NAT/Firewall stuff. I wouldnt dream of bothering myself with that kind of thing these days, as I prefer to be more productive.

    To be honest, the game state stuff really isnt THAT hard of a task, at least not as hard as it was in the days of 2400 baud modems etc.

    These days, your task is mainly latency hiding (prediction etc) and trying to maintain consistancy as best as possible, assuming you dont go for a truly deterministic lockstep model.

    A good example from one of the MMO books btw, talks about why you WOULDNT want to use bitmasks for designating states for update. But anyway, it does all tend to be fairly game specific. For instance an RTS game requires a fair bit of difference to a MMO to an FPS etc.

    I'd suggest getting "Massively Multiplayer Game Development" 1 & 2 (Thor Alexander as editor, charles river media publishers). There is also a multiplayer game roundtable thing usually at GDC, perhaps there are some notes from those meetings?

    In the end, this is another one of those things (like game architecture in general) where there is no *right* way to do it. Only ways that work and ways that dont.
    www.mindflock.com - social AI-based games

  26. #26
    Junior Member
    Join Date
    Oct 2006
    Location
    Manila, Philippines
    Posts
    13

    Default books

    The book Programming Linux Games by John Hall, which is also available as a PDF download, contains a chapter about adding networking to a game.

    You may also want to take a look at the book Core Techniques and Algorithms by Sanchez-Crespo Dalmau, available online via Safari, which also contains a section on multiplayer game programming. If you don't already have a subscription to Safari, you may want to avail of a free trial, which should allow you to access the book plus a few others for a few days.

    Another book which you may want to look at is Programming Role-Playing Games with DirectX. As pointed out in GameDev.net's For Beginners page, this book is a good general game programming resource despite its title. And, it contains sections on implementing networked games. It's also available online through Safari.

    All three books, being surveys of game programming in general, should contain material that is generally accessible to the average programmer.

    Another corner of GameDev.net which you may want to look at is their Networking Books category, which also contains reviews.

    A book which I saw in our university library which may also be of interest to you is NetWarriors in C++, which was reviewed in ACCU.

    As you have noted earlier, most of these books have been around for quite some time already, but the principles behind them should still be applicable today.
    Chuck Arellano - Game Programming Video Tutorials for Beginners at http://www.scriptedfun.com/

  27. #27
    Senior Member
    Join Date
    Aug 2004
    Posts
    443

    Default

    I picked up a book in Japan called "MMORPG Game Server Game Programming" written by one of the lead coders of the Lineage games. It seems pretty good, and has a lot of info that I haven't seen in any books in released in the US. The problem is, its Japanese and I don't really know any Japanese . As far as I know, there are only Korean and Japanese versions of this book. I would love to see someone localize it to English. If you want to check out the source code included with the book, you can download it here.

  28. #28

  29. #29

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •