OOP Commands

DCurrent

DCurrent

Site Owner, OpenBOR Project Leader
Staff member
I was just reading through the manual and I see some things that somewhat bug me - much of it I am also guilty for: Multi parameter settings. These should never have been allowed. When I get back to code cleanup, I'm going to take an object oriented approach to commands. Old commands will get an alternate, new commands will always use the new concept. Let's use attack boxes as an example.

Currently, we have attack1 {x} {y} {h} {w} {damage} ... with the in text command being attack1 50 40 30 25

The OOP version will look like this instead:
attack {param} {value}

Then the author puts this into text files:

attack Type 1
attack X 50
attack Y 40
attack H 30
attack W 25
attack Damage 10

Looks more complex right? But look again. Unlike the old style attack box command, the order you use for the OOP style attack box command doesn't matter at all. Switch it, swap it, the engine won't give two spits so long as the required stuff is there. It's also a lot simpler to read when you come back later (no more counting positions to see which parameter is which).

Now think for a moment about adding say, Z depth to your attack box. With the old version, it's the very last parameter, meaning you are forced to put in a dummy value for all the parameters in between. It's inconvenient and leads to potential problems down the road. With OOP style that's no longer the case. You just populate the required parameters like size, add whatever extras you want and forget the rest. So in this case, add attack Z {value} and you're done.

When we later want to expand the command with more features (like an index to allow multiple attack boxes...), no problem. It's just a matter of adding the option and old modules carry right on with a default. No sticking it onto the end of an ever growing and confusing multi-parameter line. No backward compatibility issues.

It will even help if we absolute HAVE to break backward compatibility for some reason. Let's say for we are forced to change Type to Hittype. With the old style you'd have to retro fit modules by hand. But with OOP, do a blanket copy/replace "attack type" with "attack hitype" for all text files in the data folder. Done.

As an added bonus, this will also have the effect of making editors much, MUCH easier to create and so we might see more start to show up. Thoughts?

DC
 
I think it's a brilliant idea!!

At the beginning it will result on longer text files (more lines) but on the long run and with the possibility of add more commands it opens new frontiers!

Ps: what does oop means? On the music area it is "out of print"    :P
But I think is "object oriented parameter"?
 
Die_In_Fire said:
I think it's a brilliant idea!!
Click to expand...

Thank you!

At the beginning it will result on longer text files (more lines) but on the long run and with the possibility of add more commands it opens new frontiers!
Click to expand...

Longer yes, but easier to read/edit, and they won't use any more memory. OpenBOR does not store the text files in any way - it only reads and keeps the specific bits of information it needs from them, which is always the same no matter what style you use.

Ps: what does oop means? On the music area it is "out of print"    :P
But I think is "object oriented parameter"?
Click to expand...

Object Oriented Programming. It's an in vogue (and I'm definitely part of the bandwagon) style of coding that groups functions into class files that are then converted to objects, which are in turn manipulated to do things. It's more of a pain to set up first, but it makes the code much simpler to read, debug, modify and distribute.

Text files have nothing to do with programming of course, but that doesn't mean we can't apply some of the benefits of an OOP way of thinking.

DC
 
hum, sounds a good idea. But let me ask you something:

Let say I have this:

attack Type 1
attack X 50
attack Y 40
attack H 30
attack W 25
attack Damage 10
Click to expand...

And I want to use that code again, but including Z. Would I be allowed to do just:

attack Z 10
Click to expand...
And OpenBOR would get the other paramters from the previous attackbox? Even If I cancel it by using "attack 0"?

If its the case, I say go for it.

As an added bonus, this will also have the effect of making editors much, MUCH easier to create
Click to expand...
I don't see why, since the old style is one line only and easier to read (by the tools).
 
O Ilusionista said:
...

And I want to use that code again, but including Z. Would I be allowed to do just:

attack Z 10
Click to expand...
And OpenBOR would get the other paramters from the previous attackbox? Even If I cancel it by using "attack 0"?

If its the case, I say go for it.
Click to expand...

Honestly, the way I planned it, no. Currently, the engine just reads straight through the text, populating its own variables as it encounters commands. It's quite efficient, but there's no persistence, nor was there meant to be.

To make it remember command settings in the text and reapply them to another instance of the command, I would have to either store the last values in a separate variable (not even close to feasible as we would need dozens and dozens to accomidate), or take assigned values from the last command instance in order. That could have its own set of problems. It's an interesting idea (and I also know why you might like it - being a Mugen guy). I'm just not sure if I can do it without making a mess. Will defiantly give it a try though.

I don't see why, since the old style is one line only and easier to read (by the tools).
Click to expand...

Reading is one thing, writing is another and editing is a nightmare. Especially when you start getting into multiple columns where you don't know how many columns there are going to be. It's doable of course, but more difficult than always knowing this text block = X length no matter what - all you have to do is write over it. It may or may not lead to more editors showing up, but most certainly won't hurt, and is just a side benefit anyway.

DC
 
Reading is one thing, writing is another and editing is a nightmare. Especially when you start getting into multiple columns where you don't know how many columns there are going to be.
Click to expand...

Ah, I get it. Indeed, this new way could be easier to handle.

It's an interesting idea (and I also know why you might like it - being a Mugen guy). I'm just not sure if I can do it without making a mess. Will defiantly give it a try though.
Click to expand...
Then just the use the way you you planned, it will be helpful for sure.
 
The new drawmethod commands were great, so this makes sense to me.  Thou I just use stats for attacks and bbox, it saves a lot of time and you don't really have to worry about misreading anything.

bglayer/fglayer could use this too, because they have so many values, it's easy to mess up, and one line can be bigger than the text file will even display properly.
 
bglayer/fglayer could use this too
Click to expand...
I can't agree more. There are just SO many values that it makes very hard to read. Is this possible, DC?

And a question: I really don't want to piss in your crops and I know that working in new things is way more cool than fixing old stuff, but would be better to fix some old bugs?
 
Pretty much everything will get this treatment long term; I Just used attack boxes because they are a perfect example of line command bloat. It also happens that attack boxes are one of the largest internal objects in OpenBOR, with dozens of parameters. All the various attack supplements like dropv, damage over time, etc. are really just part of the attack box as far as the engine is concerned. See for yourself - here's the structure right out of the engine code that makes up an attack box:

Code: 
typedef struct
{
    int attack_force;
    int attack_coords[6];
    s_staydown staydown;    //Modify victum's stayodwn properties.
    s_axis_f dropv;   //Velocity of target if knocked down.
    int hitsound; // Sound effect to be played when attack hits opponent
    int hitflash; // Custom flash for each animation, model id
    int blockflash; // Custom bflash for each animation, model id
    int blocksound; // Custom sound for when an attack is blocked
    int no_block; // If this is greater than defense block power, make the hit
    int counterattack;
    int no_pain;
    int no_kill; // this attack won't kill target (leave 1 HP)
    int no_flash; // Flag to determine if an attack spawns a flash or not
    int grab;
    int freeze;
    int steal;
    int blast;
    e_direction_adjust force_direction;
    int forcemap;
    int seal;
    u32 freezetime;
    u32 maptime;
    u32 sealtime;
    e_dot_mode dot; //Dot mode.
    int dot_index; //Dot index.
    u32 dot_time; //Dot time to expire.
    int dot_force; //Dot amount per tick.
    int dot_rate; //Dot tick delay.
    e_otg otg; // Over The Ground. Gives ground attacks the ability to hit lying ents.
    int jugglecost; // cost for juggling a falling ent
    int guardcost; // cost for blocking an attack
    int attack_drop; // now be a knock-down factor, how many this attack will knock victim down
    int attack_type;
    int damage_on_landing; // same as throw damage type
    float grab_distance; // suck target near by
    int pause_add; // Flag to determine if an attack adds a pause before updating the animation
    u32 pain_time; // pain invincible time
} s_attack;

IOW, there won't be any reason to have dropv or any other attack supplement because in reality there's really no such thing. Dropv for example does not exist in any form. It's just a loading command that allows you as an author to change an attack value that was always there.

In the new style, there won't be any need for separate commands like that. You want to change the horizontal drop velocity? Include this:

attack velocity_x {value}

Done. Just think how much simpler a lot of things will be once this gets rolling. I really feel stupid for not having thought of it before.



Point of fact, a lot of the engine's commands (level spawns in particular) already use this style to a degree - and they are much easier to deal with on all fronts because of it.

PS: Once I get this going, I will require the style on all new commands going forward. Also, support will immediately be dropped for old style commands already in place. This means that they will still work as they did, but won't be given support for any new additions, and all how to questions will be answered with "don't use that anymore".

Honestly, I'd remove the old style commands outright to cut down engine bloat if I could get away with it - but that would be a huge backward compatibility break.

DC
 
O Ilusionista said:
And a question: I really don't want to piss in your crops and I know that working in new things is way more cool than fixing old stuff, but would be better to fix some old bugs?
Click to expand...

Yes, and I plan to fix as I go. The only reason certain bugs go un-fixed is because they are simply beyond my current resources to do anything about, so I do what I can do in the meantime. There is also a matter of cleaning up the code, which is necessary because several bugs are beyond anyone until some spaghetti gets unraveled. Think of it as organizing the toolbox before giving your car a tuneup.

DC
 
In the new style, there won't be any need for separate commands like that. You want to change the horizontal drop velocity? Include this:

attack velocity_x {value}
Click to expand...
I would love you if this works not only in falls (like dropv) but in non-knockdown attacks :)
 
O Ilusionista said:
I would love you if this works not only in falls (like dropv) but in non-knockdown attacks :)
Click to expand...

I'll have to add that as a new feature. There's no default friction system in OpenBOR, so if you "push" something, it's going to go forever until a new velocity value is applied.

DC
 
Well, as it stands now the grapple/throw system is seriously outdated. in most cases, the advice given is to bypass THROW entirely. Use GRABBACKWARD and a GRAB/THROW SCRIPT that as of now, still has innumerable "How do I use this?" posts here in the forum. If that doesn't scream overcomplicated workaround, i'd be hard pressed to find out what does. This is not to say that I believe it to be an easy or simple undertaking in the least. I just believe that the effort put in would be reflected in an almost immediate payout as far as overall mod quality.
The more things that can be added WITHIN REASON to the out of the box package, the more approachable the engine becomes. There's also an element of variety to consider. Not everyone here comes on with the intent to make beat em ups. Bloodbane and Pierwolf have made side scrolling platformer action shooters, and NickyP even made a tower defense and top down zelda style mod. Granted, the "you can just do it with script" argument is definitely valid, but when there is a thread here whose sole purpose is trying to figure out how to use script to simply make ducking and attacking function properly... How much is too much?
Also how many people have downloaded CRIME BUSTER simply to grab the initial script for throwing? It's in everything now. How long should something be an unofficial official standard before it or something similar is inducted into the hall of new basic functions?
Again, text has no tonality, so I'd like to reiterate that my intent is not at all to come off as rude, finger pointy, or ungrateful for the colossal amount of work that has already gone into this engine. It's just food for thought. Besides, when your game crashes over a normal code mistake at least you can look it up in the log. when it crashes due to script mistake, 8 out of 10, you get nothing.
   
 
I have answered this question in painstaking detail on several occasions, and am not inclined to do so again. As you say, there's no tone in text, so don't think I'm landing on you. But I'm not going to retype at length all over for the 10th plus time. Requests are case by case. Some we can/will grant. Others, grappling in particular are absolutely not going to happen.

DC
 
amm... will this can function with the menu options too? like hide parameters to a more arcade feel or reorganize them...

I mean maybe is just a cosmetical thing but it feels odd when you open a game/module appears:

Press start
---then---
game start
option
how to play
hall of fame
quit
---in press start---
new game
load game
---in new game---
mode a
mode b....

in my very personal opinion if the oop can be applied on those parameters the games can have a more professional look.

press start
--the main menu--
game start
load game
option
how to play
quit
----hall of fame just play after the intro secuence--

or press start
-straight to default game mode-
no visible options

i know not necessary nor essential
 
When I said I want to eventually make ALL existing commands OOP style, that's what I meant. So yes, any existing commands will ultimately receive this treatment.

DC
 
If wishes were horses i guess. :/
Hakuna Matata. Either way, I'm still exited to see how this all comes out. Though I'm pretty sure it will be a while.
 
You must log in or register to reply here.
Back
Top Bottom