An Improved(?) Tile Inventory System

By Jaime Ramón Carbó Sánchez

Table of Contents

  • Introduction
  • Chapter 1: Baseline
  • Chapter 2: Giving feedback to the players
  • Chapter 3: Preparing a demo
  • Chapter 4: Extras
  • Conclusion
  • References

Introduction

Managing your inventory in a game can be frustrating. This is, in most cases, caused by a clunky system where the player is given really limited space and many items to place in it. This results in players getting irritated every time they press the key and resorting to ignore the mechanics.

There are plenty inventory types out there, but there are some that only fit in with certain genres of games. Choosing the right one can make the experience much more rewarding for the players.

Here is Deus Ex’s inventory. This one specifically made players develop a mod that allowed them to carry more items. This was caused by the huge amount of resources the game gave them, and the limited space of the inventory.

An ‘unlimited’ inventory rarely works with survival games. For example, think how much the experience of Minecraft would change if you didn’t have to build a storage room to dump all your stuff after a long journey.

Personally, I’ve always enjoyed the idea of arranging my inventory in games. Specially, in tile-based inventories, I get a rewarding feeling every time I clear it and get prepared for a new item recollection session, or I am given a dilemma where I need to pick which item I should put in my bag and which one to leave behind.

Resident Evil 4’s inventory. A great example of a successful implementation of this system.

It is important to have in mind that the perception changes a lot between the game and the player. As with almost all design decisions there will be people that love it, hate it or don’t mind it, the first two being the most vocal on the internet. What I found after doing some research was that what all parties agree on is, that there are certain practices about these inventories that we as developers should avoid if we want a positive reception.

This is why I decided to focus my research on trying to improve upon this exact type of inventory system. Through this article you’ll be able to glance upon the practices that make the system good, and which things to avoid.

Objective

My main priority will be creating a tile-based inventory. One of the most beloved by the survival simulation player base, which I belong to myself. Along the way I will explain the different factors that influence the success or failure of this system.

I won’t be making a basic tile-based inventory. I will add my own spin to it and explain how those changes might improve or worsen the overall experience with the help of research and playtests. Visuals won’t be a priority for this project, players will be given feedback through visuals but the designs won’t be the main concern.

The article will be divided into chapters, each one with a design objective, and at the end of it I’ll make a few comments on the value it brings to the final product. This will be based on the playtests I performed at the end of the R&D and the research I did (Section called Perspective on the Result)

Chapter 1: Baseline

1.1 Research

The design of the UI plays a crucial role in the overall experience of the players, it doesn’t just serve the purpose of looking pretty or accessible. As Sarah Adedun mentioned in her article it affects them in multiple ways. For example, the immersion, a dissonant UI can kick them out of the game world each time they press the inventory key. Another example is the accessibility, the simpler the UI, the broader public your game can reach. Most games that use this inventory have the shape of their items reduced to rectangles of different sizes. This is usually done for simplicity and aesthetics, so players feel more accomplished when they organize their inventory. You can see this in games like Resident Evil 4 or the original XCOM game X-COM: UFO Defense.

It is important to note that both these games shifted from this inventory type in their sequels. In the case of XCOM it was because the game had too many mechanics and they wanted to streamline the gameplay as much as possible, so they decided to scrape this complex system. Resident Evil decided to go for a system where all items just took 1 tile of inventory, so a gun would be the same size as a medicine, their fanbase wasn’t happy with this change.

As one of my additions to this inventory type I would like the items not just be x * y rectangles and have any combinations of tiles as shape. This is a risky addition since from the opinions I gathered, having to play Tetris every time you open the inventory gets old too quick for many players. Have in mind this is the case with rectangular items, so adding more complexity to it could make it worse for those players.

Loop shaped item from one of the first versions of the game. This is what I meant by items of any shape.

My hypothesis is that, these games I mentioned had way too many different items to manage. That’s one of the biggest complains of the players. If there’s few stackable objects, it makes the managing quite simple. The problem comes when the player must get rid of hard-earned items in substation of others. If the player is going to be given a lot of different item choices, another type of inventory would be better suited.

My inventory will be a simple one, with few different items to place which will reduce the frustration of the players. The solution to the frustration of having to let go of hard-earned items isn’t one that the game inventory can solve. It is true that giving the players an infinite inventory would get rid of it, but the first reason why I’m researching this inventory is because the immersion and gratification it brings when done right. Another possible solution would be to make resources scarce. If the player finds few items, substitutions won’t be needed, and it will also create a bigger attachment to the ones they keep.

1.2 Goal

The size of the inventory will be small. This is not an arbitrary decision, as I said, the game this inventory was designed for is one with a small amount of resources. The inventory should be in consonance with this decision, and make the player attached to the few items they can pile up.

Items should be able to rotate, to make it easier for the player to fit all the different shapes of the items. They won’t be just rectangles.

The implementation should allow the creation of multiple grid inventories at the same time. This is done preemptively to allow the player to move items from the ground or storages to their inventory without problem.

1.3 Development

1.3.1 Inventory and Items

To create the grid inventory, I followed a very detailed tutorial by Greg Dev Stuff. It helped me understand how Unity Canvas worked and I started thinking about the differences I wanted my inventory to have. I planned my inventory to be used in a post-apocalyptic game setting, similar to games like Rust or Day Z. For that reason, I decided to go with a plain grey style, it should be simple and not bring joy to look at, consonant to the game world.

The main difference was the shape of the items I wanted to store. The most common approach to this has always been rectangular items, so every item would have a x * y shape. This greatly helps when implementing rotations since rotating rectangles is quite simple. I wanted to have items with any shape, not just rectangles, and I must say this was harder than I thought.

In the tutorial, the way items are implemented, is with a scriptable object that contains all the items data. I took my own approach to this, so all items are instantiated from an empty item prefab which is then assigned an ItemData object to it. The item will then copy the attributes from the scriptable, so they can be modified without changing the original item data. Modifications would be performed with actions like rotations.

The main attributes of an ItemData at this time are the following:

  • The item’s sprite.
  • 5 arrays of length 5 that would contain the shape of the item. This would work as a 5*5 matrix where there would only be 1s in the positions occupied by the item.
  • 4 arrays of length 2 that would represent the texture’s pivot coordinates. There should be one for each position the item could be in. Every time the item is rotated, the next pivot array is selected so the texture is represented correctly.

The main difference between my approach and the tutorial’s is, that in the tutorial items would just have a height and a width. Now they have a whole matrix where I had complete freedom to decide the shape of my items. This is how the gun shape matrix would look.

For the inventory grids, I just needed a texture placed as an image in a canvas that would repeat itself when extended. To this image I would attach a script that gives it the grid behavior. To the camera I attached a script that allowed the player to interact with the grids.

This way the camera would always “know” which grid the player is hovering over. With this implementation moving items between multiple inventories would be perfectly possible.

1.3.2 Rotations

With the way the items shape was defined, a 90-degree rotation would be applied by placing the matrix in a x y axis and multiplying the coordinates of each cell by a 90-degree rotation matrix like this:

This sounds simple but the implementation was one of the hardest challenges of these research. There were a few obstacles to this, like solving the fact that using this rotations matrix would result in negative coordinates that I couldn’t place in my item-shape-matrix so I had to add an offset to the result, so all coordinates were positive.

This is how the offset is calculated and applied. Remember, this is done after calculating the rotated shape of the item, which returns some negative coordinates. With the offset I move the shape just enough, so all coordinates are positive.

There are two offsets, the left and the bottom. Each one will end up being coordinate of the furthest apart point of the rotated shape. After adding it to the rotated shape the result it will be placed in the bottom left corner of the matrix, just like in the example.

The texture pivots required some brainstorming too, otherwise the image of the item would appear so far from the actual position in the grid. The solution was handwriting the coordinates for each of the 4 positions an item could take and iterating through them with each rotation.

1.4 Perspective on the result

After doing some research, the way this grid inventory was created is one of the most simple and optimal, so there is no reason not to do it the way Greg Dev Stuff explained. The different shaped items was the spin I wanted to give to this mechanic, and I am not completely satisfied with the result I got.

The way it is now, every item contains a lot more information than what a rectangular item would. This makes it unintuitive to create new items, and if another developer wanted to use my system, a lot of documentation would be needed. Technical problems aside, I’m not sure if this brings that much value to the product.

After the playtests, many testers pointed out how interesting was having all these weirdly shaped items, and how it took them a bit longer to figure out how to place them which made it more “fun”.

After reading some opinions of people on grid inventories, many said that playing Tetris every time they opened the inventory broke the game loop a lot. Have in mind this was with rectangular items, so in a longer playthrough having to play Tetris with all these shapes would have a worse result.

But it is internet’s nature to have polarized opinions. There were many that explained how organizing a tile inventory brought joy and enriched their gameplay. So, I as a developer have to decide which group to satisfy. It will be the one I belong to, the one that likes managing inventories.

Overall, If I found survival simulation game with this inventory system in place, I think it would make for some gratifying situations. The fact that the items are harder to fit together makes for a bigger satisfaction when you find the right disposition, and I I’m a order maniac so I’d love it.

Chapter 2: Giving feedback to the players

2.1 Research

As Editorial Aela mentions in their article “UX designers develop signals and provide feedback for the players so they can quickly know what’s happening at a given point and the results of their actions in the game”. I need to make the player’s actions clear if I want my gameplay to feel smooth and responsive.

For an inventory, one of the best clues you can give are highlights. Since the item shapes are quite unusual, it is even more important to give information about them to the players. This was one of the biggest comments I got while performing playtest.

Showing where the item is being placed is also really helpful for the navigation of the inventory. This was one of the main milestones of the project since it is so important for the sake of the User Experience. Highlights will be the only way to show the player if their actions are correct.

2.2 Goal

My main concern is showing the players what the item’s shape is just by hovering over them. After that, adding another layer to the system, where the highlights are shown while holding the items. This will make perfectly clear where the item is being placed.

Many games have similar highlight system in place, Minecraft is one of them. The obvious difference being that all items in Minecraft take just 1 tile.

The last and most ambitious goal is to make the highlights detect which tiles are already occupied by another item and highlight them in another color. This would greatly help with placing the items since the player would always know what’s holding them back from placing an item.

2.3 Development

2.3.1 First layer: Highlight on mouse hover

As I already explained my first objective was setting up the structure to create highlights over objects. I had two main ideas in mind when planning how to implement it:

  • Changing the texture of the grid whenever the mouse hovered over an item.
  • Instantiating a transparent object over each of the tiles of whichever item was being hovered.

I ended up deciding to go for the second option. The first approach seemed harder to do for me given that I have much less experience with shaders and textures than code but I believe the first option is completely doable and probably more efficient.

The whole system would revolve around some simple code logic. If the mouse was over a grid and an item at the same time, instantiate one object over every single position the item is occupying. I just need two variables for that, one for the grid that’s being hovered and another one for the items that’s being hovered.

This is the flowchart of my first idea. This checks would be done inside the update loop of the game.

The way I would highlight the item was instantiating a transparent object over all the tiles of it. For that, there had to be a check in place that detected if an item was already being highlighted so no more objects were instantiated. I did this by checking if a variable called highlightedItem was null before placing the highlight.

Another important part of the behavior was making sure the highlight got updated every time the mouse hovered over a new item. To achieve that, if the highlightedItem was different from the hoveredItem the highlight would be moved to the new location where the mouse is placed.

Here you can see the system in action.

2.3.2 Second layer: Show placing highlight

I already created the skeleton that would allow me to go a little further with the highlights. My next milestone was to add highlights to the placing action. Once the player clicks on an item, they start holding it and another click will place it wherever the mouse is pointing to. Until now there was no way to know which tiles were going to be occupied after placing the item so a highlight was the solution.

For this, I implemented a function that “fake placed the item” over the tile the mouse was hovering. To put it clearly, once the player holds an item, every time the mouse hovers over a tile, the player would be able to see which tiles the item would take if it was placed there. Getting the coordinates of this “fake placing”, I could instantiate the same transparent objects on them.

This is the method used to detect the “what if the item was placed here” tiles. It has to be performed over a grid, that would be the hovered grid. It takes as input the item the player is holding and the coordinates of the tile the mouse is hovering.

In the first “if” statement of the method I check whether the item could be placed in that tile. If it can’t I just return an empty set of coordinates. Those coordinates are the ones used to instantiate the highlight shadow. So if the item can’t be placed there, no highlight would be placed. This would be solved in the next milestone.

Once I had the coordinates of the tiles the item would occupy, the placing of the highlight was performed the same way as before (by instancing an object over those coordinates). And with some more logic, it was correctly updated. In this case the updates would be done whenever the hovered tile changed.

You can see I ended up creating a lot of variables storing the state of the highlights. I ended up with 4 of them:

  • hoveredItem
  • highlightedItem
  • hoveredTile
  • highlightedTile

All these are harmoniously updated every time the highlights are placed or removed. They are mostly necessary to check when the mouse hovers from one item to another without touching an empty tile. By checking if hoveredItem is equal to highlightedItem, I can tell if the mouse has gone from one item to another. If so, all highlights are cleared, and since highlightedItem becomes null, a new highlight can be placed on the hoveredItem.

You can see how now the players have an idea where their items are going to be placed.

2.3.3 Third and last layer: Illegal tile highlight

The last touch to the system was showing the player exactly which are the tiles of the item that can’t be placed. This way the players are being given info on exactly what they are doing wrong and they know how to solve it. This would reduce the frustration by a lot since now they won’t need to “memorize” the shapes of all other items before placing one.

By adding a highlight of a different color I could tell the player which exact tiles are causing them problems. This added a higher complexity to the system, placing highlight should return 2 sets of tiles, the legals and the illegal ones. The illegals being the ones occupied by another item.

For this I used a dictionary. Dictionaries are a way to associate key value pairs, so I could assign a “color” to each one of the tiles the item would occupy based on the coordinates the mouse is hovering.

You can see I use a loop that iterates over all the tiles of the object. For each one of them I check if it could be placed in their respective location in the grid. If the result is positive, I give them the value 1 which means the highlight will be normal colored. If they can’t fit in their assigned location, they are given the value 0, which means the tile is “illegal” and thus red colored.
Here you can see the last version of the highlights in action.

2.4 Perspective on the result

This was one of the most satisfying parts of the project to develop. Mainly because the results were apparent as soon as they were implemented. During the playtests, some players got to play with the final version and others with some in between versions. The playtesters were game developers, some just played games and even a few weren’t even usual players and through the 3 groups they all noticed the lack of feedback in the versions without this system.

The players that didn’t have the whole highlight system available often had difficulties to place the items and even asked why couldn’t they place an specific item. Many commented that a mechanic like this would be really appreciated.

The last playtests that were performed did have this system in place, they felt much smoother and obviously there were no complaints about the shapes of the items. As I already said, the results are impeccable and I believe it is a great example on how feedback makes the user experience much better.

Chapter 3: Preparing a demo

3.1 Research

Since this research dug into user experience a lot, I needed some tool that allowed me to perform playtests on some users to know their experiences. These would be of great importance for my project. Since I’m developing an interactive UI element, I believe it is much easier to spot possible improvements, compared to for a example a game mechanic where one possible outcome would be to scrap the whole system.

As this article by Vera Rabkina mentions, playtests are often resisted by the developers for multiple reasons. These being, emotional connection to the product which makes it hard to take criticism, how difficult it is to scale up from so many different interviews and how much time it usually takes to iterate over the product and the interviews.

For a project like this, approaching the target audience is of great importance. As the previous article mentions, having access to target reception data early in development can greatly hasten the iterations required to reach the desired product. I knew from the beginning I should get my hands dirty with this matter and I should perform interviews from as early as possible in development.

As I said, my first impression when considering doing playtests was that they would be simple to do. At the beginning I also believed, doing playtests consisted of letting someone do a run of my demo, and then ask what were their feelings about it. I was wrong, and I noticed that after the first couple of interviews. During the class guild meetings I understood that I needed a plan, with questions that allowed me to get the exact info I wanted.

A plan wasn’t enough since I also needed a playable demo. One where the players just moved a couple of items around wasn’t enough. There had to be an objective that motivated them to get as engaged to the system as possible.

3.2 Goal

My main intent was to figure out if the inventory I created was making the players think. This inventory was designed with a survival simulation game in mind. A game that would make the players consider their resources as much as possible, and one where the inventory would have a big role. I want decisions to be made, this is my final goal. The opposite of this would be to have players mindlessly pick up all items they see, which in other game contexts would work but not the one I’m working towards.

There was a big problem, an inventory without a game behind it doesn’t motivate a player to do any decisions. In broader terms, It is hard to playtest an UI without a game context wrapped around it. I had to figure out a replacement for a whole “survival simulation game” that would place the players in the situations I want them to take decisions in.

3.3 Development

3.3.1 First playable demo

The simplest solution I found to motivate the players to move items around was creating a score system. A system that would reward the players similar to how, picking up items would improve your experience while playing a survival game.

For this, I decided to create a minigame where a set of random items would spawn in a “floor inventory”. The player should pick up as many items from that inventory to their own, which would be of lesser size. This would be done under a timer, stressing them a little bit, which would cause a bigger friction with the mechanics.

The points each item would give was what caused the biggest difference in the playtests. My first approach to this, was to give the player 1 point for each tile of their inventory they managed to occupy. This way, the maximum score possible would be the total tile surface of the player’s inventory.

There were 3 portions I needed to implement to create this demo:

  • An item spawning algorithm, that filled the ground with as many items as possible.
  • A timer that would start ticking after the player says they are ready.
  • The score counting system

The first one was the hardest to implement. If I wanted each game to be different, I needed it to work correctly. What I ended up with was an algorithm that worked like this:

For each tile of the floor inventory if the tile is empty

  • 1 Create a random item from the total list of items
  • 2 Rotate it up to 3 times, decided randomly
  • 3 Try to place it in all tiles of floor the inventory until one placement is successful.
These are 3 different generations of items for the minigame. You can see the items are different from the previous example recordings. This is an earlier version with different items.

And this is how a playtest would look. You can see the game ends when all the tiles are occupied but there is one problem with this. It doesn’t play out like how you would actually use the inventory in a game. Here you just put as many items as you can, without thinking about the actual usefulness of them. That’s why I had to think of a new approach.

3.3.2 Introducing contexts

After some brainstorming and some discussion with our teacher Coline, I ended up deciding the best possible approach to simulate a game context was to create random statistics that would determine how useful would the items be in that specific situation.

There are a few things that I think could add up to create a survival game context. Depending on the context the point value of the objects will change. It will no longer be the tiles each item occupies, but a the result after being modified by the context parameters.

  • Location: the location the player is placed in conditions which items are more useful. Wide field in the hills: long range weapons, have more value. Inside a dark building: short range weapons, flashlights.
  • Stat bars: Having a hunger bar generated at the beginning with a random value would affect the value of food items. If the character is starving, the player should prioritize food.
  • Enemy danger: this stat would replace the feeling of danger when enemies are around you. This usually causes the player to have to arrange their inventory faster, so in my demo the higher the danger, the less time the player will have to get a high score.

All these variables will add up to a set of context stats. These stats will be different each game to create an unique context setting that will decide the value of the items generated:

  • Short range power
  • Mid-range power
  • Long range power
  • Hunger
  • Thirst
  • Health

It is easily understood with an example:

In this instance, you can see the value of mid range weapons will be bigger than others. This would cause the players to pick one weapon over the other, similar to how they would do in a survival game.

To implement this I defined 4 possible locations, each one with different optimal weapons. The hunger, health, thirst and danger were randomly generated numbers. A different context would be generated for each game. From the items side, they all would have to have the same stats that would be used to calculate their point value.

With both sets of stats, item’s and context’s the score of an item could be calculated by applying the context modifier over each placed item’s own stats. This resulted in weapons like the shotgun, give 12 points in some favorable context and 6 in unfavorable contexts.

Consumable items, like food or water bottles updated the context stats. This meant that if the context said your player was thirsty, the first 2 or so bottles would be very valuable but the ones following after would be much less valuable. The item spawning had to be updated too, so each weapon could only appear once, it made much more sense to just have 1 available of each type.

This got much closer to the experience of playing a survival game. The way testers played the demo changed a lot from the last version so I can consider this implementation a success.

In this example you can see how the long range weapons are much useful, so the player will lean to place the sniper rifle first, since it is the best performing at long ranges as can be seen in the menu of the left. The stats can be seen update whenever consumables are placed inside the inventory.

3.3.3 Playtest plan

Using some feedback from the guild meetings and a few online resources like this questionnaire published by theTechnische Universiteit Eindhoven I managed to create an interview of 6 questions. I must say this was a great challenge for me, never before had I done something like this so the results weren’t as good as I would have liked them too.

The questions were the following:

  •  1 From 0-5 how much effort did it take you to get that score? -> The average result was 2,25 which was a bit higher than expected since the demo was supposed to be simple. Since a few testers weren’t familiar with games, the results increased a lot.
  • 2 Why didn’t you place x item (while pointing at an item they didn’t place)? -> This way I can try to understand the decisions the player did. if it was because they didn’t think it was the best option, or it didn’t fit they already are solving the dilemmas I’m looking for. The results were quite favorable, almost all players said they were considering the context while placing the items.
  • 3 Would you like to try again to get a higher score? -> If they do I can get more info, and also it shows if the system is doesn’t cause frustration. More than a 70% of the players said they wanted to try to get a higher score.
  • 4 Repeat the 2nd question. -> So I could get as much data as the decision-making the players were doing.
  • 5 From 0-5 how much would you like to see this system in the next survival game you play? -> Part of my research is finding out if this system is more enjoyable than other systems. From the results, I believe I was right, since the average was 3,35 which was quite a positive result.
  • 6 What was your biggest inconvenience/annoyance while playing the demo? -> This question was just to get some feedback on the mechanics themselves. It was from here where I got a lot of improvement like the different color highlighting.

3.4 Perspective on the result

I must say I was quite proud of how the context system worked. Not so much of the playtest questions, but they helped me understand how the players were doing their decisions anyways. The biggest things I got out of it was that players were actually having to make decisions and how important giving feedback in UIs was.

One should consider that even though the context was trying to simulate a whole game, the tests didn’t play out like an actual game with this inventory would. The results were overall positive, but no players played more than 10 minutes with it, the opinions could and probably would change after playing a few hours with this inventory.

What I ended up taking out of it was, that adding more complexity to the items adds immersion and a bigger fun component. In longer game sessions this might change, but the increased challenge of arranging these shapes looks like would be a welcomed change by the general public.

Chapter 4: Final Chapter – Extras

4.1 Research

There is little research about this section. There were a few new mechanics I wanted to implement to make the system a little more deep and challenging. I ended up just having time to implement one of them which was Tetris-like gravity.

Adding more complexity to the inventory system was something I knew wouldn’t add up to the general game experience. I already talked about how players shouldn’t spend too much time on their inventories, it should actually be playing the game. Adding more mechanics on top of it would make players spend too much time inside the UI.

There are mechanics that would actually improve the speed of the system, like shortcuts, auto-sorting or quick-transfer of items. You can see those implemented already in many famous titles like Minecraft, or Subnautica.

4.2 Goal

Seeing the actual opinions of players on adding more layers to the inventory system. Since there’s been little innovation in these field, and I had already seen how adding complexity to the shapes of the items was well received I wanted to test the reception of other changes.

The one I decided to go for was Tetris-like gravity. This came to mind when thinking how objects fall down to the bottom of a bag when you place them in it. This would add some realism and another layer to consider when arranging the items.

4.3 Development

I created a simple script I could attach to any grid inventory that would make the items in it behave like the bricks in Tetris do. This was quite simple as I just had to move the items down a tile every few fractions of a second as long as there was nothing under them or they had reached the bottom.

The results can be seen here.

4.4 Perspective on the result

Not many playtesters got to play this version of the game, but the ones that did almost didn’t notice it. After placing one item and seeing it dropped, the rest of the session played out similarly to the past versions. It was mentioned how it didn’t really add much to the experience, and how in longer playing sessions I would just become an annoyance more than an immersive change.

I had many other little ideas I wanted to add, but because of time couldn’t. Seeing the results of this one and reading through articles, I understand how adding this type of changes are almost unnoticed by the players and doesn’t affect the experience like the item shapes do.

I believe the gravity wasn’t an improvement overall. That’s different for the odd item shapes, I do think they were an improvement over the classic rectangle shapes.

Conclusion

To close things up, the development and testing of a grid inventory system with differently shaped items showed mixed results. The system was found to be simple and optimal, and the addition of oddly shaped items was found to be interesting and fun by some playtesters.

Additionally, the feedback system was found to be crucial for improving the user experience, as playtesters noticed a lack of feedback in earlier versions. The gravity feature was found to be unnecessary and potentially annoying for longer sessions, while the oddly shaped items were considered an improvement over traditional rectangular shapes.

Overall, one could say the additions to the system were positive. From one side, the focus on UI feedback was a great success, not many inventories are so clear about the placement of the items. The odd shapes of the items added to the immersion for multiple testers.

Adding too many complex mechanics to a secondary element like inventories are can have bad results. That isn’t the case with UI feedback or smoothness implementations like shortcuts, these are almost always welcomed by the players.

References