SporeDay – Answers from Chris Hecker
Posted by ballightning on May 27, 2009
Maxis recently got people to ask questions for Chris Hecker to answer about the various areas of spore his has worked on. Maxis choose the top 50 and then users on the official forum voted for their top 10, through Chris has answered many more then that. Here are our two favorites, head over to the Official Forum for more.
What do YOU think of the asymmetry campaign? Do you think it may be a good idea?
Asked by CubeTubeMan, Sgt.Waffles, TexasGamer, ZEE_EXX, poisfig, dinoboy300, nebula27, SPYDR
I’m really glad this one got the most votes, because it happens to be what I’m working on right now! So, yes, I think it’s a good idea! First, some important caveats: this is research work we’re doing to investigate the feasibility of asymmetry in the creature and vehicle editors. It might not work for any number of reasons, and therefore, there are no guarantees it will ever see the light of day and ship, but please keep your fingers crossed and beam us good bug fixing karma!
A bit of history about the creature editor and asymmetry to give context: there were actually three generations of the creature editor over the years of Spore’s development, lovingly called CE1, CE2, and CE3. Each successive editor built on the lessons learned from working on and testing the previous one. Obviously, only CE3 ever got to a shippable state, and the others were just prototypes. I think they all supported asymmetry to one degree or another at various points in their development, even CE3. However, as we fixed the bugs, figured out the final user interface paradigms, and polished up CE3 into the creature creator you all know and love, the asymmetry code got less and less attention because resources were limited and it was optional for shipping, while the symmetric editor manipulations were essential to making the editor work intuitively. As we say in the business, the asymmetry code “rotted”. This is a pretty natural process for complex software…the more important features get prioritized, and some cool-but-optional parts sometimes rot and have to get disabled due to time limits and resource constraints. We always hoped to bring it back, but we just couldn’t spend the time to do so before Spore’s release.
After we shipped last year, Dave Culyba, one of the main editor programmers, and all-around awesome guy, started to resurrect the old asymmetry code and fix the bugs. Let me be clear: the old asymmetry code never actually worked well and it needed to be completely rethought, and so Dave had to do a ton of smart and hard work to get it up and going. He solved a lot of the difficult problems (like “How does the editor economy work when you can delete one of the pair of parts?”, “What do you do if you drag a symmetric part to an asymmetric limb, and then drag it back, without releasing your mouse button?”, etc.). After GDC this year, I decided to take it on, and now Dan Moskowitz, the lead editor programmer, is working with me and we’re giving it a shot.
We’re really excited by the potential, and we’ll be able to talk more about it later, assuming our confidence in it shipping increases over time. It’s still buggy with lots of edge cases that we need to fix, but we showed it to the Adventure Camp folks last week and they all literally gasped when I did the first asymmetric operation, which was great. If it ever ships, you guys will go crazy with it, and I can’t wait to see what you make!
Just remember, there are no guarantees this will get released, it’s still a research project at this point, so please be patient and think positive bug-fixing thoughts!
Why did you get rid of the procedural animation for Spore? Was it a play testing issue? Was it buggy?
Asked by Bofosho2, Mystfan, TexasGamer
Also, how did the original, (GDC ’05) Proc. Animation system work? (I know that it wasn’t a working game then, but you did have the editor, according to one of your interns.) It must have been a pain to code.
Asked by Bofosho2
First, it’s important to understand that there never was some other version of Spore that got changed at some point, there was only a growing number of technologies that solved problems and a constant learning on our part about what game we were making and how to best use those technologies to make it. To use an biological analogy, it’s not like there was an existing, fully formed species that then went through natural selection yielding other fully formed species over time, and then we finally decided to ship one of them. It’s more like a single creature gestating in utero, starting out as a clump of cells that looks nothing like a game, eventually forming into somewhat familiar shapes (maybe it had a vestigial tail at one point in its development that disappeared, etc.), and finally it develops lungs and a heart and becomes viable and it gets born. Or something like that. 🙂
As for how the 2005 animation system worked specifically, I talk about it a bit in my GDC 2007 lecture. There’s a screenshot of one of the scripts in the slides at that link if you’re curious, and you can download the mp3 to hear the description. It was basically a scripting language built on top of Lua. There were two main problems with the original system. First, it was very difficult to get expressive motion out of it, because the motions it produced were very linear. In other words, a hand could grab towards a piece of fruit, but it was hard to naturally vary the hand’s speed during the grab, and it was even harder to script movement tangential to the direction of the fruit, both of which are absolutely vital to an animation reading as having anticipation and intent. Second, as I say in the lecture, because it was a programming language, it was unclear who we should hire: programmers who can animate, or animators who could program. Unfortunately, the intersection of those two sets is almost empty, which created a huge production risk because we had thousands of animations to create.
So, to solve these two problems, we redesigned the system to implicitly handle the proceduralism as much as possible, and expose the expressive parts to the animator, as you can read about in the SIGGRAPH paper. The final system has a lot of familiar controls to a character animator, and then it handles the heavy procedural lifting of applying the animations to the different shapes of the creatures. We’re pretty proud of the results, and you can see the animators were able to get a lot of emotional expression that reads even on pretty insanely shaped creatures!
I also think there’s a misconception about the definition of the word “procedural” when it comes to Spore’s animation system in the first question. There isn’t really a consensus on what “procedural animation” means in the computer graphics community. It’s a pretty blanket term for “non-traditional animation”, so it’s not really very useful to try to label one system procedural and another not. A working definition could be, “is a given animation asset described only by code?”, in which case the old system was procedural and the current one is not, but that ignores how the line between code and data is quite blurry in practice, and so a more useful definition that would better fit the more common graphics usage would be, “is animation data just a recording of joint angles that’s played back, or is heavy processing involved in taking the source data and producing character motion?”, and by that latter definition the current system is highly procedural.
Rather than labels, I think players are more interested in what the system can do, and although I think we did an amazing job, I also know the GDC 2005 demo showed a couple cool things that really resonated with people that the system we shipped did not do. The two biggest ones are what we callweapons-anywhere, which I discuss below, and drag-carcass, which is something we hope to get back in there at some point. Both were just time/priority issues during development; there’s no inherent reason they would work in one system but not the other.
I hope that clears up some of the questions around these topics!