Stairway solution, is there any?

[utunnels]

I mean 45 degree stairways connect 2 floors, like those in Castlevania.

For example, when the character is near the stair, press up arrow and the character will star climbing. He can stop on the stairway, but will fall if an enemy hits him. If he jumps, he can land on the stairs instead of falling through.

[Plombo]

I don't know of any, and I would like for there to be one.

[Damon Caskey]

I posted on outline on how to do this (or ladders) but I'm pretty sure it got wiped. Maybe Bloodbane has it.

DC

[Bloodbane]

 Sorry, I don't have that. But you posted how to detect ladders (not stairs) in Double Dragon mod thread by alemasper.

If he jumps, he can land on the stairs instead of falling through.

 I'm really lost on how to make that. IIRC in Castlevania, players just fall through if trying to jump on stairs.

[utunnels]

IIRC in Castlevania, players just fall through if trying to jump on stairs.

Hmm, press up while falling and you stay on the stairs.
Maybe this kind of object detects your key input.

[NickyP]

The only thing I can think of is having a 3D stage made 2D using walls, then having like a break in the walls where the ladders are. Something like this...

--walkable area----walkable area--

[wall][wall][wall]  [wall][wall][wall]

--walkable area----walkable area--

The player would be spawned and basically trapped on the bottom part of the walkable area. Then they move "up" in where there's a space between the walls. Basically, you use the Z plane to create the illusion of a top floor. Of course, this method is by no means foolproof, and probably more of a headache than anything...

[Plombo]

It would be best if the engine just supported sloped surfaces.  There could be an "interval" of 1+ pixels, which would be the minimum vertical step.  So an interval of 1 would be a slope, >1 would be a staircase.

Of course, I'm not volunteering to implement this; I'm not familiar enough with that part of the engine.

[utunnels]

 

Yeah, slopes were something I was after but never wanted to finish.

If you merge the feature with wall code, then a lot of changes need to be made into the wall detection. If you made the slot a stand alone feature, then a lot of new commands and functions have to be made.

The worst side effect would be endless bug fixing loops.

[Plombo]

In my opinion, we should modularize the game physics, collision detection, etc. and put it in a separate file from openbor.c.  If it could actually be done, then that could save some of the "endless bug fixing loops".  The biggest problem with maintenance and scope creep in OpenBOR is how interconnected all of the game mechanics are - it doesn't help that it's all lumped into one source file.

[utunnels]

Here's two solutions.

1. The new wall model with a slope face on top.

2. A standalone slope model.


Other models might be too complex for a 2D engine. But new ideas area always welcome. Hmm, maybe this should go to the coding section, though it will probably not be developed too soon.

[MatMan]

Having slopes would be pretty cool.

I did a little hack with my last stage where I used the walls around the slope to give the illusion of a slope (check attachment).

[NickyP]

I did a little hack with my last stage where I used the walls around the slope to give the illusion of a slope (check attachment).

Yeah, that's sort of the method I posted. And just like I said, it looks like a huge headache.

[Plombo]

Here's two solutions.

1. The new wall model with a slope face on top.

2. A standalone slope model.


Other models might be too complex for a 2D engine. But new ideas area always welcome. Hmm, maybe this should go to the coding section, though it will probably not be developed too soon.

As an extension of both solutions, how about making a standalone combined slope+wall model, then using it to implement the existing wall model and scrapping the existing wall code?

It could even be put into a new file separate from openbor.c, like I was suggesting earlier.


I'm thinking now about possibly implementing slopes myself (i.e. not a guarantee).  Here's my unfinished, tentative idea of what I would do if I were to implement slopes (thinking out loud here):

• Create a new source file separate from openbor.c, for all wall/platform/slope code.
• In pseudo-OOP style, create a platform "class" with the following attributes:
  
  • X and Y (A) coordinates of the 4 corners
  • depth
• Implement separate collision detection functions for each side depending on the direction the side is facing (both left/right/horizontal and up/down/vertical alignment).
• Write a method for the platform "class" that takes an entity's current position and velocity as parameters, and returns the new position and velocity (unchanged if no collision). (FIXME: handling of multiple walls/platforms/slopes that are close together, or for very high entity velocities, where an entity collides with >1 platform in the same update; need to make sure the entity is stopped at the correct position!)
• Implement walls using new code, and remove existing wall code from engine.
• Create a new platform command that takes as parameters the X and Y coordinates of each of the 4 XY points, and the Z depth of the platform.  In the wall/platform source file, implement a function to take these coordinates and construct the specified platform by calculating the slopes of the top and bottom.  If either side is also sloped, create a separate sloped platform object for that side, adjacent to the main object.

*To be finished and modified...*

[utunnels]

OK, I see you are still editing, but I'd like to point out something:

X and Y (A) coordinates of the 4 corners

We'll probably need x, y and z for each point, if you want the new model to compact with the old wall logic.

Maybe the slope ( or wall+slope) model's front face is smaller than the one in the back, like a wall.

Instead of letting this idea leads us to the 3d nightmare, I think we need to find some example games that use slopes (2D games of course).

Write a method for the platform "class" that takes an entity's current position and velocity as parameters, and returns the new position and velocity (unchanged if no collision).

Sounds good. Current wall code is just acting too solid.  For example, if a player walks against a wall, he will be blocked completely despite the shape of the wall.

*-----------------------------
Edit-
*------------------------------

The 3D solution could simplify the system if you code it properly, but I'm afraid it'll mess up current wall system (mostly script compatible issues).

That is, drop the wall model completely and use face model instead. A wall is technologically 6 faces, or 5 if you don't count the bottom one, but a platform should have 6 nonetheless. A face can be single sided, for example, some platforms can only be passed from below.

If you like, the ground can also be a face, and thus you don't even need the hole logic.

Code: [Select]

typedef struct
{
  float x;
  float y;
  float z;
}s_vert;

typedef struct
{
  s_vert verts[4];
  int single_sided;   //for platform logic, see above
  s_vect normal;     //normal of the face if necessary
  float slide_factor;    //friction
} s_face;


[Plombo]

OK, I see you are still editing, but I'd like to point out something:

Actually, I'd forgotten about that post.

X and Y (A) coordinates of the 4 corners

We'll probably need x, y and z for each point, if you want the new model to compact with the old wall logic.

Maybe the slope ( or wall+slope) model's front face is smaller than the one in the back, like a wall.

I was mostly thinking of 2D walls and platforms when designing this, since the visibility of the Z dimension is impaired somewhat by OpenBOR's semi-2D view, and I couldn't think of any practical uses for a Z-slope.  Maybe Z slopes could be added when XY slopes are finished, since they would add more complexity to the collision detection functions.

Aren't walls in OpenBOR rectangular prisms, where the front and back faces are the same size?

Write a method for the platform "class" that takes an entity's current position and velocity as parameters, and returns the new position and velocity (unchanged if no collision).

Sounds good. Current wall code is just acting too solid.  For example, if a player walks against a wall, he will be blocked completely despite the shape of the wall.

Yeah, the Newtonian normal force is needed for slopes.

*-----------------------------
Edit-
*------------------------------

The 3D solution could simplify the system if you code it properly, but I'm afraid it'll mess up current wall system (mostly script compatible issues).

Oh...I wasn't thinking about script.  I forgot wall properties could be accessed through script.  Will need to come up with a backwards compatibility layer somehow without overcomplicating things.

That is, drop the wall model completely and use face model instead. A wall is technologically 6 faces, or 5 if you don't count the bottom one, but a platform should have 6 nonetheless. A face can be single sided, for example, some platforms can only be passed from below.

Why not make all faces one-sided?  If we already have a top, bottom, left, right, front, and back face for every platform, then each face will only need to detect collisions from the direction it is facing.  Top-only platforms could then be implemented by adding a "solid" flag to your s_face struct, where if it's unset the collision detection for that face is disabled completely.  So a top-only platform would have every face except the top be non-solid.

If you like, the ground can also be a face, and thus you don't even need the hole logic.

Sounds good.

Code: [Select]

typedef struct
{
  float x;
  float y;
  float z;
}s_vert;

typedef struct
{
  s_vert verts[4];
  int single_sided;   //for platform logic, see above
  s_vect normal;     //normal of the face if necessary
  float slide_factor;    //friction
} s_face;


In addition to the "solid" flag I mentioned above, s_face would also need flags to specify the X/Y/Z direction it is facing, to avoid recalculating it before every collision detection.  On second thought, I guess that information could be determined by checking the +/- direction of the components of the normal vector.