Game Attributes Vs Tables

wilsongalucho

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.

wilsongalucho

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

wilsongalucho

Socks

@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 ?

Franto

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?

wilsongalucho

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.

Franto

@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.

wilsongalucho

Hello @Franto

I will look into this alternative for timers. Cheers

The_Gamesalad_Guru

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

wilsongalucho

@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_Guru

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.

wilsongalucho

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

wilsongalucho

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.

The_Gamesalad_Guru

It's somewhere in your code.