Tuesday, 26 June 2012

Bolo

Bolo was a popular Mac multiplayer tank battle game back in the early 90s (predating the Web!). I played it a good deal in the computer science grad lab at Auckland University. It's probably the most fun multiplayer game I've ever played. The core gameplay was quite simple (it had to be, on that era's hardware), but team strategy and tactics got very deep and games would often get very intense. It didn't have the problem that has turned me off RTSes --- an initial "rush phase" that usually decides the game in the first five minutes. Skilled players could turn around an inferior position, but it mostly avoided endless see-sawing too.

I've been looking for classic games to play with my kids and yesterday I decided to see what had happened to Bolo. The original Mac version is long gone but a clone, Winbolo, was written for Windows and ported to Linux. It was shareware for a while but now it's been released under the GPL. There is actually no downloadable Linux client --- the port was not maintained --- but in a few hours of hacking last night I was able to bring it back to life. The gameplay feels great, closely matching what I remember.

Winbolo would be a great game to port to the Web. It's tons of fun, multiplayer, open source, and not very demanding on the client. The only difficult part (but it's a biggie) would be networking. Winbolo is client-server using UDP. You could use Websockets but that wouldn't be ideal. What we really need is WebRTC datagram support. Fortunately, that's coming!

12 comments:

  1. Wow, that brings back the memories; I used to play that every day after classes in middle school. 30-odd kids in a lab full of mac whatsits... I can't even remember the teacher's name now, but he really showed us what was possible.

    I also played winbolo a bit back when it first came out.

    Porting it to the web is a great idea.

    ReplyDelete
    Replies
    1. Did you happen to go to school in the Chicago land area?

      Delete
  2. Well, not to discourage any new work, but there is an extant port using node.js and coffeescript with websockets. Adding support for WebRTC to node.js and porting it to use WebRTC could also be an interesting challenge. It also supports the original maps and documents the format.

    https://github.com/stephank/orona

    ReplyDelete
  3. Oh, that rocks!!! That looks like a great start to build on!

    ReplyDelete
  4. Reminds me of xblast, which we used to play in undergrad. Kind of like Bomberman. It needed a network protocol, because the network protocol it supported was "export your DISPLAY to another terminal". I think that eventually it got one...

    ReplyDelete
  5. I am not sure I understand something: how would WebRTC be superior to websockets in this instance? Thanks :)

    ReplyDelete
    Replies
    1. WebRTC adds support for an unreliable datagram protocol (including NAT traversal).

      Delete
    2. As I understand it, WebSockets are connections initiated by the client towards the server, thus bypassing any NAT traversal problem. If the client can connect to the Web server to get the JS code, it should also have no trouble initiating the Web Socket with the server. Or do I have an erroneous understanding of Websockets?
      Maybe you are implying that WebRTC would allow direct player-to-player communication without any server interaction? Thus reducing delay in communication by avoiding transit at the server? Then are you suggesting the server is only used to serve the code and insure the initial player "meetup", and then players play directly with each other, totally bypassing the server?
      Thanks for your answers !

      Delete
    3. What you say is correct, but Websockets use a TCP transport which means dropped packets require buffering and retransmission. This is undesirable for a game like Bolo.

      Suppose the server sends out a series of game state update messages G1, G2, G3 etc. For a game like Bolo you can fit the important game state into one packet. If packet G2 is dropped in the network, TCP will not deliver G3 etc to the application until the drop is detected and G2 has been successfully retransmitted. That's much worse than just ignoring the loss of G2 and delivering G3 etc, which obsolete G2 anyway.

      Delete
    4. I get it now! Thanks for the explanation :)

      Delete
  6. That screenshot is begging for community made reskins.

    ReplyDelete
  7. You know what I liked about Bolo, was the screen was very reminiscent of Exodus Ultima graphics on the C64. But you're a little tank with AI helpers, running around munching up trees, setting up mines, blasting other tanks. They put Spaceward Ho! on Android, this should be next.
    Lastly - Castles of Dr. Creep. Practically begging to be put on Android.

    ReplyDelete