* 1011: Added SuppressWarnings for SonarCloud errors All of these files are causing SonarCloud to report the following error: Loops should not be infinite Since these instances all require an infinite loop that will never end, these warnings should be disabled so that SonarCloud no longer reports them as error. The rule is: squid:S2189 * 1011: Made all of the randoms static and final According to SonarCloud rule: "Random" objects should be reused, randoms should not be recreated. This commit has taken all of the Randoms and made them constant variables in the files that are using them.
layout, title, folder, permalink, categories, tags
layout | title | folder | permalink | categories | tags | ||
---|---|---|---|---|---|---|---|
pattern | Type-object | typeobjectpattern | /patterns/typeobjectpattern/ | Game Programming Patterns/Behavioral Patterns |
|
Intent
As explained in the book Game Programming Patterns by Robert Nystrom, type object pattern helps in
Allowing flexible creation of new “classes” by creating a single class, each instance of which represents a different type of object
Applicability
This pattern can be used when:
- We don’t know what types we will need up front.
- We want to be able to modify or add new types without having to recompile or change code.
- Only difference between the different 'types' of objects is the data, not the behaviour.
Explanation
Say, we are working on a game which has a hero and many monsters which are going to attack the hero. These monsters have certain attributes like attack, points etc. and come in different 'breeds' like zombie or ogres. The obvious answer is to have a base Monster class which has some fields and methods, which may be overriden by subclasses like the Zombie or Ogre class. But as we continue to build the game, there may be more and more breeds of monsters added and certain attributes may need to be changed in the existing monsters too. The OOP solution of inheriting from the base class would not be an efficient method in this case. Using the type-object pattern, instead of creating many classes inheriting from a base class, we have 1 class with a field which represents the 'type' of object. This makes the code cleaner and object instantiation also becomes as easy as parsing a json file with the object properties.