Open Surge Forum

A fun 2D retro platformer inspired by Sonic games and a game creation system

You are not logged in.

Announcement

Our community has moved to Discord! https://discord.gg/w8JqM7m

#1 2018-07-01 00:23:59

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

[Idea] Collision Maps

Here's an idea that just struck me. This is just a brainstorming, but you can see where I'm going.

Creating brick scripts by hand is time consuming and error prone. It is error prone mainly due to the computation of angles, useful only if the brick is solid (thus affecting collisions). If it weren't for the computation of angles, it would be easy to automate the whole brick generation task.

What if, in our thinking process, we could detach the collision from the bricks? Think for a moment that you only have passable bricks in your brickset. These bricks are independent blocks. They make sense by themselves in terms of visual design, but they handle no collisions. Collisions would be handled in an independent layer designed by the author of the level.

Objects in Open Surge can be scripted. An interesting thing about objects is that they can be made to behave like bricks, thus affecting collisions. Let's call these collision objects. If your collision objects could be fully customized (in terms of scale, angle and so on) - and you would have many of them - wouldn't you be able to define the whole collision map for a level? And if your collision objects could be fully customized visually, wouldn't that greatly simplify the task of creating bricks?

In short, the "collision map" is just a set of objects that become solid bricks once the level is started. Surprisingly, this concept can be tested even in the legacy version of Open Surge.

Offline

#2 2018-07-01 12:23:34

svgmovement
Member
Registered: 2011-11-24
Posts: 209

Re: [Idea] Collision Maps

Sounds interesting. I would like to see how this will look in practice.

Alexandre wrote:

In short, the "collision map" is just a set of objects that become solid bricks once the level is started.

The collision map would create solid bricks, or each object would act as a brick?


-- svgmovement

Offline

#3 2018-07-01 13:47:36

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

svgmovement wrote:

The collision map would create solid bricks, or each object would act as a brick?

Each collision object represents a brick. Once the level is started, they become solid bricks.

Rather than defining collisions in a brick script, you define them visually by creating a collision map.

A brick script defines visually coherent pieces of your level as non-solid bricks.

Offline

#4 2018-07-02 10:54:11

G.E.R.
Member
From: Russia, Krasnodar
Registered: 2017-12-26
Posts: 177

Re: [Idea] Collision Maps

Simply put, a level is consists entirely of passable bricks. The floors, walls, breackable wall and clouds is an independent technical objects. I think, it can help in creating level process and will expand possibility of using coarse slopes and loops.

I have difficulties when I want to create an uneven road. I use the simplest solution is creating individual brick for each uneven road:
illust_1_020718.jpg.png

Offline

#5 2018-07-02 14:06:05

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [Idea] Collision Maps

like this?

I tried that with scripts but the result was inconsistent. sometimes physics were ok, others just wonky.

collision.png

https://drive.google.com/open?id=1VvktM … 44rK_lPLgH


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#6 2018-07-02 17:52:13

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

G.E.R. wrote:

I have difficulties when I want to create an uneven road. I use the simplest solution is creating individual brick for each uneven road

What if you could approximate your uneven road with some sort of polyline?

KZR wrote:

sometimes physics were ok, others just wonky.

How did you set the angles?

Offline

#7 2018-07-02 19:42:51

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [Idea] Collision Maps

27, 45, 63 +90 for every quadrant. sometimes collision objects allowed the player to clip through or would get him stuck. as bricks they work perfectly.


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#8 2018-07-03 13:41:46

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

I see.

Here's another observation: the main limitation of the current system is not the collision per-se, but rather, it is the brick angle. In a solid brick, a collision is defined by two things:

- A collision mask
- A brick angle

A collision mask can be implicitly defined by the brick image (whatever is not transparent is solid) - or it can be defined by the user (for custom masks). A brick angle is a single number that defines the normal vector of that brick, to be used by the physics engine. That is fine for small bricks, but what about something like this?

grassbrick.png

Clearly, the normal vector of the surface varies according to the position. Even though the collision mask can be perfectly defined for that curvy surface, the angle can't, because it changes. Therefore, the problem isn't the collision, but just the angle.

What if a single brick could have multiple angles? All the user would have to do is define a normal vector for each part of the brick (perhaps visually), and the angles would be computer automatically. tongue

In practice, currently we end up breaking the brick into smaller bricks, setting their angles and putting them together again in the level editor. While it works, it is painful for the user. We should just be able to put the whole thing in the level as a single brick and it see that it just works. smile

Offline

#9 2018-07-03 14:01:26

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [Idea] Collision Maps

wait, how about this, add two feet sensors, and compute the angle between them. a function called, for example, floorangle() can be used to read the value and used separately from the already existing brick angle.
#Edit

Not to mention these can only trigger when the player is standing on ground.

I wrote

while defining a character one could then choose between legacy angles(brickset based) or computed angles (sensor based).

but deleted it. after thinking it through, it would only lead to more unnecessary coding.

I think it is best to mix both and use precomputed where angle = 0. that way we get the pixel perfect collision and correct behavior of player's actor and sprite without changing things around too much.

Last edited by KZR (2018-07-03 14:08:44)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#10 2018-07-03 14:09:27

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

KZR wrote:

wait, how about this, add two feet sensors, and compute the angle between them.

Think about it: can this angle be uniquely defined, or does the equation have multiple solutions?

edit

"add two feet sensors": this reasoning is very good. The trouble is: we don't know what "feet" mean. The character won't walk on the brick before this is specified (currently by the angle).

However, if we state what "feet" mean (what is the direction of the floor?), then we can indeed compute the angles by taking the derivative (it's like using two sensors).

A brick syntax could become something like this:

// compute angle automatically
brick 0
{
   type                obstacle
   behavior            default
   angle               auto floor-bottom

   sprite
   {
      ...
   }
}

For each pixel of the surface, we can tell its normal vector if we know what "floor" is (up, down, left, right).

Last edited by Alexandre (2018-07-03 14:57:39)

Offline

#11 2018-07-03 15:31:09

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

The problem with the approach above is that the following brick is neither floor-bottom, nor floor-left. So, it's not enough yet. Take a look at the normal vectors:

brick_normal.png

edit

yes, but at least we know what part of this brick is solid and what part isn't. Isn't that enough to compute the normals? smile

Last edited by Alexandre (2018-07-03 15:42:23)

Offline

#12 2018-07-03 19:00:23

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [Idea] Collision Maps

I imagine the two feet are offset 2 pixels to the left and right and stay this way no matter what animation plays. like this you have 4 pixels to determine an angle of 0, 27, 45, and 63, roughly. I suppose increasing the distance to 8 would give out more results but I wouldn't go more precise than that.

Remember that the floor angle only affects the sprite angle and the physics, so for sprite angles would be nice to have some soft rotation to interpolate better and giving off a better feedback of what's truly happening.

Last edited by KZR (2018-07-03 19:02:38)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#13 2018-07-04 01:55:45

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

KZR wrote:

so for sprite angles would be nice to have some soft rotation to interpolate better and giving off a better feedback of what's truly happening.

I agree this is a good idea.

I did some experimenting today. Here's what I came up with. In this example, I'm storing the surface normals in what I'll call a normal map.

Here's a brick:

grassbrick.png

Its bitmask:

grassmask.png

Compute the derivative in the x-axis and in the y-axis using Sobel with a large kernel:

dx.png dy.png

Now take the arc tangent of the images and get the angles of the normal vectors:

normalmap.png

ta-da!

The surface normals are codified in the colors. The angles at each point are displayed. This is a normal map of the brick.

With this method, perhaps we can leave the "angle" property in the past? cool

Offline

#14 2018-07-04 12:01:55

TheSeventhEmerald
Member
From: Spain
Registered: 2010-04-19
Posts: 302

Re: [Idea] Collision Maps

This seems interesting.

Taking also in account that, as you mentioned, collisions in OpenSurge are implemented with polygons, another idea would be to let the user put whatever bricks they want and then create collision polygons. From this, computing normals is even easier.

In any case, an improvement in this direction would be a huge step for the game, in my opinion. Really looking forward to it.


Piece of cake...!

Offline

#15 2018-07-04 13:53:52

KZR
Member
Registered: 2010-07-14
Posts: 1,447
Website

Re: [Idea] Collision Maps

I too vote for polygons. with a grid for goodness' sake. this normal map approach is ok I guess, but I see that it computes an angle for each line break, like every time the line gets shifted, thicker or thinner. this introduces a problem

I see that some points look to be dotted or dithered. What should be a soft slope has parts where the game would treat it as a rapid succession of different angles or solid types until it settles for one.

here we must set a standard: what is the minimum size for a normal patch? I'd say 16*16 is a good unit of measure, that leaves space for many different angles while keeping the physics precise

edit:

it just struck me: polygons, yes. grid, yes. but the grid has a twist: it snaps either in 4*1 or 1*4 steps, along with 4*4, meaning you can use a 16*16 block to produce multiple angles. You could even store these possible angles in a table, like you did with bricks, making it that much more efficient and probably even cross reference that into the brickset system, like making these possible angles into actual images hard coded into the game. we would call that the brickset and leave only one of it.

actual "bricksets" as we know it, would then rather be a collection of images to build and decorate the level layout. we could call this level blocks, or simply blocks.

Last edited by KZR (2018-07-04 14:05:38)


SD_sml.pngSeD_sml.pngLTot_W_sml.png
https://discord.gg/w8JqM7m ---> Open Surge's Discord server

Offline

#16 2018-07-04 14:14:32

Alexandre
Administrator
From: Brazil
Registered: 2009-01-27
Posts: 3,300
Website

Re: [Idea] Collision Maps

TheSeventhEmerald wrote:

as you mentioned, collisions in OpenSurge are implemented with polygons,

Collisions in Open Surge are implemented using collision masks. Bricks can be thought of as polygons, specially in the old days of 0.1.4 (as we didn't have collision masks back then).

I want to make the brick system easier. Easy to use, easy to put together, easy to create. It is easy (conceptually): you just place the bricks in your level and you're all set. What makes it hard is the "angle" property. Can we ditch it?

What I am proposing is to make something better than polygons: a collision mask combined with a normal map. Easier to use, easier to compute, and great physics! cool Why is it better? Because it has the accuracy of a collision mask, with no extra work required. It's also better than tile-based collision.

TheSeventhEmerald wrote:

let the user put whatever bricks they want and then create collision polygons

You can just place your bricks on the level, and that's it. You don't need to worry about anything anymore. No angles, no polygons, nothing! It's all done for you.

How is this achieved? This is what this brainstorming is all about. You use something magical called a normal map. A normal map offers geometric properties of the brick and can be computed by a program.

KZR wrote:

I see that some points look to be dotted or dithered. What should be a soft slope has parts where the game would treat it as a rapid succession of different angles or solid types until it settles for one.

The visual part isn't as important as what is being conveyed. When the ramp goes up, the angle goes up. When the ramp stays roughly on the same level, the angle doesn't go up. smile We can, of course, smooth the image further. wink

TheSeventhEmerald wrote:

In any case, an improvement in this direction would be a huge step for the game, in my opinion. Really looking forward to it.

As far as I know, this proposed method has not been implemented anywhere else for a purpose like ours. I find it very exciting. It's innovative and very user-friendly. cool

Offline

#17 2018-07-04 15:49:46

Race the Hedgehog
Member
From: Sao Bernardo do Campo, Brazil
Registered: 2010-12-16
Posts: 163
Website

Re: [Idea] Collision Maps

I'M SO EXCITED ABOUT THIS!
the angles being calculated automatically will bring much more engagement to level mods and recreations, it looks very promising!

adding to the conversation, the brick's PROPERTIES (solid, cloud, passable etc.) are also an obstacle, but it's easier to resolve in a theoretical point.
I think the most practical solution would be to be able to change it directly in-game, the same way that we do to change what layer the brick is in.


PunBB bbcode test
Creating and Editing Sprites.

Offline

Board footer

Powered by FluxBB  hosted by tuxfamily.org