Feedback First impression and ideas

Hey guys,

So, I took a quick look at this package. I'm a big fan of standardization, so I'm really excited about it. What you should know about me and about what I think before I make a short list of my ideas/feedback/opinion:
I'm not working on mobile games, never have and probably never will. This is important, because my point of view is a general package, a standard tool which equally can be used in an indie offline RPG and in a hardcore whaling mobile game as well. And my point of view is obviously on the offline indie RPG side.

So, unfortunately in the package I have found in the PackMan there is a very simple Game Foundation. It lacks of a very numerous things which was showcased in the Unite video. Like pricing details for example. But I guess they are coming at some point in the future.

What I think about the rest of it:

- Having stats is a very great idea
- Although I would like to see categories for them (so we can easily organize the different type of stats), like "skills", "attributes", "modifiers" or "damages", "defenses" or "physical" and "mental" or anything
- I would like to see codegen instead of string handles everywhere so instead of

Code (CSharp):

1. void Start()
2.     {
3.         // get the coin item by its ID
4.         InventoryItem coinItem = Wallet.GetItem("coin");
5.         Debug.LogFormat("coins in wallet at start: {0}", coinItem.quantity);
6.         coinItem.quantity -= 25;
7.         Debug.LogFormat("coins in wallet: {0}", coinItem.quantity);
8.     }

we can have something like this:

Code (CSharp):

1.     void Start()
2.     {
3.         Debug.LogFormat("coins in wallet at start: {0}", Wallet.coin.quantity);
4.         Wallet.coin.quantity -= 25;
5.         Debug.LogFormat("coins in wallet: {0}", Wallet.coin.quantity);
6.     }
7.  

- Also it would be nice to have events or delegates, so we could subscribe to changes (like in the example above subscribe to the coin quantity change and update a text UI element or something).
- I wouldn't put too much effort into having Strings (DisplayName, Description), because most of the time people want to get these from some sort of localization service, the ID is more than enough to handle these things. Actually I'd like to ask to avoid them if possible.
- I would like to have stats where the calculation of the stat is a delegate (calculates when something is changing), so I can create stats, which are depends on other stats and/or some calculation (like MeleeDamage = Strength % 10 + Dexterity %10 And then this can be modified by InventoryItems.

Again, I'm very happy that this package is coming and that it is not only for microtransactions and mobile games.
When new package drops, I will continue to share my thoughts if you don't mind.

 

Hi @Lurking-Ninja!

Thanks so much for taking a look at Game Foundation and taking the time to give us your feedback! We love hearing it! These are great ideas that we'll definitely make note of! As you said, not everything in the presentation at Unite is available now, some of it is stuff we have planned. Sorry for the confusion!

For the events or delegates when something changes, we do have a few things, though they look like they slipped through our documentation a little bit. (They are documented in the Wallet class, but in fact also exist in and should be able to be used with the standard Inventory class as well: https://docs.unity3d.com/Packages/c....1/api/UnityEngine.GameFoundation.Wallet.html) We have callbacks for onItemAdded, onItemRemoved, and onItemQuantityChanged (You may also see OnItemQuantityOverflow in the doc, but that is actually related to a previous iteration of the code and needs to be updated so that's not ready for use yet.)

It sounds like you probably want a more general callback system as well? Or do these three callbacks meet the needs that you had in mind?

Thanks again for your feedback!

 

Hi, thank you for listening!
To shortly elaborate what I think about this.
If we keep the string-based query system, I would like to see this pattern to emerge:

Code (CSharp):

1. [...]
2. Wallet.GetItem("coin").quantityChange += context => someFunctionToUpdateUI(context.ReadValue<int>());
3. [...]
4.  
5. private void someFunctionToUpdateUI(int newValue) {
6.   [update UI with the new value]
7. }

Just like in the new Input System handles these.
Obviously if we will have codegen, it can be even more awesome:

Code (CSharp):

1. [...]
2. Wallet.coin.quantityChange += context => someFunctionToUpdateUI(context.ReadValue<int>());
3. [...]
4.  
5. private void someFunctionToUpdateUI(int newValue) {
6.   [update UI with the new value]
7. }

Or something like this. (Obviously the CamelCasing depends on your choice, but would be great to stick to a common style and the new input system started it )

Also with codegen we can have methods like
bool Inventory.playerInventory.hasShovel(). -> playerInventory is the ID of the inventory, shovel is the ID of the item we're looking for. int Inventory.playerInventory.shovelCount can return the no. of shovels in the inventory)
And so on and so forth.

I will revisit the documentation and codebase later so I will get back to you. what kind of callbacks, events and structure I would like to see more in deep. Obviously I can also reason why I prefer the codegen and the not string-based system if needed, but I think also the Input System team also can communicate the reasons.

 

Thanks, @mingz-unity!

Codegen (again)
One more short thought about GF and codegen (I will leave it there to chew on it, I promise ):
Please, correct me if I'm wrong, but the database can be only changed in editor time. Since both the Stats and the Item blueprints are static data. And in run-time they get instantiated by the application.
This philosophy would/does allow a O(1) search at all times in run-time if you put together with codegen.
How? Let say we have an array (the quickest form of iterable for mass changes or filters, etc). Let's say you have an Intelligence stat in it. Let's say it is at the index 5 in this array.
So, with codegen, you can generate code like this:

Code (CSharp):

1. private Stat[] _stats = new Stat[N] {[...all data goes here...]};
2. [...]
3. public int Intelligence {get {return _stats[5];} set {_stats[5]= value;}};

So, there is that.

Composite stats
I mentioned that it would be handy to have categories for the stats. But those purely for editor time reasons to find/organize stats easily.
For run time, I would like to see composite stats. Composite stats (or calculated) have values depending on other stats.
For example: MeleeDamage stat. It calculates like this: Strength + Dexterity % 10; This composite stat would recalculate automatically whenever either the Strength or the Dexterity stats change values. Obviously we, game devs can make it happen with extensive event-subscription and whatnot, but it would be more simple for us to have it out of the box.
(Also if you utilize codegen, you can even ask for the equation from the person who is editing the stat in the editor. You can then put the equation into codegen C# and in run time it just works, obviously optional and advanced feature)
It is a quasi alternative to the delegate stats what I mentioned in my very first post here.

Stats having "max" value
Coming from the hard core RPG stance again, where it is customary to having a lot of stats two fold: stat and maxStat. Example: (current)health and maxHealth. You could provide this functionality out of the box like this:
- when the person editing the stat, you present two checkboxes:
--- have max value
--- allow exceeding max value (this is for turning on or off the in-built protection against adding more than the max)
So, the stat with haveMaxValue property would have a max<StatName> member with the same type and same codegen property if you use codegen.
If the allowExceedMaxValue (sorry sometimes I'm terrible in naming, I'm better when I'm actually coding the thing ) is false then when you get a new value for the stat you check if it is higher than the maxStat and just cut off at maxStat.

Template Inventory
It would be nice to have if we could put together template inventories. For example in editor time I can get an inventory instantiated with the template:
- one item from the "CommonSwords" category
- one item from the "UniqueUtensils" category
- Random(30) + 50 coin
Something like this would allow the users to edit the potential loots in editor time and when the template inventory comes to play, we just iterate over the content rules and instantiate the items based on the rules. Or even you could instantiate the entire inventory, depends on the solution you have put together in the code.

That's it for today. These are obviously more advanced features and ideas, so I just leave them here for reading. I decided to wait with more in-depth look into the system when more "Details" (components) land in the package. BTW, I really like this Entity-Component-style editing (Item is an entity, these details are the components I guess).

 

Hey,

Yes, absolutely. I'm open to any solution you can provide through this system, as long as there is an option to drive them locally without dashboard somewhere in the cloud.

 

I also strongly prefer codegen here. We codegen enums for skus. We have a sku editor in Unity where sku's are strings. We have a SkuDefinition.cs that has an id, string, and couple of categorization enums also. So our sku editor supports the same categorization that our item editor does.

Like most production games we have multiple VS projects involved. We actually do the codegen on the client. Every developer has a general configuration and one of the settings is the VS project where Sku.cs resides. We could use T4, it's just easier to have a one button publish sku's right where we are editing them.

Enums I prefer over constants. More flexible especially in Unity custom editors.

 

Hi, me again.

So, I have took a little bit closer look at the system we currently have in the PackMan (0.1.0).
I just realized that the current state of the Stats is not a general Stat system, it is mainly for the Items (since the documentation is a little bit scarce, the code examination helped ).

Two things about this:
- I would like to ask to have this same Stat system to use as a general Stat system. Like for characters and stuff. The backend probably very-very similar, but not with GameItems but with characters or character-types (like RougeArchetype has 9 Strength but 12 Archery or something, 8 Strength but 11 Detxerity) and then we can Instantiate real character-stats from those templates. Just like Items.
- Since the stats are for Items, I'd like to see Stat-Sets, like we have "Attack", "Defense", "Accuracy", "Weight" stats and the Sword blueprint should have the "Attack", the "Defense" and the "Weight", the Bow blueprint should have the "Accuracy" and the "Weight", etc... This is for simplify the edit of the individual Item blueprints (IDK what's the name you will call these "Items" in the editor, because they're more like blueprints.
So when I apply this set of stats on a blueprint later I can set it to 5, 10, 1 for "Iron Sword" and 10, 11, .5 for "Mithrill swords", etc...

 

I can do that, but the general public won't understand at first, even if you write it down in the documentation. They will take a look at the GameItem and they will see it is an Item, it is not a Character or Actor or whatever. So you will (or us, who help on the forums) will have to explain time and time again that it is perfectly fine to use this way.
So from that point of view I would prefer to at least generalize the terminology in order to avoid confusion.

 

@Lurking-Ninja hi i was playing with Game Foundation lately too and i just read this thread, and was wondering about the loot or prize inventories and Composition stats that u offered.

on loot/prize inventories
when i thought about creating something slimier to that i thought that creating an inventories with names like "EnemyX_Drops", put there all the items i want that enemy to drop, and make this inventory auto created so i can just see the items in there and drop them or no auto create them, and just create a new inventory of that definition and move the items to the player inventory and then destroy the now empty inventory.

not sure about the 2nd solution i had cause we cant create at run time any new items so not sure if i can create a new inventory at run time too. also what i was stack about is how to make a drop rate for the items that i dont want to drop all the times.

if what i said at the start sound like what u wanted to create i think GF already has the ability to do so.
if u meant the drop rate and thing then i am stack on that too and would love a system for that to XD

On Compostion Stats
about the Composite stats that was mentioned, i was wondering if there can be option to make it a solid value instead of a formola? i mean something like this:

i have my player str stats and atk stats that is composite from str, something like:
Atk = Str*10

but i would like to create a weapon that only raise my atk value by a fixed value like
Atk = 50

so if i have a player with Str = 10, i will have Atk = 10*10 = 100,
but if i also equip my weapon i will on the same player, without changing my Str value from 10, my Atk will get a boost of 50.

in short if the Composite Stats be implemented, When i create the Composite State in stat window, i will give the formula to be used (from my example the "=Str * 100") and when i add this stat to an item or player i can chose to use the formula or a solid value(from my example the giving the weapon Atk = 50).

i hope my ideas were understandable, not sure i explained my self well XD