• 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!

Small inspiration needed

S

Shaddy

Guest
Im coding a state maschine for my enemies and this is the code I set up for the Idle state


counter += 1;
y+=vsp+grv
x+= hsp*walkspd;

//Transition Trigger
if (counter >= room_speed *3)
{
var change =choose (0,1)
switch (change)
{
case 0: state= ENEMYSTATE.IDLE;
case 1: var hspr = choose (0,1)
switch(hspr)
{
case 0: hsp= -1
case 1: hsp= 1
}
}
}

the issue is at the moment it spins around like a beyblade and doesnt set to go to one direction... How could I code this slightly different so that the enemy decides to chose a side, and not beyblade?
 
L

Lonewolff

Guest
Probably handle 'counter' a different way.

As soon as you hit 'room_speed * 3' in the main loop, things will go nuts (which is what you are experiencing).

You need reset counter to zero when the condition is met and increase the trigger time a bit if need be.

Code:
if (counter >= room_speed *3)
{
     counter = 0;
 
S

Shaddy

Guest
Probably handle 'counter' a different way.

As soon as you hit 'room_speed * 3' in the main loop, things will go nuts (which is what you are experiencing).

You need reset counter to zero when the condition is met and increase the trigger time a bit if need be.

Code:
if (counter >= room_speed *3)
{
     counter = 0;
ill be honest with you, I dont know why I didnt do that already... Why is it that ones coding mistake is always the most stupid thing ever? Thank you!
 
L

Lonewolff

Guest
ill be honest with you, I dont know why I didnt do that already... Why is it that ones coding mistake is always the most stupid thing ever? Thank you!
Hehe, don't be so hard on yourself. It happens to all of us (more than we would care to admit) :D
 
S

Shaddy

Guest
Sadly, that was not it, it is still beyblading around... I feel like because this is happening, I need to implement an enemy that beyblades into my game now
 
L

Lonewolff

Guest
Probably need some break's in there too. As each case is likely cascading over the next. Not sure if it is the root cause of your issue (without digging deeper), but will cause a problem nonetheless.
 
S

Shaddy

Guest
Probably need some break's in there too. As each case is likely cascading over the next. Not sure if it is the root cause of your issue (without digging deeper), but will cause a problem nonetheless.
I wonder if there is a more elegant way to code this without using 2 switch cases... I was hesitant to do 2 in the first place...
 
L

Lonewolff

Guest
I wonder if there is a more elegant way to code this without using 2 switch cases... I was hesitant to do 2 in the first place...
Not really a bad way to do it though, especially if you start adding more options.

I've added some "break's" in there. So this should work (in theory). Also added some braces for readability (just my personal preference).

The last break isn't required, but good to keep things consistent to save it biting you later on when you add things.

Oh, and I just added hsp = 0 in the event that the enemy is idle. Otherwise it will keep moving when idle is called.

Code:
if (counter >= room_speed * 3)
{
    switch(choose(0, 1))
    {
        case 0:        // Enemy idle
        {
            state = ENEMYSTATE.IDLE;
            hsp = 0;
        }
        break;
        case 1:        // Enemy moving
        {
            switch(choose(0, 1))
            {
                case 0:        // Move left
                {
                    hsp = -1;
                }
                break;
                case 1:        // Move right
                {
                    hsp = 1;
                }
                break;
            }
        }
        break;
    }
}
 

Joe Ellis

Member
This is how I would do it yo:

x += hsp
y += vsp

(walk speed and gravity should be pre calculated\added to the speeds before this, especially after collisions with everything, and also clamped(max_spd, -max_spd)

THEN:

if ++counter = switch_time
{
if irandom(1)
{state = ENEMYSTATE.IDLE}
else
{hsp = -1 + (irandom(1) * 2)}
}
 
S

Shaddy

Guest
This is how I would do it yo:

x += hsp
y += vsp

(walk speed and gravity should be pre calculated\added to the speeds before this, especially after collisions with everything, and also clamped(max_spd, -max_spd)

THEN:

if ++counter = switch_time
{
if irandom(1)
{state = ENEMYSTATE.IDLE}
else
{hsp = -1 + (irandom(1) * 2)}
}

im a new to programming, could you explain to me your logic? and hsp and vsp are set in the step event, this here is a script I am calling
 
S

Shaddy

Guest
Not really a bad way to do it though, especially if you start adding more options.

I've added some "break's" in there. So this should work (in theory). Also added some braces for readability (just my personal preference).

The last break isn't required, but good to keep things consistent to save it biting you later on when you add things.

Oh, and I just added hsp = 0 in the event that the enemy is idle. Otherwise it will keep moving when idle is called.

Code:
if (counter >= room_speed * 3)
{
    switch(choose(0, 1))
    {
        case 0:        // Enemy idle
        {
            state = ENEMYSTATE.IDLE;
            hsp = 0;
        }
        break;
        case 1:        // Enemy moving
        {
            switch(choose(0, 1))
            {
                case 0:        // Move left
                {
                    hsp = -1;
                }
                break;
                case 1:        // Move right
                {
                    hsp = 1;
                }
                break;
            }
        }
        break;
    }
}
I tried that out, it span around like a beyblade and then the sprite disappeared...
 
A

ArchbishopDave

Guest
If you're still seeing issues with the above set of code that you used, I'm not convinced from what's in there that the actual problem is with the script itself.

Sounds like your step event is simply checking the state, then calling the appropriate state script (the code block you've shown) right?
The latest blocks, with the breaks, while a little verbose for what you're doing should work.
 
S

Shaddy

Guest
If you're still seeing issues with the above set of code that you used, I'm not convinced from what's in there that the actual problem is with the script itself.

Sounds like your step event is simply checking the state, then calling the appropriate state script (the code block you've shown) right?
The latest blocks, with the breaks, while a little verbose for what you're doing should work.
that is correct, my step event just keeps checking which state everything is


switch (state)
{
case ENEMYSTATE.IDLE: EnemyIdle(); break;
case ENEMYSTATE.WANDER: EnemyWander(); break;
case ENEMYSTATE.ALERT: EnemyAlert(); break;
case ENEMYSTATE.SHOOTING: EnemyShooting(); break;
}

there is more to my event later, but thats related to the Alert event and its in the outside of this if statement...

the code from lonewolf... just makes it spin as well and then the sprite goes missing after a while...
 
Last edited by a moderator:

Joe Ellis

Member
im a new to programming, could you explain to me your logic? and hsp and vsp are set in the step event, this here is a script I am calling
Sorry for the late reply,
I did several things that are classed as coding tricks,

The main one was ++counter,
"++" adds one to the variable next to it, so I saw that you're only adding one to it at the start, then the first question asks if it = a value, so you can condense it into the first if, it is actually pretty good once you get used to it, especially with state scripts.

and then after, all I did was not use a switch statement, because only 2 outcomes were possible anyway (for each if), so it was simpler to just use 1 if for the counter time = switch time, then another if and else inside that

The Choose(0,1) is the same as irandom(1), cus irandom picks a whole number between 0 and the number you put in the brackets, however I prefer to use this to choose cus choose normally has alot higher chance of giving the same value twice in a row, it might be for a reason, but irandom is normally more random.

The part at the start when I said walk speed and gravity should be pre calced first was mainly due to collisions, but that mainly applies to platformer and games where the player bumps into walls and the ground so it might not be that important here.
 
S

Shaddy

Guest
Sorry for the late reply,
I did several things that are classed as coding tricks,

The main one was ++counter,
"++" adds one to the variable next to it, so I saw that you're only adding one to it at the start, then the first question asks if it = a value, so you can condense it into the first if, it is actually pretty good once you get used to it, especially with state scripts.

and then after, all I did was not use a switch statement, because only 2 outcomes were possible anyway (for each if), so it was simpler to just use 1 if for the counter time = switch time, then another if and else inside that

The Choose(0,1) is the same as irandom(1), cus irandom picks a whole number between 0 and the number you put in the brackets, however I prefer to use this to choose cus choose normally has alot higher chance of giving the same value twice in a row, it might be for a reason, but irandom is normally more random.

The part at the start when I said walk speed and gravity should be pre calced first was mainly due to collisions, but that mainly applies to platformer and games where the player bumps into walls and the ground so it might not be that important here.
I actually did realize that choose seemed to pick the same value over and over again when I was testing the script, since I had to wait like 10 sec or so for it to switch stance (so three rotation)... maybe it has to do with the fact that I didnt randomize the game, so it kept choosing the same choose...
the colision is handled in the step event and should have prio over my scripts, otherwise imma have to do wall collision for all my scripts... Ill try your code out and see if it works... hopefully it does

I kinda dont want to clamp my spd because I want my game to be speedrun, and if the players find some janky way of gaining insane speed, so be it... I should do it to the enemies though
 
Last edited by a moderator:
S

Shaddy

Guest
I figured out the beyblading... it was my wall collision which was making issues... I really should have checked that earlier...
 
Top