Search this blog

25 May, 2008

Best tech for next-gen games

I've got a new projector, here at home, so I'm trying to watch some horror movies. I have "the exorcism of Emily Rose" and "the Blair witch project 2", both of them I've already seen. Problem is that I'm really scared by horrors (that's why I watch them) so I used to always watch them with a friend of mine, when I was in Naples. Shame is that I can't call her now, so I'll try to distract myself from the movie by writing a couple of posts.

What's the best tech, the most useful piece of technology we can code for a next-gen game. Well, some will say things like realtime shadows, ambient occlusion, HDR, DOF, motion blur, rigid body physics etc... Very interesting and exciting stuff.

Stuff that requres time, to be done properly. And who knows what other interesting stuff we will invent, in the following years... Does all that really matter?

I don't think so, no, it does not matter too much. I've seen incredible games being made with relatively low tech engines an example being GT5. The truth is that we're not limited by the technology, we're limited by the time (and money). Next-gen projects take so much effort in order to be done that we're not really using properly even well known algorithms and shaders.
Designers and artists need time, and iterations, in order to fully use what we give them. Giving them more time, faster iterations, that will make the difference. And the same applies to coders as well.

The key to the success of a nextgen game is the iteration time. What's the key to lowering iteration times? Data-driven design. Databases. Databases are the best tech for next-generation games. Tools matter. More than anything else.

Some effort has been made, it's not rare to have some kind of scripting, probably an in-game console, the ability to tweak some parameters, probably to save them too. You will be really lucky if you are working with an engine that lets you hotswap shaders. Even more lucky if you can hotswap meshes and textures, after processing them with your asset pipeline.

But usually even if you have all those commodities, what I still have to see is an integrated system, decoupling code from data, dividing data in its most basic components and relation between components (i.e. meshes, shaders, textures, material parameters, are separate, but related, entities), and integrating with version control, build, DCC applications, networked update (hotswapping), reflection of code structures into data and code generation of data into code structures.

I would like to be able to launch the game, drop a track, make a model of a car with a DCC application, "build" it, load into the game, attach the car to the AI, tweak its material parameters, and save the resulting configuration into the version control system. That would really be a technological breaktrough.

It would be a dream come true if I could even hotswap code, not only tweaking scripts, but actually having a dynamic linking system... On some platforms this is not allowed in a shipping game, but for development is doable...

P.P.S. Data driven does NOT mean overengineered. You should not reduce everything to single system, small, specialized systems are fundamental, procedural models, ad-hoc algorithms, are often better than collating together pre-existing generic pieces. The data-driven infastructure
should also make easier to write a new subsystem, and to integrate it with the tools. Generalizations should be made only if they save work, and only if and when they are needed, not apriori.


Anonymous said...

I think you're correct with the tools. They really are very important, much more so than anything else in there since the project will live or die by the quality of them. Unfortunately it's a little bit like televised poker with games development. You only see the exciting moments, but not the important buildup. HDR rendering, massive physics systems etc. They can all be summed up and highlighted by a small video or screenshot. They look cool. But how do you quickly summarize that you've got a really simple pipe for the artists? Oh, look we can click this and click this ...

As for the dynamic code. Edit and continue for the win :) I think it also worked on Microsoft's platform, although as I understood it doubled the code size each time (so you'd better have your codesize down). It works pretty well on the PS3 as well. On the PS3 you can also pretty easily create a system for reloading your SPU elfs during development. It's kind of trivial since it's data as well. Really useful though, more so the more code you have on the SPUs of course.

I enjoy your blog, keep up the good work.

DEADC0DE said...

Edit and continue is really nice, but on C++ projects it's incredibly slow. It's usually faster to do a full recompile, it's true that you have to restart the application, but still works better. But I didn't know that you could edit-and-continue on the ps3, and I haven't tried it on the 360 as well, I'm talking about my experience with PC, that was so bad that I didn't try it again with the other platforms.