The game I'm developing is going to have online multiplayer functionality, I know that much. I don't know much about how to go about doing it, but that much is fine; I can do the research, and I've downloaded http://code.google.com/p/kryonet/ (Kryonet; I haven't yet learned how to turn the URL into some other text :p) to help me out. However!

Would you guys recommend I start developing the multiplayer infrastructure now, while the engine and the game are somewhat in their infancy, or would you recommend waiting until the client is fairly robust and complete before working on the netcode? Having never done this sort of thing before, I'm not sure what would be considered a smart move or not! Thanks for your guys' time and inputs!

Networking is not fun. If you like developing your game, don't do networking. I know that isn't what you asked, but you'll realize.

There is no good way to do networking. It's all bloody disgusting and not very fun.

lol Well I could have guessed that from what I've heard. I don't expect the process to be fun... I just want to know whether it's smarter to start working on it ahead of time or whether it can wait until the client is about complete. :p But thank you for the advice nonetheless! Based on what you're saying, it sounds like it'd be better to just wait until the client is finished and then work on networking :p

For a multiplayer game you need to design the whole architecture in a different way from the ground up.Some points to consider:You need both client and server modules, have shared code probably. You need to be able to deal with network latency for real time games.Treat the player as one of many game characters.On game start, wait until all clients are ready to play, but consider a timeout for unresponsive clients.In a real time game, movement and things like collision detection must be mirrored on client side.Designing messages between clients and server (when to send which information)Dealing with connections, wanted and unwanted disconnects. Error handling.

Using a matured network library is good, but it doesn't help with the basic architecture which is up to you to build.

Probably the best advice or realizations I've had is that everything you send over a network is in bytes (1010101011011110). Everything on a computer is in bytes for that matter. I mean I've heard and "known" this before but I'd never really understood what it meant until I delved into making networked games.

I had a sort of presumption that you can send either Strings, Files, data (ints, longs, bytes) and never really understood that they're all the same. It all depends on how the receiving end interprets the BYTES it is being sent. (Because everything you send, receive, save, etc on a computer/phone/etc is in bytes).

But how can you tell the receiver you're sending Strings, images, or ints? or a combination of those? The answer is you can't. This is where Protocols come in. A protocol is a fancy pants word for a "set of predefined rules on how and what is being sent by 2 or more computers/people/whatever". I.e, in layman's terms "How do we order and interpret all of these 1's and 0's (bytes) so that we can understand each other". E.g. HTTP.http://thesaurus.com/browse/protocol?s=t

In basic terms HTTP says that if you send the bytes [01000111010001010101010] ( also know as the ASCII string "GET", see: http://www.digitalcoding.com/tools/text-to-binary-conversion.html) to a computer on port 80, assuming the computer you're sending to is familiar with HTTP, it will, first of all, know that whatever bytes it is being sent it's going to interpret them as ASCII string characters (Defined in HTTP). When it reads the command "GET" as defined in the HTTP it will send you an html file.http://www.jmarshall.com/easy/http/#sample

All browsers send GET requests for every site and page you visit.

A domain name e.g. "google.com" simply links to an IP address. In the early days people came up with an idea of representing computer ip addresses as easy to remember names. This spawned the DNS, Domain Name Service. You can buy a domain name from a DNS registered reseller (all over the place) for about 5-10$ per year at a time - varies slightly on name and suffix. And all the DNS servers around the world will link that name you've chosen to an ip address of your choosing.

So to create your own multiplayer game you've got to make your own little protocol, i.e, define rules for how your game clients and or server will communicate with each other. Once you've got the protocol down it's all about building the game to adhere to the rules set forth by the protocol.

@jonjavaWell, using Kryonet you don't have to worry too much about having an efficient protocol. If an int is not needing all of the 4 bytes, it'll just scale it down.

Kryonet is really a nice way to go around all that silly technical networking. Not that you shouldn't know - it's just not necessary for development, which saves you tons of time!

On the server, what I usually do is this: Have your listener report back with what packets where received, and from whom. You can insert this data in a queue. Your game-loop (logic, that is on a different thread than the listener), will then at the start of each cycle go through and process each packet. Since you know who it's from, it's easy to find the client to apply the changes to. If any of the packets needs a response, make it and queue it (like the receiving queue).

Afterwards, you do a "process" of your game world where you update everything that runs without player interaction. These would be behavior for NPC's, or changing up how your fountain sprays water.

In the end of the game-loop, you send a same packet to each client with the most general information. For me, this has usually been movement of all players and/or appearence-flags. Like animations. You can assemble these individually for each specific client, but so far I've just sent the same packet to everyone. Then the client can figure out who's who.

Lastly, you can send the response packets to each client. The reason I wanted to wanted to queue this, was so that I'd send out packets roughly at the same time. This probably doesn't make any sence for most games, but I always wanted to keep my ticks intact, and not make some packets come way before others.

That's just how I'd do it, though. I don't think you even need a "tick". You can just respond right away, every time the listener receives something. Just remember not to block the listener, because it's kind of important.

Yikes.... that doesn't sound too fun. Even with the use of a helper library like Kryonet?

If 64K's explanation doesn't suffice, take a look at a real world example, a little known java game named Minecraft, which originally had it's single player and multiplayer components separated into two distinct packages, which needed to be updated and debugged independently every time something changed.

Only recently have they integrated both elements into a single cohesive structure. Go take a look down their release notes to find out how many times that design choice has been a problem.

In other words... Multiplayer is not a feature, it's a design paradigm.

Thanks, you guys! Lots of great information that I can't wait to delve into and experiment with. I think I will begin incorporating networking and the related design into the overall game very soon just so that everything is cohesive and doesn't suffer from something like Minecraft's former paradigm. I love Minecraft, but I do remember hearing something about that in the past!

Adding networked play as an afterthought is likely to be very difficult, but if you start with networking in mind, and adhere to the necessary discipline rigorously, then networking can be a painless add-on once the networking itself is reliable.

A few things(1) Maintain a rigorous separation between events which are strictly local and events which everyone needs to know about. Tracking the mouse or changing a view is a local event. Moving an object is a public event.(2) All public events have to go through a serialization knothole and will encounter random network delays. Do this even when developing, and not really using a network. From the viewpoint of the app, there is no difference between networked and non-networked play; the app is not aware of the network at all, all it knows is it has a sequence of events to process.

The two big confounding factors are(1) you have to update local views immediately, even though the network delay hasn't happened yet.(2) unless all actions are strictly synchronous, players WILL see different sequences of events and disagree about reality. Chess is easy because it's always someone's turn. Shooters are hard because you don't wait your turn to shoot someone.

The uncomfortable question that should be asked is, do you have enough experience writing games to go multiplayer?

Even writing offline games can be a pain in the ass to treat events on the correct order, run the right animation, deploy the right files, and so on.

If you haven't written and finished a couple of offline games, you will most likely to fail and waste your time. I'm not trying to discourage you from doing the game of your dreams, I'm encouraging you to do it the right way.

I know it by experience.

Although I knew java quite well when I first started writing games, I wanted to make an online Tactical game. And I went for it. So I spent like 7 months writing Tactics Pompster Online , which in the end was actualy playable, but it would randomly crash and the code was a clustered pile of mess of shit. Completely unmaintenable.So my game of dreams had failed. I still have nightmares about it, wake up sweating in the night, have flashback and all that trauma stuff.

Then I took a step back, and wrote some small games, and realized all things I've done wrong. Learned a LOT.

Almost 2 years from now I started to write another online, allegedly massive, multiplayer game: Reign of Rebels. I can say it came out pretty good compared to Tactics Pompster Online. However, I've spent weeks to fix networking bugs, lag compensation, etc etc. It is still not easy.

So what I wanted to tell with this exciting and moving story is: writing networked games is hard. Don't do it unless you know everything else about programming games. I'm pretty sure you'll use better your time if you write some small games for the experience, then move on to the game of your dreams.

I can imagine that was a pain! Perhaps I'll write a few games on the side using multiplayer to get more acquainted, but I know for sure that this game is going to have multiplayer, since that was one consideration I had throughout the whole design process... in fact, it wasn't even really a question. I don't doubt that it will be very painful of a process, but I suppose we'll see what comes out of it. Either way, I'll at least learn a lot more in the end, and this won't be the first game I develop with a very serious mindset! Thanks for your advice; I hope to just keep learning, because I think that's the best thing I can do as a programmer and as a game developer.

I wouldn't say don't try, but if you haven't done it before, for the sake of sanity: start small.

That goes for the game as well. For example start with say a networked version of tic tac toe, because its turn based there is less to deal with. Then a networked version of pong or other such simple game. This will already teach you a massive amount *and* you have a good chance of finishing them. Bear in mind that a lot of net infrastructure is needed even for just the tic tac toe game.. Like a lobby, a place to find opponents, a login system etc.

I would strongly recommend starting with TCP. Switching to UDP if you really need it later can always be done. But TCP does a lot of stuff that you will need to do yourself if you use UDP. Of course if you use some net lib then you will end up using whatever that does.

I have no special talents. I am only passionately curious.--Albert Einstein

I wouldn't say don't try, but if you haven't done it before, for the sake of sanity: start small.

That goes for the game as well. For example start with say a networked version of tic tac toe, because its turn based there is less to deal with. Then a networked version of pong or other such simple game. This will already teach you a massive amount *and* you have a good chance of finishing them. Bear in mind that a lot of net infrastructure is needed even for just the tic tac toe game.. Like a lobby, a place to find opponents, a login system etc.

I would strongly recommend starting with TCP. Switching to UDP if you really need it later can always be done. But TCP does a lot of stuff that you will need to do yourself if you use UDP. Of course if you use some net lib then you will end up using whatever that does.

I agree. Since I've already coded both Tic Tac Toe and Pong in LWJGL, I can probably convert those to networked versions for the learning process! Thanks so much! I probably won't have a lobby-type system for my game; what I mainly want is sort of a server-based process whereby Player 1 runs a server on his computer and plays locally while he can have friends join by connecting to his IP, that sort of thing.

Good idea. My games can set the required options at the command line. Both the server and the clients must have the correct options or things get quite funky. But to get going its a good way to avoid lobby and co. There really is a quite a bit of tediousness sometimes.

Currently if i want a 3 player game the server will start with something like thisawesomegame -s 3 player1 player2 player3

each client would useawesomegame -c 3 player1 player2 player3 2 10.0.0.1here i even need to tell each thing which slot they have in the game, how many players and the player names. This means i can *play* the game and work on the game netcode with very little extra stuff.

I am currently writing all the extra stuff now. What i don't like is all the extra GUI stuff you need to support it.

I have no special talents. I am only passionately curious.--Albert Einstein

That sounds like an interesting approach. I was mainly inspired by the way games like Terraria and Minecraft work with their multiplayer, particularly Terraria since my game draws a lot of inspiration from it. Terraria, fortunately, encapsulates the whole networking interface in their client code so players can start up servers rather easily, whereas Minecraft requires you to download an additional program that acts as the server. I like having less hassle, so I'll probably try to model my system after Terraria's.

I started with UDP and wrote my own tcp-methodes, it was quite funny because I haven´t done something like this before.Maybe you already know it but here are some abstract tipps.1. Your first 2 bytes of datagrampacket should be how large your packet is.2. You create another byte[] out of the data copying from 3 to the length (1)3. You got one big, I called it SendObject, object that includes the object you wanna send, the playerinformation, is TCP, object is splited, some numbers, etc.4. You use some threads:for receiving,analysing,sending, take care, because there are some racing problems. I solved it with arrayLists.5. Objects bigger than 64 kb are splited, the splited byte[] is the object in the "SendObject", I create a hashmap with the number of the splited Object (I give every SendObject a number, SendObjects including splited Objects get the same number to put it back together, what part is it and how much parts are there. That´s faster than tcp because you don´t care about the order, but you have to make sure, that lost packets are send again.6. Don´t care about player positions, if they are lost, they are. It could be that packet 1 arrives after packet 2 -> you ignore packet 17. If you have to care about the order, (I haven´t needed it yet), you just wait with sending packets until the receiver responded.8. Server-conntection:Client klicks on "start server" -> server starts -> host connectsIt´s a matter of opinion, but I did it like that, because in order it´s easy to create a "stand alone multiplayer-server" for a root-server.Maybe some solutions aren´t perfect but I am just a try and error commander -> works well

Please not the UDP is faster thing again. It was once upon a time around the mid 90's. Nowdays this is just not true. More often than not TCP is faster, hell even in the 90's TCP was often faster because modems etc could heavily compress the ip packet headers because TCP is state full.

This is still true to an extent today. Some of my test around the EU gave slightly better results for TCP than UDP. Even globally the strongest claim that could be made was TCP is no slower. Often routers etc prioritize TCP data over any UDP data, so once things get busy, UDP has more problems as well.

At best on a normal network it can't be slower, its still the same IP packets over the same network.

Once packets are getting dropped or reordered (almost never happens without packet loss), then everything doesn't work well. We have been fine tuning TCP for a *long* time.

There are 2 things most people don't get right when they roll there own TCP. By far the biggest is flow control. If you lose a packet, then send 2 packets (one replay packet and one new data packet)... but you lost a packet because the network is already struggling, now you sending *more* trafic... this eventually results in congestion collapse. It even happened a few times to the whole internet while TCP was still getting fine tuned.

The next mistake is packet fragmentation. Often these issues are even bugs in various TCP stacks. There are less now, but over all the stack will fragment for you and you don't need to chop packets up into the MTU for the link. Since you don't even know the MTU for the link there is not much you can do about it. Of course the stack now needs to wait till it receives all pieces before you see any of the packet, And your back to streamed data anyway.

UDP makes sense in a very small subset of network games. Namely a game where the entire state can fit into a single packet. Flow control and packet loss are dealt with the same way. Just wait to the next packet, packets are sent at a fixed rate. This is sort of known as the quake 3 protocol and is now used in just about every FPS.

But once the whole state does not fit into a packet.. Well most MMO games now use TCP. In fact many games a switching back to TCP.

If you don't know what the 2 generals problem is, or what flow control is. Don't do UDP... TCP is just a better fit for what most people need and will use.

I have no special talents. I am only passionately curious.--Albert Einstein

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org