[Feature Request] **Game-Objects**

[zacharyLYH]

Is your feature request related to a problem? Please describe.

No.

Describe the solution you'd like

A GameObject class that would support the availability and storage of in-game objects such as Currency, Potions, and whatever a game developer would desire. The GameObject needs to have functions to pickUpObj, useObj, modifyUserProfileAfterUse, storeObj etc. It will also need a Bag type to store and allow efficient enumerations of GameObjects. This way, in-game objects can be trivially initialized and all relevant functions can be found in the GameObjects class.

Describe alternatives you've considered

We could implement all the in-game objects individually. However, its probably cleaner, easier to debug and logically simpler to channel all in-game objects into one GameObject class.

Additional context

One problem with a GameObject class is overgeneralization. Since most objects are different in terms of behavior to one another, there might be a need to index object types, for example, index 1 could represent currency, and index 2 could represent potions. In order to specify which type of object we're using (as an example), we might need to rely on the aforementioned indexing scheme, which is less elegant and throws off readability. However, there is probably a better way than what I suggested.

[Sploder12]

In regards to the indexing in further context, with the current way things are implemented, polymorphism would probably make the most sense. Although the indexing idea could be put to use with an Enum (although Python Enums are lame) to make it more readable.

Additionally, we may want to consider incorporating functional programming as it can also be used for this purpose quite well.

[zacharyLYH]

Before moving forward, perhaps we should agree on the encoding format of GameObject and how they get initialized. Note that objects don't just have 1 function - an object could be picked up, used, discarded etc - so a simple .on_select() probably isn't going to work; there needs to be logic to figure out what kind of operation we're after. I'm not super sure about how game-2.py's .dl file is parsed, so I'll not suggest a way to lay out this logic. However, as far as game-2-layout.dl is concerned, we could make use of the desc field to encode the operation and other necessary parameters for this object.

As far as initialization and implementation, I believe we can take inspiration from the current Node, Action and the classes that inherit Action. Specifically, GameObject will inherit Node. A base definition of what pickUp() and use() among other functions can exist within GameObject class, then each individual object type further defines their specific behaviors. Any improvements to this step we should consider?

[zacharyLYH]

PR #86