Physics and Animation do not work Thusly!

Hello my friends!  Stay awhile and listen!

Last time I mentioned that I moved away from level design within Unity to attempt other things.  My original vision for how Eruptoid would work was an entirely physics based system.  Similar to Monkey ball, you didn't actually control the ball, you controlled the tilt of the world, and gravity would pull the ball.  I ultimately decided against this because for the controls to make sense, you would have to change the pivot point of the level to be directly under the ball at all times, and I just didn't have the familiarity with the engine to figure out how to make that work.

Anyway, there were a few special objects I wanted to have in the game.  I wanted a conveyor belt that would shoot the ball in the direction the belt was facing.  I wanted a magnetic floor that locked the ball into whatever its movement vector was when it entered the floor.  And I wanted a piston that would be used to launch the ball into the air (since the player can't make the ball jump).

The magnetic floor was probably the easiest.  Its just a plane with a collider.  Upon entering the collider, the balls velocity and angular velocity are read and reduced by 2/3rds.  Then as long as ball remains colliding with the magnetic floor, its velocity and angular velocity are held constant.  Piece of cake.  The nice thing about the mag floor is that it only takes a short script and the collider to work, so any portion of the game level can take on this property without having a prefab for it.


The next easiest, though tedious, object was the conveyor.  This object was built entirely with unity primitives.  One cube for the body, 2 cylinders for the ends of the body, and then a bunch of elongated cubes for the treads.  The scripting was pretty simple.  Upon colliding with the object, the ball gets a velocity in the direction the conveyor is facing added to its current movement vector.  What was tedious was animating it.  The treads, you see, have to move, otherwise it just sits there looking like it wants to be a conveyor belt, but is forever frozen in a lifeless state.  So I had to animate each and every tread "cube" from its current place to its next place.  From there the animation can loop, because the animation is just to be pretty.  It looks pretty flawless when its working.

My final object, and the one that gives this post it's title, is the piston.  The goal of the piston is pretty straightforward.  When the ball rolls onto it, extend the piston, and the ball goes flying upward.  Here's how it looks in its 2 states:

Piston Up

Piston Down

I actually did this object 1st out of the 3.  Its why the other two were relatively painless; I was able to use what I'd learned on this one to make life easier on those two.

Remember how I said that I wanted this to be a physics based game?  Originally that meant that the conveyor would work by physically moving the ball, with collisions and motion of the treads doing the work, instead of writing code to do it.  The piston above originally did nothing but move when the ball made contact.  On collision, the piston portion moved upward relative to its base.  Physics would take care of how much this would effect the ball.

Turns out, physics in unity is not nearly precise enough to make this work consistently.

I come from an engineering background.  The modeling software I use for physics based calculations care more about getting the right answer than it does looking good or being quick.  I foolishly expected unity to be able to do the same thing, only in real time.  It doesn't, and it is expecting way to much to think it would.

The problem is that unity does its physics calculations on a frame by frame basis, but the position of the piston is calculated based on time and motion.  So the frame after the ball actuated the piston, the base of the piston would be inside the ball.  The physics system says that this can't be, and applies a positional change to the ball on the next frame to move it outside the piston.  Except now on this frame, the piston has moved even more, and despite the correction, the piston is still inside the ball.  So we wash, rinse, and repeat until the ball is now moving upward fast enough so that the piston isn't colliding with it when the physics go to do the collision calculation.  In theory, we should be able to adjust how fast the piston extends to get the results we want.

However, as you can guess, this resulted in wildly different ball speeds off the piston depending only on frame rate.  If we had a high frame rate, we'd have more accuracy and the physics would apply less force to the ball per frame.  However, with lower frame rates, the amount of ball the physics system found inside the piston increased, resulting in higher forces added per frame.  Using this method I could get 3 or 4 collisions with the piston on a single actuation, and would have my ball sailing skyward at ridiculous speeds.  And sometimes, the exact same piston would barely lift the ball at all.

In the end, I had to abandon my physics based fantasies, and alter it so that there would be no physics involved at all.  The piston now adds a velocity to the ball relative to the piston's orientation.  All in code.  The piston even extends using code to change its position, rather than an animation.  This is probably the hard way, but it works and I'm done messing with it. Not as cool as if physics were doing all the work for me, but this way I get a consistent result every time, regardless of frame rate.

Materials do not work Thusly!

Last time I mentioned that, even after my week long marathon of unity tutorials, there was still much I did not know and much I did not understand.  I had hoped to be able to make about 14 levels for the game that would become Eruptoid using only the basic primitives that you can create inside the Unity Editor itself, and the stretching things using x/y/z scales.

The idea seemed like it would work at first, until I applied my first material.

The first material is actually a texture I still use in the game today, though I've done some work on it.  The simple grass texture for simulating rolling on a grassy plane.  I also had a simple stone texture for my walls.  Here they are right here:

 

Aren't they glorious?  So, with my stretched out floor and stretched out cubes, I added these textures as materials.

Well, the sides of the wall looks ok, and the top of the floor looks ok as well, but what the heck is going on with the top of the wall and the side of the floor?

Remember how I said I was using basic primitives (cubes) and scaling them to be long or flat?  Yeah, textures and materials don't understand that.  The engine believes that the object is still a 1 x 1 x 1 cube, even though its now a 10 x 5 x 1 block.  So it takes that beautiful texture you see above, and it stretches it out in the direction the primitive is scaled.  The only reason these textures look halfway passable is because I have the texture itself also tiled in that same direction.  That's all well and good for a single individual block.  But here's the thing: these settings work on a per material basis, not a per object basis.  So while the settings on the side here work for the wall we're currently looking at, they don't work for another set of walls.  And since the material is global, that meant I couldn't use only stretched primitives for my level design.  What could fix this?  Instantiated Materials at the engine level.  Unfortunately, that's never going to happen because instantiated materials that work on a per object basis would make about a million other things more problematic.  Lets just say you'd end up redoing your materials for every object you attached them to.  Better instead to do things the right way.

Being discouraged on the prospect of making levels with the unity editor alone, I actually only ended up making one of them.  After that I moved on to different challenges.  Learning experiences, really.  I set out to make game object that would directly affect the player, with physics and animation.

Stay tuned for the next blog post: Physics and Animation do not work Thusly!

Welcome to the Dev Blog!

Welcome, ladies and gentlemen, to the Specter Industries Development blog!  I'm very excited to start this blog and to share with you all the exciting, technical, and frustrating moments I encounter
while on my journey from being "just a guy" to an indie game developer.

First, some background information.  My real name is Joel Kolodziej, and as a professional I am a manufacturing engineer for an international company.  I'm the son of a computer and systems engineer, so I've always had an affinity for pc software, hardware, and other nerdy things.  I took a few computer programming classes in high school way back in 1998 (c++, and visual basic), but otherwise, I've had no formal training in programming in any of the languages I find myself coding in today.  I went through a rebellious streak after high school and determined that I wouldn't go into computers professionally like my father did.  So I went to the University of South Carolina for a degree in mechanical engineering. I've always kept my eye and interests in building computers, and have always been curious about how games are made.  One day, about 2 years ago, I decided that, in my spare time, I'd find out.

Specter Industries is the soon to be umbrella corporation that will cover a wide range of activities.  The first activity under the Specter Industries banner is Specter Gaming, my Let's Play channel, that is slowly morphing more into a PC hardware channel.  My most recent series is on building my very own SteamBox, and before that a personal home media server.  Check it out if that's your thing, but this blog almost certainly won't be about PC building, or playing video games on youtube.

This blog is about Making Games.

The game I'm currently building is a Super Monkey Ball style game for mobile platforms I'm tentatively calling Eruptoid.  On a remote tropical island there is a super-volcano that is about to explode destroying the entire island.  What the scientists observing don't understand is that the volcano is actually alive, the living mother of the island.  In order to save herself and her creation, she is sending you, the Eruptoid, to gather mythic super-cooled artifacts to become a super-cooled pyroclastic flow who will ultimately fall back into the volcano's mouth, calming the building inferno threatening to destroy everything.

Gameplay is very monkeyball like.  Levels are relatively simple and geometric, with a starting place, 3 super-cooled cubes to collect each level (optional, but required for the "good" ending), and a bubbling crater you must roll into in order to complete each level.

Eruptoid is built using the Unity 5, with level design done using Blender for meshing and UV unwrapping, and Substance Painter for texturing.  This blog will touch on the hurdles and challenges I've encountered and overcome in all of them.  I won't be doing tutorials unless heavily requested.  I may live stream some of my dev work on the afore mentioned youtube channel.  I'll let you guys know about new posts and if I go live through my google+ page.

Please follow this blog and my google+ page.  Help spread the word about Eruptoid and help me make it yet another indie success story!