Part 1 : Introduction + Recap
Hello Everyone,
It took a while but I am back with an update on the progress of the inventory system. We have now started to implement most of the launch features and I will present my solutions to you here. I have been listening and taking note of all your feedback and requirements and I hope you’ll find all of it very exciting. We are far from being ready to release the asset though, we haven’t started the integration with UCC and we need to fix bugs, clean the API, write the documentation and work on the performance.
I have heard that a lot of people want to get their hands on this asset as soon as possible, so we made a few changes in our plans for the launch content. We also plan on releasing an early access at some point once we figure out how the UCC integration will work, not before as it may require some big changes in either or both of the assets. I’ll mention in more detail what we would like to be there at launch at the end of this series of posts. Be warned that any of the statements we make here are not guaranteed. Things could change at any time, we’ll keep you all informed if that’s the case.
Introduction
As stated before, this is a stand alone asset, which means it will be usable on its own and will compete with the other inventory solutions on the asset store. We are bringing a solution that we believe is powerful, flexible and scalable while still being extremely easy to use, even with minimal programming knowledge. When it comes to items and their attribute values we believe that iteration time must be reduced to a minimum as it allows the creators to spend more time on the creative parts. Once a category of item is defined it should extremely easy to add/remove/change items.
Once again I would appreciate your feedback on the framework design, component namings, and on the Editor UI. Please let me know of any of your concerns on the subject and the limitations you encountered on other systems, which you would like to be addressed here.
If you read the first two posts you will see that we have made some changes to the requirements and goals. Be advised that any of the following statements can change, but the main idea will stay the same.
I will split the content of the update in multiple posts as it won’t fit in one post.
- Introduction + Recap
- Inventory + Item Action
- Currency + Shop
- Item Container + Save/Load
- Equiping Items + Upgradeable Items
- Crafting + Recipes
- Conclusion and what’s next
With that out of the way please let me introduce the Inventory System plan V0.3:
Inventory System
The Inventory system is an asset made by Opsive that will help developers create their own inventory system for their game. Inventories can vastly change from one game to another. We do not plan on creating all possible inventory systems, instead we give a powerful modular and scalable framework that can enable anyone to make a complex inventory system in no time.
Key information
Our goal:
Make an inventory framework that is modular and scalable. We are aiming at enabling our customers to create all types of inventories with ease. The asset should be usable by non-programmers to create standard inventories you find in popular games. But the true value comes from being able to extend the framework to create your very own unique inventory system.
I believe the best way to achieve this goal is to create a powerful core framework and polish it by using it in real world scenarios. We will build a demo scene using your feedback and your requested features. This will ensure that the framework is flexible, modular and scalable. I truly believe that the only way to know that a tool is good is by using it in multiple real world scenarios. So having you all use this asset and giving feedback will shape it to be extremely powerful.
Target audience :
Non-programmers for people who want to create any types of items while taking advantage of the demo components to create interesting inventories.
Experienced programmers and beginner programmers who are dedicated to read our documentation and follow our tutorials to extend the demo components or write their own using the inventory system framework.
Unity Version :
The minimum version will be 2019.1. We have decided to take advantage of the new Editor UI, UIElements, to create the editor window, it did not make sense to create the Editor UI twice just so it could be used on older Unity versions. Especially since by the time we release this tool most developers will have moved to 2019.X-2020.X
Recap from last post update
During the last post I explained that you create items in the editor window using ItemCategories, ItemDefinitions and Attributes. You use item categories to structure your itemDefinitions. The ItemDefinitions can be thought of as templates for an item. And finally the attributes are the properties your ItemCategory, ItemDefinition or Item (i.e Icon, heal amount, Description, etc...).
Categories and Definitions can be nested and by doing so the attribute values can be inherited or even modified using a combination of the current object and the parent object attribute values. This allows for a lot of flexibility and speeds iteration as changing a single parent category or definition can affect many others.
Once you have an itemDefinition you can add it to an inventory component in the inspector window. All “Item” attributes can be inherited, modified or override directly in the inspector for the specific item instance that was added to the inventory.
All the items in the game is managed by an Inventory System manager. The manager will assign IDs to the items that are created at runtime and will have a reference to all ItemCategories, ItemDefinitions and Items. These can be fetched by ID or by name.
For more details, make sure to referer back to the previous post. It contains examples and gifs on how all this is done.
Coming up
In this update I will show some of the demo art and scripts. All of it will most likely change , especially the art and the UX, so don’t take anything to heart. I’ve been using the demo just to try things out so it’s not optimized and the UI looks a bit weird. The only purpose here is to show you the progress I’ve made so that you can give me feedback on the newly implemented features.
In case you haven’t read the previous posts, the demo is 2D with sprites. I’m inspiring myself from old school JRPG games, where you have a party of 4 characters each having their own equipment while sharing the party inventory.
The focus of this asset is the inventory and how the items are managed. It does not focus on wielding those items. There are some interactions that we do think useful though such as picking up items. But that’s only really for the demo and therefore 2D.
Once we start the UCC integration we’ll look into all the 3D stuff. This way by the time we’ll finish we’ll have a few examples of simple interactions, like itemPickup, working in both 2D and 3D.
Let’s start with a change in the attribute system
PreEvaluate
During our tests we found that using NCalc and Regex to evaluate the modify expressions of attributes is somewhat slow and creates garbage. So we decided to add a field to the attributes which lets you preEvaluate the attribute values in editor or once in game instead of reEvaluating the expression each time the modified attribute value is fetched. This is extremely useful for attributes on the ItemCategories and ItemDefinitions which shouldn’t change at runtime. It also works well for Immutable Item attributes. Now when it comes to mutable items it’s preferable to take another approach. Since the mutable item attribute can change at anytime preEvaluating the modified attributes will cause issues because an attribute may be dependent on an attribute which can change at any time. Therefore we suggest you to write your expressions directly in C# code instead of using the Modify feature. This also gives you a lot more flexibility.
Here is an example of using of using a static function to get the “Attack” power of a weapon which has a “BaseAttack” and a “Modifier” attribute.
C#:
public static int GetAttack(Item item)
{
return Mathf.FloorToInt(item.GetAttribute<Attribute<int>>(ExampleDatabaseNames.Weapon.baseAttack).GetValue()
* item.GetAttribute<Attribute<float>>(ExampleDatabaseNames.Weapon.modifier).GetValue());
}
If you are wondering what “ExampleDatabaseNames.Weapon” is, it’s a script that is auto-generated by the editor. It contains all the ItemCategory, ItemDefinition and attribute names of your InventorySystemDatabase in an organized manner. These are all constant strings.
Note that here we assume that the attributes “BaseAttack” and “Modifier” do exist on the item. If they do not we’ll get an error here.
You could check if the attributes exist before getting them
C#:
item.HasAttribute(ExampleDatabaseNames.Weapon.baseAttack) ?
Or you could check if the item is part of a certain category to make sure the attributes do exist on the item.
C#:
if(InventorySystemManager.TryGetCategoryFromName(ExampleDatabaseNames.Weapon.name, out var weaponCategory))
{
weaponCategory.InherentlyContains(item.ItemDefinition) ?
}
As explained previously the categories specifies the attributes which its items must have. Therefore if a category inherently contains an item that item must have all the attributes specified by it. In this case “BaseAttack” and “Modifier”.