A few base questions about OpenBoR for an original project.

[VinVulpis]

Hello folks! I suppose I'll start off with a quick intro.

I'm Vince, and artist/animator (and music composer though I've been very lacking in that area lately) with aspirations to design games.

This be a character of mine. His name is Jeibu. He says hi.

I have some weird questions about this engine I'm hoping to figure out about it's capabilities and limitations and the best way to get started learning this engine if it's good to suit my project in. I'm looking for something with a good basic framework that I can figure out the scripting for quickly enough because my programming skills are novice and sloppy when it comes to working from scratch. I see there is a post here with various doc posts, but some of the links are broken.

I'd been tinkering about in MUGEN, prototyping various ideas of mine, but ultimately, MUGEN is super limiting and I'm not able to even publish with it, so as fun as it is to make stuff for, it's a dead-end.

I exchanged emails with one of the OpenBoR creators (Plombo) and he'd seemed confident in most of what I'm looking for, but he suggested I check in with the forums.

Here's a list of what I'm looking to do:
- A single plane (no z-axis), platforming beat'em-up
- Dungeon crawler like stage progression. Where runs are randomly generated within each world/stage. (maybe a seed system controlling it)
- Unlockable characters and item discovery that carries over from run to run to build upon the story.
- Basic platforming

Something that handles kinda like this Air Momentum Test Video I made with MUGEN:
https://www.youtube.com/watch?v=-XQ_mfWdSZA

The in air movement and physics are important to me.

Also a old experimental thing with combos:
http://i.imgur.com/qOD0sFN.mp4

Also, I'd like the combat system to have a more fighting game like attack attribute system, meaning a way to flag strikes, grabs and projectiles and ways to create states immune or counter to particular attributes.

How hard would it be to make this engine do something like this? I'm not exactly trying to ask how to do all of this, I just wanna know if it's possible in OpenBoR.

One issue that I was told is that OpenBoR cannot do any camera zooming. Can it not be done even with scripting? Zooming is a bit important to me for cinematic scenes, but also for gameplay, allowing some distance to be created between player/player or player/target. To what extent is the camera able to be controlled? I'm also generally interested to know what the general graphical limitations are and how they compare to MUGEN 1.1.

I suppose that's all the basics I wanted to ask. I can figure things out if I find this engine is ideal for what I wanna do.

Thanks much,
-Vince

 

[Piccolo]

Everything you said seems possible to me, but lot of stuff will require advanced scripting.

Camera zooming is possible in OpenBOR, at least to some extent, I've seen it in many mods.

Nice animation BTW.

Edit : oh and hello and welcome here  :

 

[aL BeasTie]

yeah awesome sprite/anim.  Can you keep up with this level of detail for a whole game thou?

- Dungeon crawler like stage progression. Where runs are randomly generated within each world/stage. (maybe a seed system controlling it)

stages are just what you spawn into them, so basically all your spawns would be randomized for object/enemy type, location etc.

One issue that I was told is that OpenBoR cannot do any camera zooming.

Openbor can have zoom, it's all about how you setup your art.  It can't zoom out any further than the max resolution/allocated screen.  The game art will need to be made at max zoom out.  In the example image below, inside the red area would be what is normally seen and would be zoomed in.  The image as a whole is what would be seen without zoom.

A thread here that should explain more.
http://www.chronocrash.com/forum/index.php?topic=2809.msg38044#msg38044

 

[VinVulpis]

yeah awesome sprite/anim.  Can you keep up with this level of detail for a whole game thou?

Yeah, I feel like I can, I've been doing this long enough to feel like I can for the most part keep up to this quality. Keep in mind that most attacks aren't as intensive, I just have a habit of liking to make interesting looking idles. Most attacks would still just be about 3-12 frames, with some other exceptions. Plus, it's not like I'm going to be making huge movesets like I was when I wanted to make a straight up fighting game. That's WAAAAAAYYY more work. This is simpler if I just have two attack buttons and a small set of base states to animate, (stand, block, crouch, jump, short dash).

Even when you look at old SNK and capcom animations, they usually have a few super high frame rate anims, but then not so much on other states. If it does become trouble some, I'll dial it down a bit. Believe it or not, the first version of Jeibu's animations I did were an even high framerate that that, but I realized I was stupid for going overboard. Hah.

If I manage to pick up steam along the way, I might snag help with other asset creation. Either way, it's a passion project I am aware is gonna take a while.

Also, regarding what you said about the zooming, I understand what you mean. So then I can set the engine to a high res and then have the camera move in closer for most of the action.

Is there a thing that shows how to script something like this? Because that's gonna be my next step when I get started with this engine is looking at tons of docs and examples to work from so I can learn. I know there is a docs thread here, but like I said, some site a bunch of them are hosted on seems to be MIA.

Thanks a ton though, this is a huge plus for me.

 

[aL BeasTie]

Yeah there's already a zoom script available here - it's easy to implement.

Edit: msmalik posted a demo of the script in action.

I made a demo showing a zoom effect that zooms in but then back out again like street fighter 3rd strike just thought I would share.

http://www.mediafire.com/download/59727v4l9sucn1e/3rd_Strike_Zoom_Effect.rar

Also the Scripts Index and Helpful Links threads have many known scripts and tricks others have shared.

 

[VinVulpis]

Also the Scripts Index and Helpful Links threads have many known scripts and tricks others have shared.

Excellent. Thanks again. My only concern from that point is that I had gotten the okay to possibly sell a game with this if I go through with it, and I'm not gonna tread on someone else's work like that, without at least contacting folks to see if it's okay if I feel the need to use whole pre-written script like that. (with due credit)  At the very least, I'd love to feel things out and see what I can craft with this. I have tons of older assets I already made I can prototype with.

 

[DCurrent]

You'll find this is a very sharing community. I don't want to speak for others here, but I seriously doubt any of them would mind so long as you gave credit.

In a lot of cases, the scripts around here are based directly on a lot of my old work (whether they know it or not), and I don't mind at all.

Welcome to the community, and best of luck on your project!

D

 

[VinVulpis]

I have one one question about this engine before I dive in.

Forgive me if this is a silly question but does this engine (or utility) has a way for turning games into a proper installer if I'm to post the finished projects onto some sort of platform or site (like steam) when ever I get to that point down the road? At least what I've seen so far, resources are just all open and loose in folders. I'm seeing some thing about .pak files and such. Does this turn all sprites and other resources into single game files?

I know that MUGEN has it's specific file types for sprites, animation data, sounds and such.

 

[DCurrent]

There is no OpenBOR specific tool to make it an installed application the way you are most likely thinking, nor are there any plans to make one since the OpenBOR executable is fully self contained. However, certain third parties tools can do this.

I'm seeing some thing about .pak files and such. Does this turn all sprites and other resources into single game files?

Yes. The pack combines all assets into a single file. If OpenBOR is run with only one .pak available, it will immediately default to that pak and begin play. If there are multiple .paks, then a menu will be presented allowing the user to select which .pak they want to play.

Also note that for development purposes, if a data folder is present, any contents in said data folder will override those from the .pak. This allows you to make changes and test them without having to re-pack over and over again.

DC

 

[VinVulpis]

Hello again. So I plan to dive into this engine over the fall finally and I had just a couple of other questions.

One thing I wanted to mention is that some of the links in the "Helpful Links" thread are dead, such as:

GRAPHICS / SPRITES -

Creating a Character
http://www.caskeys.com/arc/games/openbor/wiki/index.php?title=Creating_a_Character

Is there anywhere else I can get good information for getting started? That's my biggest concern, just so I can avoid posting too many questions after this post.

Also, is there any particular tools for OBoR that can let my visually work the character files, such as drawing hitboxes and such, similar to how Fighter Factory works for MUGEN?

I saw some thing about a conversion tool that can create character files for OBoR from MUGEN resources. Would it be doable to make my sprite-sets and hitboxes from a tool like that, or is it buggy?

Alsom I assume it's easy enough since there are zooming scripts to make the camera perform other functions. Basicaly I want something like this:

I'd like the camera to slide toward the direction the player is facing, smoothly. From what I saw with the zooming script, it was done per frame with simple numbers. Is it possible to make math functions that do it smoothly. How I did it there in MUGEN was I made a camera pushing object that slides into place on it's own until a certain distance from the front of the player.

Another thing about the gif I posted here is to ask a little about sprite rendering in the game. To save time on animations, I have MUGEN do some of the effect work on projectiles and such.  Jeibu's projectiles hare helper objects that use the "angledraw" state controller to spin the sprites while the animation plays out (along with a short afterimage) to get the dark matter effect I was looking for.

I do a similar thing with his super effects.

At the very least I see that all objects seem to be handled the same, including projectiles, so making punchable projectiles that bounce off of things shouldn't be too difficult.

Thanks again in advance.

 

[aL BeasTie]

- the dead links are from the wiki which is currently offline. Don't worry that tutorial is outdated and pretty much useless now anyway.  It's meant for the original BOR.  It mainly covered setting up basic attacks and palettes, which you probably understand already.  Here's an updated tuto about palettes.

http://www.chronocrash.com/forum/index.php?topic=60.msg264#msg264

- It's fine to post your questions, just search the forum first because you're likely to find multiple threads discussing the same thing.

- The tool you speak of is in OpenBOR stats, check the documentation for how to enable it.  MatMan just made it to assist him with his own mod, it was never supported.  It was never meant to be a perfect mugen to openbor convertor, it merely rips sprites and sets up the animations in a character text file.  It doesn't name anything properly or  add code for moves,  it simply copies animation and sprite data. 

You can just use Fighter Factory to get all of this anyway.  Also IMO you will get better animations copying manually from fighter factory,  as the convertor seems to add additional frames with short delay instead of changing the delay per frame.  Thou that can be a good thing for some anims, most of the time it's not really necessary.

Here's a post I made previously about ripping from Fighter Factory.

you should read this tutorial about setting up palettes. 
http://www.chronocrash.com/forum/index.php?topic=60.msg264#msg264


If you have mugen chars you want to add, it's easy to dump the axis aligned sprites from fighter factory that will already have the proper palette applied.

1. Open the SFF for the character you want to get.

2. Delete the portrait and icon groups (just save these separately or rip them again later).



3. Delete all the projectiles and non character sprites (if needed these should be ripped on their own)


4.  Delete the extra fall/pain groups, the ones that are centered on waist and head, we wont need those for openbor, they will also mess up our aligned sprites and make the canvas too big.


5. Delete any remaining non character sprites (backgrounds, healthbars etc.)

6. We must edit the palette for openbor.  Double Click the transparency in the palette screen.



Then change the value where it says Alpha Channel to 255 then hit OK


You will have something like this now.


7. Then save them as axis aligned sprites.  use range All, or rip animations one by one. 



Don't forget to save the axis information to a file.  You will use this offset in OpenBOR.


Don't save the changes to the SFF or save it as a copy if needed.

 

[VinVulpis]

Okay, I see, so it won't handle anything related to Hitbox data? I'm just looking for methods that would improve work flow once I dive in. With my animation software, it's just as simple to just make sprites tailored to work for OBoR as it was MUGEN. I'm just thinking about ease of importing my work into the engine and a decent graphical interface for hit-boxes and such.

I suppose I'll look into OBoR Stats and see all of it's functions if anything in particular will help me.

My first goals once I get started it to get the movement, platforming and camera controls working as desired. Then I'll dive into the basics of combat.

I did have one last main concern about the engine, which can probably be done with scripting, but I'm looking for the story mode to open up in a "hub world/stage" with progress of previous runs remembered. (item discovery and characters found/unlocked) The hub world will change a bit over time as things are done. Each "run" is started from that place. I'll worry about it later on down the line, I just wanna be sure it's possible before I go too far. I'll figure things out from there.

Thanks again.

 

[O Ilusionista]

Hey man, welcome to the forum. I am O Ilusionista, long term Mugen coder (I am on the scene since 1999) and a rookie OpenBOR coder. I always forgot to reply this topic, but now I remembered Let me share some thoughts with you:

- About Mugen beeing limited, my answer is "maybe". Depends too much of what you want to do. For example, for VS fights, Mugen beats all competitors with ease (including OpenBOR) in many aspects. All those fighting routines are alread done on Mugen and it handle it very good. OpenBOR can handle it too, but many you will have to it for yourself.

If you need some exemples, here are some: Mutiple colision boxes, friction system with different pyshics for standing and crouching (OpenBOR have none), true HD graphics with gaussian reduction (OpenBOR has only nearest neighbor), just to name a few. Yes, some of those you can remedy with scripting (and the last one would need to edit the source code), but you would need to built it from the scratch - and its not an easy task.

- Mugen and OpenBOR are different animals. Each one has their own pros and cons, depends too much of what you want to do. But there are areas where OpenBOR outshine Mugen - expansion power. With OpenBOR, you have a C based scripting language which let you do amazing things. Mugen has it too, but in Lua and there is NO documentation about it.

- You can talk with the creators of the OpenBOR, while you can't in Mugen (they are gone AGAIN). And you can access the source code of OpenBOR, while you can't in Mugen.

I another words, you will have a hard time making things you would do easily in Mugen but in OpenBOR. But there are a lot of things you can do only in OpenBOR itself, and there are many cool things, like attack proprieties (the engine KNOWS if your attack can burn an entity, and there are reactions if the entity stands, falls, rises and even dead from a burn attack, all coded whitin the engine). The same works for Freeze, Steal and Poison (this is AMAZING in OpenBOR).

Okay, I see, so it won't handle anything related to Hitbox data? I'm just looking for methods that would improve work flow once I dive in. With my animation software, it's just as simple to just make sprites tailored to work for OBoR as it was MUGEN. I'm just thinking about ease of importing my work into the engine and a decent graphical interface for hit-boxes and such.

No, it won't. Because Mugen can have multiple CLSN (collision boxes) for attack and damage, while OpenBOR has just one for each case. Another thing is that you should export your sprites with the proper axis from Fighter Factory (there is an option which exports an image big enough to handle all the positions for your sprite). Mugen uses trimmed sprite, while OpenBOR doesn't, because it trims the images on the fly.

My first goals once I get started it to get the movement, platforming and camera controls working as desired. Then I'll dive into the basics of combat.

I advice you to do the opposite.

I wissh you luck with your ideas, and we are here to help.

 

[Bloodbane]

I did have one last main concern about the engine, which can probably be done with scripting, but I'm looking for the story mode to open up in a "hub world/stage" with progress of previous runs remembered. (item discovery and characters found/unlocked) The hub world will change a bit over time as things are done. Each "run" is started from that place.

It does require script but what's really needed for hub world or map mode is knowledge of setting a map, levels and branches

The most complex mod to show that is Dungeons & Dragons : Rise of Warduke. But if you need small mod to learn how to set that, you can try this:

https://www.mediafire.com/?r7meg1g5hk6kqiv

It's demo to show how to set up map, areas + script to lock/unlock each areas
Actually, it has other stuffs but I'll focus on map stuffs for now

 

[VinVulpis]

No, it won't. Because Mugen can have multiple CLSN (collision boxes) for attack and damage, while OpenBOR has just one for each case.

So attacks like this are not doable?

(I also have that tail whip do different damage and knock-back based on what frame the attack hits the target)

- About Mugen beeing limited, my answer is "maybe". Depends too much of what you want to do.

MUGEN's combat system is great, yeah. Tons of features for that. I've been playing around with MUGEN for a few years on and off. I can make a beat-em up sort of like I would want in it by making the player 2 object make helper enemies to beat up, kinda like how the Rox Howard Clones work, which is how I started prototyping my ideas for this game more recently.

Thing is, it's incapable of doing  anything (continual from run to run) with story, unlockables and saves for progress in the story mode.

What I'm aiming for combat wise is something fighting game-like but simplified. Two attack buttons, jump button, guard button and some simple command inputs. (with some cancel/link combos for a little depth) (Finding out that OpenBoR has a built in status effect system is actually fantastic for the sort of game I want to make, actually)

While I do want to have some sort of verses mode, it's not what I'd like to focus on right now.

The core of what I want is a beat'em-up with simple platforming and a couple of dungeon crawler aspects (each run path being randomized slightly, effecting the worlds(stages) enemies, some platform layouts and item discovery. The save feature is important so that discovered items and characters are remembered from run to run, unlocking more paths as certain things are completed.

I'm willing to work around certain feature losses like friction controls as long as there is some way to control variable knockback, and make it that some enemies increase (or decrease) knock back applied to them so that they are affected differently by some combos.

My first goals once I get started it to get the movement, platforming and camera controls working as desired. Then I'll dive into the basics of combat.

I advice you to do the opposite.

More what I mean here is that the character mobility is part of what I'm basing the combat on. Including mid-air trajectory control. Camera isn't as important, but I feel like I wanna  get that working right before I get into more complex stage design, so that I have layouts that work well with the screen space.

mediafire.com/?r7meg1g5hk6kqiv

It's demo to show how to set up map, areas + script to lock/unlock each areas
Actually, it has other stuffs but I'll focus on map stuffs for now

Thanks a bunch, I'll be taking a look at that soon.

 

[DCurrent]

So attacks like this are not doable?

That's perfectly doable. ANY move is. What O'Ill meant is that in OpenBOR, every entity is allowed one attack and one hit box per animation frame. That means it's easier to do super precise collision detection in Mugen.

Note is it perfectly possible to script your own collision system in OpenBOR, but for beat em' up type games that kind of pixel precision is rarely worth the production time.

(I also have that tail whip do different damage and knock-back based on what frame the attack hits the target)

Not a problem. In some ways, it's actually easier in OpenBOR. Like O'Ill said, OpenBOR attack boxes are typed and each frame has its own. One frame could be a flame attack, the next electricity, the next a normal impact, and so on, with each producing a unique reaction for hits, guard, knockdown, standing up, and KO (all optional).

DC

 

[VinVulpis]

That's perfectly doable. ANY move is. What O'Ill meant is that in OpenBOR, every entity is allowed one attack and one hit box per animation frame. That means it's easier to do super precise collision detection in Mugen.

Note is it perfectly possible to script your own collision system in OpenBOR, but for beat em' up type games that kind of pixel precision is rarely worth the production time.

Well I understand why most beat'em up games don't need that with the Z-axis, it's more about being on the same z-level an having the target within reach. I'm doing something without a z-axis and focusing much more on jumping and aerial combat, so directional, more specific hit/attack boxes are needed. Only having one attack box isn't that big a deal, but for diagonal angled strikes might create an issue or for particular stances on characters/enemies.

I suppose figuring out how to modify the hitbox system would be handy. That's another thing I'll take note of.

I'll try to dive in from this point on and read a bunch and get the basics working soon. I suppose if I'll hit a brick wall later, I'll post about  specific questions on how to do particular things. I realized I spread way too thin with questions in this thread. I think I got enough info to get started.

Thanks everyone.

 

[DCurrent]

No problem. Good luck, and just ask if something confounds you. There's a ton of documentation out there - almost too much. Some information is WAY outdated. Give us a shout if you aren't sure - there may well be a way to do something that is far, far easier than the currently documented method and with no side effects to hack around later.

DC

 

[VinVulpis]

I know it's been a while but life stuff has kinda gotten in the way so I haven't been able to dive too much into the engine just yet, but I at least have tried to do some reading in the meantime. I'm still trying to understand exactly how knockback and stun time works in this engine, at least by default.

What I need is something similar to this example of Jeibu's basic combo:

The first two hits of Jeibu's attack are to do standard, small bits of knockback and stun (but enough to leave Jeibu with positive frames after the second hit for chance of a repeat link up to 3 times)

The third hit of his basic combo, the knee, is supposed to knock the target off their feet, but not into a knockdown. They should recover after stun land as from a normal air-state.

From there, optional follow-ups after the knee for cancels, but the standard is a version of his Neutron Kick that uses the knee for his step forward.  I'm mostly concerned about how to customize the stun and knockback system. To my understanding, this is something that has to be programmed into each player/enemy character's get-hit animations. You don't define the stun time within the attack programming? It's just a matter of calling a certain type of reaction animation which has that information in it? If that's the case, it sort of forces a standardized set of knockback and stun, but that's not exactly a bad thing I suppose, other than the concern of efficiency if I have to define it for each play/enemy. I can design moves to work around a set of these if needed. Is there a limit to how many of these you can create?

 

[Bloodbane]

Is there a limit to how many of these you can create?

No. You can expand attack types limit with maxattacktypes command in models.txt

You don't define the stun time within the attack programming? It's just a matter of calling a certain type of reaction animation which has that information in it?

Hmm... there is a way for which is by using script in character's reaction animation (to control how long the animation will be played) and didhitscript (to send the information). I don't have example for this so that's the rough idea