GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Game Attributes Vs Tables

Hello,

I have a few rules changing values on a table every second but it's making my game lag to the point it stops checking the rules
and I wanted to know if I was to change game attributes every second would be better in this case?

Cheers,

W.

Comments

  • wilsongaluchowilsongalucho Posts: 180Member

    By the way on Creator Works fine its only when I put in on the device that it starts messing up..

  • wilsongaluchowilsongalucho Posts: 180Member

    1114.jpg 441.8K
  • SocksSocks London, UK.Posts: 12,822Member

    @wilsongalucho said:
    Hello,

    I have a few rules changing values on a table every second but it's making my game lag to the point it stops checking the rules
    and I wanted to know if I was to change game attributes every second would be better in this case?

    Cheers,

    W.

    What happens when it stops checking rules ?

  • FrantoFranto Posts: 779Member

    The rules that are changing the values, how complex are they?

    If your game is an "Actiony" type, where it's actively doing a lot of things, if the rules involve something like change attribute(self.hp) to (self.hp-{attribute.attack/attribute.defense}), and it's being applied everytime a hit occurs, the processor needs time to make that calculation, even if it is nearly instant.

    But, if you have multiple actors running that same calculation every second, the game will begin to lag greatly.

    What you can do is something I call "precalculation". Where the moment an actor is born, they will calculate all the heavy stuff at that point and save it into a self.attribute. For example, the "change attribute(self.hp) to (self.hp-{attribute.attack/attribute.defense}" would already be calculated the moment they are born, and since the other actors exist already, they would take their stats into consideration before contact, and then when they hit they do finally hit the opposing unit, the calculation will be short and simple (self.hp-damage). With damage already existing prior to the damage calculation, thus, not straining the processor.

    And even after precalcution, any changes to damage should be calculated long before actor collision. So if something changes, like their defense drops, an attribute should save that data and re-calculate all damage at that moment, and save it for future use, rather than taking that change into consideration during an attack.

    But if you are not doing any of the above, then, the issue might be with how you are doing things with the table, what behaviors are you exactly using?

  • wilsongaluchowilsongalucho Posts: 180Member

    Hello @Franto and @Socks ,

    This is my battle system I'm creating for my vikings game, and the system is similar
    to Zombies Vs Plants.

    @Socks - when it stops calculating the logic the enemy actors start spawning all at once

    @Franto - the way I have it set up is the Warrior actor has a self.HP when collides with an Attack it triggers the rule ( self.hp - attack )

    So basically this how I have things set up with the tables.

    I have 3 tables which are updated as soon as an enemy is spawned ( the rules are
    in the enemy actor. Before I had it on 1 actor and it would update everytime an enemy actor collided with the counting actor, however if 2 enemies collided at the same time it would only count as 1 so I've put the table update rule in the individual enemy actors)

    Tables

    TB1 counting the total amount enemies
    TB2 counting the count downs before the next enemy is spawned ( each type of enemy has its own timer ..that's 16 timers counting every second ) I was thinking of having 1 main count down and have a rule like (main count down - individual type of enemy delay)

    This would mean it would only update 1 cell every second instead of 16

    TB 3 counting the amount of a certain type of enemy per row

    TB 4 counting the max of a certain type of enemy per row (updated only when the new wave is triggered).

    I'm going to try to create this main counter, see how if it makes a difference.

    What do you think?

    W.

  • FrantoFranto Posts: 779Member
    edited November 2015

    @wilsongalucho Are you using the timer behavior? 16 of them will cause immense lag. This thread explains the alternative to using the timer behavior:

    http://forums.gamesalad.com/discussion/44707/timers-are-for-chumps-gs-optimization-tips/p1

    From thread:

    Try replacing that timer with this simple rule: if self.time>2, perform actions. The result >is, a timerless timer! "For" type timers are almost identical, just flip the operator from > >to < and your actions will be performed only for the first 2 seconds of an actors life. >Cool beans, right? You may also notice that using this new rule based timer gives you >access to the "otherwise" section just like any other rule. Using otherwise can allow you >to save on timers or logic that may have been required before!

    Default timers have their uses, but for spawning tons of enemies, the method above is the most efficient. Using the game's time or an actor's self.time as a "timer" cuts down on performance, if you want compatibility over all platforms, a timer using mod(a,b) is best, otherwise mods using % operator can be used.

  • wilsongaluchowilsongalucho Posts: 180Member

    Hello @Franto

    I will look into this alternative for timers. Cheers ;)

  • The_Gamesalad_GuruThe_Gamesalad_Guru Posts: 9,913Member

    Why not use the loop behavior? This is the best way to have things check a table.

  • wilsongaluchowilsongalucho Posts: 180Member
    edited November 2015

    @Lost_Oasis_Games but isn't loop behavior be the same as a after 1 sec timer? I mean it updates the table all the same right? Or is the loop behavior somehow less straining ?

    So from my understanding it's not the actually Table updates that's causing the lag, it's actually the Timer behaviors. Am I correct? @Franto @Socks @Lost_Oasis_Games

  • The_Gamesalad_GuruThe_Gamesalad_Guru Posts: 9,913Member

    Loop over is designed to work every code cycle. It's designed to work more efficiently than a timer. It's similar to a rule but a rule only fires once when the condition changes a loop will keep firing. So putting a change attribute in say a loop the change att will fire every cycle unlike a rule where it will only fire once when the condition changes.

  • wilsongaluchowilsongalucho Posts: 180Member

    Ok so I've changed some of the timers with the self.time rule and also put the row and warrior count in the spawn actors instead of the actual enemy actors and it's running much better. Now that I know where the problem is I can think of ways to go around it. I knew that timers were heavy, but didn't know they could cause such a strain on performance. Thanks a lot guys!! @Socks @Franto @Lost_Oasis_Games :)

  • wilsongaluchowilsongalucho Posts: 180Member
    edited November 2015

    Hello again.. So I ran a couple more tests on the device after changing the timers to the self.time rules, however at some point it beginnings to lag again as more characters are generated, however not as bad before, at least it still responds to the rules and they don't keep spawning like crazy. The weird thing is that it continues to lag even after most of the characters are destroyed.

    I've tried to half the res of the pictures, but doesn't really make a difference.

Sign In or Register to comment.