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

[SOLVED] Enemy reacts incorrectly when it hits a wall

Build Man

Member
I have adapted changes made by TheouAegis regarding interaction with tiles. Then I copied some of those changes and transferred them to other objects with physics.

Here is some code:
Step Event
Code:
while place_meeting(x+hspeed,y,wall_parent)
{
    hspeed = round(hspeed);
    hspeed -= sign(hspeed);
}
wall_parent collision code
Code:
y -= vspeed;

while place_meeting(x,y+vspeed,wall_parent)
    vspeed -= sign(vspeed);
y += vspeed;

vspeed = 0;
friction = 0.6;
For enemies, I have copied Collision code, minus friction thing. For fireball... Well, same thing.

And now after I did those changes, fireballs freeze the game when they collide with vertical wall.

The same goes for enemies in their damaged state when they hit a wall.

Just so you know, here is the full information for fireball:
Code:
Information about object: Fireball

Sprite: Proj_Fireball
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent: <no parent>
Mask: <same as sprite>

Create Event:
execute code:

image_xscale = Protagonist.image_xscale
hspeed = image_xscale*9

execute code:

projectiles -= 1


Destroy Event:
execute code:

instance_create(x,y,Fireball_Particle)
if projectiles < 2
projectiles += 1


 Step Event:
if at relative position (0,1) there is object wall_parent
      set the gravity to 0 in direction 270
      set the vertical speed to -7
else
      set the gravity to 1 in direction 270
execute code:

if (bbox_right < view_xview[0] || bbox_left > view_xview[0]+view_wview[0] || bbox_bottom < view_yview[0] || bbox_top > view_yview[0]+view_hview[0])
 {
 instance_destroy();
 }


Collision Event with object wall_parent:
execute code:

//Vertical Collision
y -= vspeed;

while place_meeting(x,y+vspeed,wall_parent)
    vspeed -= sign(vspeed);
y += vspeed;

vspeed = 0;

execute code:

if place_meeting(x+hspeed,y,wall_parent)
instance_destroy()
And here is just a part of Fungus enemy's coding:
Code:
Information about object: Fungus

Sprite: Enemy_Fungus
Solid: false
Visible: true
Depth: 0
Persistent: false
Parent: <no parent>
Mask: <same as sprite>

Create Event:
execute code:

enemy_health = 10


 Step Event:
if at relative position (0,1) there is object platform_parent
      set the gravity to 0 in direction 270
      execute code:

if enemy_health <= 0 && vspeed = 0
 {
 instance_create(x,y,Knockout)
 instance_destroy()
 score += 100
 }

      set the sprite to Enemy_Fungus with subimage image_index and speed 0.3
else
      set the gravity to 1 in direction 270
execute code:

if image_xscale = -1 && sprite_index = Enemy_Fungus
hspeed = 1
if image_xscale = 1 && sprite_index = Enemy_Fungus
hspeed = -1

execute code:

if place_meeting(x,y-16,Protagonist) && Protagonist.vspeed > 2 && Protagonist.sprite_index != Mako_Damaged && enemy_health != 0
 {
 with Protagonist{vspeed = -18}
 sprite_index = Enemy_Fungus_Damaged
 vspeed = -9
 hspeed = 0
 enemy_health -= Protagonist.normal_dmg
 }


End Step Event:
execute code:

//Horizontal Collision
if (place_meeting(x+hspeed,y,wall_parent))
{
    while(!place_meeting(x+sign(hspeed),y,wall_parent))
    {
        x += sign(hspeed);
    }
    hspeed = 0;
    image_xscale = -image_xscale
}


Collision Event with object wall_parent:
execute code:

//Vertical Collision
y -= vspeed;

while place_meeting(x,y+vspeed,wall_parent)
    vspeed -= sign(vspeed);
y += vspeed;

vspeed = 0;
After many more attempts at making enemy react to collision with vertical wall properly, I have pretty much abandoned all hope at fixing it myself. Nothing ever makes it work properly. Ever.

If you are new to this thread, and do not get what I am saying about, here is the video of what is happening:


This should not be happening. The enemy should not suddenly reappear on the top of the pillar and only then get knocked out. The enemy should stop moving horizontally if it touches the wall and fall down the floor. This gets especially problematic with enemies that are not one-hit point wonders.

I do not know what to try anymore. Nothing ever worked so far. Only with the help of other can I solve this.
All issues regarding objects' troublesome interactions with walls are now solved.
 
Last edited:
S

Sinaz20

Guest
I'm going to assume its one of your while loops... but it'd be too difficult for me to try and figure out which one it is by just reading your code.

Add a break point to the inside of a while loop. Run the game in debug. When you hit a wall, you'll either end up frozen or paused at the break point. If frozen, stop execution and put the break point in the next while loop... until... If you are at the break point, then you are in the offending while loop. Use F11 to step into each line of code. You can inspect variables by hovering over them in the debug code view. That's kind of phase one... if you can isolate which while loop is causing this, then you can post just that while loop code and we can trouble shoot it from there.
 

Simon Gust

Member
It is dangerous to use built-in variables that already change x and y on their own and then do a custom collision code.
change hspeed and vspeed to your own variables an go from there.
While you are setting it to 0 after the code has finished, I do not recommend that, it makes it just more tedious.
 

Build Man

Member
I do not know what really is causing it. But I can say that it collides with floor(vspeed, vertical collision) just fine. It is collision with walls(hspeed, horizontal collision) that causes freezing.

And I do not know how to use debug to find out that while loop either.

Then again, I have used TheouAegis coding since my project has undergo major collision overhaul - no more relying on "solid" checkbox. Having gone through that, I expect TheouAegis to read this topic, then possibly help me out with that.
 
S

Sinaz20

Guest
I see the problem actually. In the vertical collision loops, you removed the curly braces {}. Those curly braces constrain the code that is executed in the loop. Without them, the loop executes everything under the while () to the end of the code block. That includes the part where the vspeed is set to zero, and that turns the loop inescapable.

Look at the formatting on horizontal collision. Emulate that.

Also, you mention that you don't rely on "solid" anymore, but the solid flag changes the way the collision event behaves. Solid collisions set the non solid (moving) instance back to its previous position before executing the event...

If the code was written with solid in mind, then it expects the instance to be in a safe position at the start of the event. But it won't be. It will be embedded. After you fix the while loop I expect you to encounter some other issues with collision if you haven't accounted for this change in behavior (which it appears you haven't.)
 

Simon Gust

Member
I see the problem actually. In the vertical collision loops, you removed the curly braces {}. Those curly braces constrain the code that is executed in the loop. Without them, the loop executes everything under the while () to the end of the code block. That includes the part where the vspeed is set to zero, and that turns the loop inescapable.

Look at the formatting on horizontal collision. Emulate that.

Also, you mention that you don't rely on "solid" anymore, but the solid flag changes the way the collision event behaves. Solid collisions set the non solid (moving) instance back to its previous position before executing the event...

If the code was written with solid in mind, then it expects the instance to be in a safe position at the start of the event. But it won't be. It will be embedded. After you fix the while loop I expect you to encounter some other issues with collision if you haven't accounted for this change in behavior (which it appears you haven't.)
Actually, the while loop without curly brackets only executes to the next statement (vspeed -= sign(vspeed). So do if-statements other loops and with statements. This is just C syntax.
 
S

Sinaz20

Guest
Duh. Thanks for the correction... I'm troubleshooting in my bed :p

Looking again the issue is that the loop is changing vspeed, but not moving the instance... So the while loop is always satisfied by the place meeting and becomes inescapable.

The original while loops changed the y position to meet the blocking instance I assume, looking at the horizontal code (but I suspect that to still break if you've changed the wall objects to non solid.)

Edit: just want to be clear, it appears you expect the vspeed to be applied within the while loop... But vspeed is only automatically applied during the step phase (without looking it up, I think between begin step and normal step.) Which is why the original code walked the y value to the collision point then set vspeed to zero.
 

Build Man

Member
You have mentioned the curly braces {}, but the thing is that I never had them in that piece of code, so I do not know where they need to be exactly.

Also, I have stopped relying on "solid", because TheouAegis told me to stay away from it. He said "solid" property reeks of bugs in Classic iterations of Game Maker(I am using GM8 by the way), and thus should not be touched.
 
Last edited:
S

Sinaz20

Guest
Code:
while(!place_meeting(x+sign(hspeed),y,wall_parent))
    {
        x += sign(hspeed);
    }
hspeed = 0;
^^This is your horizontal code. Compare it to...

Code:
while place_meeting(x,y+vspeed,wall_parent)
    vspeed -= sign(vspeed);
y += vspeed;
Your horizontal code is ok (presumably)... but your vertical code is fundamentally different.

You alter the vspeed in the while loop... which doesn't move the instance until the next frame. So the conditional for your while loop just keeps making the same exact check under the same exact conditions getting stuck in the loop.

Whereas in the horizontal while loop, each cycle of the loop marches the object by 1 pixel (positive or negative depending on the hspeed) by changing its x position before rechecking the conditional for the while loop.

With the two bits of code sitting closer together I hope you can see what I'm talking about.

x and y are the instance's physical position in the room. Changing them has immediate effect.

vspeed and hspeed are rates used in an automated 'kinetic' step to update the x and y. This occurs after regular step I believe. But changing either of them does not have an immediate effect on the position of the object.

I hope I'm making sense to you. I want you to grok how movement code and changing transform variables work.
 

Build Man

Member
I do not seem to have an idea what should I bracket in curly braces {}. I tried some variant, but they either did not have an effect or only made it worse. Or maybe, they will not be helping of the position they were placed.

Ideally, I would wait for TheouAegis, who's code I have inherited, but he does not seem willing to respond. His code works perfectly on Protagonist himself, but not on monsters or fireballs. Which he should have taken into account.
 

TheouAegis

Member
Wow I had an explanation typed up then my browser froze and it didn't save my draft.

First off, I will reiterate that you have way too may objects. Terrain shouldn't be objects like you have them; that's nearly 100 objects just for ground and even non-ground backgrounds. Tiles may be slow in GM8, but at least they're more manageable than all your objects.

The protagonist works because his horizontal collision is handled in the keyboard events -- don't move forward any more than you can. In light of this issue, though, I may have to take a look at the player's ability to be knocked back.

The fireball has a persistent horizontal speed, so it was able to move horizontally into a wall. This had two drawbacks: 1) if low enough in a block, the fireball would 0 out its vspeed while still in the block, and 2) if two blocks were stacked, it would 0 out its vspeed while inside the second block. This warranted the need for a few changes.

Code:
y -= vspeed;

//If moving to yprevious doesn't get out of any wall collision, destroy the fireball
if place_meeting(x,y,wall_parent)
    instance_destroy(); 

else
{
    //Get the sign of vspeed first
    var s; s = sign(vspeed);

    //Only check for collisions with the current wall instance
    while place_meeting(x,y+vspeed,other.id)
        vspeed -= s;

    y += vspeed;
    vspeed = 0;
}
A couple other things. Your step event should just be
Code:
if at relative position (0,1) there is object wall_parent
      set the vertical speed to -7


execute code:

if (bbox_right < view_xview[0] || bbox_left > view_xview[0]+view_wview[0] || bbox_bottom < view_yview[0] || bbox_top > view_yview[0]+view_hview[0])
 {
 instance_destroy();
 }
Set gravity one time -- in the Create event -- and don't touch gravity every again after that.


I'll play around with knockback on the player and make sure things are in working order there.

Update: The protagonists current knock-back script works just fine.
 
Last edited:

TheouAegis

Member
Dude I'm not making your whole game for you. I've told you what you need to handle collisions and stuff. I've also told you what you should change to make your game more manageable. If you can't manage your game as it is you should consider making a new one and using this one as a test bed to try things out before implementing them into the actual game. I am not going to sort through 100 objects making sure every single one is set up right.
 

Build Man

Member
Dude I'm not making your whole game for you. I've told you what you need to handle collisions and stuff. I've also told you what you should change to make your game more manageable. If you can't manage your game as it is you should consider making a new one and using this one as a test bed to try things out before implementing them into the actual game. I am not going to sort through 100 objects making sure every single one is set up right.
Do not worry. Collisons and speedway interactions are currently only things buggering me, and all other aspects should not cause trouble. They should not. I hope so.

Oh, and if anything, I never yet had any experience with tiles. In fact, I have not had any experience
with Game Maker in general, but I will make up for it by keeping looking for tutorials.

Again, big thanks for your assistance. If I am to include credits in my game, I will write your name in here.
 

TheouAegis

Member
Well I'm not trying to force you to implement tile collisions in your project, as I know you're nowhere near ready to work with them. Although You could use tiles for the backgrounds and place invisible objects wherever you wouldn't want the player to pass through. This method of background collision handling will cut your object use drastically, though. It will make your projects much, much easier for you and anyone else to work with.
 

Build Man

Member
Well I'm not trying to force you to implement tile collisions in your project, as I know you're nowhere near ready to work with them. Although You could use tiles for the backgrounds and place invisible objects wherever you wouldn't want the player to pass through. This method of background collision handling will cut your object use drastically, though. It will make your projects much, much easier for you and anyone else to work with.
Well, composing tileset is easy. Total conversion from object-based graphics to tile-based, however, will be a colossal time sink. And I am not that good at major overhauls.
 

kupo15

Member
while place_meeting(x,y+vspeed,wall_parent)
vspeed -= sign(vspeed); .
y += vspeed;
Wanted to quickly touch up on this as an afterthought. @Sinaz20 wasn't wrong with the {} his solution would still have worked based on how you set it up.

Code:
y -= vspeed;

while place_meeting(x,y+vspeed,wall_parent)
{
vspeed -= sign(vspeed);
y += vspeed;
}
This would have nudged the y coor based on the value of the vspeed before rechecking the loop. But as mentioned previously using built ins are not advised at all. If you wanted to still use built ins you should be doing

Code:
y -= vspeed;

while place_meeting(x,y+vspeed,wall_parent)
y -= sign(vspeed);

y += vspeed;
Also worth mentioning your logic here isn't correct. You are moving the object then applying a predictive collision check. You should either be doing a predictive check then move afterwards or move first then check for a collision with the new position. In your current code you are moving first (assume into the wall) then you are checking if you are still colliding with the wall with more movement. Depending on your speed and floor sizes that second check could be through the floor and then you would pass right through it

You are also applying two y movements in the same step even if there were no collisions
 

Build Man

Member
Okay. While tiles are good and all, I am afraid, they are not suited to hide objects beneath them at all. Like, objects will always be before tiles. Or is there a way to hide objects beneath tiles? Because one of enemies - Man-Eating Plant - supposed to hide behind a stump covered by lushes.

Also, if a defeated enemy falls into a wall, he appears on the top of it. Which should not happen. How to halt enemy's movement into a wall without ending up with them on top of a wall?
 
Last edited:

TheouAegis

Member
Tiles have depth the same as objects. If you want an object to be behind a tile, you put that tile at a lower depth than the object you want it to hide.

Anything you can do with objects you can do with tiles, at least in gm8. (with a lot more work)

In regards to your defeated enemy, are you talking about when using tiles or are you talking about even with your normal object walls? When you say he is on top do you mean his overlapping the wall or do you mean he is actually on top of the wall, like he jumped up really really high?
 

Build Man

Member
In regards to your defeated enemy, are you talking about when using tiles or are you talking about even with your normal object walls? When you say he is on top do you mean his overlapping the wall or do you mean he is actually on top of the wall, like he jumped up really really high?
On top of it. Yes, I have meant the second one.
 

Build Man

Member
Tiles have depth the same as objects. If you want an object to be behind a tile, you put that tile at a lower depth than the object you want it to hide.

Anything you can do with objects you can do with tiles, at least in gm8. (with a lot more work)

In regards to your defeated enemy, are you talking about when using tiles or are you talking about even with your normal object walls? When you say he is on top do you mean his overlapping the wall or do you mean he is actually on top of the wall, like he jumped up really really high?
On top of it. Yes, I have meant the second one.
While I am at work redrawing my levels using tiles in place of objects, can you give a hint on how to move tiles? I have a transition stage that imitates an earthquake by disabling Protagonist's gravity and rapidly moving all objects in-game up and down. Objects, but not tiles.
 

TheouAegis

Member
What about moving the view instead of the tiles? Or are you going to have the tiles moving up and down at different speeds so it looks like the ground is undulating?

In GM8, I always just used 2 loops to find the id of every tile and set each tile's movement. Unfortunately this is a bit slow due to how GM8 handles ids.

(in the code below, it's assumed your tiles are 16x16)
Code:
var xx,yy, tile, lx, ly;
lx = view_xview+view_wview;
ly = view_yview+view_hview;
for(yy=view_yview; yy<ly; yy+=16;)
for(xx=view_xview; xx<lx; xx+=16;)
{
    tile = tile_layer_find(moving_tile_layer, xx, yy);
    if tile > -1
    {
        //whatever code you need to use to move the tile
        //use tile_set_position(tile,x,y) to change the position of the tile. 
    }
}
The only issue I have with this method is that, unlike objects, tiles don't have an xstart and ystart variable, so you can't easily set the tiles back to their starting position once the earthquake is done. To counter that, I personally would have an array of all the different offsets to adjust the tile positions so that I could make sure myself that the tiles would end up back at the right spot. You might not like that idea and I encourage you to try to come up with a better one, but I'd strongly advise against making the tile movements completely random.
 

Build Man

Member
Code:
var xx,yy, tile, lx, ly;
lx = view_xview+view_wview;
ly = view_yview+view_hview;
for(yy=view_yview; yy<ly; yy+=16;)
for(xx=view_xview; xx<lx; xx+=16;)
{
    tile = tile_layer_find(moving_tile_layer, xx, yy);
    if tile > -1
    {
        //whatever code you need to use to move the tile
        //use tile_set_position(tile,x,y) to change the position of the tile.
    }
}
I think I have made a mess. Can you check it out?

https://www.mediafire.com/file/rk19biqmi3z2a03/Legend of Mako Experimental TA 8.gmk
 

TheouAegis

Member
Where at in the project am I going to have to look? I don't want to have to dig through the whole thing just to find your error.
 

Build Man

Member
Where at in the project am I going to have to look? I don't want to have to dig through the whole thing just to find your error.
Sorry for not explaining. It's in Objects/Terrain/Zone 1/Transition. The object is floor1_trans. It is necessary object, because it triggers an earthquake and self-destructs after 70 in-game ticks, dropping Protagonist in and transitioning him into Level 2.

The other terrain objects are not deleted yet, because not everything is converted to tiles yet.
 

TheouAegis

Member
Ok I will take a look at it tomorrow if I remember.

Can you post a drawing (or really good description) of how you want your earthquake to appear to the player? Or compare it to a game with similar earthquakes.
 

Build Man

Member
Ok I will take a look at it tomorrow if I remember.

Can you post a drawing (or really good description) of how you want your earthquake to appear to the player? Or compare it to a game with similar earthquakes.
Back when it was objects, I just used this code:
Code:
if earthquake = 1 && shake >= 0
 {
 if shake = 1
  {
  shake = 2
  with all
   {
   y -= 1
   }
  }
 else
  {
  shake = 1
  with Protagonist {gravity = 0}
  with all
   {
   y += 1
   }
  }
 }
The "earthquake" and "shake" were both created via Create Event.

This is as descriptive as I can get. Sorry, but I can not be very descriptive due to speech programming flaws.

The concept remained the same. I just want to shift tiles up and down 1 pixel. After all, this is just a simple, NES-like game.
 

TheouAegis

Member
You do realize with your old code you're removing every object up and down one at a time. This is no different than moving the view up and down one pixel at a time. This is how they would have done it on the NES.

But for educational purposes I will still try to make it work for you with tiles. But like I said, you shouldn't even do it that way. You should take the simpler and more logical route.
 

Build Man

Member
Just so you know, I did not forgot about my project.

At the same time, I could not quite get my hands on it and do some experiments just yet. Until now. What I am trying to do is to figure how to make hurt enemies stop by the wall and not teleport above it or below the ground. Currently with no much luck.

EDIT: And while we are at it, could you give a hint? I did all I could process about, and some things outside, but nothing worked. A simple fungus keeps warping through the floor or popping up the wall edge.
 
Last edited:

Build Man

Member
After many more attempts at making enemy react to collision with vertical wall properly, I have pretty much abandoned all hope at fixing it myself. Nothing ever makes it work properly. Ever.

If you are new to this thread, and do not get what I am saying about, here is the video of what is happening:


This should not be happening. The enemy should not suddenly reappear on the top of the pillar and only then get knocked out. The enemy should stop moving horizontally if it touches the wall and fall down the floor. This gets especially problematic with enemies that are not one-hit point wonders.

I do not know what to try anymore. Nothing ever worked so far. Only with the help of other can I solve this.
 

TheouAegis

Member
Whaaat.... I don't remember seeing that happen in my testing. Which object is that wall? I will make sure I test with it.
 

TheouAegis

Member
No need. I also fixed the freezing. It didn't freeze with a stacked blocks, but it did freeze when i scaled it up. So i had to rework some stuff. Good news is things should be simpler.

In the enemies:
Remove the collision events with wall_parent and the box. Remove the end step event. At the bottom of the Step Event, put this code:
Code:
var sh,sv;
sh=sign(hspeed);
sv=sign(vspeed);
while place_meeting(x+hspeed,y,wall_parent) hspeed-=sh;
while place_meeting(x,y+vspeed,wall_parent) vspeed-=sv;
if sign(hspeed)!=sh {
image_xscale = -image_xscale;
hspeed=-sh; }
 

Build Man

Member
Thank you. Your method works. Also, now I have realized that I have been using var wrong in floor1_trans. var must be in the same event as the trigger for it.

But anyway, how do I imitate an earthquake in zone1_trasition? I am not picky now, you can suggest any variant.
 

TheouAegis

Member
As I said in your earthquake post, the way your original code was set up, all you need to do is just move the view_yview up and down; don't move the objects.
 

Build Man

Member
As I said in your earthquake post, the way your original code was set up, all you need to do is just move the view_yview up and down; don't move the objects.
But how? I have not done this before and I do not know where to start from and what code responds to this.
 

TheouAegis

Member
Is the earthquake going to pause the action in the game or will the game still be able to play while the earthquake is going on?

Either way, a popular method is to use a sine wave to chart the position of the quake so it essentially cycles. This is the code I used:

Create two variables eq_state and eq_size both set to 0. When you want tge earthquake to start, set eq_state to 1. This will tell our code to start increasing the earthquake in intensity. But you also need to make the view stop following the Protagonist.
Code:
eq_state = 1;
view_object=-1;
Then in the Step Event (or one of its ) i have this:
Code:
if eq_state {
   view_yview = sin(eq_size) * eq_size div (45 * eq_state);
   if eq_state==1 {
      eq_size += 10;
      if eq_size>720
         eq_state+=1;
   }
   else {
      eq_size-=3;
      if !eq_size {
         eq_state=0;
         view_object=protagonist;
      }
   }
}
You may notice that the size of the quake increases faster in the beginning and then decreases more slowly at the end. This would create essentially a bell curve of intensity like a natural quake.

All of the numbers tie in together. All-terrain one number well effect the style of the earthquake to some degree. The ratio of "720" and "45" determines the intensity of the quake at its peak; that is, the higher the ration, the farther the view jumps. Multiplying the "45" with eq_state will lower the intensity on the tail end. The "10" determines how quickly the quake intensifies and thus how long it takes to reach peak intensity; this means changing "720" may require you to change the "10". The "3" is lower because we want the tail end to be longer in duration. However, this also affects how long the quake's intensity is at its max.

Also note that this will cause the view to jump between negative values, thus exposing the top of the room, and positive values, thus exposing the bottom of the room. Now, this would normally mean you would have to add extra tiles to the top and the bottom of your rooms. However you can alleviate this, simplifying it to where you only need extra tiles at the bottom of your rooms by changing sin(eq_size) to ceil(sin(eq_size)). Bear in mind however that this will slightly change the appearance of the quake. Personally, I like it better this way since it halves intensity.
 

Build Man

Member
This does not seem to work. I mean, it hardly works, because HUD moves, but not the rest of the screen. Maybe that is because transition room's view is the same as room's size, which is 640 width and 480 height. We could either use a workaround or some other way.
 
Last edited:

TheouAegis

Member
Wow, I never realized it behave that way. I have always had the view enabled when I use code that uses views. So go ahead and turn the view on in your transition room and it will work as i made it.
 

Build Man

Member
Wow, I never realized it behave that way. I have always had the view enabled when I use code that uses views. So go ahead and turn the view on in your transition room and it will work as i made it.
Ow, right. View was disabled for that room, because it has nowhere to scroll. Unlike playable rooms that have wide area to side-scroll through. Now I have view enabled, and it works as intended. Thanks. Now, all that is left is some major mechanic involving Akir's Sandals and their interaction with speedways.
 

TheouAegis

Member
Yeah i took a glance at what you had so far there. I think the issue may have to do with how you use slopes, but i didn't look at the code.
 

Build Man

Member
Top