A friend of mine has made a Java version of a popular board game in Java, and has it working for multiplayer on one PC with different turns for each player. He's mentioned he wants it to eventually run from a webserver and people around the world can play the game together, but he's dismissed this as impossible (translated: Too hard to be worthwhile).

I'd like to make this happen for him, and I'm wondering:

  • Do we need to completely rebuild or can we just adapt the existing code, for the game to work across a network?
  • What are the advantages of a GWT based browser game, compared to a swing based client side game that updates to a server?

What is the common practice here, for going from one instance on one PC to multiple instances across several networked PCs?


The game code is very well broke and down and generalised; game logic and display are completely seperate. The main GUI is a scroll pane with a dungeon, squares are coloured for monsters, players, doors, floors etc, and are just JButtons essentially. Players have turns and then the monsters have a turn. It's very simple in essence.

  • 1
    \$\begingroup\$ Your best bet may just be to port to JavaScript, if it's a simple enough game. Aside from that, adding networking to a game that wasn't designed from the ground up for it is a very difficult task. You at least have a turn based game, which makes it easier, but there are still goIng to be a lot of rough bits. Especially if you want smooth enjoyable experience and not "just working". \$\endgroup\$ – Sean Middleditch Aug 12 '12 at 3:30
  • \$\begingroup\$ @seanmiddleditch thanks! This exactly the sort of thing I need to know. It is an excessively simple game though. \$\endgroup\$ – Pureferret Aug 12 '12 at 3:54

I know nothing of your game design, but I can say that attempting to develop a game in GWT probably isn't the best path to take. A team and I created a Words with Friends clone in GWT, and while we did get it fully working, we were very limited by what we could do graphically within the GWT framework. We also used Google App Engine as the server solution, and outside of using their great, but expensive, Channel API to update data between client and server in near-real-time, we had to just continuously poll the server, which wasn't ideal. This is just one issue you'll have to face when dealing with browser limitations. So, I would say there really is no advantage of using GWT alone, if due to the graphics limitations alone.

I'm not sure why your friend thinks "it's impossible", and it would be helpful to have more details on that, but I would have your friend take a look at PlayN. From the PlayN site:

PlayN is an open-source cross-platform abstraction layer that uses the GWT compiler to take one code base written in Java and compile it into targets that run it as HTML5, Flash, Java, or as a native Android application.

It's hard to say the level of work involved without knowing more about your friends code base other then it's a Swing application, but he could port to PlayN, which I'd imagine would allow him to keep a majority of his game logic code. Regardless of porting or not, he would still need to implement networking capabilities in order to make the game multiplayer, both client and server side, "tack on" as you put it. What is impossible is to tell you if that would relatively be a nightmare or not without knowing about how he implemented his game in Swing.

  • \$\begingroup\$ I'm not sure what I'd need to tell you about the game so you could answer better, but knowing not to go with gwt and keep it in java/swing with a tack on network code to pass information is great to know. Thanks! \$\endgroup\$ – Pureferret Aug 11 '12 at 22:42
  • 1
    \$\begingroup\$ Sure thing. Based on your edit, sounds like porting to something like PlayN wouldn't be too bad (and would help make the game look prettier :p). If you need a quick overview of traditional game networking, see gafferongames.com/networking-for-game-programmers/… \$\endgroup\$ – Cooper Aug 11 '12 at 23:19

The changes to the game logic to support networked play ought to be fairly minor. Essentially, the UI generates events which happen to be transmitted over a network. As long as all the events are pushed through a knothole somewhere, turning that into a networked version is relatively simple.

Developing the network infrastructure itself is difficult, because you have to deal with player disconnection and reconnection, simultaneous setup, and keeping all the players in synch. It's also probably unnecessary to do it yourself, as several good frameworks exist. (Try Jogre for example).

The hardest thing is developing an audience for the proposed web site, as it's not something you can do by just increasing your effort. Getting to the point where 4 players are routinely available to start a game is hard.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.