• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

A script functionality question

Jihl

Member
Hey there everyone :)

I hope this is a simple question for you to understand, I will do my best to explain it
First of all, I am dealing with player states, I save all the states in a ds_list so I can have more than 1 state (E.G moving and casting) that would be naturally possible in my game.
I am struggling when I need to delete the states

I am using script_execute(script) to execute in the step event the state of a player
In the step event of obj_player
Initialization of the player:
Code:
// Set initial state
scr_state_add(lf_state.idle)

// Set initial state
state = scr_player_move_state
// PD: Move state does actually support idle = no movement
Step event of the player
Code:
// Execute states
script_execute(state)
scr_player_move_state:
Code:
...
If player starts to walk
// Add walk state
scr_state_add(lf_state.walk)
The thing is that I sometime have to change the state of the player:
scr_player_attack:
Code:
// Add State and set melee attack cooldown
scr_state_add(lf_state.attack)

// Change State
state = scr_player_attack_state
but I need to delete the state of the script that was being executed before, so I can handle the states cohesively.

So, is there any way of doing this?
Code:
// Inside scr_player_move_state
If script was canceled or stopped running
  scr_state_del(lf_state.walk)
Or any way around it that would accomplish the same thing?

EDIT:
Further explanation

For example I would like to save this list for the player in case I need to check if a specific state is active
that would be. If the player gets hit and it is moving (scr_state_check(lf_state.moving)) then apply a hindered_movement debuff
but the player could be moving and also dashing, so I would first check if it is dashing (scr_state_check(lf_state.dash)) so that way the debuff would not apply to him
In this case I need to know about these 2 states. If the player is dashing then it must be moving, but if the player is moving it is not neccesarily dashing

Thank you everyone!
 
Last edited:

YoSniper

Member
It looks to me like it would just be easier to have two separate states: one for movement, and one for attacking/casting. I feel like that would get rid of the convoluted means of storing multiple states in a list and then worrying about which ones to remove later.

That's what I would do, anyway.
 
T

Taddio

Guest
What I do for this is use one instance variable "state", and do in an empty script something like
Code:
#macro RUN 10
#macro IDLE 11
#macro SHOOT 12
#macro DEAD 13

//Use any numbers, but I suggest not 0 or 1, just to be safe
Then you can just use a simple switch(state) statement to define behaviors in the step event
Code:
switch(state){
     case IDLE:
           //define sprite, set speed to 0, etc
               break;

     case SHOOT:
           //define sprite, create obj_spell, do attack stuff...
              break;

     case DEAD:
            //Remove a life, set alarm, whatever you want to do when it dies, etc...
//And so on for each state
It's simple, clean, easily readable and doesn't require adding and removing from list. A player state is probably something you want to keep throughout your game, so it's not something you really would want to destroy anyway.
It's also easy to trigger, for example you can do in a key_press event
state = SHOOT;
and that will trigger what's inside your
Code:
case SHOOT:
        break;
code. For me, it' the best simple/efficient ratio when it comes to player states. I like ds_lists a lot, but not for these things.

EDIT: one thing that could be iseful if you want to stick to ds_ stuff, is "Stack" and "Pop". That's also useful if you want to keep track of the previous state your player was in (sometimes very useful, altough most of the time you won't need that)
 
I

immortalx

Guest
For small games, you could use distinct states for both single and compound behaviors. Like: "idle", "idle_shooting", "running", "running_shooting", "jumping", "jumping_shooting", etc.
These are easy to manage, but you have to take care deciding which states are "allowed" to switch to from the current state, providing escape conditions.
The bad thing about this is that you get some duplicate chunks of code, but as I said for a simple game it shouldn't be much of a problem. I don't know how people manage this problem for complex games.
 
Top