Best Practice for RPC on multiple platforms?
Chris Schalk
between a PlayN game running on the web, mobile or other, and a
generic service that could be running on any webserver?
In my case, since I deployed my app as a compiled HTML/JS app to the
web, I simply set up the client code using GWT's RequestBuilder. And
for my server code, since it's independent from my client(game) code,
I just used a Servlet. (I used App Engine, but it could run on Tomcat
or any standard Java server)
Logically I assume this approach won't port to Android/flash, since
GWT's RequestBuilder is not available.
Is there a better way to do multi-platform RPC so I don't have to
write different code for each port?
Thanks!
-Chris
Michael Bayne
> Is there a better way to do multi-platform RPC so I don't have to
> write different code for each port?
We have a networking library that is designed to be used alongside
PlayN for synchronous or asynchronous multiplayer games. For Android
it uses straight sockets, for web games it uses WebSockets. It
provides a GWT-like RPC mechanism, as well as an event-oriented API
wherein clients subscribe to "distributed" objects and receive events
when attributes of those objects change.
Unfortunately, it is not currently well documented, because it is
evolving, along with PlayN, as part of Three Rings' new MMO game
development platform (which is open source, as is all of our
infrastructure software). However, if you are working on a
serious/large project, investing the time to figure out how it works
will pay back great dividends.
The project itself:
http://github.com/threerings/nexus
And here's a (demonstration) game that uses it (also in-development,
but the basic bits are there):
http://github.com/threerings/atlantis
Currently the game uses a standalone server that embeds Jetty and uses
Jetty to serve the servlet which handles the web sockets stuff. The
non-web-sockets (i.e. Android) connections happen over a straight
socket, with a custom binary serialization protocol. If you plan to
host your own server, this is likely to be the best approach. At some
point, we plan to investigate how to get Nexus working on Google App
Engine, but there are various issues we need to sort out before that's
going to be turn-key.