Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
performance question: hardcoding units stats — Gideros Forum
  • Home
    • ›

    performance question: hardcoding units stats

    piepie Member
    edited February 2017 in Game & application design
    Hi, I need to write the stats for my units somewhere, and I was wondering if there is a better place than another from a performance point of view.

    I have a single Actor class which can be any unit: on spawn it change its stats/properties accordingly to the unit type.
    Right now I have every unit property inside an if statement in spawn method, something like
    function Actor:spawn(unit_type)
      if unit_type == "ghoul" then
            self.prop1 = 12
            self.prop2 = true
     elseif unit_type == "mummy" then
            self.prop1 = 8
            self.prop2 = false
    -- and so on..
     end
end
    This is a bit difficult to keep track of because there are many properties and many units - however I think it could be the better performing option because theoretically everything outside the specified "unit_type" should be ignored.

    The other options I thought of are keeping the structure of the spawn function, but instead of defining properties directly there, I could read them from somewhere else, like a json file or a lua table.
    The last one has the benefit of being already in the best format available, but I should load the table somewhere, keeping it available ad therefore occupying resources. it's a tower defense like game, actors respawn almost continuously.

    What do you think is the best approach? There is a better one? :)

    Thank you
    +1 -1Share on Facebook

    Comments

    • mertocanmertocan Member
      Prototype pattern is the best approach here.

      Check this link.
      http://gameprogrammingpatterns.com/prototype.html

      Likes: antix

      My Games. Mert Can KURUM
      +1 -1 (+1 / -0 )Share on Facebook
    • antixantix Member
      edited February 2017
      The prototype pattern is pretty good but might be tricky to make work with pooled objects. In my experience, if you are creating many objects then your performance will be very bad without pooled actors.

      I use a pool of Bitmaps as Actors. Each one gets all the common properties (position, velocity, gravity, etc) and then like your code I do a large if then block to set unique properties depending on the actor type. This is not the prettiest or easy to manage code but it works and is very fast.

      Personally I have found this to be the best performing method, if performance is what you are after.

      What does everyone else do?
      +1 -1Share on Facebook
    • mertocanmertocan Member
      Then I can suggest you Flyweight pattern :)

      http://gameprogrammingpatterns.com/flyweight.html

      It is the best performing method.
      My Games. Mert Can KURUM
      +1 -1Share on Facebook
    • piepie Member
      edited February 2017
      Thanks for the inputs, I am pooling already. I wonder how a Flyweight approach could be implemented in gideros, and on a wider scale how is it different from object programming:
      please forgive my ignorance :)
      When I write a base class from which I start to build other classes which inherit properties and methods am I not using flyweight approach already?
      I figured that a single class with all the available options (properties for each unit type) embedded is lighter than a master class plus many children classes - where most of the differences are in properties values.
      Pooling one single class looks easier than having to decide every time if I am spawning the right subclass, and if it's not already available in pool, create a new instance for the subclass.
      This also avoid keeping useless objects in the pool.
      Am I wrong?
      Thank you :)
      +1 -1Share on Facebook
    • antixantix Member
      After your initial post I started investigating the possibility of combining pooled objects and the prototype method in @mertocan's first post. Unfortunately I couldn't get it working because when using pooled objects you are using the pool of bitmaps as game objects, and in the prototype method this won't work.

      My priority is to have the best performing game I can and bitmap pooling gives that. The code can be harder to maintain but that's an acceptable trade-off in my opinion.

      The flyweight method is also not worth consideration in my opinion because it requires creating more stuff on the fly (pun fully intended) which is what we want to avoid to minimize slowdown in our games.

      Likes: pie

      +1 -1 (+1 / -0 )Share on Facebook
    Sign In or Register to comment.