Things that make an OpenBOR game appealing enough

[Mr.Q!]

Well, I am not asking, I am writing this in order to help people put their ideas in order on how I tend to make my games at least, and also others can complement this with their own. This also tells a lot about me and why I don't tend to give my opinion on others' work, because at the end of the day, it's just a matter of tastes...I think?.

1st of all, I might say that the main thing about making a mod, at least for myself, is actually a mixture of: having fun and learn stuff in the process + getting satisfied enough with the final result knowing I did my true best towards my goals with it that will make me go back to play it after finishing it.

I an mod making process, the order I try to do things is:

1. Making a short stage/training stage.
2. Making a functional playable character.
3. Making an enemy (just one, no need to make another for now).
4. Making the rest of the playable characters, and doing adjustments to the enemy I created (pain, fall & death animations)
5. Making one boss so I can add special pain, fall and death animations if any.
6. Making the game items & obstacles.
7. Making all enemies and bosses.
8. Making all stages.
9. Making transitions and cutscenes/ending.

For me, going through this basic order of things makes revisiting entities for adjustments minimal, also the dev process is converted on a lineal walkthrough knowing everything that has been done is complete, even if this means almost no demo versions for the community due to leaving the stages dev for the last.

Some insight about the dev process:

• Making a short stage/training stage: I find pretty usefull having a square shaped box stage with custom walls so it can tell me about my combos structure, bugs with scripted slams & throws, testing pain fall and death animations on enemies and bosses, and overall mechanics.

• Making a functional playable character: 1st I try making his default moveset & normal FFight/SOR type chain using the default attack button, then I try making his specials, super arts and whatever fancy thing you want to add, taking care of also using different attack(#)s so I can set up different specific death(#)s on enemies and bosses. Some people sometimes don't like the fact that playable characters in my games having a hundred moves and combos to learn haha but hey, to each his/her own and the more the better. At the end of the day, it's you who's pressing dem buttons, right? So the more options a player has to play the game, the better, I think. Of course, paying attention to properly adjusted offsets so the animations look ok is a must. Also, adjusting proper hitpause on all attacks should be done in order to feel the hits when they connect and not feeling like you are hitting air. I would also recommend having different hitfx's for punches and kicks, and their strenghts as well, because having the engine to distortion the used hitfx according to the damage it does is just plain wrong. It's pretty useful to set all moves use the same offset, it would make the character dev process go faster.

• Making an enemy (just one, no need to make another for now): This will help you adjusting different dropv values for proper juggling, setting up the slams & throws if any, interactions between obstacles when done so you can spawn them in the training room, custom pain & death animations according the attacks from playable characters, etc.

• Making the rest of the playable characters, and doing adjustments to the enemy I created (pain, fall & death animations): After making the 1st playable, making all others seem so easy and quick to do, it's like each character gives you more and more experience to deal with new stuff flike custom slams or new special moves, faster than before. In my last games, I use different attack(#)s to set up spectacular bosses death animations depending on who defeats him/her and using a special move or super art, just as a way to make things look better and different, to have that satisfactory feeling after a boss defeat. I think it's important, makes you game different, more better built, and it also gives it more replay value. This means you will have many many attack(#) at the end of the process, so I also keep track of those in a notepad, because it's pretty easy to forget about them, and it will be useful for the next step in development.

• Making one boss so I can add special pain, fall and death animations if any: Time to test those custom death animations and giving them a cool attack pattern, finding a balance between cheapness and vulnerable spots here and there.

• Making the game items & obstacles: Pretty self explanatory. A cool twist would be making some obstacles having platform values so you can try some moves above them with enemies.

• Making all enemies and bosses: Just like the playable characters, but even quicker. Setting up specific death animations is so fun actually, you can have almost all enemies behaving different according the attack they receive, makes the game more unique and 'alive' due to the amount of detail give to everything. Also, using a universal offset for all of them helps on making the moves faster. You can make different enemy categories and just making slight adjustments to their bboxes as well. remember to set different AI movement so they approach the players in cool ways. You can set up riseattacks that don't have to hit players at all, you can just make them to jump forward without any bbox to avoid getting hit by your meaty attacks, and in the same way, they can have attacks that are just about movement and placement so they don't get grouped easily by players trying to take them all with a single attack chain.

• Making all stages: In my early dev years, I used to try replicating other games stages exaclty as they are and call it a day. Now I can see things different and having npc's, weather elements, trees, birds, etc, eveyrthing that makes the stage feel more a real place is always welcome. You can even have some interactions with the stage elements and make some funny scenarios, or even easter eggs.

• Making transitions and cutscenes/ending: You can even have no cutscenes in the game and just cool stage transitions to have an arcade feeling in the game. Sometimes i had so much stress making cool cutscenes and then when I watch gameplays from others they just skip through them, it's kinda depressing haha. Sometimes you just have to make them, it depends on the game I think. In my UDD project, I wanted to have the most rich DDragon game in terms of content that will ever exist, that was the goal, at least, but in my current one, Fight Forever, almost the entire game will be just about gameplay and no cutscenes until the final part. Stages intro are also cool for telling a story of the stage you are going to.

I am sharing some long a$$ videos from my latest complete project, Ultimate Double Dragon. Please try watching these and pay attention to details, not much to the gameplay itself. You can see some cool stuff going on the stages, and learn a lot from stuff like:

Stage transitions
Stage intros
Enemy behaviour
Different attack strenghts
Specific dropv values for enemies and players falling animations
SFX's
Graphics coherence
Movesets from enemies
Enemy reaction towards players
Custom antigravity values (slightly slower gameplay than usual)
Universal music soundfonts for coherent feeling
No reusing SFX from other projects / universal good quality for SFX's

These points I made are also something that make me almost not watching others project, because most of these things are the stuff that gives a project the most important thing for me when I make them: Stuff that I trully and honestly like despite being done by me (sounds weird but it isn't) and also replay value. Most of the current projects don't pay much attention to all of these poinst and seem like clone projects, which might not be something really bad, but hey, we all could do better, yes. I don't tend to criticize other games, but I do take a look at these things, and sadly, not many people pay attention to these.

You know, you can have some transitions between the title screen and the character select screen, without the use of script, and already have a feeling like a cool commercial game. That's also one of my goals, and also people outside the scene tends to look at.

My current project, Fight Forever, doesn't have its name just because it's kinda catchy. If things go alright with it, it could be the most fun game to play overall due to its replay value & 'fast fun' factor.

Would be good to read others' takes on these points and what makes a mod appealing enough for you to try it.

 

[O Ilusionista]

I agree with all the points, it's basically my way of working too.

The big advantage of working on just one character and perfecting it is that it serves as a basis for all the others. So it needs to have all the animations that you're going to use in the game, such as pains, falls, etc. It's much easier to do it this way than having to change it later.

I would add two points that I use a lot:

1- PLANNING. Try to plan everything that your project will have.

Write down somewhere everything you're thinking of adding and make a list to compare. I know that a lot of people don't like Excel, but I use it to create a table where I control everything that each player or enemy will have, such as health status, speed, animations, etc.

This gives you a macro view of your project, which saves me a lot of time.


2- Before adding something to your game, ask yourself the question: WHY.

Why should I add this to the game? What new does it bring? How different is this from something similar that I already have in my project?

For example, you have a healing item and want to add a new item. What's the difference between the new item and the old item? If you're going to add a new healing item, make it heal a different amount than the previous one, whether it's HP or MP (you can do both via script). And make sure they're visually different enough for the user to notice - putting a hamburger and a can of soda is a good idea, but putting two cans of soda that are practically the same is not).

And this becomes especially dangerous when it comes to, in that order, bosses and playable characters. Common minions might look more similar to each other, but the rest don't.

A big mistake is having enemies and players that sound like skins of each other - this is something that, to me, lowers the overall quality of a game. If you want to make a skin, make an alternative mode within the character itself, like a different palette. It's also a good idea to make certain attacks only available on certain palettes (something I do in my games), so that the player knows that if they encounter an enemy with a new color, there's something new about them, even if it's just more HP.


(the lady in greyscale isn't just a palette - she is touhger and have more HP than the other versions)

Are you going to add a new boss? Great, but what does he do differently from the previous ones? Vary his speed, HP, attacks, AIMOVE. Try to create new challenges for the players - there's no point in having several bosses if they all just approach you and perform an attack that always knocks you down.

And this gets even worse when we're talking about playable characters. There's no point in having dozens of playable characters if half of them act as skins for each other.

An example: let's say you have two characters who manipulate fire. Why would I choose one over the other? How do they manipulate fire in different ways? If they both use a long-range projectile that sets the enemy on fire when it hits, what's the point in having two separate characters? It's better to make a skin, an alternative mode. You need to vary them, and there are several ways to do this - one may have a long-range attack that hits only one enemy, while the other has a short-range attack that hits multiple enemies at once.

And be careful with the usability of each character.

If you have a character that is super strong, with high resistance and you have a second one that is the same but can fly, you have a problem. Except perhaps for a personal challenge, why would someone choose the one that doesn't fly, if they are both the same thing?

QUALITY > QUANTITY.

 

[Mr.Q!]

When I was making Ultimate Double Dragon, I had a short talk with the author of the Street Fighter X Mega Man homebrew game, which was endorsed by Capcom in some way, they had the homebrew game on their website for download at least, and that's not something small, it's kinda big actually. I told him I had plans to make an OpenBOR game about Final Fight, but not just a common project, more like an special and ambitious overhaul of the game, but as soon as he read the word OpenBOR, he said, and I quote:

BOR mods are not well-liked in the industry I think. Game-wise BOR tends to be unresponsive and feels bad as compared to something build from scratch. I remembered the enemy behavior is very rigid and the feedback response on the games are not as good as compared to others beat em up created from scratch. The engine might have evolved now, the last time I tried was years ago.

You can see that the overall opinion about the engine is that it's bad, but people think it's about the engine itself, and which is obviously not the case. No one can stop people trying their projects, make a couple of characters and 10 clone enemies and call it a day, but quality projects get drowned by these things.

Gameplay and the engine capabilities are two separated things. Even myself after trying my best with my projects feel like I don't want to see them anymore as soon as I finish them due to all the months/years of work invested, I have to take some days off until I give a try as a legit game from someone else and pretend I don't know what happens when, despite making a project which was ultimately created for my enjoyment on 1st place.

I am very lucky that my decisions in my games are well liked by others, and I always try to stick to my guns instead of getting overwhelmed by hundreds of suggestions, that's also a good point to take care of, but with years of experience, you learn to listen only to the good advices, and having a balance in gameplay between advanced players and button mashers.

 

[Mr.Q!]

2- Before adding something to your game, ask yourself the question: WHY.

Why should I add this to the game? What new does it bring? How different is this from something similar that I already have in my project?

LMAO yeah, this.
Why adding playable characters that behave the same? I am planning having as much playables as I can, it's a risk at some point but if you have decent planning you should be OK on the long run. As of now, I think I have enough experience that I could give the most amazing moveset even to an empty shoe.

Also there are minimal things that can put people off in terms of gameplay (specially myself) when I see small 8bit characters in big scren resolutions and having attacks that send them flying from one corner to the other. There are good examples out there for making these kind of games, take a good look at any NES Nekketsu game and their physics, the 'dropv' values, etc.

Some stuff that also gets pretty annoying is giving characters some voice lines in their moves that get them to be annoying after hearing it hundreds of times, for example, bad choice of voice fx's in several Street Fighter characters when SFIV voice samples are used and players spam said moves. Talking parrots during fight sequences are always tedious.

 

[Kratus]

I agree with almost everything posted, but I think that some things may vary depending on the project's type or the author's methods that fits better for each one.
For example, some steps may change between a remake of an already existing title, in which you already have all the concept/assets defined, or a game created totally from scratch.

However, some things I understand that must be a default for almost every project.

1) Plan your game, like @O Ilusionista said very well. In addition, I agree with him that having an Excel spreadsheet that contains many details about the game is essential not to get lost during the production, mainly in long term projects.
Additionally, keep notes of every feedback you think it's important and define every step based on a priority scale (DO NOT lose your mind in low priority tasks).

2) Start creating at least one complete version of the playable/enemy/boss character, and one full level, everything based on the concept you are planning.
In my case I prefer a full level instead of a training mode. I believe that this environment is closer to what usually the game will be, plus can act as a laboratory to make experiments, test everything you planned and define the main game concept. Believe me, you will not want to make big changes on the game patterns after having more than 70% of the project finished.

3) Always try to create the content in a "batch" process, producing all the same type of content at once (i.e. all enemies, all levels, all items, all obstacles, etc).
In this point I totally agree with @Mr.Q! It will speed up the production a lot because after a certain point the repetition will train your mind to always work better/faster, plus you will not have to think too much when making important decisions.

4) Let the aesthetic improvements, cutscenes, menus, translation, etc always to the end.
Another agreement with @Mr.Q! here. I saw the death of countless projects where the authors put all the initial energy and a lot of time to aesthetic things first or created all the history cutscenes without even having the core of the game mechanic defined/tested/applied, ending in a bad gameplay and gradually losing people's attention.

5) And last, try to always use the proper tools, preferentially professional ones.
Just my two cents, I think it affects the project quality/speed too. Try to avoid Windows notepad to code or paint to edit images, the Notepad++ and Gimp are a better start point.
In addition, I always recommend the combo GitHub Desktop + Visual Studio Code, where you can see/rollback each change, make detailed searches or apply changes in multiple files at once with a high accuracy, plus you will always have a cloud backup in each commit.

 

[Smart Kitty]

Very wise advices, I had one of the hundreds of projects that gets cancelled due to bad management or planning in general. In my case was mostly due to irl bad stuff that happened those days. But well some of the experiences gives some knowledge, at least if is just like *the things that you should not do xD*

Thanks for the advices, are really appreciated by my part

 

[O Ilusionista]

Here are a few additional points I’d like to add. Once again, these aren’t rules - just practical tips.

• Think about the flow of your combat, especially at the level scale.

Levels can vary in length, but the player should never feel like things are dragging on. Time is money.


A bad example of this is Power Rangers: The Movie on the Mega Drive.

In the video below, at 2:30, the first fight begins in the very first section of the level. You’re forced to face 10 enemies right away, which is completely unnecessary. It’s so excessive that the player almost runs out of time.

So how do you avoid this?


Early levels should be easier, with fewer enemies and a clear sense of progression. As the player advances through the level, you can gradually increase the number of enemies. Ideally, you should also vary enemy types between encounters, introducing certain enemies only after the player has dealt with a set number of foes. Streets of Rage 2 is a great example of this approach.

• Be careful with mechanics.

One mistake that really bothers me is when a game introduces a mechanic and, instead of letting the player choose when to use it, forces them to rely on it constantly (excluding basic actions like jumping).

A classic example is dodging. If dodging is an optional tool the player can use when they want, that’s fine. But if your game requires the player to dodge all the time - as if it were a roguelike - then something is probably wrong with the design of your beat em up.


Finally, a personal tip:

• Learn to distinguish between project errors and engine errors.

Like any engine, this one has its own bugs, and the developers are usually very helpful when it comes to fixing them - just make sure to report issues clearly on GitHub.
That said, before blaming the engine, take a close look at your own work. Computers only return what you give them. If the input is wrong, the output will be wrong too.

If you’ve double-checked everything and the problem persists, post a question on the forum and the community will do its best to help.

However, avoid blaming the engine for mistakes that are actually your own. I clearly remember users who, even after multiple attempts to help them - and after ignoring all the advice given - kept insisting the engine was at fault. Some even went as far as adopting hostile attitudes toward the community, insulting the team behind their backs and inventing conspiracy theories.

This kind of behavior gains you nothing - quite the opposite. Aside from a few very patient people, most experienced users will simply stop engaging. Not because they’re unkind, but because time is money. If someone doesn’t want to be helped, you can’t help them.

The fable of The Boy Who Cried Wolf explains this perfectly.

PS: After translating this text with Google Translate, I went through chatGPT only to correct errors and improve the flow, as I am not fluent in the language. But everything here was written by me.

 

[masterderico]

I use mic to not forget my ideas when my inspiration born. The rest i use ms word for details!

 

[NoxCalderin]

Well, I am not asking, I am writing this in order to help people put their ideas in order on how I tend to make my games at least, and also others can complement this with their own. This also tells a lot about me and why I don't tend to give my opinion on others' work, because at the end of the day, it's just a matter of tastes...I think?.

1st of all, I might say that the main thing about making a mod, at least for myself, is actually a mixture of: having fun and learn stuff in the process + getting satisfied enough with the final result knowing I did my true best towards my goals with it that will make me go back to play it after finishing it.

I an mod making process, the order I try to do things is:

1. Making a short stage/training stage.
2. Making a functional playable character.
3. Making an enemy (just one, no need to make another for now).
4. Making the rest of the playable characters, and doing adjustments to the enemy I created (pain, fall & death animations)
5. Making one boss so I can add special pain, fall and death animations if any.
6. Making the game items & obstacles.
7. Making all enemies and bosses.
8. Making all stages.
9. Making transitions and cutscenes/ending.

For me, going through this basic order of things makes revisiting entities for adjustments minimal, also the dev process is converted on a lineal walkthrough knowing everything that has been done is complete, even if this means almost no demo versions for the community due to leaving the stages dev for the last.

Some insight about the dev process:

• Making a short stage/training stage: I find pretty usefull having a square shaped box stage with custom walls so it can tell me about my combos structure, bugs with scripted slams & throws, testing pain fall and death animations on enemies and bosses, and overall mechanics.

• Making a functional playable character: 1st I try making his default moveset & normal FFight/SOR type chain using the default attack button, then I try making his specials, super arts and whatever fancy thing you want to add, taking care of also using different attack(#)s so I can set up different specific death(#)s on enemies and bosses. Some people sometimes don't like the fact that playable characters in my games having a hundred moves and combos to learn haha but hey, to each his/her own and the more the better. At the end of the day, it's you who's pressing dem buttons, right? So the more options a player has to play the game, the better, I think. Of course, paying attention to properly adjusted offsets so the animations look ok is a must. Also, adjusting proper hitpause on all attacks should be done in order to feel the hits when they connect and not feeling like you are hitting air. I would also recommend having different hitfx's for punches and kicks, and their strenghts as well, because having the engine to distortion the used hitfx according to the damage it does is just plain wrong. It's pretty useful to set all moves use the same offset, it would make the character dev process go faster.

• Making an enemy (just one, no need to make another for now): This will help you adjusting different dropv values for proper juggling, setting up the slams & throws if any, interactions between obstacles when done so you can spawn them in the training room, custom pain & death animations according the attacks from playable characters, etc.

• Making the rest of the playable characters, and doing adjustments to the enemy I created (pain, fall & death animations): After making the 1st playable, making all others seem so easy and quick to do, it's like each character gives you more and more experience to deal with new stuff flike custom slams or new special moves, faster than before. In my last games, I use different attack(#)s to set up spectacular bosses death animations depending on who defeats him/her and using a special move or super art, just as a way to make things look better and different, to have that satisfactory feeling after a boss defeat. I think it's important, makes you game different, more better built, and it also gives it more replay value. This means you will have many many attack(#) at the end of the process, so I also keep track of those in a notepad, because it's pretty easy to forget about them, and it will be useful for the next step in development.

• Making one boss so I can add special pain, fall and death animations if any: Time to test those custom death animations and giving them a cool attack pattern, finding a balance between cheapness and vulnerable spots here and there.

• Making the game items & obstacles: Pretty self explanatory. A cool twist would be making some obstacles having platform values so you can try some moves above them with enemies.

• Making all enemies and bosses: Just like the playable characters, but even quicker. Setting up specific death animations is so fun actually, you can have almost all enemies behaving different according the attack they receive, makes the game more unique and 'alive' due to the amount of detail give to everything. Also, using a universal offset for all of them helps on making the moves faster. You can make different enemy categories and just making slight adjustments to their bboxes as well. remember to set different AI movement so they approach the players in cool ways. You can set up riseattacks that don't have to hit players at all, you can just make them to jump forward without any bbox to avoid getting hit by your meaty attacks, and in the same way, they can have attacks that are just about movement and placement so they don't get grouped easily by players trying to take them all with a single attack chain.

• Making all stages: In my early dev years, I used to try replicating other games stages exaclty as they are and call it a day. Now I can see things different and having npc's, weather elements, trees, birds, etc, eveyrthing that makes the stage feel more a real place is always welcome. You can even have some interactions with the stage elements and make some funny scenarios, or even easter eggs.

• Making transitions and cutscenes/ending: You can even have no cutscenes in the game and just cool stage transitions to have an arcade feeling in the game. Sometimes i had so much stress making cool cutscenes and then when I watch gameplays from others they just skip through them, it's kinda depressing haha. Sometimes you just have to make them, it depends on the game I think. In my UDD project, I wanted to have the most rich DDragon game in terms of content that will ever exist, that was the goal, at least, but in my current one, Fight Forever, almost the entire game will be just about gameplay and no cutscenes until the final part. Stages intro are also cool for telling a story of the stage you are going to.

I am sharing some long a$$ videos from my latest complete project, Ultimate Double Dragon. Please try watching these and pay attention to details, not much to the gameplay itself. You can see some cool stuff going on the stages, and learn a lot from stuff like:

Stage transitions
Stage intros
Enemy behaviour
Different attack strenghts
Specific dropv values for enemies and players falling animations
SFX's
Graphics coherence
Movesets from enemies
Enemy reaction towards players
Custom antigravity values (slightly slower gameplay than usual)
Universal music soundfonts for coherent feeling
No reusing SFX from other projects / universal good quality for SFX's

These points I made are also something that make me almost not watching others project, because most of these things are the stuff that gives a project the most important thing for me when I make them: Stuff that I trully and honestly like despite being done by me (sounds weird but it isn't) and also replay value. Most of the current projects don't pay much attention to all of these poinst and seem like clone projects, which might not be something really bad, but hey, we all could do better, yes. I don't tend to criticize other games, but I do take a look at these things, and sadly, not many people pay attention to these.

You know, you can have some transitions between the title screen and the character select screen, without the use of script, and already have a feeling like a cool commercial game. That's also one of my goals, and also people outside the scene tends to look at.

My current project, Fight Forever, doesn't have its name just because it's kinda catchy. If things go alright with it, it could be the most fun game to play overall due to its replay value & 'fast fun' factor.
Would be good to read others' takes on these points and what makes a mod appealing enough for you to try it.

Good breakdown of your workflow. Focusing on one solid character/enemy first really does make everything else smoother later on. A lot of what you mention comes down to feel and replay value, which is easy to overlook but makes a big difference in the end.