Issues with platformer game regarding jumping and delayings.

M

muxebv

Guest
Hello Everyone, First of all thank you for your time to read this topic.

So the issue that we are facing is as follow we have made a platformer setup however there are still 2 bugs that we havent been able to solve.

Issue one is that when you stand directly at the walls and click the jump button once or twice (W) it will dissapear within the wall and after that you can still move around in the game but the character will be gone.

http://muxehub.com/games/Digizones/ On this link you will be able to test the first level of the game to notice the bug I mentioned above. (walking with WASD and Running or shooting with Spacebar).

Issue 2 is that we are loading enemies in the game at a variety of different places. In the room editor we have placed them at their location (however a few of them automatically disappear) others will be there until falling off a wall (leaving them in a small corner). What doesnt make sence is that not all of them are there ( even its the same object).

Some of the codes for subjects:

Issue on jumping:

Code 1 is the create event of the player:

Code:
/// @description Settings

//No animation right now
image_speed = 0;

//This is the current state of the player
int_state = en_states.idle;

//The form of the character (0 for small mario, 1 for big mario, 2 for fire flower mario)
int_form = 0;

//This is how quickly we move horizontally
int_xSpeed = 0;

//This is the gravity aspect of mario
int_gravity = 1;

//For how many frames have we held the jump (w) key?
int_yHeld = 0;

//We use this growState to dictate of how the growth of mario happens (see alarm[0])
int_powerUpOrDownState = 0;

//When I am invincible, when this number is 0 I am visible, when 1 I am invisible. It flips back and forth until I am vulnerable again
int_invisibilityNum = 0;

//When I touch an enemy, briefly allow the player to be invincible to get away
b_invincible = false;

//Array to assign the sprites of mario [form, state]
spr_marioSprite[0, 0] = spr_marioIdleSm;
spr_marioSprite[0, 1] = spr_marioRunSm;
spr_marioSprite[0, 2] = spr_marioJumpSm;
spr_marioSprite[0, 3] = spr_marioSkidSm;

spr_marioSprite[1, 0] = spr_marioIdleLg;
spr_marioSprite[1, 1] = spr_marioRunLg;
spr_marioSprite[1, 2] = spr_marioJumpLg;
spr_marioSprite[1, 3] = spr_marioSkidLg;
spr_marioSprite[1, 4] = spr_marioDuckLg;

spr_marioSprite[2, 0] = spr_marioIdleFLg;
spr_marioSprite[2, 1] = spr_marioRunFLg;
spr_marioSprite[2, 2] = spr_marioJumpFLg;
spr_marioSprite[2, 3] = spr_marioSkidFLg;
spr_marioSprite[2, 4] = spr_marioDuckFLg;
Code 2 is the step event of the player:
Code:
/// @description Meat and potatoes

/*
We control our character thru what is called an FSM, or a "finite-state-machine".
It works by analyzing the current state of the character and allowing certain actions to happen
based on the actual state the character it is within
*/

var a, b, c, d, e;

//Get keyboard inputs
a = keyboard_check(ord("D")) - keyboard_check(ord("A"));//Which direction am I trying to go? -1 left or 1 right
b = keyboard_check(vk_space);//Am I trying to run? 0 false 1 true
c = keyboard_check(ord("W"));//Am I trying to jump? 0 false 1 true
d = keyboard_check(ord("S"));//Am I trying to duck? 0 false 1 true
e = keyboard_check_pressed(vk_space);//Did I press the space key this frame? 0 false 1 true (This is for shooting fireballs in form 2)

//Activate all objects within this region (We keep them in suspension until they are within range)
instance_activate_region(__view_get( e__VW.XView, 0 ), 0, __view_get( e__VW.XView, 0 ) + __view_get( e__VW.WView, 0 ), room_height, true);

//Flip the sprite based on the character input (make sure it 'a' is NOT 0 - otherwise he will be flat and invisible).
if (a <> 0){
    if (int_state <> en_states.jump && int_state <> en_states.fall && int_state <> en_states.death){//Do not allow the player to flip image_xscale if they are jumping or falling
        image_xscale = a;
    }
    if (int_state <> en_states.duck && int_state <> en_states.powerupOrDown && int_state <> en_states.death){//Do not mess with int_xSpeed if I am ducking or powering up or dead
        int_xSpeed += a;//Increase xSpeed by a (-1 or 1 until it reaches either -5 / 5, or -7 / 7 if we are sprinting)
    }else{
        int_xSpeed += -sign(int_xSpeed);
    }
}else{
    int_xSpeed += -sign(int_xSpeed);//Return x speed to 0
}

//Increase x by int_Xspeed, increase this further if we are running (If b is true - remember it is either a 0 or 1)
if (place_meeting(x + int_xSpeed + b * sign(int_xSpeed), y, par_brick)){
    while(!place_meeting(x + sign(int_xSpeed), y, par_brick)){
        x += sign(int_xSpeed);
    }
    int_xSpeed = a;
}else{
    x += int_xSpeed + b * sign(int_xSpeed);
}

//Do not allow xSpeed to go higher or lower than -5 or 5 or -7 / 7 if the player is running (shift)
int_xSpeed = clamp(int_xSpeed, -4 + b * -3, 4 + b * 3);

//Shooting a fireball, but only in form 2 and only while I am not ducking
if (int_form == 2 && e && int_state <> en_states.duck){
    instance_create(x + image_xscale * 7, y - 48, obj_fireballExpl);
    with(instance_create(x, y - 48, obj_fireball)){
        int_dir = other.image_xscale;
    }
}

//Analyze the state of the player and adjust his mechanics
switch(int_state){
    //Idle
    case en_states.idle:
    if (c){
        int_gravity = 0;
        int_state = en_states.jump;
    }else{
        if (d && int_form > 0){
            int_state = en_states.duck;
        }else{
            var t = instance_place(x, y, par_enemy);
            if (t > -4 && !b_invincible){
                switch(t.object_index){
                    default:
                    if (int_form > 0){
                        alarm[1 + int_form] = 1;
                        int_state = en_states.powerupOrDown;
                    }else{
                        int_gravity = 0;
                        int_state = en_states.death;
                    }
                    break;
                    case obj_koopa:
                    if (t.int_state <> 2){
                        if (int_form > 0){
                            alarm[1 + int_form] = 1;
                            int_state = en_states.powerupOrDown;
                        }else{
                            int_gravity = 0;
                            int_state = en_states.death;
                        }
                    }else{
                        t.int_state = 3;
                        t.int_dir = image_xscale;
                    }
                    break;
                } 
            }else{ 
                if (place_meeting(x, y + 1, par_brick)){
                    if (a <> 0){
                        int_state = en_states.run;
                    }else{
                        sprite_index = spr_marioSprite[int_form, 0];
                        image_speed = 0;
                    }
                }else{
                    int_gravity = 0;
                    int_state = en_states.fall;
                }
            }
        }
    }
    break;
    //Run
    case en_states.run:
    if (c){
        int_gravity = 0;
        int_state = en_states.jump;
    }else{
        if (d && int_form > 0){
            int_state = en_states.duck;
        }else{
            var t = instance_place(x, y, par_enemy);
            if (t > -4 && !b_invincible){
                switch(t.object_index){
                    default:
                    if (int_form > 0){
                        alarm[1 + int_form] = 1;
                        int_state = en_states.powerupOrDown;
                    }else{
                        int_gravity = 0;
                        int_state = en_states.death;
                    }
                    break;
                    case obj_koopa:
                    if (t.int_state <> 2){
                        if (int_form > 0){
                            alarm[1 + int_form] = 1;
                            int_state = en_states.powerupOrDown;
                        }else{
                            int_gravity = 0;
                            int_state = en_states.death;
                        }
                    }else{
                        t.int_state = 3;
                        t.int_dir = image_xscale;
                        with(t){
                            while(place_meeting(x, y, obj_mario)){
                                x += other.image_xscale;
                            }
                        }
                    }
                    break;
                } 
            }else{
                if (place_meeting(x, y + 1, par_brick)){
                    if (a <> 0){
                        if (sign(int_xSpeed) == a){
                            sprite_index = spr_marioSprite[int_form, 1];
                            image_speed = .5 + b / 3;
                        }else{
                            sprite_index = spr_marioSprite[int_form, 3];
                            image_speed = 0;
                        }
                    }else{
                        int_state = en_states.idle;
                    }
                }else{
                    int_gravity = 0;
                    int_state = en_states.fall;
                }
            }
        }
    }
    break;
    //Fall
    case en_states.fall:
    if (place_meeting(x, y + 1, par_brick)){
        if (a <> 0){
            int_state = en_states.run;
        }else{
            int_state = en_states.idle;
        }
    }else{
        if (d && int_form > 0){
            sprite_index = spr_marioSprite[int_form, 4];
        }else{
            sprite_index = spr_marioSprite[int_form, 2];
        }
        image_speed = 0;
        y += int_gravity;
        if (int_gravity < 18){
            int_gravity += 1.5;
        }
        var t = instance_place(x, y, par_enemy);
        if (t > -4){
            with(t){
                event_user(0);
            }
            y = floor(y);
            int_gravity = 6;
            int_state = en_states.jump;
        }else{
            if (place_meeting(x, y, par_brick)){
                y = floor(y);
                while(place_meeting(x, y, par_brick)){
                    y --;
                }
                int_gravity = 0;
            }
        }
    }   
    break;
    //Jump
    case en_states.jump:
    if (d && int_form > 0){
        sprite_index = spr_marioSprite[int_form, 4];
    }else{
        sprite_index = spr_marioSprite[int_form, 2];
    }
    image_speed = 0;
    y += -18 + int_gravity;
    if (int_gravity < 18){
        if (c){
            int_gravity ++;
        }else{
            int_gravity += 2;
        }
    }else{
        int_gravity = 0;
        int_state = en_states.fall;
    }
    t = instance_position(x, y - sprite_height, par_brick);
    if (t == -4){
        t = instance_place(x, y, par_brick);
    }
    if (t > -4){
        y = ceil(y);
        if (t.object_index == obj_brickBreak){
            with(t){
                event_user(other.int_form);
            }
        }else{
            with(t){
                event_user(0);
            }
        }
        while(place_meeting(x, y, par_brick)){
            y ++;
        }
        int_gravity = 0;
        int_state = en_states.fall;
    }   
    break;
    //Duck (only if I am large tho)
    case en_states.duck:
    if (place_meeting(x, y + 1, par_brick)){
        if (d){
            sprite_index = spr_marioSprite[int_form, 4];
            image_speed = 0;
        }else{
            if (a <> 0){
                int_state = en_states.run;
            }else{
                int_state = en_states.idle;
            }
        }
    }else{
        int_state = en_states.fall;
    }
    break;
    //Power up
    case en_states.powerupOrDown:
    image_speed = 0;
    //Basically do nothing and freeze myself. We will will halt everything until the powerup is complete (take a look at alarms 0 - 3)
    break;
    //Death
    case en_states.death:
    sprite_index = spr_marioDead;
    int_xSpeed = 0;
    y += -18 + int_gravity;
    if (int_gravity < 36){
        int_gravity ++;
    }
    if (y > room_height + 100){
        room_restart();
    }
    /// @description  Try to consume life and go to

    break;
}



/* */
/*  */

Our own assumption is that it gets stuck under the wall of certain objects who are not squared). I think after multi clicking jump that it forces the player to vanish as it gets stuck in the game.

Perhaps anyone knows a good way to solve it. I have tried instance destroy, bounces or bump false for this issue but none are responding to it.


As for issue 2 the enemy it doesnt make sence at all as theres another enemy (which we currently havent placed in the level). Even though the settings are completely the same that other enemy is not having the same bug.




And when game loaded starts like this

http://muxehub.com/games/Digizones/bug2.png
 
M

muxebv

Guest
Do your sprites have the same size hitbox and is the origin for each Sprite the same position relative to the hitbox?
Hello Thank you for responding TheouAegis,

I assume you mean the entire frame of the sprite itself right? Its a bit confusing but for the small char its 98 x 98 pixels and for the bigger sprites its 115 x 115 pixels. I believe they are all relative to the other as they were imported perfectly adjusted one to another except for maybe the jumping sprite itself. Every sprite position has been set to centered middle so should be the same as well.
 

Relic

Member
Echoing TheouAegis, check not just the size of the sprite but the collision mask of all the sprites. For example, if the idle/stationary sprite has a collision mask 50x50, centred about the middle of the 98x98 sprite and the walking sprite has a collision mask 55x55, you will have issues where an instance can go from “next to a wall” to “inside the wall” when the sprite assigned to the instance changes.

For many games it is safer to set a collision mask independent of the sprite assigned to an instance. This can be done in the object’s window below where you assign a sprite in the IDE.
 
M

muxebv

Guest
update: I just caugth the same object (Floor with leaves on top that are hanging over the edge). When the enemy touches this particular part of the object it vanishes as well which is the same object causing the player to vanish after a period of time.
 
M

muxebv

Guest
Echoing TheouAegis, check not just the size of the sprite but the collision mask of all the sprites. For example, if the idle/stationary sprite has a collision mask 50x50, centred about the middle of the 98x98 sprite and the walking sprite has a collision mask 55x55, you will have issues where an instance can go from “next to a wall” to “inside the wall” when the sprite assigned to the instance changes.

For many games it is safer to set a collision mask independent of the sprite assigned to an instance. This can be done in the object’s window below where you assign a sprite in the IDE.

Hello Relic, First of all thank you so much for your response that means a lot to us.

Basically all sprites from the characters have the same collission settings and pixel details in the frames. I dont believe its relative to this after figuring the monster sprites who exist out of 2 sprites only have some very odd vanish issue in level 2. I will update the game on the web server now so if you manage to get to level 2 you would be able to see what I refer to.
 
M

muxebv

Guest
Game is now updated so if you check the link again you should see the latest version.
 
M

muxebv

Guest
Update: We just found that some bricks and trees were still set at Custom instead of Middle Center we updated this and after that had to repair all tiles since they moved to another position as logical was expected.

Anyway, unfortunately, it also didn't solve the issue and the player and monsters can still disappear in these objects.
 

Relic

Member
Are the player and monsters inside the platforms or have they dramatically shifted their y positions so they may be outside of the room/view?
 

Relic

Member
Just managed to get to a pc and played your game. When I walk into the tree on the ground then turn around I get stuck - nothing to do with jumping at all. This still really seems like a collision mask mismatch issue. Even if you think you have it right in each sprite, being off by 1 pixel is enough to ruin your day. Even swapping image_xscale from 1 to -1 can hurt if you don't have a well sized sprite with origin in the middle.


Try using a mask as I suggested rather than relying on "lining up sprites".
 

TheouAegis

Member
the small char its 98 x 98 pixels and for the bigger sprites its 115 x 115 pixels.
For example, if the idle/stationary sprite has a collision mask 50x50, centred about the middle of the 98x98 sprite and the walking sprite has a collision mask 55x55
Also important is if the origin is centered around the bounding box (not centered to the sprite) so you can flip sprites easily, the sprite's width MUST be an even number. A 98 width sprite with full bounding box can be mirrored properly. If it's 115 wide with full bounding box, it cannot be mirrored evenly. A sprite's bounding box must be "odd width". So a sprite with bbox left at 4 and bbox right at 63 has an odd bounding box (even though technically it's even... LOL) and can be mirrored properly, but if bbox right was 64, that's an even bounding box and won't be mirrored properly.

So putting it all together... If you were moving right or facing right and hugging a wall... If the right edge of your bounding box is 6 away from the origin on the right side but 8 pixels away from the origin on the right side in another sprite and you change to that sprite, you are now inside a collision. If the first sprite had a bbox left of 0 and a bbox right of 24 with the origin centered, if you set image_xscale to -1, you would actually shift the bounding box into the wall and be stuck in a collision.

If you are still confused, you can postthe Sprite information for each of the involved sprites. You can also post how you handle collisions, which might give insight into where the player is actually disappearing to.
 
B

blandanablandana

Guest
try removing
+ b * sign(int_xSpeed) from your collision x part. That's my only guess, I'm still a beginner but you might not need that part.

I'm not sure you need to keep it in collisions since you already say
x += int_xSpeed + b * sign(int_xSpeed); right afterwards

It might be a combination of collisions and also just sprite having boxes that are too big or something I have no idea. Most people here know more about the program than I do right now. I just started using it about one and a half weeks ago.
If you want you can draw a bounding box it will show you where you collision mask actually is by typing this at the bottom of your players (or other sprite's) step event.
Code:
draw_rectangle_color(bbox_left,bbox_top, bbox_right, bbox_bottom, c_yellow,c_yellow,c_yellow,c_yellow, true)
that's probably where I would start looking first to try and see what is actually off.
 
Last edited by a moderator:
B

blandanablandana

Guest
Also important is if the origin is centered around the bounding box (not centered to the sprite) so you can flip sprites easily, the sprite's width MUST be an even number. A 98 width sprite with full bounding box can be mirrored properly. If it's 115 wide with full bounding box, it cannot be mirrored evenly. A sprite's bounding box must be "odd width". So a sprite with bbox left at 4 and bbox right at 63 has an odd bounding box (even though technically it's even... LOL) and can be mirrored properly, but if bbox right was 64, that's an even bounding box and won't be mirrored properly.

So putting it all together... If you were moving right or facing right and hugging a wall... If the right edge of your bounding box is 6 away from the origin on the right side but 8 pixels away from the origin on the right side in another sprite and you change to that sprite, you are now inside a collision. If the first sprite had a bbox left of 0 and a bbox right of 24 with the origin centered, if you set image_xscale to -1, you would actually shift the bounding box into the wall and be stuck in a collision.

If you are still confused, you can postthe Sprite information for each of the involved sprites. You can also post how you handle collisions, which might give insight into where the player is actually disappearing to.
It sounds like TheouAegis understands your problem better than I do. See if you can use that information to ...fix it lol.
 
M

muxebv

Guest
H
try removing
+ b * sign(int_xSpeed) from your collision x part. That's my only guess, I'm still a beginner but you might not need that part.

I'm not sure you need to keep it in collisions since you already say
x += int_xSpeed + b * sign(int_xSpeed); right afterwards

It might be a combination of collisions and also just sprite having boxes that are too big or something I have no idea. Most people here know more about the program than I do right now. I just started using it about one and a half weeks ago.
If you want you can draw a bounding box it will show you where you collision mask actually is by typing this at the bottom of your players (or other sprite's) step event.
Code:
draw_rectangle_color(bbox_left,bbox_top, bbox_right, bbox_bottom, c_yellow,c_yellow,c_yellow,c_yellow, true)
that's probably where I would start looking first to try and see what is actually off.
Hello Blandanablandana first of all thank you for commenting. Glad to hear that you are new to the community and tool and already picking things up so well. We tried implementing the code you suggested in the step event of the player object however we noticed no difference.

As far of the collision mask we have set it at precisely for every object.
 

Relic

Member
Being precise can cause this issue too. If the character has 20 pixels in front of the origin and 21 behind, flipping along the x axis will cause you to be stuck in walls. It’s also the reason why the character runs into the tree but moves in slowly every couple of sprite frames- your collision mask is getting smaller for some sprites.

Precise collision masks is useful for some circumstances but not for a platformer where player and enemy sprites changes shape.
 
M

muxebv

Guest
Turn off precision. See if things work better. Do you even need it?
Hello TheOuAegis, The reason why we use it is that for example the player object and other objects like trees are not square. We wouldn't know how to probably mask the collision otherwise.
 
M

muxebv

Guest
Being precise can cause this issue too. If the character has 20 pixels in front of the origin and 21 behind, flipping along the x axis will cause you to be stuck in walls. It’s also the reason why the character runs into the tree but moves in slowly every couple of sprite frames- your collision mask is getting smaller for some sprites.

Precise collision masks is useful for some circumstances but not for a platformer where player and enemy sprites changes shape.
I also just figured in level 2 when getting stuck in a wall (At a higher position it kicks the player down over 10 blocks of 128 pixelx) so in other words, it's not deleting the char but it's removing it far below the screen). So atleast we have establishes that knowledge.
 

Relic

Member
It's probably this line

while(place_meeting(x, y, par_brick)){
y ++;
}

I'm guessing when you transition from a run or idle animation to the jump animation your collision mask is now inside the wall (is the player sprite a bit wider while jumping? Ignore transparent pixels as I'm suggesting the collision mask gets into the wall) and so this triggers - pushing the player down does not get it out of the wall so the player keeps going until it is below every platform, below the view even.

There is a reason why, even to this day, most platformers use block shapes - at least for the platforms. Doing collisions for weird shapes is harder. You would still have more luck having a separate collision mask (3rd time I'm saying this I know, but it IS THE SOLUTION) while still having precise collisions on. This will give you a stable collision mask for the player while still having whatever shape you want for the tree.
 

TheouAegis

Member
Hello TheOuAegis, The reason why we use it is that for example the player object and other objects like trees are not square. We wouldn't know how to probably mask the collision otherwise.
You would mask it logically. Precise collisions are kinda slow, anyway. But the way to think of a collision mask is just look at yourself. If a zombie is running toward you and you shoot it in the arm, is that going to stop the zombie? What if you graze its cheek, would that stop it? What if you shoot it in the foot? Your bullets would have the most impact if you shoot it in the torso (to slow it down) or square on in the head. Hit boxes work the same way. You don't need to include the hands and arms. In some cases, you don't even need to include the head.

People riffed on old video games for how hard or frustrating they were, but a lot of games were actually quite forgiving to the player and people just didn't realize it. Incorporating the entire sprite into hit detection can be detrimental to the gameplay. A lot of games are criticized for enemies being able to kill players without ever even touching the player, or for giving the enemy a huge melee attack range while the player has to practically be standing right on top of the enemy. Each of these issues are caused by the player's collision mask being needlessly inclusive. A typical platformer collision mask covers the torso-proper (not necessarily the arms) and spans from the soles of the feet up to the shoulders (not the head, unless the sprite has a huge, blocky head). If the sprite is shaped oddly enough, you use multiple masks. Or you just don't even use masks at all and use fuzzy logic.

But yeah, precise collisions are usually wasteful on a platformer. Are your sprites normal 2D sprites, or are you guys using skeletal sprites? Working with skeletal sprites usually requires special treatment of collision masks, but then again you would still be able to speed up the game by not using overly inclusive collision masks.
 
M

muxebv

Guest
It's probably this line

while(place_meeting(x, y, par_brick)){
y ++;
}

I'm guessing when you transition from a run or idle animation to the jump animation your collision mask is now inside the wall (is the player sprite a bit wider while jumping? Ignore transparent pixels as I'm suggesting the collision mask gets into the wall) and so this triggers - pushing the player down does not get it out of the wall so the player keeps going until it is below every platform, below the view even.

There is a reason why, even to this day, most platformers use block shapes - at least for the platforms. Doing collisions for weird shapes is harder. You would still have more luck having a separate collision mask (3rd time I'm saying this I know, but it IS THE SOLUTION) while still having precise collisions on. This will give you a stable collision mask for the player while still having whatever shape you want for the tree.
Hello Relic, Interesting Wisdom thank you for sharing. Do you suggest taking that line out to be the solution?
I understand your explanation of the collission. We will follow up on your advice and I believe the answer has just became clear to me I will update this thread asap!
 
M

muxebv

Guest
Update: So what I have changed is all the precise collisions to either rectangle automatic or manual depending on requirement. I found a solution between the answer of Relic and TheouAegis regarding the physics or in this case hit detection to make a lot of sense.

Its now much harder to get into the glitch but sometimes its still possible. I will see what I can do with the collision of the player object as that one is still confusing at the moment. After a few more tests and attempts I will reupdate the URL.

Edit: When changing collision of object player from precise to either manual retangle to replace the inside of the body or elipse both make the player stop allowing to move as it gets stuck in the ground
 
Last edited by a moderator:
M

muxebv

Guest
Update: So what I have changed is all the precise collisions to either rectangle automatic or manual depending on requirement. I found a solution between the answer of Relic and TheouAegis regarding the physics or in this case hit detection to make a lot of sense.

Its now much harder to get into the glitch but sometimes its still possible. I will see what I can do with the collision of the player object as that one is still confusing at the moment. After a few more tests and attempts I will reupdate the URL.
 

Relic

Member
Are you still using different collision masks for each sprite of the player?

Please do what was shown in the video I posted- use a unique sprite for the collision mask that will never change, even going from idle to run to jump sprites.
 
M

muxebv

Guest
Hello @Relic I have tested your idea of deleting while(place_meeting(x, y, par_brick)){
y ++;
} by adding a // infront of the Y....; however whether I do this at the plus plus or minus minus scenario of the place meeting pac brick var it then crashes the entire game (Closing screen even needs to be done by reopening the game again in gamemaker studio 2 so I added them back. I do think however that its close because whatever is preventing the game from crashing might cause the object of the player to glitch jump
 

Relic

Member
I doubt deleting that line is the solution- it will be playing a role in keeping the player from passing into platforms elsewhere.

Edit: and of course your game crashes- you caused it to be in an infinite loop:

While collision{
//do nothing because code is commented out
}

There is no way for the code to “move on” if there is a collision happening.
 
M

muxebv

Guest
Update: we just reupdated the url but now the html5 output is all of a sudden not properly displaying the game and graphics anymore for both the live link as the localhost link http://muxehub.com/games/Digizones/ and also in the game maker studio html 5 tester. This wasnt the case before so its a bit confusnig.
 
M

muxebv

Guest
I doubt deleting that line is the solution- it will be playing a role in keeping the player from passing into platforms elsewhere.

Edit: and of course your game crashes- you caused it to be in an infinite loop:

While collision{
//do nothing because code is commented out
}

There is no way for the code to “move on” if there is a collision happening.
It indeed was not the solution however things are much better beside a few small things remaining a lot less buggy anyway. However please see my comment above there is some odd displaying issue in the html output.
 

Relic

Member
Does it work on windows target platform? Can’t help much with that issue- it’s as if all your sprite assets got jumbled up :-s
 
M

muxebv

Guest
Does it work on windows target platform? Can’t help much with that issue- it’s as if all your sprite assets got jumbled up :-s
Yes it works perfectly fine on windows so this is a complete new odd situation
 
Top