next »

[GCshepard]

EDIT2: Solved.
EDIT1: The below problem is solved. Here for documenting.
So I'm making a game, and I'm planning on making multiplayer (co-op AND versus) a significant feature in the game. However, most of the gameplay is content, and the focus of the game (co-op) has a heavy orientation on enemies, of which are quite different. Thus I'm asking at what time should the networking system be implemented? and how hard is it to inject networking to a developed game structure?

If it matters, I'm using XNA.
EDIT1: The above problem is resolved (start on multiplayer ASAP and use client-server), but how do I manage data? And how much data do I give the server to process?

[zacaj]

Dont know about XNA but I was trying to add multiplayer into my game engine for #7dfps and it was HELL.  I'd recommend coding multiplayer in right in the beginning, and having your single player game run the server silently instead of having separate modes.  Multiplayer affects almost every aspect of your engine, and in many cases you'll be re-coding stuff from scratch if you did it before you added multiplayer

[Maud'Dib Atreides]

OH MY GOODNESS I CANNOT STRESS THIS ENOUGH.

Dont know about XNA but I was trying to add multiplayer into my game engine for #7dfps and it was HELL.  I'd recommend coding multiplayer in right in the beginning, and having your single player game run the server silently instead of having separate modes.  Multiplayer affects almost every aspect of your engine, and in many cases you'll be re-coding stuff from scratch if you did it before you added multiplayer

^Truth

If you plan for multiplayer, DO IT NOW.

I've been working on my own online game thingy for almost 3 years now.

Yes.

3 years of backtracking code and rewriting everything to function with multiplayer.

If you have a project, decide if you want to make it multiplayer before you begin.

You must build your game around the multiplayer. If you slap it in at the last second you'll either have something half assed networking wise, or you'll find yourself completely tearing things apart just to slap something in.

[Average Software]

My current project supports networked multiplayer, and yes, you need to get it in from the beginning.

My project is completely network transparent, which worked out great.  Everything uses a client-server model, even the single player.  When it came time to add multiplayer, I was able drop it in with almost no problems.  It was just a matter of changing where the messages went, the client has no idea if it's talking to itself, a server halfway around the world, or the computer next to it on the LAN.  This is the way to go if you can pull it off.

[EdgeOfProphecy]

From the very, very, very beginning of the project.  If you defer its implementation, you're going to probably end up with a situation where you're trying to add mutliplayer to an existing game, only to realize that conflicts exist between the two architectures.  Then you'll be faced with writing some hack to shoehorn multiplayer into the game, or going back and redoing vast sections of the game.  Neither are fun.

Plus, by thinking about the mutiplayer implementation from the get go you can come up with some pretty sweet architectures.  Some games are written such that they always run in a multiplayer mode, and a single game is really just a special 1-user multiplayer game communicating with a spoofed server.  Stuff like that is cool since you don't have to write a separate single player/multiplayer version of the game, it's all the same.

[st33d]

Um, I just added an optional multiplayer to some stuff I'm working on. It was pretty easy.

But it depends completely on the type of game. What sort of game is GCshepard making?

[JOBA]

If your game is varied in terms of unit types, bullet types, abilities, vehicles, etc and the game logic itself is not simple like FPS(it's either a RTS or RPG) consider using lock-step networking model.
It is 1) simple and 2) relatively easy to integrate into finished/semi finished game. It has its drawbacks, like you might run into hard to debug out-of-sync bugs and the highest latency / lowest framerate is shared among all the players.

If you're planning to use fixed lockstep, I don't think it is that important to get networking to work from the get go.

[GCshepard]

Thank you all for the input on telling me to start on the multiplayer right-the-hell-now. Now to learn how to do multiplayer before I get started on my game...

 

@st33d: It's a 2D fast-paced no-gravity shooter with rogue-like elements in it (the luck and random levels (and maybe loot) part). The game is extremely enemy-intensive in coop, and I'm planning on a good number of bosses as well.

Since the game is going to be pretty fast-paced, I don't think I'll be able to use the Lockstep method that @joba suggested, as its sounds like the latency is quite a problem. I imagine it does work brilliantly for a turn-based or slower strategy game where you have all the time in the world to transfer information.

@Average Software: That client-server format sounds like the way for me to go, as single-player will not be the focus, but will not be non-existent. Thanks for the idea.

[Klaim]

Basically you just have to make sure of several things:

1. Separate the game code in client and server, as already suggested. The client provide inputs and output, the server process requests from the client and send events to the client.

2. This suggest that what happen in your game is more or less event driven, so you have to setup some kind of protocol.

3. Now, the way you pass messages between client and server have to be either only through network (event if both are the same executable instance) OR made in a way that allow you to pass those messages directly in the same thread (client&server on the same thread - with or without coroutine), between threads (client and server on separate threads) , or between processus (if you manage to have client and server to be separate processus). The choice totally depends on the kind of  game and the technical cost you are willing to pay.



 

[GCshepard]

@Klaim
So what you're saying in #1 is the server processes the data and the client gives data on what it's doing. The game IS event driven, so #2 is true. I get this much.

In general, I'm guessing the client side would be visually processing where a bullet or object is visually, but the server would send out information whether and when the bullet hits or what an object does (shoots, moves, etc). I think the game Ace of Spades used a function that predicted where a Player was moving by giving Players a velocity, but I remember it was pretty buggy and latency was a huge issue. That problem might just have been due to the excessive amounts of terrain height difference there was. With the top-down design of my game, that probably won't be a problem.

#3 is where you're losing me. I'm guessing "Only through network" is where you have the values being sent out to be caught by the server. It may only be 1-2ms of latency on single-player, but it'd be easier, if not quite as fast. I'm guessing the best way to do this method is have one of the clients act as a "server" using a "Server" class that basically acts as a "Manager".

"between processus" would be where you have two separate programs for the client and server, and would be harder to do, I'm guessing. If you wanted to set up a server on a separate computer, couldn't you just start an executable on "Server" mode so that it just processes the data, but doesn't have a client running on it? I think I'm going at this all wrong...

[Maud'Dib Atreides]

Remember this before you design your characters. Your characters (or sprites) will have 2 modes.

Mode 1: Player mode

Mode 2:Other Player mode

This means that you need to have functionality for each player to either be controlled by the controller, or by inputs sent from the server.

One final thing

Try to contain as many sprite variables and properties to the sprite.
If there's a flag you check per player, try to contain these flags in the player class.
If you use global variables for player based crap, you'll end up in a clusterfuck of what the hell is going on..

[GCshepard]

Remember this before you design your characters. Your characters (or sprites) will have 2 modes.

Mode 1: Player mode

Mode 2:Other Player mode

This means that you need to have functionality for each player to either be controlled by the controller, or by inputs sent from the server.

One final thing

Try to contain as many sprite variables and properties to the sprite.
If there's a flag you check per player, try to contain these flags in the player class.
If you use global variables for player based crap, you'll end up in a clusterfuck of what the hell is going on..

Ok so I have half of the idea down. Creating a Sprite class sounds key... But how much data do I leave for the server to interpret? Do I let the server interpret everything and only let the client send out input and let them move the sprites to where they *should* go? This is what makes the most sense as anti-cheat, but it sounds extremely latency-inducing, due to the amounts of bullets and enemies there may be active at any time. I may also be under-estimating internet speeds.

[Aloshi]

Now to learn how to do multiplayer before I get started on my game...

I really recommend giving these articles a read if you don't know much about the subject (though you can probably skip the Sending and Receiving Packets article as it's pretty specific). This article is a nice overview of how implementing networked physics is more of a headache than you'd think.

[GCshepard]

I really recommend giving these articles a read if you don't know much about the subject (though you can probably skip the Sending and Receiving Packets article as it's pretty specific).

Oh wow. Those really help giving me an idea how to manage this. It's actually more applicable than you would think.

This article is a nice overview of how implementing networked physics is more of a headache than you'd think.

It's hard to fathom that networked physics could be any more complex than how complex I already thought they were going to be. I'm being rather pessimist after "postponing" my learning of 3D 

[Maud'Dib Atreides]

Well

First I reccomend using a networking library (I'd use Lidgren.Network in your case)

NEVER trust the clients, at least you have that down.

The only thing the clients should send is input data, NOT player coordinates.
Why is this? Because there's no point in 'hacking' input data.

The server sends updates. If the player gets an item or loses health, the server should be checking for this, and sending it to the client. THE CLIENT SHOULD ONLY BE RECOGNIZING INPUT AND RENDERING THE GAME. THE CLIENT SHOULD NOT BE editing player health, player items, etc and sending it to the server!

When you use Lidgren.Network, things are pretty simple, and you shouldn't get your hands dirty. I believe you said you're using XNA, and Lidgren supports it.

One final thing is verification of syncronization. Most people implement interpolation of sprites, but an easier way for you to start out is to send the actual player coordinates from the server to the clients each 2-5 seconds to verify that everything is synced.

This way the client doesn't wait for a server update for the movement of sprites, but it uses both client and server data to guestimate where the sprite should be.