"Sticky" platformer

Discussion and feedback on Construct 2

Post » Sun Feb 05, 2012 12:54 pm

This isn't in the bugs section because I am not sure it is a bug.

Basically, I have noticed that a platform-enabled object will 'stick' to walls of an incredibly steep slope (anything short of vertical). This is a big problem as most people don't want their players being able to make their way up cliffs.

Here's an example. Totally default behaviors in a new project.



It gets even more insane!



Is there any way to fix this manually? Or could Scirra implement a solution? Because I am sure this is not what 99% of platform games need!sqiddster2012-02-05 12:57:02
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Sun Feb 05, 2012 1:26 pm

You could do this manually some how.

something like:
Player.IsNearWall(Left)
Wall.Angle >= 70 // Or what ever is your max angle etc.
     -> Player.applyVectorX(-2) // this is out of my head, so im not sure if this is the exact action but its something to do with vector x. And you might have to change it to a possible value.

Hope that helps you figure it out.
B
29
S
12
G
7
Posts: 740
Reputation: 7,849

Post » Sun Feb 05, 2012 2:57 pm

That would work, however the problem lies in finding the angle of the wall relative to the player, since my game is gravity-shifting and rotating.
And still, this doesn't seem to be the best way to solve the problem, I am sure there would be issues...
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Sun Feb 05, 2012 3:06 pm

This sample file may can help you doing what you want. I think if you make a mask around the player, aligned by his middle/bottom point, and overlapping the walls, you will can detect the walls and use this system to make him drop away.

The mask need to be bigger than the player, and you set what walls can ignore this system by using a collision check on another object (the wall, for example)

http://dl.dropbox.com/u/47035927/temp/SandBox-R007.rar

http://dl.dropbox.com/u/47035927/sandbox/index.htmlTELLES08082012-02-05 15:08:09
ImageImageImageImageImageImage
B
93
S
20
G
12
Posts: 1,214
Reputation: 18,486

Post » Sun Feb 05, 2012 4:09 pm

All right, I managed to achieve it with invisible collision objects. However perhaps @Ashley could consider adding this as an official feature?
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Sun Feb 05, 2012 4:43 pm

Agreed, this would be awesome =]
ImageImageImageImageImageImage
B
93
S
20
G
12
Posts: 1,214
Reputation: 18,486

Post » Sun Feb 05, 2012 8:52 pm

This could be a very complicated feature to add to the platform behavior itself - it's already one of the most complex behaviors, and it currently does not care what it is standing on. For example, you could also stand on a single pixel, so by the same rule you can land on a very steep slope. I'll see if it's straightforward to fix the Platform behavior to drop down in this case, but it might not be, so it would be best to work around this with events or careful level design for the time being.Ashley2012-02-05 20:53:00
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Sun Feb 05, 2012 9:54 pm

OK, sure @Ashley! This could of course be something to be left to the event sheet.
B
90
S
30
G
24
Posts: 3,189
Reputation: 32,400

Post » Mon Feb 06, 2012 10:09 am

Collision issues are always fun. :)

Thanks for noting this.
B
11
S
3
G
2
Posts: 110
Reputation: 2,410

Post » Thu Feb 16, 2012 6:04 pm

[QUOTE=Ashley] This could be a very complicated feature to add to the platform behavior itself - it's already one of the most complex behaviors, and it currently does not care what it is standing on. For example, you could also stand on a single pixel, so by the same rule you can land on a very steep slope. I'll see if it's straightforward to fix the Platform behavior to drop down in this case, but it might not be, so it would be best to work around this with events or careful level design for the time being.[/QUOTE]

I'm trying to learn fast to use C2 to develop a nice platform tutorial.

So, my workaround for this issue will be something like this:

I'll setup three slave detectors for my player gadget, as I did in the SandBOX (to detect edges and climb them, try it and look how awesome ^^ ).

If the bottom detector is overlapping the ground families, and the top isn't, and the middle detector is overlapping too, so, the player is on a climb, if the bottom is overlapping the ground and every other aren't, so, the player is on ground, if the top detector, the middle, and the bottom are detecting, he is on a wall.

But, this will bug the climbing logic, so, I'll make conditionals using "UP" and "RIGHT/LEFT" to keep him climbing, if not, he will be pushed out the wall or slip down.

So, Ashley, I don't know how you're doing the logic for behaviors, but if you're checking the collision box to make the "triggers" for example, you may can try check how much % of the sprite area is overlapping the wall instead of checking if the collision box is touching a bottom pixel.
ImageImageImageImageImageImage
B
93
S
20
G
12
Posts: 1,214
Reputation: 18,486

Next

Return to Construct 2 General

Who is online

Users browsing this forum: spacedoubt, Unconnected and 1 guest