A New Way to Collaborate
Having worked on a number of different game editors over the years, I recognize that most of them have supported collaboration via an integration with some form of version control. A game is usually made up of a number of documents that we may as well call "levels". A level might persist as XML or some other format. If two or more people edit this data file simultaneously, there are a couple of things to note. Firstly, user A may not be aware of what user B is changing and vice versa. Second of all, when user A has committed changes, user B will have to merge her changes with user A's.
It is possible to limit the tool to exclusive checkouts, but this just means one user can block others and hold up development. Performing merges is fine when they can be automated, but this is not always possible. Merging code visually is something a coder is used to, but how do you have a designer intuitively perform a manual merge on two sets of level data? Although not impossible, it is a very hard problem to solve well.
So let us take a different approach. If our dev tools are running in the cloud, with all clients connected to one server, why not allow seamless editing from all users? Again, HTML5 gives us everything we need.
Using WebSockets (bi-directional comms over TCP), we can stream edits between clients so that real-time collaboration is possible. Once you have worked in this way and experienced the benefits first hand, there is no going back to the old "exclusive checkout", single-user environment.
Social Game Development
If you are a coder, it is a fair bet that you have a GitHub or BitBucket account. Just a few short years ago, most of us were content to install a local instance of Subversion or Perforce, to name a couple of popular version control solutions. And why not? They are marvelous pieces of software that backup and manage your code very well indeed.
So why the rise of version control as a service? There are many reasons, but the key driver is community. Coders can now network like never before, following other developers or interesting projects, and receiving immediate notifications as soon as updates are made. Bugs are fixed and features are added by a committed follower-base. And projects stand a far greater chance of getting exposure than if they were sitting on someone's hard drive or personal website as a ZIP archive.
So why let coders have all the fun? The same principles are perhaps even more relevant to game development, with the whole process provided as web service. This includes code development, but also covers other functions such as asset management, level editing, localization, QA, and publishing.
Let's face it: making games is hard, and making a (good) game alone is not an option for most developers. The spectrum of skills required is often just too great. Developers need to be able to find each other and get involved in the game projects that excite them the most. Want to allow the community to build extra levels for you? Not a problem. Need your game translated into Spanish? Perhaps your followers can help.
The Cross Platform Holy Grail
Making a game cross platform matters. It broadens the potential audience and can therefore make a game more commercially successful. It is now many years since Sun Microsystems coined the phrase 'Write once, run anywhere' in reference to the Java programming language and most contemporary games middleware is designed with this in mind. In a similar vein, HTML5 certainly has the ability to deliver game content to a wide variety of device types.
I would argue that it is very important for game development tools to be cross platform as well. Perhaps 15 years ago, a tools programmer would have built an app with a technology like MFC. With the passing of time, better technologies have arrived, to the point where .NET application development is generally acknowledged as being fairly painless -- but with it, you are still limited to Windows. In our multi-device lives, it seems overly restrictive that we have to be sitting at a desktop PC to access our projects. You should be able to access, edit, and publish your work from any device via tools that have a consistent interface and suitable controls.
Interface building with HTML5 is fast, straightforward, and designing web applications to work across multiple browsers is a well-trodden route.
Just a Link Away
One of the key strengths of HTML5 as a technology for tools is that all content sits on a URL. Each of the resources that make up a game can be accessed at a specific web address: a script file, a texture, a sound, a level or even the game itself. If a new asset is added to a project, the developer can tweet, IM or mail the link immediately. Nothing for other people to sync; it is there for viewing straight away.
This also simplifies publishing a game. If the game is already on a server and playable, publishing it to the wider web is really just a matter of access rights. A developer should be able to make a game live quickly and easily -- nothing to upload and no HTML to write. Publishing should just be a matter of pulling some simple levers in a web front-end.
When it comes to writing video games, no technology is perfect. Depending on the game you are looking to build and the commercial objectives that you have for it, it is important to fully appreciate the implications of selecting one technology over another. HTML5 constitutes a truly awesome platform, not just for powering games, but also for powering the tools that are used to build them. If you can live within its limitations and work with an evolving standard, it does have the potential to make you more productive and help your games reach more people.
As we look to the future, the process of making games will continue to become ever more accessible. Development tools will run on more platforms, be easier to use, and make collaboration far simpler. The global community of game developers will strengthen and knowledge will flow more readily. The ultimate result will be that more people will be making better games and we will all be better off in terms of what is available for us to play as consumers. All of this would not be possible without the web, HTML5, and the Open Web Platform to which it belongs.