My next step is to work on the inventory system, so empty your pockets and take a look inside fearless adventurer!

Inventory and resources

Fig 1 - Some sketch concepts I made for the UI and the inventory — Fig 1 – Some sketch concepts I made for the UI and the inventory

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.

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 or The Hobbit where every time I needed to know what items I was carrying with me. Sometime later games like Everyone’s a Wally (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 adventure games like Monkey Island 2, Day of The Tentacle or Full Throttle where text was replaced by real graphics.

So I spent a couple of days looking into the most practical way to create a system with these features in Unity. 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 had a much elaborate way to handle this systems.

Fig 2 - Inventory system evolution: Everyone's a Wally, Secret of Monkey Island, Day of the Tentacle, Pokemon, Metal Gear Solid and Zelda Breath of the Wild — Fig 2 – Inventory system evolution: Everyone’s a Wally, Secret of Monkey Island, Day of the Tentacle, Pokemon, Metal Gear Solid and Zelda Breath of the Wild

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, Metal Gear, Final Fantasy or Skyrim are the most refined evolution of these systems, not to mention the later remakes of the first Zelda games where special emphasis has been placed on improving these systems, due to their importance in the final gameplay.

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.

Again, Moore’s book, chapter 8, offers us a clear description of the two basic types of inventories:

Passive inventory: 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.

Active inventory: in this kind of implementations, the 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.

My personal contribution to the project (6): Inventory system

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. We 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.

For our demo a passive inventory 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.

Fig 3 - Inventory system for Keep it Burning — Fig 3 – Basic Inventory for Keep it Burning

Fig 3 - Inventory system for Keep it Burning (top left corner) — Fig 4 – Picking up objects during the gameplay (note the inventory on the top left corner)

In the real world, resources are assets that can be used to accomplish certain goals. In a game, resources play much the same role.

Managing resources and determining how and when to control player access to them is a key part of the game designer’s 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?

By definition, resources must have both utility and scarcity in the game system. If they do not have utility, they are essentially useless. If the resources are overly abundant, they will lose their value in the system.

Lives: the classic resource in action games are lives, ore is always better and there’s no downside to earning lives.
Units: 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.
Health: Health can be a separate resource type, or it can be an attribute of an individual life in a game.
Currency: 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.
Actions: in some games, actions, such as moves or turns, can be considered resources.
Power ups: a boost of some sort to the player. Power-up objects are generally made scarce, so that finding them doesn’t make the game too easy.
Inventory: 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.
Time: 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.

Placing objects in the field

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)

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, discarding for the moment the random location of elements or even the use of procedural algorithms to generate the levels computationally.

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.

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.

The Game loop (Part 1)

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.

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)

Fig 8 - Basic flow chart diagrams for the main loop of Keep It Burning — Fig 5 – Basic flow chart diagrams for the main loop of Keep It Burning

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. Our approach, once again, is slightly conservative due to the short lead times. We 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.

More about our findings concerning the game loop for Keep It Burning on next week’s entry.

Goals & challenges

The goal is the ostensible reason for playing, but the goal is never easily attained; rather, it is the obscure object of desire.

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)

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)

Rewards of glory: 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.
Rewards of sustenance: 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.
Rewards of access: allowing a player access to new locations or resources that were previously inaccessible are very important rewards and they are generally used only once, and they have no other value to the player once they’ve been used.
Rewards of facility: 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.

One of the things that designers use to craft a player’s experience of trying to reach their goal is challenge. Challenge is often described in relation to the psychologist Mihaly Csikszentmihalyi’s idea of the flow state, where flow is described as a state of high focus and enjoyment.

Fig 5 - Csikszentmihalyi’s flow state representation chart — Fig 6 – Csikszentmihalyi’s flow state representation chart

For games, flow is a response to challenge meeting the player’s skill level, and it creates a kind of play that can be highly satisfying. But equally satisfying are games that don’t challenge players’ 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’s not the only kind of experience players can have in games, and it’s not better than other kinds of experiences. (Macklin 2016 :68)

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)

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.

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.

Weekly Challenge: SWOT chart

As part of this week’s lectures, I prepared a SWOT chart. It took me just a couple of hours since I had some of practice working on these. When I thought it was pretty complete, I asked the rest of the team to work on it as well.

Fig 4 - SWOT chart for the Wild Branch team — Fig 7 – SWOT chart for the Wild Branch team

Some of the comments I wrote about the key areas were rather hard, but certain in my view. This made me doubt when it comes to publish them fearing that any member made personal comments about it. But contrary to what I expected, I think everybody agreed on the points of view expressed.

List of figures

Fig 1. Early sketch concepts made by the author to illustrate some mechanics and UI elements of Keep it Burning. Image by the author.
Fig 2. Inventory system evolution: Everyone’s a Wally (c) Mikro Gen, Secret of Monkey Island & Day of the Tentacle (c) Lucasarts Games, Pokemon (c) The Pokémon Company, Metal Gear Solid (c) Konami Computer Entertainment, and Zelda Breath of the Wild (Nintendo)
Fig 3. Basic Inventory for Keep it Burning. Image by the author.
Fig 4. Early gameplay of the demo. Image capture by the author.
Fig 5. Basic flow chart diagrams for the main loop of Keep It Burning by the author.
Fig 5. Csikszentmihalyi’s flow state representation.
Fig 6. SWOT chart for the Wild Branch Team. Image by the author.

References

Salen K, Zimmerman E. 2004.’Rules of Play: Game Design Fundamentals‘. The MIT Press.

Brathwaite B, Schreiber I. 2009. ‘Challenges for Game Designers‘. Charles River Media.

Fullerton, T. 2008. ‘Game Design Workshop‘. Published by Elsevier Inc.

Hallford N, Hallford, J. 2001.’Swords and Circuitry: A Designer’s Guide to Computer Role Playing Games‘. Boston: Premier Press

Moore, M. 2011. ‘Basics of Game Design‘. Published by Taylor & Francis Group, LCC.

Mihaly, C. 1996. ‘Creativity: Flow and the Psychology of Discovery and Invention‘. New York: Harper Perennial.

Macklin C, Sharp J. 2016. ‘Games, Designs and Play A Detailed Approach To Iterative Game Design‘. Pearson Education Inc.

Schell, J. 2015. ‘The Art of Game Design A Book of Lenses‘. Second Edition. CRC Press. Taylor & Francis Group.

Wegner C, Seele S, Buhler H. 2017. ‘Comparison of Two Inventors Design Concepts in a Collaborative Virtual Reality Serious Game‘.(CHI PLAY ’17 Extended Abstracts). Association for Computing Machinery, New York.

GDD730 Week 7