Down/Updates

progress report

I’m on a new, somewhat dictatorial work regimen as of this week. I may explain the details someday, when we know each other a little better.

Meantime, I’ve been plugging away at this states system.

I may have mentioned the states system before, and you may wonder why the hell it isn’t done yet.

The prototype that I shared as part of my 8bit Funding video was a shoddy way of doing things, obviously new coder stuff. I didn’t really have a problem with the code being fuck-ugly so long as it works (a state I termed “fugtionality” a year or two ago), but in the end it was just infeasible.

But it got complicated very quickly. In the original template, a block of code for a single control, moving right with the D key, looked like this:

if keyboard_check(ord(‘D’))
if place_free(self.x+moveDist, self.y)
if active == true
if jumping == false
{
faceLeft = false;
faceRight = false;
moveRight = true;
}

(forgive inaccurate whitespacing, WordPress seems to be ignoring tabs and spaces)

So: if you press the D key, each character would first check if the position you were going to move to was free. It would then check if that character was even active (only one of the four characters could be active at a time). Then it would check to be sure that character was not in the middle of a jump. If it passed all of these checks, it would turn off the variables for standing and facing left and standing and facing right and turn on the variable for moving to the right.

This doesn’t even cover everything. Each of those variables had to be defined in the Step Event as well. Variables like faceLeft and faceRight were mostly just defined as setting your character’s sprite. moveRight told the character to move along the x-axis a certain number of pixels each step (determined by yet another variable, moveDist) and also set the sprite and animation speed.

It is cumbersome enough to have to do 3 checks every time you push a button, and to turn off every other variable to make sure there aren’t any conflicts. But I realized quickly that this was only going to get worse.

Say there’s a crank that one of the characters is going to operate. The obvious way to interact with it would be to just grab it (probably a mouse click) and then hold the right button (D) to crank it one way, the left button (A) to crank it the other. And the character should animate cranking right or left.

Hoo boy. So there’s another variable, “crank,” and when you press A or D it needs to do a check for whether you are currently cranking, and no matter what you do make sure that you’re not running the cranking animation. And this would have to happen every single time a character’s sprite is reassigned or the buttons map to slightly different controls.

Before long there would be dozens if not hundreds of variable checks before a character could do anything at all. A horrible chore to write and agony to debug.

states

So that’s when I came up with the states system.

I needed a way for the character’s state to be monitored at all times and make sure no more than one state could be active at a time. So if you’re moving right, the appropriate animation and speed would be assigned to you and I didn’t have to check and make sure all the other states were off. There’d be only a single variable, “state,” and it could only be assigned to one at a time.

Josh introduced me to the concept of the switch-statement, and from there I got going.

Pretty soon, pressing D looked like this:

if keyboard_check_pressed(ord(‘D’))
{
switch (state)
{
case JUMPUPL:
case JUMPUPR:
case DROPDOWNL:
case DROPDOWNR:
case JUMPR:
case JUMPL:
case DROPR:
case DROPL:
case RJUMPR:
case RJUMPL:
break;
case STANDR:
case STANDL:
case WALKR:
if keyboard_check(vk_shift)
{
state = RUNR;
}
else
{
state = WALKR;
}
break;
case WALKL:
if keyboard_check(vk_shift)
{
state = RUNR;
}
else
{
state = STANDL;
}
break;
}
}

(that whitespacing is gonna kill me)

A lot o’ work, eh? This was basically constructing a labyrinth. Each state could only move towards certain other states – from standing, you could move to walking or running, but you couldn’t move directly to dropping, for that you had to already be jumping. It was like Choose Your Own Adventure, fitting, really, since it was in service of an adventure game. You could only get to a certain result by following certain paths.

Because of that maze-like structure, I couldn’t test this until everything was in place. You can’t run a maze if chunks of it are missing, see? It’d mean getting to states that there was no way out of.

But when I finally sat down and tested it, it didn’t work. To this day I’m not sure why.

After pounding my head against it a while, I decided to strip the system down to very simple controls and then start putting the states system into place, bit by bit, and see if I could avoid making it bug out, or at least see what feature broke the system.

But in one of the first builds, it was already broken. People have spoken ill of the GML switch-statement, and I’m starting to wonder if it’s just not a good thing to be using.

So I’ve been rebuilding it up from the bottom yet again, this time building in even smaller units, and the entire state system has been reconceived.

For the most part now, the states are reacting to the character’s movements, not causing them. Making a maze is too inflexible, and mazes tend to have dead ends (I could try to explain how that allegory works, but I don’t really feel like it). As of now, if a character is in the air, gravity is on, no matter the state. Your states variable is check what is happening – if your character is in the air and moving up, then they’re jumping (state = JUMP), and if they’re moving down, then they’re falling (state = DROP). I can put in checks as to what the state is, but setting the state will, generally, be reactive to your movements. Mostly states manage animations, which is a good place to be using the switch-statement.

So far it’s working! That crank state, mind, would be something else entirely. The plan is to have a regular “state” for all normal controls, which can also be set to 0. If the state is set to 0, the game will check what the special_state variable is, and there can be all kinds of unique animations and code there. There will also be idle states when a character that isn’t being controlled busies themselves with random activities, like watering plants or playing a guitar.

a few other bits

Since the states system isn’t a labyrinth anymore, I’ve had to come up with some ways of simplifying the code instead of using a thousand variables and if-statements. Here are a few tricks:

Movement is controlled with a few variables. First there’s lspd and rspd, handling how much you’re moving to the left or right. Normally they’re 0, but pressing D will set rspd to 2 and pressing A will set lspd to -2. There’s also speed_up, which handles running – normally it’s set to 1, but when you hold down Shift it’s set to 1.5 (values to be fiddled with later). Every step, lspd and rspd are added together, and the total is multiplied by speed_up. If you’re pressing no directional keys, or both directional keys, it’ll all come out to 0. Otherwise, it’ll be some positive or negative amount. Every step, this amount is added to your x value. So you move forward by 0, a positive amount, or a negative amount.

Also, I learned that I can save an object ID as a variable (an object’s name is just a title designed to make the coder’s life easier; each object is actually identified by the code as a string of numbers). So instead of having an “active” variable and checking it every step, I can simply have the current character saved in a global variable called activeChar. So moving left two pixels can be assigned thus: activeChar.x -= 2;

summation

That’s everything. A bit code-heavy an inaccessible this time, I know. I’ve been pounding my head against this code for weeks, and it’s finally giving. It’s quite encouraging.

Josh and I will probably be adjusting our workflow soon, share more on that when and if it happens. Could change things for the better.

You should also read this: How To Steal Like An Artist (and 9 Other Things Nobody Told Me). Extremely useful and inspirational. Creative people usually advise you to just sit down and get something made, but I think most of them know that making the decision to sit down and make something is the hardest part of the creative process. At least someone is willing to admit that and give practical tips on how you get shit made.

Catch ya later.

Advertisements

0 Responses to “Down/Updates”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: