I'm working on a Sprite Kit game. I'd like to make it a true multiplayer game, by which I mean that each person joining the game has their own camera. I've seen tutorials on multiplayer games where the players share the same game screen, but that's not what I want.

I understand there needs to be a server that players connect to, which means the "world" that players connect to should be running on the server. Is this correct?

How do I have a server running the 'world' for this game? Does it have to be a specific type of server, or can I use Node.js or whatever else I want?


1 Answer 1


You're on the right track.

The gist of the client-server networking model is that a server is that it's a central point of knowledge that clients connect to. A game server typically contains

  • an in-memory world representation,
  • a list of connected players,
  • a game loop (with e.g. player control handler, a physics engine & AI).

You'll also need a communication channel between your server and clients, so clients can transmit the player's actions, and the server can transmit the game state.

More advanced client-server configurations might involve

Start simple. It's best to add complexity only as necessary. This rabbit hole is deep.

You mentioned Node.js: I've written a few servers for small games in that and it's been good. But you can write a server and clients in anything you like. Eve Online's is largely in Erlang, Minecraft's in Java, pretty much everything by Valve is in C++, et cetera.

  • \$\begingroup\$ Thank you for the detailed answer! one thing that still confuses me is: since the game is written using sprite kit for iPhones, does the server need to know about this at all? I'm just confused because I keep thinking, the game's in sprite kit, so the world being provided by the server should also be sprite-kit. What are your thoughts \$\endgroup\$ Aug 27, 2015 at 18:23
  • \$\begingroup\$ @AbdulAhmad No, you can can make the server with whatever language or libraries you want. Keep in mind that your server is and should be completely separate. You are building two different applications and you should think of it that way. One for the client and one for the server. The part that ties them together is the communication protocol between the two applications. While there will be other details that must be coordinated between them (such as game state), in essence they are totally unrelated. You wouldn't even have much use for Sprite Kit on the server side. \$\endgroup\$ Aug 27, 2015 at 18:29
  • \$\begingroup\$ @FuzzyLogic so then, trying to understand this better. If the sever is providing the 'world' (images, physics, etc..) then the clients (iPhones) shouldn't have any of that, because the client is just the "view" for this environment. is this correct? So would I just use sprite-kit on the client-side to just give a visual layer to the data coming from the server? In other words, the game should be built mainly on the server side (all logic etc.) and the client is just my view, and where I can send events/commands to the server. This means I don't need any physics engine/game logic in sprite-kit \$\endgroup\$ Aug 27, 2015 at 18:35
  • \$\begingroup\$ @AbdulAhmad Yep! A client that does the minimum possible processing is called a thin client. It's a great starting point. \$\endgroup\$
    – Anko
    Aug 27, 2015 at 18:43
  • 3
    \$\begingroup\$ @AbdulAhmad Yes and no. That's a good way to think about it but mainly for efficiency reasons, the client will usually duplicate many things rather than asking the server for every detail, otherwise you will probably have performance issues. As anko mentioned, it would be a good place to start. This is a big topic, there are many ways, many considerations and many parts so it's difficult to entirely explain how it should all work. How complicated it gets really depends on the details of your game though. To be honest, based on your questions I don't recommend you trying to do this yet. \$\endgroup\$ Aug 27, 2015 at 19:05

Not the answer you're looking for? Browse other questions tagged .