Innovation in games is all about new ideas. And new ideas, like new technology, fall into the realm of the unknown. And until you haven't experienced the unknown (that is, known it) you don't know what works, and what doesn't. This is what prototyping games is for.
Prototyping is something that doesn't receive much attention in actual game development. Surely, people talks about it, and some prototype stage is usually planned, but what usually happens is that upper management is expecting incremental releases of a product. And no matter how much you explain what prototyping means to them, they can't just be handed a demo showing a bunch of untextured cubes, "just because this is the layout of the level we're testing".
The reality is that companies don't usually pay much attention to prototyping, and yet it is one of the fundamental parts of the learning process for a developer, be it a designer, artist or specially a programmer. It is the process where the developer gets to know with some detail a specific part of the project at hand, tries different possibilities and gets data from all of them. Then, hopefully, some makes a decision, be it the developer or someone else.
Prototypes are not expected to be pretty. They are not expected to be optimal, fast or robust. Unless prettiness or speed or whatever is what you're actually testing. But generally speaking, prototypes are created to test a concept, then throw them away.
Wait a minute, throw them away? This is the part I've never understood about prototyping, or at least my idea of what prototyping should mean. Once you create your working prototype (or several) you can actually use them as the basis for more tests, or other prototypes. After all, if a prototype has been correctly designed, it should be fairly independent and isolate from the rest of the code, shouldn't it?
That's exactly the problem with most prototypes – they are created as part of the project where they belong, and creating a prototype under those circumstances breaks the idea that you're trying a new concept. What you're doing is work, actual work. And doing actual work without enough information (which is what prototypes are meant to provide) is not only a bad idea, but a waste of time.
So how does prototyping work?
Whatever your technology, the absolute requirement for prototyping is that it should be possible outside the environment where the project is being developed. Or at least, as far away from it as possible. The reason for that is that is that your prototype may interfere with other parts of the system, and there may be a lot of noise in the information obtained from that process.
So for example, if you want to try a layout for your game level, this is how you do it: you create the level in your editor, using just simple shapes and no other graphics or resources. Then place your players or spawn points, and you test it. This way there is no overhead in the level that may distract you, and you're not messing with actual assets, or a level that is half built.
For coders, prototyping is more like a dark science. The ability to isolate the conditions and data that allow prototyping a new feature is only acquired through trial-and-error. Say you want to create a new camera mode, and need to test it before you implement the whole thing. You would need an empty level to create and define your camera, and a piece of code that would load that level, and nothing else, to test your new camera.
But is this always available? Do modern engines or technologies provide support for this kind of development cycle, this trial-and-error approach?
Some of them are certainly designed with prototyping in mind – Unity3D comes to mind. Others are a pain to prototype due to the amount of dependencies in the code – UnrealEngine3. And for not so professional solutions, such engines as Irrlicht or Ogre3D allow fast prototyping with a minimal set of resources.
I've been creating a demo framework for the Zombie Engine with prototyping in mind. The idea here is that adding some complex mechanics to the whole engine and game framework may be difficult enough, which is why a simple demo environment should be enough to test many different things – new materials, lighting or rendering modes, cameras, controls, etc. I've been able in just a few hours to prototype several simple game cameras using this, and the results are excellent. With just minimal code, a few ugly resources and the bare minimum that is needed to run the engine, I've been able to test new features and experiment with control modes.
And what's more important, whenever I find a bug, or need to try something new on the same part of the game, I can just go back to the prototype (which should always be kept safe) and modify it to extend, fix or improve the feature, without the risk of breaking production code.
Go for fast code prototyping, by all means. If I could find happiness in a brick-textured torus, so can you.
No comments:
Post a Comment