User Tools

Site Tools


blog:160210_learning-from-implementation

160210 - Learning from Implementation

Last night I started the Mech Unity project and created a script to control movement that's very similar to the handling in Mechwarrior 2. In my writeup yesterday I wrote about how I viewed the the engine as a simple state machine that switched between idle and moving. I initially wrote a simple switch/case that used that exact method, but I ended up ditching it in exchange for a more direct handling of the throttle (the code's still there, just commented out).

In the Input Manager I created ten buttons for [1] through [0]. During Update(), the script runs through each of those buttons from lowest to highest in a for() loop, and if one is pressed it assigns the coordinating throttle number to a float. That float later gets divided by nine, and the result is multiplied by the maxSpeed float to determine the moving speed of the mech.

Ditching States (sorta)

So why the state machine mentality? Well, I'm not sure yet, but I think that still at least keeping some code that keeps track of what “state” the engine is in is important. This could be as simple as just setting the state enum to MOVING when throttle is above 0 or the mech's turning and IDLE otherwise, completely neglecting the typical state breakdown of the code. Other systems might care about what the engine is doing, so this could be an easy way to check to see if it's running. Heating and heat sink systems come to mind.

Physics

Tonight, I'm moving onto the basic physics involved in moving around. This is going to be a separate script, and it's going to do raycast checks to see if the mech is grounded or trying to climb a slope too steep, and apply gravity when it's in the air. It'll also (possibly) push the mech away from slopes that are too steep, but I might solve that problem by simply checking the new position and slope steepness before actually moving the mech (which makes more sense than my original plan, now that I think about it).

I should also move the movement of the mech from the Loco script to the physics script. Basically any sort of transforms done on the mech prefab should happen only in the physics script; that way there's no weird interference or overlap from other scripts.

blog/160210_learning-from-implementation.txt · Last modified: 2016/02/10 07:14 by admin