In Progress Double Dragon Mini

[MKLIUKANG1]

Positioned the menu navigation buttons

 

[MKLIUKANG1]

Ladder System for OpenBOR

Standard OpenBOR lacks built-in support for climbing ladders like in classic beat 'em ups. However, using scripts, you can implement a fully functional mechanic that allows the player to grab onto a ladder, move up/down (and even left/right), as well as jump off at any moment.
I have developed a compact, ready-to-use ladder system that:

• Works without pointers and the & operator — fully compatible with OpenBOR.
• Supports up to 5 ladders per level (can be easily expanded).
• Features two ladder types: vertical (Y-axis movement only) and HV (both X and Y-axis movement).
• Can be configured directly from the level file via global variables.
• Does not interfere with other scripts and prevents memory leaks.

System Architecture

Ladder Parameter Storage
All ladder parameters are stored in global variables. For each ladder, the system saves its center coordinates (x, y, z), grab zone width (w), height (h), and type (type). The default maximum limit is 5, but more can be easily added.

float ladd_x0, ladd_y0, ladd_z0, ladd_w0, ladd_h0; int ladd_type0;
float ladd_x1, ladd_y1, ladd_z1, ladd_w1, ladd_h1; int ladd_type1;
// ... up to ladd_x4
int ladd_count = 0;

Core Functions
add_ladder(x, y, z, w, h, type) – adds a ladder to the list.
init_ladders() – reads the level's global variables (ladder_count, ladder0_x, …) and populates the internal list.
set_current_ladder(idx) – fills helper variables (cur_lx, cur_ly, ...) with the parameters of the ladder at index idx. This approach is used specifically to avoid pointers.
process_ladders() – the main function that must be called inside the level block within update.c. It processes all players (0 and 1), checks if they are within a ladder zone, and handles grabbing, movement, and releasing.

How the Processing Works
When the level changes (current_level is not equal to the previous one), init_ladders() is called to load parameters from global variables.

1. For each player, the system checks if they are already on a ladder (using the ladder_idx variable).
2. If the player is on a ladder — the system handles movement (up/down; for the HV type, left/right as well), checks boundary limits (top/bottom), and triggers jumping off if the jump button is pressed.
3. If the player is not on a ladder — the system checks if they are inside the grab zone of any available ladder. If they are and the "Up" button is pressed, the player grabs the ladder.

Example for a single vertical ladder:

updatescript @script
void main()
{
setglobalvar("ladder_count", 1);
setglobalvar("ladder0_x", 100);
setglobalvar("ladder0_y", 95);
setglobalvar("ladder0_z", 0);
setglobalvar("ladder0_w", 40);
setglobalvar("ladder0_h", 190);
setglobalvar("ladder0_type", 0);
}
@end_script

Parameters:

• x, y, z – the center of the ladder.
• w – the width of the grab zone along the X-axis.
• h – the height of the ladder along the Y-axis.
• type – 0 (vertical, up/down movement only) or 1 (HV, additional left/right movement).

To add a second ladder, use the variables ladder1_x, ladder1_y, etc.
Anyway, there is still a lot of work to be done on it.

---

 

[O Ilusionista]

Looking good! Just two things to note:

Example for a single vertical ladder:

updatescript @script void main() { setglobalvar("ladder_count", 1); setglobalvar("ladder0_x", 100); setglobalvar("ladder0_y", 95); setglobalvar("ladder0_z", 0); setglobalvar("ladder0_w", 40); setglobalvar("ladder0_h", 190); setglobalvar("ladder0_type", 0); } @end_script

I don't think you need an updatescript here, as since you aren't using any check first, you are setting those global variable in every engine update. You can move this for a levelscript, as it is fired once per level. Or even just add the script inline in any spawn on the level.

I like the result on the video, but I think the character is too far away in z axis from the ladder, which makes him to look that he is floating