SynfigMaster91 wrote:I'm planning to make a game inspired on Mickey Mania.
I believe the easiest way to do it is to use the built-in physics of the engine. Set the slope factor to zero (in the .chr file) and don't use circular bricks.
How do I do that?
]]>I'm planning to make a game inspired on Mickey Mania.
I believe the easiest way to do it is to use the built-in physics of the engine. Set the slope factor to zero (in the .chr file) and don't use circular bricks.
]]>I'm planning to make a game inspired on Mickey Mania.
]]>Yes, and it seems also that this code has more loops than it should. I got the following code working smoothly for plain floor collision (no slopes and no ceilings)
I was surprised at how well it worked! Unfortunately tho, the loop removed here served to command when gravity should reset and when the player should fall after pushing itself against a ceiling. If it's needed, try testing on the level included to better understand what I mean. I implemented your code and included some additions, here is the updated script:
I followed your tips and multiplied the values by dt(), now it seems to be moving way more fluid than before. I also fixed the movement a bit, making it less slippery.
]]>Could gravity be messing with the vertical collision?
Yes, and it seems also that this code has more loops than it should. I got the following code working smoothly for plain floor collision (no slopes and no ceilings):
//Vertical Collision
state "vertical collision check loop"
{
execute "vertical collision fix" while "obstacle_exists($collision_x/2,$collision_y-1+$vsp)"
}
state "vertical collision fix"
{
let "$y=ypos()-sign($vsp)"
set_absolute_position xpos() $y
}
]]>
Try combining the two conditions in your while loops.
Maybe one of the loops is getting stuck?
I've tried it, but it seems to get the same result.
What gets me confused is that most of the problems comes only from the vertical collision, while the horizontal one works almost perfectly. And to make matters worse, these glitches happen at random, without having a fixed reason to why.
state "vertical collision loop"
{
execute "vertical collision fix" while "(obstacle_exists(0,$vc_counter + sign($vsp))==0) and (obstacle_exists($collision_x,$vc_counter + sign($vsp))==0)"
}
Maybe one of the loops is getting stuck?
]]>In my case, I had to pay attention when I was checking for collisions and how exactly did I adjust the position of the character.
If you just set the vertical speed to zero once the characters reaches the ground, it will bounce. Even though you update the $y variable in your script, you don't actually update the position of the object in your fast loop.
What confuses me is that I'm following the same order of factors that the video tutorial uses, where the coordinates are updated shortly after checking the collision, outside the fast loop:
And it seems that updating inside the fast loop causes the player to disappear when it hits the ground, it must be my fault in the script, but I can't think of anyway of fixing it.
I'm not sure, but I think it might have something to do with these lines in the code:
state "vertical collision loop"
{
execute "vertical collision fix" unless "obstacle_exists (0, $ vc_counter + sign ($ vsp)) <> 0"
execute "vertical collision fix" unless "obstacle_exists ($ collision_x, $ vc_counter + sign ($ vsp)) <> 0"
}
When comparing with the base code I used above, we can notice that it uses the "while" function to check the collision, with the "!" meaning "not" in the Game Maker language.
So a direct translation to the Open Surge API would be:
state "vertical collision loop"
{
execute "vertical collision fix" while "not(obstacle_exists(0,$vc_counter + sign($vsp))<>0)"
execute "vertical collision fix" while "not(obstacle_exists($collision_x,$vc_counter + sign($vsp))<>0)"
}
But that makes the engine freeze, maybe because the condition never gets false.
I reviewed the script several times and I can not find the problem.
If it's helpful, here is the timestamp in the video I'm using where he starts programming the collision: https://youtu.be/vMOJmpOxRfQ?list=LLDx3 … VMA&t=1333
In my case, I had to pay attention when I was checking for collisions and how exactly did I adjust the position of the character.
If you just set the vertical speed to zero once the characters reaches the ground, it will bounce. Even though you update the $y variable in your script, you don't actually update the position of the object in your fast loop.
Also, since you're doing it all manually, I suggest multiplying any speed by dt() when updating positions. See more: http://opensnc.sourceforge.net/wiki/ind … e_position
]]>There might be a loop function somewhere in the API.
Yeah, that was definitely a typo. Fixed it but didn't see any notable change.
Indeed there is. One way to do it is to use execute .. for (execute .. while will work too).
http://opensnc.sourceforge.net/wiki/ind … Fast_Loops
The fast loop worked! It means that it's possible now to easily customize the collision size. Just edit the value of the variables "$collision_x" and "$collision_y" in the main state.
The problem is that the little bounce he gives when touching the ground is still happening:
And he doesn't seem to reach the top very well:
As of the horizontal collision, sometimes it stops a pixel before it should, but pressing the key again makes fixes it:
Any guesses on what's causing it?
There might be a loop function somewhere in the API.
Indeed there is. One way to do it is to use execute .. for (execute .. while will work too).
http://opensnc.sourceforge.net/wiki/ind … Fast_Loops
Example:
// let $counter be a variable between 0 and 16, inclusive.
state "horizontal collision"
{
execute "horizontal collision loop" for "$counter = 0" "$counter <= 16" "$counter += 1"
let "$hsp=0"
}
state "horizontal collision loop"
{
execute "horizontal collision check" unless "obstacle_exists($counter + sign($hsp),0)<>0"
execute "horizontal collision check" unless "obstacle_exists($counter + sign($hsp),16)<>0"
}
First of all, the first bug you notice, is that the collision doesn't work perfectly, it is functional, but it is not perfect. When you are about to fall on the ground, for example, you get do a little bounce before leaning completely on the ground, it's a fast process, so it's a little hard to notice. Unfortunately I have no idea what is causing this.
I looked at the code for the player and noticed this:
state "vertical collision check"
{
let "$y=ypos()+sign($hsp)"
}
Maybe $hsp should be $vsp?
This is not exactly a bug, but something that has been bugging me a lot. If you look at the lines of code that checks the collision, you'll see something like this
//Collisions //Horizontal execute "horizontal collision" if "obstacle_exists(0+ $hsp,0)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,1)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,2)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,3)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,4)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,5)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,6)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,7)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,8)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,9)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,10)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,11)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,12)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,13)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,14)<>0" execute "horizontal collision" if "obstacle_exists(0+ $hsp,15)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,0)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,1)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,2)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,3)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,4)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,5)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,6)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,7)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,8)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,9)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,10)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,11)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,12)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,13)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,14)<>0" execute "horizontal collision" if "obstacle_exists(15+ $hsp,15)<>0"
That's because it was the only way I've found to check every single corner of the sprite. The problem is, if I need a collision greater than 16x16, the code can get pretty extensive. Is there any method where I can reduce this code, or calculate it automatically? Maybe some function that counts from 0 to 16 instantaneously without stopping? I'm aware of the sensor bar method as well, but I really want to choose not to use it.
There might be a loop function somewhere in the API.
]]>Questions and Bugs:
First of all, the first bug you notice, is that the collision doesn't work perfectly, it is functional, but it is not perfect. When you are about to fall on the ground, for example, you get do a little bounce before leaning completely on the ground, it's a fast process, so it's a little hard to notice. Unfortunately I have no idea what is causing this.
I didn't test it all that much, but I think it's possible to get stuck in some bricks corner, but you can jump to set yourself free.
This is not exactly a bug, but something that has been bugging me a lot. If you look at the lines of code that checks the collision, you'll see something like this:
//Collisions
//Horizontal
execute "horizontal collision" if "obstacle_exists(0+ $hsp,0)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,1)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,2)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,3)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,4)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,5)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,6)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,7)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,8)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,9)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,10)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,11)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,12)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,13)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,14)<>0"
execute "horizontal collision" if "obstacle_exists(0+ $hsp,15)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,0)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,1)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,2)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,3)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,4)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,5)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,6)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,7)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,8)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,9)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,10)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,11)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,12)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,13)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,14)<>0"
execute "horizontal collision" if "obstacle_exists(15+ $hsp,15)<>0"
That's because it was the only way I've found to check every single corner of the sprite. The problem is, if I need a collision greater than 16x16, the code can get pretty extensive. Is there any method where I can reduce this code, or calculate it automatically? Maybe some function that counts from 0 to 16 instantaneously without stopping? I'm aware of the sensor bar method as well, but I really want to choose not to use it.
Finally, the download link:
DOWNLOAD
(To play it, go to the options in the main menu and select the stage named "1-1".)
I will be very grateful to anyone who can help me to achieve this, I have a huge passion for this community and I hope to get back to you guys with some artworks very soon!