I often get asked what kind of technology was used to build WarLight. WarLight’s server components are written in C#, and the Flash client is written in haXe utilizing Adobe’s Flex 4 layer for layout / buttons / sliders / checkboxes / etc. All backend data is stored in a Postgresql database running on Ubuntu Linux, while the website is served from IIS 7.5 running on Windows Server 2008 R2, both hosted on virtual Rackspace Cloud Servers.
WarLight’s maps are originally uploaded in SVG format (as every map designer knows), but they’re immediately converted by the server into a custom map format built for WarLight. This format is optimized to be quickly loadable by Flash, which makes loading games much faster than if they tried to render out the SVG directly.
WarLight’s communication protocol is custom written, as well as its object serialization protocol. After all, WarLight was started as a for-fun hobby project, and re-inventing the wheel is fun!
I’m a big believer in automated testing, and I’ve worked to have thorough coverage for WarLight from the very beginning. Before every release, WarLight goes through an extensive automated test pass that takes several hours. The idea is that the tests cover as many possible use-cases as possible. Any time a new bug is found in WarLight, I add a new test to cover it and this ensures the issue never comes up again.
Some of these tests use the Selenium web-testing framework to actually automate the browser and the Flash client. Here’s a short sample of what some of these tests look like when they’re running:
Having the WarLight testing being automated is essential. Due to the vast number of settings (and permutations of those settings) that WarLight games can have, it would be nearly impossible for me to do big changes or to refactor code and still be able to release WarLight with confidence that the game will still work. However, with the tests I can simply run them all and get a level of confidence that all of the features work. The tradeoff is that this makes each feature more time-consuming to add, since I not only have to write the feature but I also have to think up and write all of the tests that ensure the feature works.
3 thoughts on “Technology behind WarLight”
congratulations for this great risk game.
i’m a senior web developer, i want to know about how you did the game… and how you manage to finish it 😉
i like program games, and i’m very interested about this game, one of the best. to be sincere, create something like this is the dream of my life, so i want to learn from you.
is the multiplayer server based in sockets or web services?
its usual to make multiplayer socket server with java, the server was created with C# or only the web pages are in .NET? use asynchronous or synchronous socket server?
know you any tutorial for creating multiplayer web games or have any advice to give me?
have you thought in create a cell phone version of the game? as you used flash client, seems not too hard to adapt it
the others questions are about the tipical problems when you start a big proyect like this. start you alone or with a game company help? seems to be a lot of work for a single person, did you contract somebody to help you? how much time take to finish the whole proyect?
and what about the money?, first you can start working at half time (as a hobby), but later need money to work at full time, and for sure later will need money to pay some programmers to help you. how do you solve all this problems? have any partners or publicity?
thanks and regards
Thanks for the nice comments!
The multi-player server uses raw http requests using a custom-built protocol. The cloest point of comparison would be REST. I don’t have any specific tutorials to share, but for advice, I’d advise starting small. Get something small that works and is playable (even if it does not have very many features), then then iterate slowly, adding small features one at a time.
I did WarLight alone, and I’ve been working on it for about three years.
Just the best web game in ages. ALL HAIL FIZZER!