How to unfuck your items

One of the main goals of the first phase is to get some core gameplay in place to show where the game is going. This has involved a load of shuffling tasks around to get a decent core planned, and one of the biggies is a working inventory.

The currently available version of the game does not have an inventory. You see either Health or Stamina, run over it and if you need one of them, you use the item. Simple, fairly reliable, but annoying as shit. You need stamina, saw the last can minutes ago, and all you can find is health? Tough. You've got rocks to throw? Have you? Who knows, cos you can't see how many you have. This is fun!

An overhaul of the item system actually wasn't intended just now, but two tasks made it a requirement. First up is the rock problem. You only get 5 right now. Second thing was adding additional items into the game. You really need to see what you have.

So, the first task was to build a blueprint for each new item. Every blueprint has the same core, but has different effects, so it makes a lot more sense to trigger the item effects from the players code. At that point, all the code in each item is just Find Player > Trigger relevant code. The final nail was that the first draft of actually storing these items once picked up looked like this:

This is fucking awful.

At the moment it's not too bad because there's 8 items to keep track of quantities. But what happens when I want to add more items? Each new item needs a blueprint, model, function on the player, added to a list of spawnable items, etc, etc. It's a lot of stuff to have to do, and any mistake at any point in that process will break the item. How do you streamline this? Especially when this is what just the blueprints of the old items looks like:

Step 1

First we tweak how the item collection works. The new dialog system has an ideal interaction system to trigger dialog. Initially I tried to integrate it with item collection, but it got messy, so I split it off into it's own pickup system. At this point, the item has certain identifiers on it, so it could add 1 item to the correct variable. Then I added hotkeys 1-6 which trigger a bit of code that first checks if you have that item available, then if it does it fires off the function to do that effect, then it knocks 1 off that item quantity. Simple.

Step 2

There's too many variables and items to build. At their base, it's the same code repeated. So we go from the set of items above to this:

The base item needs a way to decide what item it's going to be, change the mesh and display the name of the item. This is where a dataTable comes in useful. Think of it as a spreadsheet of static data. You can edit it outside of the game, but while playing, you can only reference it.

Each row in this table is a different item, and the table needs a column for each potential effect or stat change as well as carrying an identifier, scale of the mesh, icon for a UI and how likely it is to spawn...

Like that. It's worth noting that quite a few things on that list are not implemented yet. This is futureproofing and hopefully making my job later a shitload easier. This gives us some items:

Interestingly, the "Row Name" is pretty much what you'd use to set up console commands for spawning stuff...

So, now our base item has something to use to generate items, and the player now has a reference for what each item actually does and how to implement it. Even better, this means the process of adding new items is as simple as adding a fresh row with the parameters of the item and adding a mesh. 

Step 3

Now, the base item when it spawns in runs through the item table and adds the row names and probabilty to a list if it's an enabled item. Then it chooses one at random from the list, weighted on the probability. With the selected name, it looks up the complete row (this is a load faster than getting full rows  when getting enabled items), gets the relevant data and uses this to select the correct mesh and scales it to size.

Now we have randomised items spawning from a single blueprint. But the next issue is the player using the items. Well, the next big issue. First we need to see a UI with quantities on it.

Step 4

Slap together a quick UI.

This isn't the final product. Eventually the inventory system will get expanded properly to be able to show a full inventory and set items on the hotbar. But we only have 6 active items, so the hotbar can be fixed for now. The quantities were then hooked up to how many of that item the player is carrying. Easy.

Except it then hits another issue that was lightly fondled earlier. Tracking these items is intensive with each item you can buy, pick up or wear having to have a unique variable. Surely there's a neater way to do this?

Step 5

That is a motherfucking Map variable. This little bastard is your entire inventory. All it is, is an array of two variables: Name and Integer.

When you pick up an item, the name of the item is searched for in the inventory map. If there's a match, you add 1 to the integer for it. If there's no match, you add the name and 1.

When you use an item, it searches for that name again, if it isn't found or the integer is 0, you can't use the item. When you use the item and it has 1 left, it deletes it from the inventory map.

This means anywhere you are looking at or using your inventory, it just has to look that item up in the datatable, and you have your item stats.

Obviously, this will need some modifications. Right now the system is set up just for items you'd pick up or use. When it comes to adding clothing and weapons, there will need to be a slightly different way to identify items, but for now it works. Finally, we can make these items do something.

Step 6

Your hotbar says 2 is health potions. You press it and it takes the name of that item and sends it to a generic function to look up what the item is. When this system gets expanded, that literal name will be coming from what is set in that hotbar slot, but that can't be implemented until we have a customisable hotbar.

Once it hits Get Item, first it checks you actually have any of that item left. If you do, it looks up the datarow for the Literal Name and saves it for later use.

Next it looks to see if the item effect has an Effect Time. This type of item only lasts for a set period of time, so we need to get it out of the way first. If it is a timed event, it removes one of that item from your inventory, then runs through every stat that could be changed to see if any of them get modified. For example, if an item has StrengthChange 50, it would see the value is >0 and would trigger an event that increases Strength by 50, runs a timer for the Effect Time, then once it runs down removes the 50 again.

If it's not a timed event, it goes straight into health and stamina and increases them by the requested amount.

Again, I can see some tweaks that will be needed, but right now the required bits to make the tweaks work don't exist. This is a good base to build on though, and in theory should mean whatever item is added to the table can be handled by the game.

Step 7

Yeah, I know, the player UI needs some work. The last job was to set a trigger on the baseItem so it shows the prompt and item name when you come close to it, then hide them when you move away. Then I went back and did the actual last job which was to remove the random spawning items in the dungeon and replace it with the new base item.

But that's how you take a basically non-existent item usage and turn it into a basic inventory with hotbar, and streamline the item creation process. It's taken a few days of work and has gone through a few iterations to reach the end, but it's another big step forward.

Other minor jobs done recently include increasing the scale of the dungeon to make it a bit less claustrophobic, updating some of the meshes in there and adding a roof:

Also fixed a bug where the rocks you throw to distract wolves wouldn't actually distract them. They couldn't hear it. Turns out the noise report takes a few milliseconds to activate, and before it could do it, the rock had been removed from the game. So I added a 0.2 delay before removing it, and now wolves react properly.

And Finally

The next proper release on itch.io will be the end of Phase 1. This stuff is part of Phase 1-A, and I've still got 1-B and 1-C to do. 1-A had the most tasks, but the big tough tasks are spread evenly through the 3 sections. A, B and C mark where test builds will get released on Patreon. At this point in time, I'm allocating an estimate of 2 weeks per section, with 1 week down on this current one, so the hope is to have the next Patreon demo up around the 22nd Oct.

If you want to play it when the intermediate test builds are released, it's available at patreon.com/methodiaRascal

The remaining items for Phase 1-A are:

• Rebuild animation system to use player character instead of proxy characters
• Move player stats/inventory to game instance (carry inventory/stats across levels)
• Integrate species datatable into character generation (different species have different base stats, streamlines process like item system did)
• Aimable rocks with trajectory preview
• wolf jiggly bits
• Redo rear sex scene to line up properly
• Build and animate recovery process for player (masturbation with additional scenes if caught while doing it)
• Animate and set up additional sex state if wolf catches player while you are crouching

Phase 1-B:

• Basic character clothing
• Fixes to squirrel mesh and weighting
• Add fur to player
• Add fur to wolves
• Smooth ui bar changes
• Upgrade enemy AI to require visibility of player for a few seconds before triggering chase
• New enemy type
• Female characters for enemy types

Phase 1-C:

• Basic levels
• Pineridge map
• Basic storyline
• Better fluids
• Interactable characters in Pineridge
• SFX/audio stuff
• Deal with size differences between characters