Is it best to spread code load in actors as much as possible?

brett-nortonbrett-norton Member, BASIC Posts: 64

As above Is it best to spread code load in actors as much as possible? by that i mean i want to make multiple enemys all with the same code so its practical for me to put as much code in there as possible and replicate. But for example i have an actor set off screen which cleans up and destroys any un used actors that wonder off screen. Should i put the colision.destroy code in the clean up and destroy actor or is it ok to just leave all the code within enemy actors.

The enemy will contain about 10 rules. half of which could be assigned to other actors if there is any benefit.

Comments

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    edited March 2017

    I would separate out systems of rules. So your system for cleaning up should be in a separate actor. There are a couple of reasons for this: (1) actors with tons of rules tend to be hard to work with because GameSalad sometimes lags while opening, saving, or scrolling within that actor; and (2) if you later decide to change the cleaning system or remove it altogether, it's a lot easier to simply delete or alter the separate actor than it is to wade through the enemy actor for something that isn't necessarily crucial to that actor.

    Ten rules doesn't sound like much but... if those ten rules contain rules themselves or timers or Otherwise sections, etc. then that becomes cumbersome.

    On the other hand, I wouldn't necessarily split up rules just to make the actors' rule lists shorter. So I wouldn't have an enemyRules1 actor and an enemyRules2 actor unless there's a clear distinction for why that's the case (e.g. separate systems).

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • brett-nortonbrett-norton Member, BASIC Posts: 64

    Very clear answer.. i havent yet published a game or tested im pretty close now i have no idea yet how much a game engine can handle and what impacts performance etc. I want to get it right the first time.

    So much to learn starting out as a complete begginer with no experience.

    How big of an issue can timers cause?

    Is there a limit you should aim to be within for example no more than 10 per whole game. Or no more than 3 per actor etc. I would imagine the answer is much more complex than that.

  • ToqueToque Member Posts: 1,188

    Having rules in different actors might be a pain for bug fixing. Trying to find rules in actors that may not be obvious.......... Following the logic.

    I would keep in one actor but I don't have tons of rules in any one actor so I can't say exactly what you actors are doing.......

  • pHghostpHghost London, UKMember Posts: 2,342

    @brett-norton said:
    How big of an issue can timers cause?

    Use them if they are necessary. That's what it always comes down to. What is the MINIMUM you need to do to achieve a goal? It's good to think about problems away from the computer as well.

    GameSalad manages these things a lot better nowadays and also smartphones have become much more powerful than they used to be. What you want to look out for is timers or other rules that cause unnecessary loops.

  • tatiangtatiang Member, Sous Chef, PRO, Senior Sous-Chef Posts: 11,949
    edited March 2017

    Anything that loops quickly, such as a Timer or Constrain behavior will affect performance. There's no set amount that I can quote such as "only use two timers in a scene" but it's just good to avoid too many.

    New to GameSalad? (FAQs)   |   Tutorials   |   Templates   |   Greenleaf Games   |   Educator & Certified GameSalad User

  • brett-nortonbrett-norton Member, BASIC Posts: 64

    Answered my question either way. Thanks

  • The_Gamesalad_GuruThe_Gamesalad_Guru Member Posts: 9,922

    The scan plays a part in how one may want to organize code. Since actors are scanned in the layers bottom to top you may want code scanned before other code. Since actors may need to be at a specific place in a layer, due to graphic layout, breaking code that benefits from being first in the scan can be brocken out in non graphic actors. I usually put code not directly related to an actor in off screen actors. This allows me flexibility in when code is scanned.

Sign In or Register to comment.