Originally published in the Journal of Interactive Entertainment. Reprinted with permission.
"Um, Dave, we have a problem. There's a continuity error in the third scene that we missed in our initial storyboarding. We need to have Sgt. Preston turn right and walk over to the statue so that he notices the diamond ring on the table. Otherwise, the scene doesn't make any sense."The point I am trying to illustrate here is that "content assets", such as background stills, animated characters, music and sound effects are all labor intensive tasks, and once created they are not easily mutable. So once you've created them, you are pretty much stuck with them, unless you want to spend more money."We can't do that. We don't have any animated frames of Sgt. Preston walking right."
"Well, then schedule the animators to create some."
"Umm, that's a problem. You see, we only have enough money allocated in the budget to draw 63 frames for Sgt. Preston. We've already drawn 50 of them, and the last 13 are needed for the scene where he draws his gun and fires at the shadowy figure in scene 4."
"Can we drop scene 4? I mean, it's not crucial to the story."
"Well, yeah, except that all other characters in scene 4 have been drawn already, and if we drop it, all that work is going to go to waste."
"Can we get some additional money from the publisher?"
"No, we're already over budget, and the publisher is getting pretty impatient. We're just going to have to make do with the frames we have."
"Well, alright, what kinds of things can we do with the frames we already have?"
This would be fine if we could plan out everything in advance and not make mistakes. However, it is my observation that even the most carefully-made plan will have numerous tiny errors in it. Furthermore, the immutability of assets means that even if the writer or game designer comes up with a much better idea later, it can't be used because the game design is now set in stone.
Programmer 1: "Hey, I just had a cool idea. What if I made the Sword of Argon shoot flames whenever you attacked?"
Programmer 2: "Oh! And I could add a wall of ice into the DragonKeep that you have to use the sword to melt through."
Programmer 1: "Cool. OK, all I need to do is add a "hot" property to the sword, and have the sword's 'strike' script trigger a fireball effect."
Notice the difference? In a project without assets, the designer (in this case the programmers) are free to indulge their creativity at a moment's whim. They can add any feature they like, all they have to do is program it -- and if their underlying engine is robust, programming it is usually a minor effort.
In this scenario, there is little if any planning of the game in advance. The designers add new ideas as their Muse dictates, and they really don't know what the whole game is going to look like until it's done. This would, of course, tend to lead to a chaotic, disorganized game world with numerous internal inconsistencies.
Is a chaotic, disorganized game world neccessarily a bad thing? I find that role playing games, for example, are more enjoyable if they are filled with rich, heterogenous detail. It's like an amusement park, there's always something new to travel to and see, always a Shangri-La just over the horizon. (If you think about it, Disneyland has also been designed by embellishment, no matter how carefully planned each individual attraction has been). Certainly, I find this structure more enjoyable than the "watch a movie, then click, watch a movie, then click" games.
It's my contention that design by embellishment, while not appropriate for every or even most projects, is a valuable option to preserve. Certainly it's a lot more fun for the people working on the project -- and that's important, because if the creators are having fun, that's going to leak through to the audience which will help them enjoy the product more. (Also, letting your workers have fun in their work is a good way to hold on to your staff in these days of predatory talent agencies).
When all assets are mutable, we are free to engage in whatever level of planning is appropriate. We can plan just the overall story, and then design more detailed structure as we go along, or we can plan out everything to the smallest detail in advance. However, when we introduce immutable assets, we have no choice. We have to plan everything, and we have to stick to the plan.
By "parameterizable" I mean that the assets can change based on a parameter or set of parameters which are determined at runtime. Rather than trying to generate a complete new asset at runtime (such as 3d modeling), the ideas here relate to taking hand-created assets and running them through some sort of real-time tranformation.
Another form of parameterization is facial construction. For example, we could store the hair, eyes, nose, beard, etc. as seperate sprites, and "build" faces out of components. This would allow us to have many more characters, or even to create new characters during game play.
Another form of parameterization which I have had great success with in the past is component sprites. One game had each character rendered as three seperate sprites, one for the character itself, one for the object being held in the right hand, and one for the object being held in the left hand. For example, a character with 128 frames might be holding a broadsword. The sword has 32 frames, representing the different angles at which the sword can be held. As the character walks, his arms swing, and the sword moves in sync with the arm, because each character has a table of hand coordinates corresponding to the individual frames of animation. I can give this broadsword to any character in the game and it will show them holding in their hands. I can take a dagger, which also has 32 frames, and give it to any character in the game, or any other "wieldable" object for that matter. So any character can hold any object and any object can be held by any character.
You can take this even further and construct characters out of individual body parts. You could put different heads on bodies (a la Habitat), dress the characters in different clothes, or any number of other transformations.
The logical extension of this is of course tiles. We now have isometric tiles (the diamond-shaped ones) as well as the more traditional square kind. However, what people often don't realize is that any linear coordinate system can be done as a tile map. (It's also interesting to note that biggest advantage of isometric tiles, the fact that the artwork can "poke out" of the diamond shape to overlap onto other tiles, could just as easily have been used in square tiles. It's just that people had this preconcieved notion that square tiles had to be, well, square.)
Tiles are highly mutable because it's easy to place them -- most of the work is in drawing the tiles in the first place. You can add an extra building without too much work, or even have the buildings be created at run time, as in Sim City.
The ultimate form of background parameterization is ray-casting, as used in the "Wolfenstein" style of game. We have "assets" (in the form of texture maps) which can be transformed into background scenes in a fraction of a second. And we can change the map any time we want by going into a map editor. This is where we start to blur the line between parameterization and full real-time generation of visuals.
The obvious way to implement this is to use the delta-frame compression, to store only the differences between adjacent frames. What is different about the rotating heart animation is that the delta-animation is non-linear. Each delta-frame "state" has several "branches" leading other potential "states". The mouse can be used to control which branch is taken. Each possible state transition is stored as a delta record, which stores the visual changes between one state and the next.
This has a number of possibilities for use in games. For example, imagine photo-realistic puzzles involving ray-traced objects with reflections, refractions and shadows. You can render every possible state of the puzzle, as well as the animated transitions between states, as long as the puzzle as a reasonably small number of state transitions.
A lot of people have told me that this would not work out, that it would sound just like the phone company's robotic-sounding directory assistance. Well, the digitized speech you head from the phone company is deliberately robotic, to enhance clarity.
I've done some experiments using a digitizer, using cut & paste to create sentances, and it sounds terrific! You just have to watch the inflections. For example, if a word is going to be spoken in the middle of a sentance, then record it in the middle of a sentance, and clip out the word you want. Don't record it as a single word. If you have problems matching the tone, then cross-fade between samples as opposed to simple splicing (i.e. fade one sample down to zero while the other is fading up to full volume).
I have a little demo that was created for me by Lawrence Schwedler, the Dreamers Guild Music director, using the "Max" program on the Macintosh, which can interactively splice together sound samples. I recorded my own voice doing an impression of a pirate attempting to bargain: "Aye, that'll be one hundred thousand crowns." I then recorded all of the digits ("one", "two", etc.), as well as the words "hundred", "thousand", "million". As an extra touch, I put extra vocal stress on the word "million" so that the word has a touch of outrageousness to it.
In the demo, then, you can enter on the keypad the amount you want, and the pirate says it: "Aye, that'll be one hundred and twenty thousand, two hundred and sixty-two crowns."
How does it sound? Pretty good. Yes, you can tell that it's not a natural recording, that it's been spliced together, but only barely. It's unobtrusive enough that most players would be willing to suspend their disbelief.
Unfortunately, this is such a deep area that it would take a whole article by itself to really explore properly, so I'll just say this: I'm working on it, and I'll write an article about it in the future.
I've noticed that there is a certain psychological resistance to the idea of parameterizable assets, and it is invariably based on preconcieved notions which do not hold up in practice. For example, I think a lot of people have overlooked Chris's facial expression idea because of the cartoon-like facial constructions that we've seen in those "build-a face" books. And people have a resistance to the idea of voice splicing because of the phone company's directory assistance. There is this general feeling that parameterized assets aren't quite as good as immutable assets because of the "generic" quality they have. And this feeling derives, I think, from the fact that most of the attempts we've seen in real life to do parameterizable assets have been done pretty badly.
The one thing that all parameterizable assets must have in order to be convincing is seamlessness. A perfect example is tiles -- it's not very difficult to create a set of tiles that looks very natural and completely hides the fact that it's a tilemap. Tilemaps don't have to look like Lego-Land. Just make sure that each landscape tile has a rough, irregular edge that seamlessly interlocks with the tile next to it. Avoid straight lines, and avoid constructions that slavishly follow the tile geometry.
Part of the problem is that parameterizable assets are a deep synthesis of programming and art. In order to do them right, you need to have a programmer/designer who is artistically sensitive, who has a critical and uncompromising eye for artistic quality. This person needs to carefully instruct both the programmers and the artists, telling them what constraints they must work under, educating them as to how the parameterization works, and supervision the process of asset creation so that all the parts fit together seamlessly.
Given that you can find such a person, there is no reason why parameterizable assets should look any worse that the immutable kind. The sprites in my game look just as good if not better than the sprites in any other game I have seen, yet they are vastly more mutable.
By freeing designers from the tyranny of assets, we can create games that are more responsive, more adaptable, more replayable and more enjoyable than before, and still achieve the level of production quality that makes for a major seller.
[Postscript: I just spent the last two years attempting to prove the proposition given above, by creating a major game project using exactly this philosophy. I can report that it in some ways it succeeded brilliantly, and failed miserably in others. Technologically, we met or exceeded our original goals in creating a flexible, rapid-prototyping environment for role-playing games. However, this took a lot longer than we had planned. I would reccommend for anyone who wants to try this approach: 1) Make sure your engine is finished and debugged before you start embellishing the game, or you are going to have a lot of people wasting an incredible amount of time, and 2) Make sure everyone on the team, especially managerial types, understand the embellishment philosophy and buy into, instead of having people working at cross-purposes. There's nothing more wasteful of resource than having "parallel development" with a buggy foundation.]