[Gardon]

I've never done networking before. I've heard rumors that you have to design it to be online from the get go or else it's pretty hard to convert a single player game into an online version.


I don't see the big deal... as long as you have your general base for the game down (menus, combat system, etc.) and just handle how you manage the gamestates and players differently for multiplayer play.

If anyone has any links to networking for games I'd be fond of that.

Thanks,

[Hajo]

I've made two larger single player projects. One was handed to a new team about two years ago, and they tried several times to add networking, and face quite big problems. They may succeed one day though.

The other project I have abandoned for the very reason, way too much effort to add networking at a late stage.

But this does not mean you have to have networking there from the start. It means you must chose your program architecture, the design, with networking in mind, so that later you have the right places to cut the code and insert network interfaces.

I'd still suggest to implement a dummy network layer first. It does not do real network stuff, but defines the interfaces. Then build your game on top of that. At least in my case it was a big help.

PS: Being online from the go, it does not have to be. I'm working on my current project two years now and it's not been online for more than a few hours, running on my PC with friends invited for doing tests.

[Gardon]

Most "Multiplayer Game" books I've come across suck. I figured why not buy a book dedicated to multiplayer gaming? They are always full of bugs in the source code and aren't worth my time trying to debug.

With that said, do you know anywhere else I should start to learn networking from? I kind of know what you mean when you talk about the networking shell. Basically don't make the game dependent on just itself, but rather have it so it needs input from somewhere else, and structure it that way.

But some sort of book or article would be nice. Where did you learn your networking from?

[Hajo]

At first I borrowed a book about socket programming and tried a few of the examples there. After that I started with looking at open source MMO games. Also I tried to find out how commercial MMOs work, what they do, network wise, just by watching while playing. It might sound odd, but one learns most if the network is bad, when lag is high. There you can see where they allow desyncs, and what the games do to resync clients.

I'm still learning, though, the past months I posted quite some questions here. There are some around who have more experience on that than I do.

I know there are other ways, but this structure is what I seemed to understand best and which seems to be easy to use - a classical client server structure:

1) Clients send request for actions to the server.
2) Server validates and performs the action.
3) Server broadcasts action results to all affected clients.
4) Clients update themselves with the action results.

Games vary in how much data is kept on client and how much on the server, though.

The one extreme is to have all data on the client, and no server at all, using peer-to-peer protocols to keep all clients in sync. I think this is what one finds in old network games, with small player numbers.

The other extreme is to have the client only as input/output console and all of the game data on the server. Browser games often work that way.

MMO's are somewhere in between. Usually most data is kept on the server, only the data that is needed to display to the player is on the client. I think most MMOs use protocols like the one sketched above. They need measurements to hide the lag - if the player wants to move his/her avatar, the client immediately moves in on screen, assuming it's ok, to give the player the idea of immediate response. If the server confirms, it was ok to move, if not it must be reset. This is where the trick-box opens. Good games can cover many network issues, a lot of lag until the player notices.

Sorry, today my thoughts are a bit convoluted and so is my writing. Hope you can draw something useful from it, though.

[Gardon]

Yes, thanks. My main inspiration was Runescape, which I played several years ago during the older version. It was a browser based game, which you would log into via their website. You never had to download anything, and everything you needed was shown to you through the browser (everything kept on the server).

Now, I know some Java, but not enough to make me like it :) I'm sticking to C++, and I think the applet thing is out of the question. I'm looking to make a client of my own, so we'll see how that goes. Right now I'm torn between a FPS and an RPG. I'm not really looking for MMO at the moment, although that would be nice. I'd hope to upgrade the game to that someday.

So I guess it's my choice. If I had the game online, I could sacrifice quality a bit because other players and gameplay make it what it is. It would be like you play the game to have fun, and there's always something different.

Single player on the other hand, has to be perfect because that's all you get, and there aren't really any surprises once you know what the game is. If doom had crappy graphics and the gameplay stunk, would you play it?

So since I'm no artist, I'm still torn between fumbling with a single-player like game (doom type), and possibly make it multiplayer, or do some sort of RPG online, and just get the basic components down for networking (have other people join, walk around, talk, be able to trade, etc.)

So it's design at this point. What do I really want to do, you know? Do I want to shoot for some awesome FPS game, or try for a new experience and do an online RPG. Either way, I want to make both games BAD, but it's just how far I think I will get.
lol

Thanks again,

[Hajo]

[Gardon]

You said you have it online at the moment. Would you mind if I took a look? If not, that's fine, but I would really like to see what you have so far and see what networking looks like in it's early stages.

[Hajo]