Experiencing Webgamedevelopment

Hello everybody

Today I would like to share some recent experiences with you on multiplayer webgame development with Unity Pro 2.6.1 and the integration of webservices.

I will be doing this in relation to my work on Reign of Steel, an action oriented War Machine Combat game that entered the closed beta and thats running completely within the browser without any installation and reasonably short initial download times thanks to Unity Pros capabilities.
Reign of Steel offers action packed multiplayer combat on its own dedicate that offers engaging multiplayer combats


So let me start on the topic of webgame development.

Unity offers a very powerfull webplayer capability and in our case with Unity Pro we have even more powerfull capabilities in that field with the streamed webplayer and asset bundles.
These capabilities definitely help games to be developed and deployed much faster than with the traditional 3D web technologies basing on Java, yet it naturally still requires planning on how to handle the data, because one of the most important things with webgames that are not installed in some way (like BattleField Heroes or Quake Live) is that the user waits as little as possible while still being able to enjoy the game during the load of the remaining data.

We did quite a bit on research on the topic in relation to Unity and what our options are and I think we found a pretty solid solution which we intend to roll into the game at a later point.

An optimal handling is especially important in our case as we do not have some kind of social single player game but a realtime action oriented multiplayer game so when you jump into the game you need to have the data, loading them as you go would seriously destroy the experience and immersion and at worst give you a disadventage over the other players in your game.

At the time Reign of Steel is in closed beta and new keys are handed out on a regular base through the twitter channel ( http://www.twitter.com/ReignOfSteel ), through the wall on our corresponding Facebook Profile and through the thread on the Unity developer boards: http://forum.unity3d.com/viewtopic.php?t=45878


Whats just as important for the game is a good and solid choice for the networking.
We considered different networking architectures and different technologies which were suitable for our intend usage as services on our servers.
In the end after different experiments and benchmarks, and thanks to Unity 2.6s addition of headless Windows clients, we decided to go with Unity Servers, as they have a very low cpu load, offer all the data required for collision testing etc and work very well with the usage we had in mind.
Knowing about some of the problems of it we also wrote the networking code to be flexible and are now using a fully RPC based networking for all ingame things with additional WWW connections between webservice <-> client (fetching of data like username basing on the usersession on the website among many more things to come) and webservice<-> server.

This last yet a very important part of my work on Reign of Steel was and is the development of the webservice related implementation in the client and game server.
The first batch of that work is already visible in the beta, thats the usage of userdata that the client automatically fetches from the webservices basing on your session from the login on the website.

But its only one of many webservice related things on the client and also the server end that are in development or on the whiteboard for the future, like an ingame shop to buy weapon, configurable tank or gaining experience among other cool things as you play.

Working with webservices within a technology thats not layed out for webservices is not always simple.

As I’ve mentioned in the previous blog were I was not in the position to talk about the specific project in question unlike I am now, we were forced to look for an alternative solution to one of our problems due to security constraints in the webplayer (none availability of p/invoke)
For the webservices we had and have in mind, we happily had more luck, because there exist different solutions that are purely .NET.
We were looking for a library that works on the game server as well as the client and especially we wanted a lightweight solution to save precious cpu time on client and game server and we were lucky because we found exactly the solution that meets our needs, works fine with Unitys WWW while still being lightweight.


I hope you enjoyed this short episode on my past work and I would like to say sorry for all who hoped that the next blog entry will be about my IRC library.
I’ve had only restricted time recently to work on it but I definitely intend to drive it further and let you all see it in action in a way where it is enjoyable. That will likely not be in march anymore but definitely soon.