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!
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. 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
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.
Lies! Networking is a lot of fun! It’s a difficult concept to grasp and preferably craves some fundamental knowledge of the inner workings of a computer as well as how TCP and UDP works.
Here’s a few fun and useful links to get you started:
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.
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.
You have to start early but it won’t help unless you know how to solve the problems you will encounter. Try prototyping the networking part before starting on the game.
@jonjava
Well, 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.
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!
The minecraft networking was never very good. I remember last time I tinkered with it, it didn’t use non-blocking IO. Instead we had a crapton of threads and sockets.
If you want more than 10 players, use non-blocking sockets. My explanation up above was written with non-blocking sockets in mind. If you decided on Kryo, don’t worry. That’s NIO as per nature.
Last time I did something with networking I found myself spending three days at full time designing the protocol. Only then, I could move on to the game.
About a week in I realized that I could develop it much faster if it was just singleplayer. I haven’t looked back since. That’s another story though
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 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 this awesomegame -s 3 player1 player2 player3
each client would use awesomegame -c 3 player1 player2 player3 2 10.0.0.1
here 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.
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.
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 
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.