Time to Move on?

[DCurrent]

Serious topic here about the engine guys - please go over this carefully. You can't complain later if you TL;DR.

Ever since SX left and handed me they keys as "Lead Dev", I have tried to uphold his stance on maintaining backward compatibility at all costs. However, lately I am off the mind that needs to change. However, leader does not mean dictator - so I want to get a solid community consensus before moving forward.

So allow me to state my case, and what dropping backward compatibility really means:

• Bugs are piling up by the day it seems, and many of them are imbedded in archaic code written long before OpenBOR was organized into a cohesive project. Many of them cannot be fixed at all without causing new breaks.
• I have given it my best effort, but I simply cannot do much more to clean up the source code without making compatibility changes. Long requested features like animation properties or timer based ("real") random numbers just can't be added without bloating the engine and surprise, causing more bugs.
• It's not just the source code. The modding commands and script interface are extremely powerful yes; there's literally nothing in the world quite as versatile. But they're also confusing, overlapping, and often contradictory. Many of the older iterations were thrown together without any thought toward the future or ease of use. Just look at the utterly stupid and superfluous dive, the mile long attack or confusing bglayer commands for a few quick examples.
• For almost two years now I've been a one man show. It's clear the old team is gone and not coming back any time soon - if ever. I have an excellent but busy career and am up to my ears in projects. It's only going to get worse as I work toward my CS PHD. I simply cannot kill bugs, clean code, fill requests AND maintain backward compatibility all at the same time. Something has to give.
• Backward compatibility doesn't exist anyway. Rather than upgrading and helping with specific bug reports, authors generally just post a generic "This don't work!" post, pick a version and ignore updates. I understand that - it's a lot easier than waiting around for a fix. But it's not fair for the dev team (me) to be asked for backward compatibility when no one is really using it or willing to help keep up with it.

So what would it mean to drop backward compatibility? Well if adopted as a policy, parts of the engine will be subject to change without regard to making them work with existing or in development projects. It doesn't mean going off willy nilly and changing things on a whim. In fact, one of the facets of the new command design is 100% backward compatibility from that point on. Say we add multiple attack box support. Right now that would mean breaking the old attack command or adding a second one. A redesigned and object oriented attack command won't be that way. New modules use the new parameter to take advantage, old modules (old as in made after the redesign) that don't have it will fall back gracefully and work as they always did. Think of the way level spawn commands work; that's pretty much how everything else will.

It does mean that a lot of our old module catalog will eventually be phased out as the redesign progresses, but again since a lot of authors just version their work anyway does that really matter?

So... let's hear it. I want your permission for design freedom and in turn I'll give you a smaller, faster, more stable OpenBOR (though yes it will come gradually). Will you give it to me?

DC

 

[O Ilusionista]

boss, let me be straight: I see two options.

A)
In Mugen, we have a setting called "mugenversion". Once we put it on the character/stage, the engine treats it like the version it was designed for. If you use Mugen 1.1 (the newest) to play Winmugen (old beta), it will run the content in compability mode, but if you try to run DOS version stuff (very old), it won't runs well. If you don't specify the version, he will treat it as a old version.

So, maybe this could be an option. I know that this would increase the code a bit and would give you more work to put triggers to check the version, but this is a more conservative way to do things.

B) Kill the backward compatibility. There are several things broken and if you will try to fix, you will break more thangs to the spaghetti logic from the legacy code. And some old version are very old...

So, my vote is: If option A isn't possible, go for B. Drop the backward compability.

My only concern about this option is: I think we need to add something to the engine name, like OpenBOR 2, OpenBOR Plus, OpenBOR EX , OpenBOR' or whatever. Something to make it clear for all people that this is a whole new take on the engine, a new level.

 

[DCurrent]

In Mugen, we have a setting called "mugenversion"...

That is unfortunately not really an option. In fact it's half the problem. The engine is so bloated up with duplicated commands and legacy source left in for older modules, I could shave off ~30% of the code base by removing those alone.

Now the good news is, as I mentioned earlier - by designing the new commands with a modular, object style interface they'll be simpler to use and fall back seamlessly as new updates are made. So today I might break everything, but three years from now modules made tomorrow will still be working smoothly on the latest version.

DC

 

[jiam]

My vote is whether
How much time you'd need?

 

[Lichtbringer]

DC if you have to remove the backward compatibility to clean the code from unnecessary stuff that makes the Engine buggy and slower, just do it. 8)

Just Call it Open Bor 2.0 or something like that, maybe some people will complain at the beginning but if it makes the Engine better in the end they will beginn to appreciate it in the long run.  ;D

 

[O Ilusionista]

That is unfortunately not really an option. In fact it's half the problem. The engine is so bloated up with duplicated commands and legacy source left in for older modules, I could shave off ~30% of the code base by removing those alone.

Yeah? So kill the legacy compability. Just remember this:

Just Call it Open Bor 2.0 or something like that

 

[ABK]

Id prefere to work things around if you think youre not comfortable with source code or dont know right now how to fix some bugs, just separate things in sourcecode , like rand using old method and srand using new one, only srand will use timer based method so it wont break anything because it will still use old method for everything else.
It also depends how much compatibility will be lost, what exactly you want to change and how many mods will crash, is it really worth it , IMO engine is quite complete, only real things i miss from it is 32bit png support with its own alpha channels for spriutes and bgs.
I think youre too much concerned about filesize of executable instead of trying to fix things even if fix is really ugly.Filesize of the engine was never a problem, and never will be, we have gigabytes of ram and exe is rougly 2mb, it doesnt really matter if there are 2 almost identical pieces of code, what matters is that it works not that it looks ugly when you look from coder perspective.
Id prefere to not break compatibility, separate things from each other so changing rand in script wont change enemies behaviour.
Adding new attack method with  2 attack boxes is different thing, you use it or dont, you dont have to break old attack method to use new one, just create code for new one completely separated from old one so they wont clash with each other.

 

[ABK]

Well realistically guys, what else do we need, what features are missing? There is a lot of things that are possible to do, i cant think of much new features to add besides netplay and 32bit pngs which will probably never happen.Muyltiple attack and bboxes are also cool but it wouldnt really be something groundbreaking.MAybe jpegs for backgrounds, i dont know, new file formats support like video.BAckground Tiles support would also be cool for platformers but that would require level editor.These are things that i miss from other 2d  game engines.

 

[Goliath]

Collision detection, please.

Not just on attacks, of course. A feature like bbox collision detection.

Wait ... this could be made by code.  :-X

 

[CRxTRDude]

Actually, if it's for the benefit of the community and of the engine, it's time to move to greener patstures. Without restrictions aside, there's lots of things to be done such as images wouldn't be restricted to limited palettes anymore, video cutscenes, music that doesn't need to be converted to other obscure formats and OOP just to name a few can be done (for video and audio though, i recommend OGV and OGG respectively. They're both open source and works fine.

I'm especially excited about OOP especially for the scripting (note i emphasized that because I'm happy with the original commands for chars models and levels), we're not going to be limited to C-based logic anymore for people that have less of an experience than JavaScript or python.

Even from Xash, the community where i come from, they have now ditched the backwards compatibility to half life thing and go full speed on a new direction with better features (i just saw the news recently about that). I'm not really shocked that this happened, this WILL happen eventually, so if it's all for the best, go for it!

But there are conditions for this to happen.

• Name this as a different project, a sort of fork, so that they will not associate the new project from the old ones. Maybe not named as OpenBOR since we came a long way since Senile Team created Beats of Rage, many sites about this came and went and the engine has shown its cracks and age. If we want to be fresh, new documentation, new resources, new everything, we need a new name for this.
• secondly, make the file format not *.txt for the file format, txt is just too generic.
• finally, we need a migration guide so that people who ave very experienced at OpenBOR can be easily sueded to go to the new engine and will not be intimidated.

All in all, I'm fine with change and that is permanent AFAIC. Any comments, violent reaction to what i say?

 

[DCurrent]

...

Sorry friend, I'm talking evolution, not revolution.

images wouldn't be restricted to limited palettes anymore,

We have a different definition of limited. Not even the professionals bother with >64 true colors in a single sprite set. The vaunted Neo-Geo couldn't handle any more than 16, and to this day most sprites never top 32. The illusion of more is through quality artwork and special effects also available in OpenBOR.

By comparison, OpenBOR supports 256 colors per FRAME. High color backgrounds might be worth talking about, but supporting more for sprites is a waste of time.

video cutscenes, music that doesn't need to be converted to other obscure formats and OOP just to name a few can be done (for video and audio though, i recommend OGV and OGG respectively.

OpenBOR already supports OOG and has for years. OGV might be something to look into later assuming the consoles can all run it.

I'm especially excited about OOP especially for the scripting (note i emphasized that because I'm happy with the original commands for chars models and levels), we're not going to be limited to C-based logic anymore for people that have less of an experience than JavaScript or python.

Sorry, but that's not going to happen. I said OOP style, not true OOP. To do that, the engine itself would have to be built with an OOP language - C isn't. Much as I would love to take everything to ground and rebuild the whole thing from scratch in C++, that is nowhere near being in the cards.

What I'm talking about is a gradual rebuild of long standing legacy code - to clean out the junk, fix the issues and make future modding (and by extension building modding tools) easier. After that, we can start look toward filling the fantasy lists.

DC

 

[O Ilusionista]

As for the new version name, hmm.. what´s wrong with you guys?? We are already in OpenBOR version 3, so the next one have to be OpenBOR v.4 and not v.2 again ;D

That is quite simple: People will get more confused if we say "version 4090 has no retro compability" rather if we say, at least, "version 5 has no retro compability" or "OpenBOR X has no retro compability".  Take Windows for example: Microsoft has Windows 8, Windows 8.1 and will jump to Windows 9.

Well realistically guys, what else do we need, what features are missing? There is a lot of things that are possible to do, i cant think of much new features to add besides netplay and 32bit pngs which will probably never happen.Muyltiple attack and bboxes are also cool but it wouldnt really be something groundbreaking.MAybe jpegs for backgrounds, i dont know, new file formats support like video.BAckground Tiles support would also be cool for platformers but that would require level editor.These are things that i miss from other 2d  game engines.

I can give you a list of things to be fixed before anything such as:

- fix weapon model several bugs (weaponloss, guard while in weapon model, etc)
- Continue bug (this is very severe)
- unlock characters bug (even more severe, and its related with the bug above)
- platform that can't be flipped
- Mirror bug
- And many others

Some new things:

- First of all, the ability to use Bicubic Interpolation or Spatial anti-aliasing for scale, because we can only use Nearest Neighbor method, which holds us to make TRUE HD/HR resolution.

- 24bit (not 32bits) PNG support for backgrounds only (for entities is a waste of resource). Remember that 24bit images doesn't have palette (they can, but a 24bit palette weights about 2GB)

- Suport to summon entities in menu, select screen, options and such without that drawsprite hack (there is a way, but nobody remembers how to do it)

- Some video suport, for cutscenes.

- friction system

- Ability to change a Type Player entity on the fly to other type, like NPC or Enemy. This would make VS mode way easier.

- maybe a grid selection system, where you choose to use up and down to change characters, like a normal fighting game, and to be able to choose the palette after choosing the char.

To name a few. About the multiple attackbox, this is useful only if we do versus-like games with big sprites, because for Beat 'em up games uses one attackbox in most cases.

Collision detection, please.
Not just on attacks, of course. A feature like bbox collision detection.
Wait ... this could be made by code.

This is something very useful, but needs to be done in the right way. In Mugen we have it, but this can act as its Achilles Heel sometimes. For example, what do happens when two entities with that type of colision touches each other, with X velocities? The one with bigger velocity wins? ok, and when and entity with X velocity touches a stationary entity? Should it be pushed? In Mugen, the stationary is pushed and this is a NIGHTMARE in many aspects.

 

[O Ilusionista]

OpenBOR already supports OOG

Really? How?

 

[CRxTRDude]

...

Sorry friend, I'm talking evolution, not revolution.

I'm not talking about a revolution, I'm talking about change, as in the need to curb on backwards compatibility, not making a stand against the engine itself.

If you meant what I said about Xash, don't mind that, I'm just stating an example, nothing big though since they have been itching to do that anyway.

I didn't mean that OpenBOR needs total overhaul revamps, just fixing bugs, cleaning code and improving performance and gameplay with the price of breaking backwards compatibility.

Whatever you say is definite, I don't mind  ...

images wouldn't be restricted to limited palettes anymore,

We have a different definition of limited. Not even the professionals bother with >64 true colors in a single sprite set. The vaunted Neo-Geo couldn't handle any more than 16, and to this day most sprites never top 32. The illusion of more is through quality artwork and special effects also available in OpenBOR.

By comparison, OpenBOR supports 256 colors per FRAME. High color backgrounds might be worth talking about, but supporting more for sprites is a waste of time.

Again, I don't mind that as well, although I like what O Illusionista and you said about 24 bit PNGs for backgrounds, that I can do with. In fact, the limited pallette for sprites is still good. Looking at what SNK and Capcom (before they jumped to 3D) did on limited palettes (because of hardware limitations) was and has been an inspiration for me and still amazed that some indies do the same to emulate it (such as Skullgirls).

I'm especially excited about OOP especially for the scripting (note i emphasized that because I'm happy with the original commands for chars models and levels), we're not going to be limited to C-based logic anymore for people that have less of an experience than JavaScript or python.

Sorry, but that's not going to happen. I said OOP style, not true OOP. To do that, the engine itself would have to be built with an OOP language - C isn't. Much as I would love to take everything to ground and rebuild the whole thing from scratch in C++, that is nowhere near being in the cards.

What I'm talking about is a gradual rebuild of long standing legacy code - to clean out the junk, fix the issues and make future modding (and by extension building modding tools) easier. After that, we can start look toward filling the fantasy lists.

DC

Sorry about that, I meant the OOP style that you said in a previous post not true OOP. (I mean, you're just only one lead, it would take another guy to do the interpreter for that.) Good thing you replied (I said any comment and violent reactions to what I said, right?)

I can give you a list of things to be fixed before anything such as:

- fix weapon model several bugs (weaponloss, guard while in weapon model, etc)
- Continue bug (this is very severe)
- unlock characters bug (even more severe, and its related with the bug above)
- platform that can't be flipped
- Mirror bug
- And many others

Don't forget fixing saves on bigger sized levels, especially on elevator levels where there is only a single panel and moving looping background.

Some new things:

- First of all, the ability to use Bicubic Interpolation or Spatial anti-aliasing for scale, because we can only use Nearest Neighbor method, which holds us to make TRUE HD/HR resolution.

- 24bit (not 32bits) PNG support for backgrounds only (for entities is a waste of resource). Remember that 24bit images doesn't have palette (they can, but a 24bit palette weights about 2GB)

- Suport to summon entities in menu, select screen, options and such without that drawsprite hack (there is a way, but nobody remembers how to do it)

- Some video suport, for cutscenes.

- friction system

- Ability to change a Type Player entity on the fly to other type, like NPC or Enemy. This would make VS mode way easier.

- maybe a grid selection system, where you choose to use up and down to change characters, like a normal fighting game, and to be able to choose the palette after choosing the char.

I suggest animated GIFs for the title screens as well. I saw RV2.4 and I think this is something not completely utilized.

The grid selection system is also good to consider as well, especially that you can use the up and down arrow keys now for vertical selection.

We got a lot of ideas, good ones in fact, but unless we still beg for backwards compatibility, none of these "fantasy" things will be possible. We need to be cooperative and help in fixing the program before we do the rest. I support you DC all the way, just make definite that people should be aware and understand the changes and fixes, that's where the migration guide comes in.

Again, sorry about my stupid comments. Had to edit this thing. BTW, the last post, I did it while taking care of my dad in one hand and an iPad on the other, so yeah that was in a hurry.  :-X

 

[Bloodbane]

My vote for this is to move on

The con of this is that, aside of mentioned ones, we must have a storage of various builds compatible with certain mods. It will help if someone asks : "which build I should use to play this mod?"

And I agree with new name for the engine. I still remember new name for engine vote which was conducted years ago in Lavalit and the winner was MASAMUNE. It's an abbreviation but too bad I forgot the long name. Anyone remembers?

 

[Viper Snake]

I'd really like to have sloped platforms and walls. It is strange that OpenBOR doesn't have something so simple already.

 

[CRxTRDude]

My vote for this is to move on

The con of this is that, aside of mentioned ones, we must have a storage of various builds compatible with certain mods. It will help if someone asks : "which build I should use to play this mod?"

That means, we need to update the OpenBOR Wiki. DC included it in the template of what OpenBOR version the module needs. We can lead the people who want to know - about the game and what build works - to the OpenBOR wiki.

I'd really like to have sloped platforms and walls. It is strange that OpenBOR doesn't have something so simple already.

Like in streets of rage, where the player would go down to one side? That would be nice as well.

 

[aL BeasTie]

@DC - I support this and I've suggested it before.  I'm glad you changed your mind, it's definately time to move on.

My only concern about this option is: I think we need to add something to the engine name, like OpenBOR 2, OpenBOR Plus, OpenBOR EX , OpenBOR' or whatever. Something to make it clear for all people that this is a whole new take on the engine, a new level.

lol, when I first started openbor project it was actually called OpenBOR+ ;D  (open meaning opensource and + meaning extra features.)

 

[O Ilusionista]

I dont think we need to vive a whole new name, just a extension like OpenBorX (I like this one or openbor+

 

[erf_beto]

I say move on, and don't look back! This is something I've been meaning to suggest for a long time now, but since I'm not a "real" modder, I never felt entitled to.

A cleaner code, even if we players and modders don't see, will make potential developers less scared to jump in and help carry the torch and DC is burnt out. I feel this is really important, otherwise the system may die real quick, unmotivating potential modders and we'll never see another spritebased beat'em up again, the sky will fall and zombies will eat our grandmothers. Seriously.

As for the name, I think v4 would work. If I recall correctly, it was like that when v3 was announced: several new improvements have had been made and the engine was far evolved from where it started. I believe retrocompatibility was "dropped" for older mods (not sure if it's as grand a change as you're proposing).

But my personal preference is "OpenBor EX Plus Alfa Double Strike X".