Feedback I think you are heading in the wrong direction too

I think the idea of introducing a new data layer in the form of GameItems makes sense, and the concept of managers operating on them is very easy to grasp. But I think there is one issue that is an absolute dealbreaker: subclassing from GameItem. This is a seriously bad idea for a couple of reasons:

1) It doesn't match the way GameObjects and Entities work. Too many different concepts are not just a pain in the ar$3, you also loose the 1:1 correspondence you need to easily bridge between these layers.

2) If you have a GameItem that is used by more than one Manager you will run quickly into trouble when every Manager expects a different subclass of GameItem. So you either have to convert from one type to the other all the time, or you have to copy the data and keep it synchronised. So if you have a lot of managers, you will quickly learn the meaning of combinatorial explosion.

3) It's inflexible. GameItems should be simple containers, just like GameObjects and Entities (ok, these are not really containers, but close enough), and managers, just like systems in ECS, should only care about the shape of the GameItem, but not it's type. Decoupling ftw! But if you really want to have different classes for different systems, please make them wrappers instead of subclassing.

Even when you just use the inventory system it works out like this:
There is a GameObject in the scene with a reference to a GameItem. When you want to pick up the GameObject, you have to instantiate the related InventoryItem (a relation you have establish yourself), copy the data from the GameItem, and finally destroy the GameItem and the GameObject. When you want to drop the Item again, it's the same in reverse.
So far that's annoying, but with more systems it will quickly become unmanageable. With a few systems more you will end up spending more time writing adaptors then you would if you just rolled your own system. That's especially true for simple stuff like inventory systems.


Another issue is that Stats are not reactive. It would be awesome if they would work like ReactiveProperties in UniRx:
1) They are IObservables. Unity has this tendency to not stick to standards, which leads to nonsense like UnityActions instead of regular Actions and stupid conversions between the two. Please don't do that.
2) Subscribers get called immediately when they subscribe.
3) Subscribers are only notified when the Value actually changes, not every time a Value is assigned.

 

Hi @jheiling,

Thanks for your detailed feedback. We're actually currently working on the next release of Game Foundation which has significant changes to the current structure of the code, including GameItems, in order to make it more compatible with some new features. It doesn't necessarily address the concerns you're presenting, so I don't want to promise that, but it may change them, if that makes sense. That release should be coming soon, and when it's out, if you let us know whether you have the same (or different) concerns, that would be awesome!

On the Stats feedback can you give more details? Are these the things you're saying they _should_ be doing, or the things you're saying they are doing, but shouldn't? Or are all of those three things features of ReactiveProperties that you like?

 

@erika_d
I will definitely check it out!

Regarding the Stats: That's how ReactiveProperties work. If you have any further questions, I'm happy to help.