I am following the 2D tutorial and having no trouble thanks to the clear writing, getting up to this point:
https://orkframework.com/guide/tutorials/2d-rpg-quickstart/09-first-abilities/

As I am not experienced with this, I've assumed there's a good reason for everything and just try to understand the systems. This step, however, baffles me. As it says at the top, damage is calculated like this:
User.ATK / ((50 + Target.DEF) / 50)

Great, lovely. But to implement this simple formula in the game, we need to create six different nodes? The result is unwieldy, hard to read, and seems like it would be a pain to change, especially if you have nested subcalculations and ever change your mind about their balance.

I recognize my ignorance here, but I don't get this at all. Damages formulas are a huge part an RPG, so what is gained by handling them like this? I presume that there must be a reason that I'd see later in development that makes this better than typing a formula.
  • I mean, most formulas are either a status value or a value with whatever operation you're performing. you could create a template with both of those already placed and all you do is copy-paste as needed.

    relative to all the things you'll be doing to make a game, I think formula's will take up a very small amount of time.
    Miuratale : coming March 29 2025
    Miuratale
  • For what it's worth, you could also create custom formula nodes that handle the formula in script if you'd prefer too, and then in ORK your "formula" just calls into that function that returns the value.
  • I mean, most formulas are either a status value or a value with whatever operation you're performing. you could create a template with both of those already placed and all you do is copy-paste as needed.

    relative to all the things you'll be doing to make a game, I think formula's will take up a very small amount of time.
    So it's less that it has to be that way and more that others don't share my feeling on this? I know it's not the biggest thing in the world, but a decently complex RPG could have hundreds of skills with their own unique formulas. I'd likely spend a fair amount of time creating and rebalancing all of those.
    For what it's worth, you could also create custom formula nodes that handle the formula in script if you'd prefer too, and then in ORK your "formula" just calls into that function that returns the value.
    That functionality would handle my complaint fine, but can you help me find it? I searched for all kinds of things when creating a new node but I haven't found the right type.
  • edited October 7
    So it's less that it has to be that way and more that others don't share my feeling on this? I know it's not the biggest thing in the world, but a decently complex RPG could have hundreds of skills with their own unique formulas. I'd likely spend a fair amount of time creating and rebalancing all of those.
    Part of the issue is "just write the formula" means you also need to write a parser for what you are writing. When it's something straight forward, like User.Attack - Target.Defense, that's not too bad, but what happens when your formula requires Loops, Selected Data, Branching choices (such as if status effects are present, abilities are learned, various combatant aspects), and more?

    That's a lot to pack in, and then also can be pretty unwieldly because now you have multiple keywords to account for, and various math symbols as well. You've also got to now account for different languages and string + system cultures too.

    I'm not saying nodes are perfect, but 'it works' largely because of the complexity that can be achieved and everything that you can look at. You're not just limited to user and target status values in your formulas.

    Something that might help, is to have a generic formula that remains consistent, and then instead move the knobs onto ability variables instead.

    For example, you'd have a formula like damage = Damage = ((((2 * Level / 5 + 2) * AttackStat * AttackPower / DefenseStat) / 50) + 2)
    (Pokemon base damage formula).

    Pulling from the Combatant, we have Level, Attack Stat and Defense Stat. Those are tweaked on the combatant themselves.

    Attack Power is the power of the move, and this is something we'd set on an ability variable.

    Rather than creating a variation of this formula for every move that has a different power, we can instead just use a single formula on all of them, and tweak the value on each ability as necessary.

    Then you only need to make a new formula when said ability is actually different in how it will calculate damage.
    That functionality would handle my complaint fine, but can you help me find it? I searched for all kinds of things when creating a new node but I haven't found the right type.
    You can open up the source Zip files (from purchased version) and just find a formula node, then copy it into a new script file but put your calculations in place of the node you copied. ORK will automatically pick up your new node after compiling (make sure to name it something else). Same concept with Schematic nodes too actually.

    Or another option is that you can create a Static function in a script, and use the Function Value node that can call into that Static function where you do your calculation that returns a number.

    Edit: Also just want to throw it out there that I'm not the dev (that's GiL/ gamingislove), I don't know the actual design intentions, this is just my thoughts on it and I know how much of a pain string parsing can be lol.
    Post edited by Acissathar on
  • One thing to keep in mind with formulas is: They're calculated node by node.
    I.e. the usual mathematical order of operations is not used.

    This might be a bit counterintuitive at first, as you'll need to use sub calculations or split a formula into multiple formulas to achieve the same thing. However, it allows for a lot more flexibility and create very complex formulas, taking all features into account (just like in schematics or battle AIs).
    Since every node does it's own thing, you can e.g. at any point in a formula just set the current value to whatever value you want and exit the formula at that point.

    Ultimately, this was a design decision made 15 years ago in ORK 1 and just has been kept that way ever since ...

    Also, see here for writing custom formula nodes.
    Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found.
    If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
  • edited October 7
    Part of the issue is "just write the formula" means you also need to write a parser for what you are writing. When it's something straight forward, like User.Attack - Target.Defense, that's not too bad, but what happens when your formula requires Loops, Selected Data, Branching choices (such as if status effects are present, abilities are learned, various combatant aspects), and more?
    I'm not unappreciative of this capacity! There are definitely situations where branching nodes would make a skill's function much easier to read. I'm particularly excited about skills that work differently depending on the target's status effects, which would be best handled by branches. My ideal look would probably just be branches leading to different formulas.
    You can open up the source Zip files (from purchased version) and just find a formula node, then copy it into a new script file but put your calculations in place of the node you copied. ORK will automatically pick up your new node after compiling (make sure to name it something else). Same concept with Schematic nodes too actually.

    Or another option is that you can create a Static function in a script, and use the Function Value node that can call into that Static function where you do your calculation that returns a number.
    This may be beyond my pay grade for now, but if this is possible in theory, I am content to return to it at later date when I have the paid version.
    One thing to keep in mind with formulas is: They're calculated node by node.
    I.e. the usual mathematical order of operations is not used.

    This might be a bit counterintuitive at first, as you'll need to use sub calculations or split a formula into multiple formulas to achieve the same thing. However, it allows for a lot more flexibility and create very complex formulas, taking all features into account (just like in schematics or battle AIs).
    Since every node does it's own thing, you can e.g. at any point in a formula just set the current value to whatever value you want and exit the formula at that point.

    Ultimately, this was a design decision made 15 years ago in ORK 1 and just has been kept that way ever since ...

    Also, see here for writing custom formula nodes.
    I will need to test to be sure I understand the documentation, but if the capacity to write custom formulas already exists, that sounds great!

    Thank you both for your assistance. ^-^
    Post edited by SierraLee on
Sign In or Register to comment.