Dev Log – dasparadoxon gaming blog

Changing the uss style sheet of a Visual Element during runtime.

I want to be able to use a default uxml as inventory for example. I need the structure of the inventory to be the same, but the uss changes per game or even per scene.

I used a game object that I called „Scene Configuration“. (could make it a scriptable object and integrate into game manager, but that is for the future).

The Scene Configuration has an entry

public StyleSheet inventoryUSSFile;

There I drag the custom uss file for the generic inventory uxml.

In the controller for the Inventory UI I read this value from the scene configuraton. This is the uss file asset I want to apply to the inventory on startup.

        private void SetSceneDependantInventoryUSS()
        {
            // get the style sheet list

            VisualElementStyleSheetSet styleSheets = m_Root.styleSheets;

            if (sceneConfiguration.GetSceneInventoryUSS() != null)
            {
                m_Root.styleSheets.Clear();

                m_Root.styleSheets.Add(sceneConfiguration.GetSceneInventoryUSS());
            }
        }

I get the list of style sheets attached to the uxml, but rather a VisualElementStyleSheetSet, that has the ability to add uss style sheet assets to the Visual Element. Thus you need to work directly with the styleSheets object from the Visual Element.

Then I clear all active stylesheets and add mine. Done. No refresh needed.

I need an inventory for Interaction Project – Part 2

Actually, the Game Foundation package from Unity itself is pretty neat.

I just need the Inventory System from it for now. It also offers a currency system, a trade system with a transaction system and some kind of reward system.

There are some tutorials on the package page, yet they are not updated to the latest version and some things have changed, so one must think a bit.

It is pretty easy to use and the editor interfaces are very nice.

Example of an InventoryItem definition, on the left side the overview with all inventory item definition, well there is just this one at the moment, so 🙂

Since I want to be able to choose an item definition in an Action, so that the item can be instanced and given to the player, I need a way to list all item definitions in the catalog.

This is done by using one of the catalog API methods, as shown by a post on the unity forums. At the start I was not sure which type to use for the CatalogItemAsset ICollection which is of course an InventoryItemDefinition List.

    // You can use any type of catalog item for this list.
    List<InventoryItemDefinition> itemDefinitions = new List<InventoryItemDefinition>();
    GameFoundationSdk.catalog.GetItems(itemDefinitions);
 
    foreach (InventoryItemDefinition definition in itemDefinitions)
    {
        // Process your definition here ...
    }

My next problem is that I want a nice way to present the available ItemDefinitions in the custom Action Editor. Right now one could go into the catalag asset and open it and drag the containing InventoryItemDefinition Scritable into the Action ItemToAdd List, but yikes.

So what I really, really would like to have is that nice overview and filter/search listing element in the image above and let it pop up in a window so one can just doubleclick on an InventoryItemDefition and it would add it to the list in the custom Action inspector. Hmm. Onwards to adventure, maybe I can check out how to do this.

I need an Inventory. To put stuff in. And take stuff out. You know. A first look.

I need an inventory system. Mainly for the Interaction Project. Of course an inventory system consists of two parts, the Inventory Data and the Inventory UI.

Let me check my option here first :

Option 1 : Write one myself.
Option 2 : Use a free one
Option 3 : Try to utilize Unitys Game Foundation
Option 4: Buy one on the Asset Store

Option 1 is tedious. I already wrote one for Interaction Project. But besides the fact that it was poorly designed, it was bound to the Interaction Project way to close. While something like that is done fast, doing it right is not done fast.

Option 2 is ok, there are several open source inventory systems. But the learning curve, the quality check and also checking if there is still active development also takes time. And it has to be adaptable to the Interaction Project, which I plan to do by using an interface.

Option 3 is interesting. The Game Foundation seems high quality and provides one part of the Inventory, the Data Layer for it. It also has a currency system. Mainly done for making predatory mobile games, nevertheless it seems to be what I need. Will definitly try it out.

Option 4 requires a bit of research and of course money. (which is totally ok for an external quality asset that saves time and/or enhances the posibilites)

The Generic Menu – bon appetité – Part 1

(this article is more for myself and for future documentation, but it might be interesting for people struggling with Generic Menus.)

For my Interaction Project one main goal is that you can add Flags easily to an Actionable Object Flag Dependency.

Meaning : If there is a chest which can be opened, then you add a flag to it like „open“. The open and the close action then depend and act on the state of that flag.

For adding a flag dependency to an Actionable Object, I wanted a fast, organized and quick way to choose a flag. For this I use an Generic Menu in the Editor Script for the Flag Dependency Class, a custom Property Drawer.

(Of course, if you have multiple chest this gets a bit confusing when they have the same name, but I will add a menu entry for the flags in the current editied AO. Also there are some more ways to group AOs, like region, area, group, scene…)

My first approach used simply the flag names. But this did not work out. I need a unique identifier for each flag. That is necessary cause Actionable Objects Flag Dependencies can depend on flags from other AOs. Also to be able to clone an Actionable Object easily, for example windows or doors, you need to be able to create the flags with the same name but with another unique identifier.

Also there was one small problem I solved for this to work : Since there can be more than one Action in an AO logically, the menu in each of these has to report to the AO which Action actually used a menu to create a new flag dependency.

I solved this by adding the unique property path to the return value of the selected menu item.

flagNameToAdd = property.propertyPath + "\n" + flagNameToAdd;

Here I still use the flag name instead of the flag uniquie uint identifier.

Then the next „trick“ I used is to place the selected menu item string into an member of the FlagDependencyDrawer. In the next OnGUI the drawer checks if the member variable is empty, if not, it parses the content and creates the Flag Property accordingly. It also makes sure that the string is for this drawer, which seems a bit redundent, but seemed necessary at the time.

if (property.propertyPath == propertyPath)

[InterAction Project] Quest Nodes and FlagDependentObstacles

After hardening the whole system and capseling it into its own project, I can move on with other needed functionalites for it. Ah yes, also I versioned it with git, since my ultimate goal is it, to publish InterAction System on GitHub.

I needed for my adventure game the Quest Nodes and obstacles. The Quest Nodes (you could also call them location triggers) were allready in places, but not using the Flag System.

A QuestNode is a box collider set to a trigger, that, for now plays a sound and shows a message, optionally depending on flag settings.

A FlagDependent Obstacle is basicly the same, but instead of triggern it blocks passage depending on flags.

More about Actionable Objects. ( InterAction Project Series )

Let’s have a look how this little system I am doing enables the player to open and close this power block door, as a simple example.

The orange door you see in the scene view in the picture above has a component called ActionableObject. If the layer „ActionableObjects“ exists, a GameObject with this component on it will be set to this layer. This is needed because the raytracing of the EyeModule only hits on objects in this layer. (If the layer does not exist, errors will be thrown, but there is a convient editor menu where you can create all needed layers without having to add them manually.)

Re-Usability or what was that about the Wheel ? (just a few thoughts)

I decided to use the preview animation rigging package from Unity. After a few problems with importing the rigged Blender models as FBX I could easily use this quite good package. (Mainly MakeHuman screwed the scaling, but thats for another time)

I started a small new project to practice the use of it. And while doing that I also decided to export my game system for the main project I am currently working on, which I described in the previous articles a bit.

When you do something like this, you can easily see how reusable and how independed it is from the project you first implemented it in.

A (very basic) Quest/Environment System for Unity (ongoing) #1

Questnodes

Questnodes are the trigger elements. They work closly together with the Game Scene Controller. After being triggerd once, a Questnode deactivates itself, if multipleTriggering is not set to true. If it is set to true, the Questnode will trigger again if the player leaves and enteres the trigger collider again.