Sponsored By

Build Versus Buy - When Reinventing The Wheel Can Be A Good Thing

'Why reinvent the wheel?' is a frequent question in the games industry. There are a lot of companies out there building great technology, which can save you time and money. Huzutech however, found creating their own solution had greater benefits...

Graeme Harvey, Blogger

May 10, 2011

9 Min Read

Before we kick off, here’s a little bit of background on the company itself...

Huzutech is a company that sits on the intersection between the virtual world, massively multiplayer and social gaming sectors.  The company has created a technology platform - HuzuVirtual - which allows developers, publishers and brand owners to create their own, wholly customised online, browser-based, multiplayer virtual world - quickly, simply and cost-effectively.

Huzutech virtual worlds allow players to interact, take part, compete and collaborate in online games and provides full integration into the various social networks that players use.

So, having said all of that...

One of the main social features of a virtual world is interaction between the players, users and participants.  This interaction can take many different forms.  It can  include explicit interactions between players, such as chat, but also game-based interactions such as movements of player avatars, which of course need to be transmitted to all nearby players, so the movement is duplicated within each participant’s browser.

In addition there will be server-level events which require notifications to be sent to one or more specific users, or indeed all users connected to a particular server.

The problem is one of passing messages between the player's game session, within the browser and the server to which it is connected - and routing all of these messages to the right destination.

There are several existing software solutions that can provide this kind of messaging within Flash-based environments, which was the initial technology for the creation of HuzuVirtual worlds.

In the early stages of the HuzuVirtual project, the plan was to use one of these packages - with Smartfox Server chosen as having the closest feature set.

However, the fit wasn't entirely perfect for the open and multi-featured environments Huzutech wanted to create. Smartfox’s memory footprint was larger than we wished, it uses Java primarily, which is not one of preferred development environments and there are issues around licensing and scalability.

Rather than compromise on the capabilities of the virtual worlds themselves, we decided to explore other options.  Specifically, we decided to look at writing our own simple messaging server.

Huzutech has a policy of allowing its development team to spend 5% of their time exploring and working on new concepts, technologies and ideas which could be useful for the company.  So the development team took the opportunity to explore what a multi-user virtual world messaging server might require.

The intention was to make something as simple as possible, that would scale out from a single server, through to dozens or hundreds of servers worldwide - without the licensing headaches which can accompany this sort of scale.  If we could do so, then it would make it easier for us to grow rapidly and be able to over-deliver on performance for our customers.

We also wanted to create something which we could adapt and customise freely, so we could optimise it to do exactly what we needed and focused on the virtual environments Huzutech was interested in creating.

Over a period of a couple of weeks, the team explored the technologies and infrastructure out there, the current tools and the benefits of each.

In the end, we chose to use a variety of widely-used and well understood, proven technologies.

The team chose to create the service using Python.  There were several reasons for this, not least of which is that Python is Huzutech’s preferred development language for a lot of server-side work.  So creating something using the same technology means we can rely on existing skills.

We chose to build the messaging service on the "Twisted" Python networking library.  This has a number of benefits, not least the fact that it’s open source, allowing us to get our hands dirty, go in and update things should it become necessary - though as it turns out we didn’t have to.  Twisted has proven very popular with a variety of very large projects around the world (and is used by NASA among others).

By focusing on the core capabilities and using simple, well supported technologies, we were able to create a comprehensive, yet focused messaging service, which provides Huzutech with all of the capabilities required and which can scale globally, handling tens of thousands of concurrent connections per server,yet is still extremely lightweight in terms of memory and CPU consumption.

We achieved this by creating a simple, dedicated core system.  This is extensible and supports multiple plug-in modules, which allow the handling of multiple message types and provides additional services as and when required.  This core  can be scaled out by connecting multiple servers together, while maintaining the simplest, fastest messaging possible.

The message server uses a simple protocol, which is easy to write for in any language and which can be balanced, tested and exercised with a variety of automated test tools.  Again, simple, easy to use, easy to test and focused.

In addition, by creating our own technology, there were a whole host of non-technical benefits in addition to those noted above.  First and foremost, creating our own technology means that there are no license fees.  At all.

This is significant because there are no complications with licenses and validation on multiple servers, which are intialised, shut-down and changed dynamically to keep pace with demand on a global level.

The whole project has added value to Huzutech as a company, since it provided a great deal of new experience for the development team, brought new skills in house and has created some useful new technology IP.  It may even create a possible new revenue stream for the company if we decide to release it commercially, or increase the company’s industry recognition should we license it out under the GPL.  Or indeed both.

Finally, the fact that it was created in-house allowed us to brand and personalise the project as we wished.  So please welcome ‘Hurutech’ (after the Ruru owl from New Zealand).

Overall, the decision to create new technology in house has provided huge benefits to the company on technical, skill-based and business levels.  All of which was enabled by the company’s decision to allow developers to explore new directions and ideas.  As technology evolves, and tools, platforms and middleware becomes ever more diverse, let your development team take the initiative and you can reap considerable benefits.

Read more about:

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like