Nested Calculations

TheAlchemyst

Hey yall,

So I am working on planning my modifiers. I've got a Team composed of Heroes. Each Hero gains Powers (special abilities) and XP (leveling up). Each Hero can also be assigned Gear which improves their individual stats. There are also Devices which affect the whole Team. Some Powers affect only an individual while others advance the whole team.

Looking at a single stat, [Damage], in the interest of efficient calculation, should I nest the calculations between different variables, or have them all laid out in a single equation?

Nested:

• [HeroDamage] = [BaseDamage] x [XP] x [HeroModDamage] x [TeamModDamage]
• [HeroModDamage] = [HeroPowerDamage] + [GearDamage]
• [TeamModDamage] = [TeamPowerDamage] + [DeviceDamage]

Single Equation:
- [HeroDamage] = [BaseDamage] x [XP] x ([HeroPowerDamage] + [GearDamage]) x ([TeamPowerDamage] + [DeviceDamage])

pokapola

Doing the nested equation will save you some time whenever you feel like altering or modifying the overall equation. I think that is the only advantage.

tatiang

@pokapola said:
But I have read so many times in this forum that if you are doing a lot of calculations and saving the results, it is better to use Tables as it they are more reliable than Attributes (someone correct me if I'm wrong).

@pokapola Reliable is not really the right word. Attributes can be a big hassle when compared with tables. To save ten attributes, you need ten Save Attribute behaviors and ten Load Attribute behaviors. And then you need to make sure that every key value matches between Save and Load behaviors. And then you need to figure out where to put the Load Attribute behaviors (hint: at the top of an actor's rule list outside of any rules and on a title or menu screen is best). Hassle. With a table, you can have ten or ten thousand "attributes" and save them all with a single Save Table behavior. And table data auto-loads at runtime so there's no need for (and it doesn't exist) a Load Table behavior.

Tables also make for some really powerful logic that either can't be done with attributes or that would take forever to code with attributes. If you wanted to have a quiz game with 100 questions, you could use a single scene and put the question, answers, correct answer, and image name in each row of a table and have a rule that picks a random number for the row of the table and populates a bunch of actors based on that row number. Then when you change the row number again to pick the next question, those same actors seamlessly grab that data and voila!

jonmulcahy

I've always used single equations, some of them get very complicated, but for me it always made sense.

TheAlchemyst

Well as an excel geek I prefer nesting equations as well, I was just concerned that having it pull from so many resources may bog down the game speed.

To add to this, I've seen some people using Attributes for stats, other people are rewriting Table entries. I would prefer to use Attributes since I'm averse to trusting a Table to be rewritten correctly all the time, but is there a speed advantage to either approach? There's going to be a LOT of calculations going on and changing variables all the time.

pokapola

I am not sure if there's a speed advantage of using Attributes instead of Tables. But I have read so many times in this forum that if you are doing a lot of calculations and saving the results, it is better to use Tables as it they are more reliable than Attributes (someone correct me if I'm wrong).

I have one game which does a lot of calculations, and I used Tables, it worked well.

tatiang

I always find it interesting when people are averse to using tables. Usually it's because they are "too complicated" or in your case not reliable. Tables are the foundation of GameSalad for me. I would never build an app without them. They are fast, reliable, flexible, and my go to solution for almost everything. In this case, I don't see a need for tables. I would keep everything in a single equation as long as the expression doesn't get too unwieldy (that can happen quickly, especially with table functions; unwieldy to edit, that is). Otherwise, multiple equations can keep things a bit clearer and allow for more pinpointed Note behaviors instead of just a single one to explain everything. But as far as speed and reliability are concerned, you're really fine with any method: single equation or multiple; tables or not.

AlchimiaStudios

@tatiang said:
I always find it interesting when people are averse to using tables. Usually it's because they are "too complicated" or in your case not reliable. Tables are the foundation of GameSalad for me. I would never build an app without them. They are fast, reliable, flexible, and my go to solution for almost everything. In this case, I don't see a need for tables. I would keep everything in a single equation as long as the expression doesn't get too unwieldy (that can happen quickly, especially with table functions; unwieldy to edit, that is). Otherwise, multiple equations can keep things a bit clearer and allow for more pinpointed Note behaviors instead of just a single one to explain everything. But as far as speed and reliability are concerned, you're really fine with any method: single equation or multiple; tables or not.

+1 I can't imagine doing a save system without them now among many many other things.

pokapola

@Tatiang I have always hated the Save and Load Attributes, LOL. I always have my equation involving Tables written down first on a piece of paper before putting in GS, it helps a lot.

I have always wondered, is it possible to change Attributes in Loop behaviour, for example : While AnotherAttributes <10, Change Attributes : Whatever.."AnotherAttributes" while incrementing the "AnotherAttributes"?

TheAlchemyst

OK great, thanks yall! I hadn't even started thinking about Save/Load yet. I definitely want the game to save the entire game state easily so that definitely answers the attribute vs table question!

tatiang

@pokapola Do you mind starting a new thread for your question about changing attributes in a loop? I'd hate to hijack this thread. Thanks.

pokapola

I'll open a new thread, sorry didn't mean to hijack this thread