Warning: Parameter 1 to wp_default_styles() expected to be a reference, value given in /home/www/dotmos/wp-includes/plugin.php on line 546

Warning: Parameter 1 to wp_default_scripts() expected to be a reference, value given in /home/www/dotmos/wp-includes/plugin.php on line 546
DOTMOS » How one step back can result in five steps forward

How one step back can result in five steps forward

Posted by on Feb 26, 2014 in Game Development, gentlymad, Shader & Effects | No Comments
How one step back can result in five steps forward

Cross post from gentlymad.org

While developing In Between we had the idea of a dynamically shattering a specific story scene into pieces. The scene should shatter based on the players position in the world and should react to it in realtime.
We discussed the matter and came to the conclusion that we would create an animation in 3D Studio Max, export it to Unity as .fbx and then set the animation timeline position based on the player’s coordinates. This way we would have the most freedom in staging the animation.

Matthias ended up creating a pretty cool animation. It was well thought out and shattered nicely.


Then we tried to export it.

It turned out, that you can’t bake some modifiers in 3dsmax so when we exported the model, the shatter-animation was missing. We tried different scripts that would first export the model frame by frame and then re-assemble it in a second step, but these often crashed and if they didn’t crash the outcome was completely wrong. At this time, Matthias had spent 4-5 hours on the whole thing and was now pretty busy with cursing 3dsmax.

Me: “Well…i could try to write a shader for this effect…shouldn’t be too hard. But i can’t promise if it’ll be fast enough on mobile devices … drawcalls or fillrate might kill us”
Matthias: “You can do that…?”
Me: “I guess…”
Matthias: “How long would that take?”
Me: “About 30 minutes to 1 hour for a prototype”
Matthias: “I think you should give it a try”

So i started working on it and to my surprise had a working prototype in about 30 minutes (more on the technique in a future post). I then started playing around with it…
… about 1 hour later Daniel looked over my shoulder, trying to catch a glimpse of what i was doing all the time.

Daniel: “What the…this looks great!”
Me: “What the… where has the time gone!?”
Daniel: “We should totally make this a gameplay element, this looks fun!”
Me: “Yeah… i have been blowing up spheres and cubes for an hour… i guess you are right”

So we ended up putting the shatterizer in every scene, blasting the level into pieces each time the player dies without any sort of pre-production or baking. We also introduced a special “Shatter Mode” to the game that will be unlocked once you played through the game once, making it significantly harder to beat the game. Over the time we also extended the system step by step to make the game more responsive to the player’s actions in general.



So, after all, 3dsmax modifiers not being bakeable was actually a good thing. Not only is it a lot easier now to shatter a level, it is also a easier to tweak the shattereffect than it was in 3dsmax. It’s also more responsive and led to an improved look and feel of the game.
Oh and it also helped us in solving a pretty big dilemma with storytelling (more on that in a future post).



Sometimes limitations can really help to push your game forward as they force you to think in other directions.

Do any of you guys have similar experiences you want to share?