Tuesday, January 31, 2012

Veggie Might

As I announced last week, I participed once again in the Global Game Jam. Sadly, our game was not ready at the end of the 48 hours, but there are still some lessons to draw. Moreover, we are planning to continue its development, so version 2 would be presentable.

The game is entitled Veggie Might. This is a MMO game where armies of Baron Broccoli and Count Carrots fight for... well, nothing at this time, but we've thought to bases to take over in a Domination mode. Anyway, we wanted to represent a huge, endless battle a la Lord of the Rings, and this is the link with this year's theme Ouroboros.

We used HTML5 and WebSockets. The idea is to let the players enter the battle as soon as possible. As such, we don't wanted them to download and install the game, it would have been an extreme barrier to the player amount. Therefore with HTML5, they just have to visit a web page and they're ready to go. Moreover, the other programmer and I were pretty new to this world of real-time online games, so we were willing to cross the gap.

The server was programmed in Java. I wanted rather to use Node.js to iterate faster, but I was angry whether it would support the overhead of 1024 players. Maybe it wasn't the proper question at the time, but anyway, it worked. The server is basically in charge of relaying one player's messages to the others (we didn't bother that much with security).

Server and clients communicate via WebSockets, on the server we used TooTallNate's WebSocket library. It works as expected, that is, the user sends and receives messages like with any other network library. Our messages were JSON encoded, there is no need to design a binary protocol in a prototyping phase.

The client uses LimeJS, a framework handling graphical scenes, events and sounds. The scene is a tree of nodes, Sprites being a particular node type. This translates well into HTML where the scene is a tree of DIV, and is very similar to Flash programming.

LimeJS is actually a library to use with Closure. Basically it is a JavaScript to JavaScript compiler, and that reminds me my work on libfirm (and that I also have to continue this work...). It adds a system for including other files that JavaScript misses a lot.

I wanted to do the client side to see the problems related to prediction and collisions. I've already done a project handling these problems, but wasn't in charge of that part. I guess it's useless to tell right now how I've done it as it's not working properly. One thing to note, however: I worked with a mockup server, actually a false WebSocket interface which simulates a server. This was very practical since I didn't have to wait the features on the server to be ready before making my own code. Therefore I'll always recommend to work with mockups on projects related to network.

The artist worked with an incredible interactive pen display. He drew in Flash, allowing to quickly see animations. The exported SWF sequence was transformed into a PNG sprite sheet with SWFSheet. The anchor point was buggy and I had to handle it outside of the animation controller.

I recommend two games from my location: Quadd for the hardcore gamers, and Backdraft for the softer ones. Both of them were made with Unity3D. A programmer on Backdraft told me that Unity3D was hard to use for a pure 2D game. Special ovation for the group from Toulouse which has spent the whole event doing paper prototyping.

A last word about the event: you, as a creator (programmer as well as artist), really have to attend to this kind of events. You'll learn a lot. And don't try to stay awake, particularly at the beginning. By sleeping, the brain will continue to work on your ideas, and this is much more efficient.

As I said, we are willing to continue the development, so stay tuned!

No comments:

Post a Comment