Phantom Needs Help

Phantom9

Phantom9

Member
Hello everyone, I am Phantom9 aka Phantom9015 from Mugen Archive & AndersonK1.

- If you wanna skip my dialogue I have placed my request below the following paragraph -

I am a seasoned Mugen character coder and was hoping someone could maybe introduce me to the OpenBOR code. I've always had a love for 2.5D side-scrolling beat em' up games like Double Dragonn & Streets Of Rage etc, and have long desired to make my own take on one of those games. However I have no knowledge of basic syntaxes the OpenBOR runs on.

So I was hoping someone could devote a little time to kinda show me the basics so I can have a basic understanding of the coding process. I am unsure as to whether or not my Mugen experience will be of much use or not, but I am willing to learn what anyone is willing to teach. An yes, I have watched tutorials and have just straight up failed to understand them. If anyone is willing to help me I'd be Eternally Grateful.
 
Hello Phantom and welcome to ChronoCrash.
I'd love to help you learn how OpenBor works and build your first project (if you have a specific one in mind).

For me, Openbor is a dream come true, but every dream comes at a price, and you have to be prepared. Fortunately, we have a fantastic community, and I thank everyone who participates ;)
 
Last edited:
Phantom9 said:
Hello everyone, I am Phantom9 aka Phantom9015 from Mugen Archive & AndersonK1.

- If you wanna skip my dialogue I have placed my request below the following paragraph -

I am a seasoned Mugen character coder and was hoping someone could maybe introduce me to the OpenBOR code. I've always had a love for 2.5D side-scrolling beat em' up games like Double Dragonn & Streets Of Rage etc, and have long desired to make my own take on one of those games. However I have no knowledge of basic syntaxes the OpenBOR runs on.

So I was hoping someone could devote a little time to kinda show me the basics so I can have a basic understanding of the coding process. I am unsure as to whether or not my Mugen experience will be of much use or not, but I am willing to learn what anyone is willing to teach. An yes, I have watched tutorials and have just straight up failed to understand them. If anyone is willing to help me I'd be Eternally Grateful.
Click to expand...

Welcome to the community @Phantom9, glad to have you. OpenBOR and Mugen are nothing alike when it comes to building - in fact, they are just about polar opposites in nearly every way they approach things. That said, the basic skills of design, sprite handling, and engineering are universal, so you'll have a strong foundation to work with.

@O Ilusionista wrote a guide for Mugen creators learning OpenBOR, and also a basic getting started guide which I'll link below. It's a little out of date, but will get you going on the basics. Also, one important and very cool facet of OpenBOR is the rule zer effect. ANYTHING can be done or changed because of C based script support. So whatever you are reading about or working with, if there's something that seems limiting, that's the default - not the absolute.

How To Start On OpenBOR O Ilusionista

How To Start On OpenBOR

A collection of useful information to get started with OpenBOR

Samples and Tutorials

Tutorials, script packages, and demonstration modules for use in OpenBOR projects.
www.chronocrash.com www.chronocrash.com

O Ilusionista

Thread 'Mugen to OpenBOR migration guide'

On this topic, I will be explaining (as much as I can) explain the difference between the two engines, showing how to get the same results as we have in the Mugen OpenBOR when possible. For this, I need everyone's help.

I think it important to be able to invite more people from the community to the Mugen OpenBOR, since we have a lot of good people there, and OpenBOR is a fantastic engine. Both engines works different, and both have its good and bad points.

This post will be a constant work in progress. Since english is not my native language, please inform any english error.

TABLE...

DCurrent

Post in thread 'How similar are mugen and openbor?'

@PS_VITA,

I'm two years late to the party, but for what it's worth....

Mugen​


Mugen is basically like the ultimate .ini config file reader. You have a huge list of attributes and formulas that work in a hard coded logic tree, with just about anything you can ever think of to configure a fighter available. It's not very human readable and has a bit of learning curve at first, but once you get passed that initial barrier it's all good. The main issue with Mugen is that it has limited versatility. It does what it does better than anything else, but that's it. If the engine does...
  • Like

It is mentioned in these tutorials, but I like to emphasize for all incoming Mugen devs - Do NOT trim your sprites individually for OpenBOR. You can and it won't hurt anything, but you are wasting massive amounts of time doing so, because OpenBOR auto trims and optimizes sprites on the fly when it loads them. Choose a uniform size for any give set of sprites, one uniform offset, and you're good to go. :)

HTH,
DC
 
kimono said:
Hello Phantom and welcome to ChronoCrash.
I'd love to help you learn how OpenBor works and build your first project (if you have a specific one in mind).

For me, Openbor is a dream come true, but every dream comes at a price, and you have to be prepared. Fortunately, we have a fantastic community, and I thank everyone who participates ;)
Click to expand...
I actually do infact. I'd like to start working on a Double Dragon 2 project. (Yeah I know there's a lot of those, but mine will be different... Hopefully...)

-EDIT- Forgive me if I'm a bit hyper active, I'm just a little bit of a talker haha. I actually asked MSMalik if I could use part of his project as a base and use it to make my own. And my idea is to make like a sort of take on what DD2 would look like if the guys behind DD iOS (we'll call it Double Dragon Special), had made DD2 as well. I'm even in the process of some sprite color separations and partial redesigns of some of the sprites.

Here's a few of em.
 

Attachments

  • i2 - selection.png
    i2 - selection.png
    2.2 KB · Views: 10
  • i - selection.png
    i - selection.png
    2.9 KB · Views: 9
  • i - selection.png
    i - selection.png
    2.1 KB · Views: 9
Last edited:
A great way to get started is to read the entire openbor manual then just start tinkering with a game to see how it works, i would not advise you jump into the scripting until you have a firm grasp of the basics.
 
Yeah, that's what everyone else has told me. I'm actually about try to find and read it right now. Just trying to figure out GIMP real quick because I'm not familiar with it and it was recommended for use with OpenBor. I am far more used to editing sprites on my phone strangely. Seems the only thing I have going for me with this right now is my sprite skills haha.
 
This is great, and I recommend that you first prepare all your assets carefully. Jeff would require more advanced color separation between his boots, pants, and skin. An important point in Openbor is that all sprites in an entity must share the same well-ordered color palette to make them easier to find.

I like to use MSPaint Classic for editing my characters and Gimp from an optimized GIF image to create and organize my color palettes well (because yes, Openbor can use the basic palette as well as the alternative ones from an image).

It is also good to have, as far as possible, the same offset for your animations, that is to say that the character's feet, for example, start from the same base.

I'm currently on vacation but I'll make you a base with a stage and a character (which will be a player and an enemy clone) that you designed so that you can start from there and explain how it works 😉
 
kimono said:
This is great, and I recommend that you first prepare all your assets carefully. Jeff would require more advanced color separation between his boots, pants, and skin. An important point in Openbor is that all sprites in an entity must share the same well-ordered color palette to make them easier to find.

It is also good to have, as far as possible, the same offset for your animations, that is to say that the character's feet, for example, start from the same base.

I'm currently on vacation but I'll make you a base with a stage and a character (which will be a player and an enemy clone) that you designed so that you can start from there and explain how it works 😉
Click to expand...
You don't have to if you're on vacation, but if you're that determined I'll send some of the basic sprites. From what I've seen the sprites should ideally be cropped to be the same size within a box (unlike Mugen, where I could have a 100x87 sprite in a 735x300 selection box and just crop it to whatever I want automatically...).
 
For now, you can simply prepare your sprites in a spritesheet per entity (you can check out the Golden Axe Remake thread to see how I do it) and take care of each one. There's nothing urgent at the moment anyway and this preparatory work is important before proceeding with the integration of these into a game 😉
 
kimono said:
Jeff would require more advanced color separation between his boots, pants, and skin.
Click to expand...
So I guess the guy who I planned to be a Mysterious Warrior type boss is Jeff instead of the very DD1 looking Jeff I had here? Lol.
 

Attachments

  • callofthedragon2 - selection.png
    callofthedragon2 - selection.png
    2.8 KB · Views: 5
  • jeff - selection.png
    jeff - selection.png
    3.1 KB · Views: 5
Hi there.
As @DCurrent said, I've wrote some tutorials for people which comes from Mugen to OpenBOR. Also, I've compiled a big "how to start" on OpenBOR topic too, with full of useful information Tutorial - How To Start On OpenBOR

Phantom9 said:
From what I've seen the sprites should ideally be cropped to be the same size within a box (unlike Mugen, where I could have a 100x87 sprite in a 735x300 selection box and just crop it to whatever I want automatically...).
Click to expand...

Yep, sprites are trimmed on the fly by OpenBOR, so there is no need to trim them. And using the same image size for all players, enemies and NPC can speed up the process a lot. as you can set one axis for each animation and forget about it, and you can re-use bbox coordinates for all characters.

Some points worth mentioning:

- In Mugen, a collision box, whether for attack (clsn1) or damage (clsn2) only works in that frame, unless you set it as default. In OpenBOR, it works the other way around: collision boxes are persistent and if you don't want them to be, you need to turn them off with commands like "bbox 0" or "attack 0"

- Damage collision boxes (clsn2 or bbox here) have a big difference too: While in Mugen they are solid (and you can turn this off), in OpenBOR it works the other way around - they are hollow and you need a script to make them not be like that. Except for cases like Obstacles.

In Mugen, if a character walks towards another character that has a CLSN2, he can't pass through (unless you want him to). In OpenBOR, characters pass through each other.

- The coordinates on the Y axis work in reverse as well: In Mugen, if a character is 100 pixels above the ground, he is at -100 y while in OpenBOR he is at 100 Y.

- Still talking about the Y axis, in Mugen a character can, by default, go beyond the 0 point on the ground (a very common bug). In OpenBOR, this is not the case.

- Mugen only has two axes - X and Y (since the Z axis was removed by Elecbyte in Mugen 1.0). OpenBOR has 4: X, Y, Z (depth) and B (base).
This image may help you understand how it works
1745080045943.png
 
O Ilusionista said:
In Mugen, if a character walks towards another character that has a CLSN2, he can't pass through (unless you want him to). In OpenBOR, characters pass through each other.
Click to expand...
...and right off the bat, some advice about that. OpenBOR lacks space and friction, both for a good reason.

If you decide to script friction, that's no big, but space is something I wouldn't recommend unless you really know what you're doing design wise.

It sounds like a great idea until you have four players and a bunch of enemies who can't pass through each other and have to waste most of their time pathfinding.

DC
 
So, I'm assuming when Ryu jumps onto the box, he doesn't necessarily have to jump the exact height? Because my mind is registering that image as "Ryu jumpheight = 34 and I guess the bbox 40 tall and Ryu can still jump on it. But once he jumps off it it goes back to 0 since the object is no longer below him" Do forgive me if I'm being stupid, I could just be overthinking.
 
Phantom9 said:
So, I'm assuming when Ryu jumps onto the box, he doesn't necessarily have to jump the exact height? Because my mind is registering that image as "Ryu jumpheight = 34 and I guess the bbox 40 tall and Ryu can still jump on it. But once he jumps off it it goes back to 0 since the object is no longer below him" Do forgive me if I'm being stupid, I could just be overthinking.
Click to expand...

I think you're over complicating things a bit.

Base is your height when the engine considers you grounded. That's it.

No, you can't jump 34 pixels high and ascend a 40pixel platform You have to clear the platform height to get on top of it, at which point the platform height is now your base. If you jump or just walk off, the engine knows this and your base becomes the highest platform or terrain map below you.

With no terrain maps or platforms, default base is 0.

Incidently, you absolutely can have a negative base (that's how pits work), and with script you can also go below base height.

DC
 
DCurrent said:
I think you're over complicating things a bit.

Base is your height when the engine considers you grounded. That's it.

No, you can't jump 34 pixels high and ascend a 40pixel platform You have to clear the platform height to get on top of it, at which point the platform height is now your base. Of you jump or just walk off, the engine knows this and your base becomes the highest platform or terrain map below you.

With no terrain maps or platforms, default base is 0.

Incidently, you absolutely can have a negative base (that's how pits work), and with script you can also go below base height.

DC
Click to expand...
Ah okay, that makes sense. Thanks for correcting me.
 
As fellow creators here have noted, studying manuals remains the most effective way to build expertise. Modifying existing projects helps internalize the handbook's principles—once mastered, you'll be ready to architect original games. Let's grow together through this process. Onward and upward!
 
You must log in or register to reply here.
Back
Top Bottom