Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat | DONATE
performance question: hardcoding units stats — Gideros Forum

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

Comments

  • Prototype pattern is the best approach here.

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

    Likes: antix

    +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?
  • Then I can suggest you Flyweight pattern :)

    http://gameprogrammingpatterns.com/flyweight.html

    It is the best performing method.
  • 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 :)
  • 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.