\n
![\"\"](\"https:\/\/www.patricioland.com\/wp-content\/uploads\/2021\/08\/blueinventory3.png\")
My next step is to work on the inventory system, so empty your pockets and take a look inside fearless adventurer!\n<\/span><\/p>\n
\u00a0<\/span><\/p>\n <\/p>\n Most games include an inventory to carry items collected during the gameplay, some allow the manipulation or combination of those elements; others function as simple virtual pockets, and they are nothing more like than a list. Having created a graphic adventure before, one of my biggest headaches was related to the number of items this system must handle and how such elements should be combined or not. If you do not pay good attention all this might get out of control very fast.<\/p>\n I’m old enough to remember a couple of things regarding inventories. I remember, for example, typing this word in the parser of the Zork<\/strong> or The<\/strong>\u00a0Hobbit<\/strong> where every time I needed to know what items I was carrying with me. Sometime later games like Everyone’s a Wally<\/strong> (a precursor to adventure games) gave us a visual representation of up to two of these objects at the top of the screen. Things got more interesting with the second wave of Lucas Arts<\/strong> adventure games like Monkey Island 2<\/strong>, Day of The Tentacle<\/strong> or Full Throttle<\/strong> where text was replaced by real graphics.<\/p>\n So I spent a couple of days looking into the most practical way to create a system with these features in Unity<\/strong>. My first approach was based upon the classic form of using a vector variables or matrix to store the elements; a dynamic structure that allows to delete, sort or add components making proper use of the memory. My old notes on developing data structures in Pascal they would have been very helpful now (at least in theory) however, I learned that Unity<\/strong> had a much elaborate way to handle this systems.<\/p>\n All these examples divided a screen area between inventory (or a primitive version of it) and game zone until some RPGs started to offer so many items that soon there was no more space on the same screen and we had to access our catalog through menus. The inventory is now a fundamental part of the game, designed to perform a series of tasks far beyond being a mere repository of things. Games like Resident Evil<\/strong>, Metal Gear<\/strong>, Final Fantasy<\/strong> or Skyrim<\/strong> are the most refined evolution of these systems, not to mention the later remakes of the first Zelda<\/strong> games where special emphasis has been placed on improving these systems, due to their importance in the final gameplay.<\/p>\n It is not my intention to make a treatise on this subject in this entry (although given the scarce amount of detailed information I have been able to find in the bibliography, I will surely focus on it in the future). For practical purposes, it seems to me that the following classification will be provisionally satisfactory.<\/p>\n Again, Moore’s<\/strong> book, chapter 8, offers us a clear description of the two basic types of inventories:<\/p>\n Passive inventory<\/strong><\/span>: is an interface screen or part of a screen where items are stored which the player does not directly manipulate. Items can be grouped together by functionality. The primary purpose is to show the player clearly what items have so far been collected. As a consequence of this automatization, one drawback to such an approach is that the player might not notice if a resource has reached a maximum level or has been completely emptied. Empty spaces can provide a clue for the player, indicating that some item are yet to be found.<\/p>\n Active inventory<\/strong><\/span>: in this kind of implementations,\u00a0the player has free rein to combine, move things around and even discard items that are no longer wanted. RPGs have the most complex inventories, and their layouts and functionality can vary widely from one game to another. The inventory can be seen as a giant knapsack with enough storage to see the character or party through consider- able periods of exploration and combat before having to find another source of supplies.<\/p>\n We decided that all the items the player can use will be added to the inventory automatically so as not to get complicated with a drag and drop system for both gathering and using the elements to be found along the way.\u00a0We have also decided that just a few items, such as logs, stones or wood, would be more than enough for the purpose of this demo.<\/p>\n For our demo a passive inventory<\/strong> seems to be the practical way to go. Though not extremely original, I thought it would be fun to use a flat stone drawing as a base for putting the items on it by way of a board.<\/p>\n <\/p>\n In the real world, resources are assets that can be used to accomplish certain goals. In a game, resources play much the same role.<\/p>\n Managing resources and determining how and when to control player access to them is a key part of the game designer\u2019s job. How does a designer decide what resources to offer to players? And how does a player control access to those resources to maintain challenge in the game?<\/p>\n By definition, resources must have both utility and scarcity in the game system. If they do not have utility, they are \u00a0essentially useless. If the resources are overly abundant, they will lose their value in the system.<\/p>\n Lives<\/strong><\/span>: the classic resource in action games are lives, ore is always better and there\u2019s no downside to earning lives. As important as figuring out the layout of the playfield is the task of determining where items and encounters will be placed. Obviously, these game objects cannot be placed on or behind impassable terrain or players will never get to them. (Moore 2001 :302-303)<\/strong><\/p><\/blockquote>\n<\/div>\n<\/div>\n<\/div>\n When designing the map of the area, we decided to place some kind of particular element on the map so that they functioned as a guide to initiate the player in the resolution of the first mission,\u00a0discarding for the moment the random location of elements or even the use of procedural algorithms to generate the levels computationally.\u00a0<\/span><\/p>\n For this purpose, we used some small rocks with a little red hand-painted on them, like a cave painting. The second function of these boulders is to invite the player to explore the area. These rocks cannot be moved from their place, and the use of sound (the drums played by the tribal elder) should also serve as a guide, but I will talk about this later in the corresponding section.<\/p>\n Given our interest in demonstrating the importance of maintaining the balance of the environment, used items and felled trees will not grow back or reappear at least until the player discovers how to plant seeds and restore the balance, something that we have to integrate into the game later on.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n Every game has a game loop during which the player has the opportunity to perform actions repeatedly. Some of these loops are simple, with few mechanics to choose from, others are rather more complicated.\u00a0<\/span><\/p>\n A game’s core mechanic contains the experiential building blocks of player interactivity. It represents the essential mom-ent-to-moment activity of players, something that is repeated over and over throughout a game. During a game, core mechanics create patterns of behavior, which manifest as experience for players. The core mechanic is the essential nugget of game activity, the mechanism through which players make meaningful choices and arrive at a meaningful play experience. It is therefore very important to be able to identify the core mechanic at the beginning of the design process, even if it changes as the game develops. (Salen 2004 :394-396)\u00a0<\/strong><\/p><\/blockquote>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n As in so many other areas, a designer may have a set of mechanics in mind that he wishes to implement directly inspired by some other game where he has found that they work well, and sometimes this prototyping stage is fertile ground for trying different things and experimenting with it.\u00a0Our approach, once again, is slightly conservative due to the short lead times.\u00a0We did not find it important to emphasize too much that the player had to collect timber to eventually keep the fire burning. This should become obvious after a few minutes, revealing itself naturally. During the subsequent gameplay, we noticed that some players simply enjoyed collecting whatever objects were around or even cutting down trees, without the need to perform these activities still influencing the development of the game.<\/p>\n More about our findings concerning the game loop for Keep It Burning on next week’s entry.<\/a><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n The goal is the ostensible reason for playing, but the goal is never easily attained; rather, it is the obscure object of desire.<\/p>\n The goal helps move players through the space of possibility, a space stretched between the starting state of the game and its outcome like a billowing cloth staked to the ground. The goal acts to guide the players along the axis defined by the beginning and the end, letting them know if they are advancing or falling behind. (Salen 2004 :428)\u00a0<\/strong><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n It’s surprising how many developers forget that it’s the victories and the treasures-not the obstacles-that make people interested in playing in the first place. If you stop giving out the carrots that will keep players excited, or even worse, if you start punishing them for their curiosity, you’re only going to drive away the very people who want to enjoy your game. (Hallford 2001)\u00a0<\/strong><\/p>\n Rewards of glory<\/strong><\/span>: are all the things you’re going to give to the player that have absolutely no impact on the game play itself but will be things they end up taking away from the experience, from winning the game to defeating a big boss. One of the things that designers use to craft a player\u2019s experience of trying to reach their goal is challenge. Challenge is often described in relation to the psychologist Mihaly Csikszentmihalyi\u2019s<\/strong> idea of the flow state, where flow is described as a state of high focus and enjoyment.<\/p>\n For games, flow is a response to challenge meeting the player\u2019s skill level, and it creates a kind of play that can be highly satisfying. But equally satisfying are games that don\u2019t challenge players\u2019 skill. Instead, the game might confront the player with a challenging narrative or an experience that the player can enjoy regardless of skill. So, flow can be experienced in games, but it\u2019s not the only kind of experience players can have in games, and it\u2019s not better than other kinds of experiences. (Macklin 2016 :68)<\/strong><\/p><\/blockquote>\n Concerning videogames the challenge gradually evolves over a sequence of levels as we can see on the above chart on the left. This situation must be balanced depending on each player skills and speed to finish or solve a level. This connection between skill and the speed of finishing a level helps keep skilled players from getting bored.(Schell 2015 :141)<\/strong><\/p>\n While the first scenario may be good enough, the second box presents us with a much more exciting option for the player (right on the same chart): a tense and release, tense and release cycle where we face an increasing challenge, followed by a reward, which gives an easier period of less challenge just to get the challenge ramping up again, and so on.<\/p>\n I think that our prototype at this point is framed in the first case and, at times, it can even get boring. We need to So we will have to add elements and modify the mapping to keep the player motivated.<\/p>\n<\/div>\n<\/div>\n<\/div>\nInventory and resources<\/span><\/span><\/h1>\n
![\"Fig](\"https:\/\/www.patricioland.com\/wp-content\/uploads\/2021\/08\/KIBconcepts.jpg\")
<\/a>My personal contribution to the project (6): Inventory system<\/b><\/span><\/h1>\n
<\/a>
\nUnits<\/strong><\/span>: in games in which the player is represented in the game by more than one object at a time, they generally have unit resources to manage rather than lives. Units can be all of one kind, or a number of different types; can keep the same values throughout the game, or they can upgrade or evolve.
\nHealth<\/strong><\/span>: Health can be a separate resource type, or it can be an attribute of an individual life in a game.
\nCurrency<\/strong><\/span>: one of the most powerful resource types in any game is the use of currency to facilitate trade. Currency is one of the key elements of an in-game economy.
\nActions<\/strong><\/span>: in some games, actions, such as moves or turns, can be considered resources.
\nPower ups<\/strong><\/span>: a boost of some sort to the player. Power-up objects are generally made scarce, so that finding them doesn\u2019t make the game too easy.
\nInventory<\/strong><\/span>: some game systems allow players to collect and manage game objects that are not power-ups or units. These objects help players to accomplish game objectives, and they are made scarce.
\nTime<\/strong><\/span>: Some games use time as a resource restricting player actions by time or phases of the game in periods of time, an inherently dramatic force when used as a resource.<\/p>\nPlacing objects in the field<\/span><\/h1>\n
The Game loop (Part 1)<\/span><\/span><\/h1>\n
<\/a>\u00a0<\/span><\/span>Goals & challenges<\/span><\/span><\/h1>\n
\nRewards of sustenance<\/strong><\/span>: recompenses of this nature are given so the player can maintain their avatar’s status quo and keep all the things they’ve gained in the game so far as medic kits, health packs, mana potions, tech armour and so on.
\nRewards of access<\/strong><\/span>: allowing \u00a0a player access to new locations or resources that were previously inaccessible are very important rewards and\u00a0they are generally used only once, and they have no other value to the player once they’ve been used.
\nRewards of facility<\/strong><\/span>: they enable a player to do things they couldn’t do before or enhance abilities they already possess. They should increase the number of strategies and options that player will have for playing the game.<\/p>\n<\/a>