progressively obsolete

Screen Guy Re-Write

The platform character, Screen Guy, was the very first I worked on. I had no idea how Unity worked, no idea what I was doing, and no idea what I wanted.

Fast forward a few months, and while I'm still green, my dev skills have certainly improved. Most importantly, I'm getting familiar with Unity and getting a feel for how to resolve issues. Yes I'm still Googling syntax all the time, but I'm getting better.

The Screen Guy code was in a right state. What started as a Unity store asset with a few hundred lines of code had been bludgeoned to some 2k+ lines of mumbo jumbo. That's a technical term.

And that was just one script.

In total, there are maybe 10k lines of code I'd knocked together without much thought or coherence or foresight or skill.

The character controlled well, but I was at a stage where if I wanted to add something, like a new ability to grab to a rope, I'd not know where to start. So many If statements and caveats and bools being set. And of course there were bugs in there which were getting harder and harder to resolve, as one thing relied on a hundred others and one change here would mess up all the caveats I'd put in place to hard-wire another issue.

I investigated state machines the other month, and started using one for the enemy AI - until I decided to put that on hold as I'm making a platform game, not Metal Gear Solid, and the AI was getting too convoluted. I knew the day would come when I'd have to re-write Screen Guy using a state machine, and I was dreading it.

Well, end of last week I got the balls together to do it. It effectively meant starting from nothing and adding each state - standing still, moving, different jumps, etc. I decided on an approach I'd seen mentioned once but not subsequently; having an individual script for each state.

It's taken me a bit of trial and error, but I've finally got it working Smile Basically, we have only one state / script Enabled at any point in time. I have a rough template for each state script, and then make state / script specific tests to see if the player is doing something different to the current state. If so, the script disables and then we enable the new state. I've a counter in Update to an int in state manager, and I reset that in LateUpdate. So basically, only one state should be on at a time, and I monitor that to ensure that's the case and to stop funky things happening.

I can now add states pretty easily - take the state template, do required checks, chuck it on Screen guy and voila. As long as any other required scripts know what tests are needed to activate it, we're away. There's a bit of leg work adding new tests to older state scripts and any universal flags I like to keep track of (canJump, canMove, canCrouch, etc) but it seems to be going well so far.

As of right now, Screen Guy can do about 85% of the things he could before I started. I've added a few new things (Plummeting, Hard Landing). The only things missing are Wall Grab (which I'll work on tomorrow) and GrabItem and PushItem (which I need to reconsider). And I've been able to resolve the long standing issues I had with special jumps like the Back Flip which just didn't work properly. There's bound to be a few bugs that will come out in playtesting, but so far, so good Biggrin