In the past I have made some abstract games, some text based games and a few platform games. Text based is obvious and irrelevant here. Abstract games generally involve drawing and moving sprites around (e.g. draw 'knight' sprite at co-ordinates [4, 3]). Platform games are similar, except there is some sort of 'physics' going on. I loop over my character and enemies, maybe each frame, and check if there is a 'block' under them, if there is that's fine. if there isn't they may have an 'isFalling' attribute which gets set and while it is set - 'gravity' decreases their 'Y' coordinate, until there is something under them. The world/level is stored as a list of objects (floors/spikes/water) with their x, y co-ordinates so I can loop through to see what the character is 'standing' on (or not).

So a slightly nicer looking game may have slopes. So, how do I check whether my character is standing on anything? I can represent a line (say a sloped floor) as two sets of co-ordinates. My line may be [(0,0),(100,20)] and I can store the whole level with as many lines as need be as a big list and loop through them, but if my character is at (15,3) - how do I know that he is standing on that bit of floor.

I suppose I have an idea that pops into my head, but I don't know if it's plausible or sensible or if there is a better way.

When the level starts, I can convert all the vectors for the level into 'traditional' blocks and store those as a list just while we are on this level and then do the same for the next level when we get there. So a line [0,0]-[15,15] might make the following 5 pixel sized blocks: (0,0) (0,5) (0,10) (5,5) (5,10) (10,10) Each block would need to store the 'angle', so I would know whether, which direction and how fast my character would slide down a hill if it was steep.

And what about if I further complicate matters and want curves?

Why don't you describe you geometry as volumes instead. This way you could define your objects as a set of lines that form a bounding box. Now draw a line for each "moveable" to the ground and try to find any line that intersects. If you find one, you know the next "physical volume" and decrease Y as long as there is space between. A curve can be tested too using some math.

To speed things up use a quad tree to determine the cell/cells for objects you need to test

Typically you would do this by casting a ray downwards from the character's feet, testing that ray against all objects in the scene, and using the intersection point and the intersection normal vector to calculate whether the character stops or slides.

If you have a lot of line segments/curves to deal with, you probably want to use a spatial partitioning structure (for example, a quad tree) to avoid casting the ray against every object in the scene.

If you're using Unity...

https://www.youtube.com/watch?v=GSo_fU1JdfM

and if not maybe it will give you some ideas.

Thank you so much for the replies. And sorry for the delay.

I think Shaarigan and swiftcoder are describing the same thing draw a line down/cast a ray downwards. I'm not sure how it would be easier if it was 'boxes' over just lines, is that just because it's easy to 'miss seeing' a thin line, but you are more likely to 'see' a box; if I check downwards every, say, 10 pixels for example.

I assume curves work in a similar manner to lines, but the maths is different.

I'm not using Unity, but I will take a look when I can get my sound to work.

On 3/30/2019 at 11:26 PM, Banananana said:

is that just because it's easy to 'miss seeing' a thin line

Line intersection test is something of basic math so this should not be the problem. Describe your boxes just as a quad of 4 lines and test either the horizontal or vertical ones for an intersection in Y/X direction. I used this simple technic to test for cars outside of the visible map where physics wasn't an option in a 3D driving game. Cars were described as a box volume and I casted a line from the front to test for possible cars in speed distance.

A curve is a bit more complex to test but also possible