0
\$\begingroup\$

I'm tasked with the development of a general use multiplayer API in JavaScript, with a Node.js back-end. The goal of the API is to provide a service to JavaScript mobile game developers so they can develop multiplayer games with an easy to use API and existing back-end.

The project also includes the development of implementations, a Node.js server and a test game, otherwise I can't test it ofcourse. So it's more accurate to call it the development of an entire library.

The problem I'm having is trying to figure out how to provide a nice mechanism for game synchronization. The library can provide room- and connection-management, friendlists, registration and soforth because those things are using the same mechanism in every game. However, game synchronization logic can be very game-specific and that is absolutely not allowed in a general use library and server.

I'm using the following libraries/frameworks for development:

  • Node.js as a game server.
  • Socket.io on client- and server-side for websocket communication.
  • Require.js client-side to enable modular development.
  • Redis as a database for persistent storage.

To clarify the goal of the library:

  • Support for a wide range of games, from a turn-based strategy game with 100 syncable objects to a multiplayer top-down shooter where latency is of the utmost importance.
  • No client has to act as 'server' of some sort.
  • Minimize manual setup client-side.
  • Accurate synchronization without synchronizing the entire gamestate.
  • Server-client architecture without the server containing game-specific code.
  • Shouldn't pose restrictions to the developer and shouldn't demand certain coding practices.
  • Provide an easy to use abstraction to use the generic synchronization mechanism.
  • The whole range of games has to be supported by the same generic server logic.
  • Lag compensation must be automatic in the API or on the server, but not game specific.

So for the main question: is this possible or should I just provide a way to easily cast, multicast and broadcast messages, and leave the actual synchronization mechanism to the developer? How would you go about it?

\$\endgroup\$
4
  • \$\begingroup\$ This question is asking how to create a library that works for any game, complete with easy-to-use abstractions, accurate but generic synchronisation mechanisms, lag compensation... This is is way too broad! I could imagine spending a few years writing multiple books on this. Deal with each part at a time. \$\endgroup\$ Commented Apr 8, 2014 at 14:17
  • \$\begingroup\$ @Anko I know the question is too broad for answering all those points. I just want to know if I should leave the synchronization simple with just the ability for the developer to send messages. I only have 20 weeks for the entire development and I want to know if my goal is realistic in the slightest or that I should ditch the idea and make it simpler. \$\endgroup\$ Commented Apr 8, 2014 at 14:39
  • \$\begingroup\$ Still depends on everything: How large and expert is your dev team? What platforms are you targeting? If you have to ask, make it simpler. \$\endgroup\$ Commented Apr 8, 2014 at 14:46
  • \$\begingroup\$ @Anko I'm alone in the dev 'team' and learned JavaScript and Node.js just 8 weeks ago. I'm trying to target mobile webkit browsers. Thanks for the link, I'm starting to make sense of everything again... finally. \$\endgroup\$ Commented Apr 8, 2014 at 14:48

1 Answer 1

Reset to default
1
\$\begingroup\$

It would be hard (and probably overkill) to try to provide anything besides casting, multicasting and broadcasting of generic messages for real-time multiplayer games.

You could even make it more generic by creating simple key-value (string-JSON) room storage behind websocket service with operations like:

  • set(key, value)
  • get(key)
  • observe(key)
  • maybe something like setReadOnly(key, bool)
  • or more sophisticated permissions API
  • maybe API for operations on arrays

It would be easy to use it as a broadcast by observing the same key ("/msg/broadcast") in each client. With API like that you can even have multiple broadcast channels (keys like "/event/broadcast" and "/chat/broadcast"). It could be also used for direct communication and for storage of game-state information (available for players that join the room during the match).

BTW: You can look at Google Play Game Services. They have (among other things) REST API for turn-based matches.

\$\endgroup\$
9
  • \$\begingroup\$ Thanks for the answer. Room management is already build in into socket.io so I don't have to create that myself. So the advice for game synchronization is to stick to generic messages with variable scope (broadcast, casting, multicasting)? I've looked at the Google and Apple API and both of them seem to leave the syncing to the developer. Don't you think it's not only hard but even impossible to provide a one-size-fits-all synchronization mechanism? That's basicly what I'm trying to develop - without succes ofcourse, hence this question. \$\endgroup\$ Commented Apr 8, 2014 at 11:05
  • \$\begingroup\$ No, I think it's quite reasonable, and may not be hard to implement if properly designed. As I mentioned, I would just create key-value storage for the room (I will add more description in the answer). \$\endgroup\$ Commented Apr 8, 2014 at 11:51
  • \$\begingroup\$ I've clarified the goals in the question. I hope it provides a better image of the requirements. \$\endgroup\$ Commented Apr 8, 2014 at 12:19
  • \$\begingroup\$ And does my answer satisfy your requirements? :) I would save lag compensation for separate quastion. \$\endgroup\$ Commented Apr 8, 2014 at 12:30
  • \$\begingroup\$ I'm not sure. I seem to be more confused about the whole thing than I initially thought. Are you familiar with Socket.io by the way? I think you are trying to explain me things that are already handled by Socket.io. The room management is not a problem and broadcasting through the room isn't either. I'm trying to find a working system that minimizes custom code client-side and avoid game specific code anywhere else. While still providing a robust syncing system, even in the face of losing packets. I appreciate your effort by the way :-) \$\endgroup\$ Commented Apr 8, 2014 at 12:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.