Running games on the cloud is an obvious use of these resources.  Need a game server accessable from anywhere in the world?  Start one up on a virtual server.  The ability to build machine images (AMIs on Amazon), complete with your own software running on operating systems like Linux, OpenSolaris, or even Microsoft Windows Server gives you that possibility for pennies a day.

But, where cloud computing could really come in handy is in game development.  Imagine starting a build distributed across the cloud, in which thousands of virtual machines simultaneously start processing individual bits data.  You might see builds going from minutes or hours to just a few sconds.

And the cloud isn’t just for processing either.  Some companies offer services for managing data that would traditionally reside in a relational database, and as well as file storage services.  You could even use your own machine image running some flavor of SQL.  With that capability, why not store assets in the cloud?  An asset control vendor could use the software as service (SAS) model for asset control, supplying developers with web and client based views into an asset database on the cloud itself.

The big problem here is that we’re trading bandwidth for processing power and flexibility.  The build process may take a few seconds, but retrieving the results to local machines may eat up every bit of build-time savings and then some.  We may see overnight builds turn into overnight downloads, and that’s no savings at all. 

Bittorrent file serving (available on AWS) may be useful as a build distribution model, but with most users on a single network, it doesn’t seem likely to make a difference.  Limiting the download process to necessary files only is simply the flipside of building necessary files only, so may also offer little in the way of savings.  Doing a bit by bit comparrison of files built on the cloud, and downloading just the file differences, may be a way to reduce the download time, assuming there are chunks of data in a binary file that remain constant between builds.  Other optimiztions almost certainly exist.

All in all, it could be a big win, but until someone proves it, we can’t know for sure.

Team sizes are increasing.  So are the assets, themselves.  The more users stressing the system, the more fragile it becomes.

NxN had the right idea with Alienbrain but never really got anywhere due to serious technical issues with their back-end.   It’s been a few years since I used it last, so they may have fixed a lot of those problems.   Anyway, it also had some very nice features you don’t get in other source control solutions.  You could easily redesign the whole interface (it was mostly html and javascript as I recall), and they included a feature that was very art-centric.  Previews.

You could generate previews of assets and view them right in the Alienbrain interface.  It was a very slick feature and a selling point of the software.  Finally, a user could see a preview of a model or texture (and many other asset types) without doing a get and opening the files in Maya or Photoshop, etc.  That’s a real time-saver if you don’t remember the filename that was used for a specific asset.  You have the chance to browse all the assets of that type and find the one you want pretty easily.

Like I said, though, NxN had its share of troubles.  Still, I believe we can do better than the source control status-quo.  I imagine an asset database solution that integrates with every asset generating tool, as well as the build process, generates a preview for each asset (even if it’s a bitmap that says “Preview Not Available”), and is searchable by its meta-data, including tags, creator, last modified, and so on. 

The classic view of assets as a collection of files inside of folders, with users having to know exactly what files need to be checked in and out of source control when changes are made seems a little antiquated.  Instead of searching through folders ten layers deep, how about using a tag cloud to find assets instead?

I imagine being able to open a web-based interface, searching for an animated character from an old project and clicking a button to copy it to a new project, including all of it’s vertex, texture and animation data and using it as the starting point for a brand new character, or maybe just as a placeholder until a new character is created.  How many walk cycles does one studio need to recreate every time a new project is started, anyway?  Why not take something you have and modify it to fit a new character in a completely different game?

I really beieve that asset databases are the wave of the future for game development.  When the Xbox360 and PS3 came along, team sizes doubled, and assets got bigger and more complex.  What’ll happen next time there’s a hardware revolution?  We need to streamline the way we manage assets, or else, it’s going to bite us in the ass… even more.

Luckily, there is a lot of great software out there that is either open source or very cheap, and the very best solutions have risen to the top.  Most of us have heard of Blender, Gimp, the Torque Engine and Unity (which includes a $200 “indie” version), and there are a great deal more.  Check out IndieGameTools.com for a good list of the best stuff.

While some of these tools are really great, there will always be a need for custom tools, that aren’t very useful to other developers.  Smaller developers should consider partnering with a small tools development company or individual contractor.  there are a few people out there who are doing this sort of work and banding together can be mutually beneficial.  Getting someone experience to help out in this area can give a leg up on the competition, after all, the better the tools, the easier it is to make a great game.

Middleware companies sell complete packages for AI, physics, UI, animation, you-name-it, but what constitutes a “complete package” anymore?  What a lot of middleware companies deliver seems no where near complete, even for the subset of game development technology of which they are supposed to be the leading industry experts.  They release new versions monthly that game studios have to integrate to get lastest features and bug fixes.  Are we game developers, or simply beta testers for middleware companies? 

Many of these companies have great customer service.  They offer support tickets so developers can submit bugs and feature requests, but at this point, they’ve gone from middleware provider to service provider.  They customize a solution intended for the masses to the needs of individual companies, when what they should really be doing is applying the effort spent on maintenance of the current version on developing the next version.  After all, once a few games have shipped on the current product, its viability has been proven.  STOP DEVELOPMENT!  Give us what you have right now and put your development effort into making the next version that much better.

Sure, those companies that shipped games probably needed workarounds.  And the other companies out there with games in development have workarounds too.  Some of the currently supported features have unexpected results, or just don’t give you what you want. But do you really want to wait around for the “fix” anyway?  Waiting around holds up your production.  You have to remember that you are not their only customer.  It may be months.  It may never come.  It could be the fix that breaks everything else in your game.

You can’t rely on it.

So what can game developers do?  Well, the next time you’re shopping for a middleware solution for your project, and the salesperson tells you about the cool new features coming in the next or upcoming release, don’t plan on getting them in your lifetime.  If you can live without a feature, design your game without it.  If it isn’t there now, and you really need it, shop for another solution.  I don’t want to be a beta tester any more.  Neither should you.

Following up, what has been the impact of these rising development costs and a dwindling economy? What concerns have increased most for developers in recent years? […]Here we find interesting new news. Rapid prototyping enables a developer to more quickly draft and test game concepts for fun in the early stages of a project, and also use the prototype to acquire funding. Rapid iteration gives one the ability to quickly try out many ideas during development, improving the game through frequent experimentation and fine-tuning.

If rapid prototyping and rapid iteration are weighing heavily on people’s minds, what are they using now? And how many studios have live preview on the target platform in their current content pipelines?

It looks like they probably create one-off C++ applications, sketch things out on paper, or use Flash or Lua. I had suspected that more developers would be using C#/XNA due to the ease of quickly knocking out quick test applications with it, but only 5% of the responders said they are using this for prototype development. (However, 76% of developers are using C#/XNA for tool building.)

If rapid iteration is also a growing concern in game development, how many developers currently have the ability to do live preview on the target platform for their content developers (artists and designers)? According to the results, 62.5% currently have this capability. Several responders noted that they preview on a PC version of their engine and that this is good enough for most work. Certainly using the actual target platform would be even more valuable though!

This is one of many reasons why I think that increased effort in the Tools SIG will be important in the coming years. We should not only be helping people create prototyping systems (or building on those already available), but pushing for sharing of information that would allow things like live preview on all platforms, cutting turn-around time for all studios, and thus cutting costs.

As I said in the previous post, the Tools SIG will probably be running its own, similar survey soon, which will hopefully give us some ideas on where to focus our attention to make the biggest impact in tools development.

After some discussions with game engine middleware manufacturers, I decided to post a couple of surveys to see if I could get the pulse of what game developers are thinking.

There are two different surveys, one for technologists and one for producers, and I encourage everyone to go over and give Mark a piece of your mind.  Or at least some data for him to work with.

On a somewhat unrelated note, the Tools SIG will probably run it’s own survey in the future, and it will be one of the things on the table at the GDC talk next month.