Chris Hecker and Chaim Gingold spoke at GDC 2006 about prototyping and I’ve only recently discovered it. I wish I had read it before I began my prototype because they discuss some gnarly issues I’ve encountered.
1) Game Design Documents are truly useless in answering questions about a game like “Will it be fun?”
And that’s why we always need to prototype - to answer some hard questions scientifically (rather based on hunches). I completely agree with I’ve tossed large parts of my original GDD away because the GDD was based on speculation on what would be fun/easy/simple/understandable - half of which was wrong.
2) All prototypes try to answer hard questions so those questions should have yes/no answers that can be falsifiable. There is no point in asking a question that can not have an answer.
- Can this cooking game mechanic be made compelling?
- Can the player control driving a car using a video camera (i.e can the player deal with video processing lag)?
One thing Hecker + Gingold emphasize is failing early. The prototype’s goal is to answer the question as quickly as possible.
Quick == Cheap
Cheap is good!
3) Cost vs. Quantity… due to economics you can not just create a prototype will full-art and gameplay and in the end you DO NOT WANT TO. Hecker and Gingold talk about answering questions as CHEAPLY as possible - steal, use existing art tools, mock stuff up, etc… anything to avoid actually building a prototype with code + art.
Now, eventually you will need to program code and create art - the question is how much of each?
They say code is VERY EXPENSIVE and non-linear as you will need to build an engine, physics, rendering, input, etc. even before any “prototyping” begins. The cost of content is flat throughout the prototype (and game). It can contribute to answering the prototype’s question from the start.
They argue that content is preferred over code - that means trying stuff in Maya or Max or an art tool first. In my prototype, I’ve spent far too much time building tech and too little on the gameplay / asking-answering questions bit. Code is necessary in my specific case, but I should not be building scripting systems or anything that is more technology than necessary for the prototype:
The reason why you still need to code is to answer some technical questions like… Can I get 30fps with 1M polygons on the screen?
Their rule is “Only spend code where you need understanding; throw content at the rest.”
In my prototype, I needed answers to some hard physics questions that could not be answered using Maya-based art mock ups. I also had some critical pipeline and schedule/timeframe questions that if the answers were negative would have killed the project immediately. Remember, fail early!
I’m about a month or so behind schedule so I might as well talk about why:
Implementing deformable collision is HARD
My giant robots require skinned collision (collision geometry deforms while the bones are animating) for the superheroes to walk on. Most physics engines will not allow non-static collision meshes to deform/animate and not only will they not allow that they won’t calculate physics afterwards.
I’ve had to create a low-resolution collision mesh that deforms and matches the visible mesh. All of this was expected and planned. At every frame, I grabbed the skinned/deformed data from the graphics engine and update the collision mesh. Performance-wise this sucks. This wasn’t planned. Mesh-to-mesh collision is slow and expensive. The hero is a sphere/capsule and the robot is a mesh, there shouldn’t be any problems, right?
Wrong.
Mesh-to-mesh collision occurs when the robot interacts with the buildings of the city… this results in an immediate frame drop to 5fps or worse. The robot’s 50K polygons try to collide with 3000 polygons of a building The results are brutal.
There are multiple solutions to this problem, but none that pleasant:
Mirrored physics worlds with ultra-low resolution geometry
Pro: Speed, separation from main physics
Negative: Sync issues with duplicate physics world, adding complexity to the art pipeline
Extending the physics engine to accommodate for multi-resolution collision detection
Pro: One unified physics world, can make-do with procedurally generated collision meshes (requires no artist)
Negative: Very complicated to modify the design of physics engines (i.e BULLET)
My solution is a mix of the two. I’ve created ultra-low resolution collision geometry for the robots using a script and while I’m not extending the physics engine, I’m using its facilities to filter out collision between two classes of objects. It’s not ideal, because this filter is accomplished closer to the narrowphase level.
Designing vertex/fragment shaders is HARD
Months ago, I roughly mapped out the look and feel of the heroes and robots. I knew I wanted a GI look of spherical harmonics and to avoid lambert + blinn rounded white hilights + specular.
So I designed shaders to use BRDF textures. I started with one BRDF texture then two then three… each to control different viewer vs. light setups. The result is a shader that can emulate toon shading to satin - while avoiding the circular hilights of lambert. Every new feature I added (normal maps + hardware skinning) had to be properly integrated into the existing shader which was time consuming.
The worst part is taking these HLSL/Cg shaders and migrating them into your engine, because it’s not as easy as 1-2-3. Each engine has their own methods of binding lights/cameras/matrices to shaders. In OGRE the binding is accomplished in .program and .material files. Thankfully there’s a python-based script available for FX Composer that exports a basic .material file (40% of the work), but the rest requires a lengthy trial and error phase.
mul(M,V) is preferred in OGRE vs. mul(V,M) in HLSL/FXComposer
Y texture co-ordinate flipping
Global variables in HLSL/Cg are horrible and should never have been allowed, but all shaders use them.
.fx/.cgfx passes have to be manually re-coded.
The shaders from FXComposer are unoptimized for OGRE - also, sample OGRE shaders work in local/tangent space whereas the FXComposer shaders operate in world space.
I don’t recommend writing your own BRDF shader. I’d take an existing one and modify it:
Being a producer, lead developer and lead technical artist is HARD
I thought once the prototype ramped up, my managerial roles would diminish, but in fact they have increased. While I’m assigning work to 3rd party contractors (I understand I can’t do everything), I’m spending just as much time checking the work and fixing it as I am on my own work. The rigging has proved most complicated, but that’s a topic for another post.
Other tasks that have proved difficult:
Robot rigging (it’s not a simple character with a single rig)
But now the first robot has been properly rigged and joined together in game. Unlike most 3D characters, the robots in The Supers are merely a collection 12-15 parts that are stitched together using dynamic parenting.
The second robot, after much haggling, is almost through the rigging process. The time frame estimates per robot have been blown due to the unusual nature of rigging.
The hero is essentially ready for animation.
Oh yeah, Telefilm Canada is now an official financial participant on The Supers!
My first two robots in The Supers went from concept/design to hi-polygon modeling (waterfall method) which is a complete mistake because any future changes requires a massive re-working. I suspect AAA games have this problem. Once something has been decided and implemented, changes are hard + problematic + expensive.
So I’ve decided to use a more iterative approach since my deadlines are not as firm as others. I plan to rough model each robot, add a rig, insert it into the game and test out the gameplay before going into hi-polygon modeling. This is more of the “prototype first then implement” methodology and I suspect it will provide a better end result, but cause the project to take longer than expected.
An expensive game with a large team probably would bleed money and get canceled if it tried this method but that is the beauty of indie games - experiment, refine, experiment, refine!
100+ people showed up Friday night to attend the “screening” of the games made at TOJam 3 - all of thanks to the hard work of Jim, Em, and Rob.
It was a lot of fun to see games projected onto giant screens and have people play (or fail to play) them instead of hiding our works in some obscure directory on a hard drive never to be seen again.
Photos of the third jam can be found here/ Pictures of the Arcade night should be up very shortly.
It’s amazing, two years ago I looked for a public implementation of workflow management system for small media projects (like games) and now I still haven’t found an easy/cheap one.
I’m not talking about version control system like Perforce or Alienbrain. I’m talking about Flickr-like access to concept art, web-based access to changes + comments (think blog/Drupal), easy file upload and download (the version control part) and the ability to set and track the status of an asset (think approval levels). The justification behind all this overhead is the ability to share assets with offsite artists without resorting to FTP and E-mails. With FTP and e-mails there is version explosion and a lack of metadata (comments, history, requested changes, approval level, etc.) connected to it
The animation + visual effects business has Tactic but it’s not open and tailored towards those industries.
