Player Inventory

Initiating the Player's Inventory
The 'PlayerInventory' class will be attached to the player's character game object and will store a list of objects the player has collected.

The list will be read-only meaning I will need to create multiple methods to manipulate the list. The class will require a method to add an item, merge an item, remove an item and retrieve read-only copies of the items.

Add Item:
The 'add item' method is fairly straight-forward. It is a method called whenever the player collects an item. The method requires an item variable within it's parameters. The collected item will contain a database index useful for retrieving an item from the database and adding it into the parameters.

The 'add item' and 'merge item' methods are combined into the same method therefore I need to do some exception handling before I can add an item to the inventory. I need to ensure no copy of the item exists within the database. If the item already exists I need to simply merge the quantities assuming the combined quantities do not exceed the limit.

Sort Items:
I have created four methods used to differentiate the items into the four item sub-groups. The four methods return all items, weapons, gear and quest items. This is useful when I need to draw the items into the inventory. I can just call the appropriate method and retrieve all the objects I require. 

The class checks all the items in the inventory for a certain class type. As I created multiple classes that inherit from the same parent class I was able to add all inheritance classes to the same list. This design pays off now as it's simple to search and retrieve specific class types. 

Creating the item database

Inventory Object Constructor Classes:

Firstly, I need to create a constructor class that will define the properties shared by all objects. A weapon would require stored data determining it's attack however potions would have no such requirement. A potion would require stored data to determine it's quantity; as would the weapon.

There are four data types I believe all objects would require; a name, icon, description and quantity. You may question that items require a value to transact with merchants however quest items wouldn't function in this fashion.

I start by creating an empty class that doesn't inherit from mono-develop. I add in the four data types and then add a public constructor method. This method contains the values required to define the class. It's called while creating a new class instance. I finish by adding multiple virtual methods, known as 'getter' methods, to allow other classes to read the class variables.

I need to create multiple sub-classes that inherit and expand from it to create unique inventory objects. I have created 'armour', 'consumable', 'merchant', 'quest', 'ring' and 'weapon' sub-classes. As all classes operate in the same manner I will explain one of these sub-classes which will provide insight towards how they all operate. I will used the 'consumable' class as the example.

A 'consumable' object is something which can be expended for personal gain. This encapsulates items such as potions, cuisine and drinkable liquids. In order to account for all the multiple usage of these items I need to implement multiple class constructor methods. 

Each constructor will inherit and expand upon the original constructor outlined within the base class. This means a consumable item will contain, minimum, a name, icon, quantity and description. 

If an item is consumed for instant player gains it would require a stat increase value. If an item is consumed for small gains over a period of time it would require a stat increase values and duration time. An item such as an antidote would require neither. It's for this reason I need to implement multiple class constructor methods.

Constructing a database:

This is actually fairly straight-forward therefore I won't explain in too much detail. The short explanation is that as all my methods extend from a base object class therefore I am able to add all sub-class items into the same list. 

This list will be loaded upon start up to store the in-game objects values eliminating the requirement to create items during run-time. I will be able to match the interacted item to an object within the database and store a copy of it to a localised list.

Designing the Inventory

General Design:

The inventory UI will be split into three sections. The items the player collects will be sub-categorised into four item classifications. An item will classified as consumable/merchant items, quest items, weapons and armour. Therefore the first section will allow the user to cycle through these sorted items.

Section two will concentrate on displaying and interacting with these categorised items. If the player selects to display weapons all weapons will be displayed within this area. The player can then browse through and interact with these items, whether it be to consume or equip one.

The final section will deal with player feedback; informing the player of the items purpose and in-game uses. It will hopefully give the player insight on the best time and benefits to using the item or whether it would be within their interest to sell the item. 

All three sections will be displayed on the screen at once while the player has their inventory open, covering the entire screen. Each section will have it's own border to hopefully separate and inform the player each section serves it's open purpose.

UI Background Textures:

I have developed my UI textures with the colour scheme of brown which I will be using in conjunction with all other UI textures in my game from this point onward. This is the first draft design for the background textures of my inventory interface.

The aim is to add four buttons, equally spaced, and as large in height as the background, displayed horizontally across the top image. I will display the items in a list, each item occupying half the background's width, with up to 12 items per column, allowing for 24 items to displayed on top of the second image. I will use the third image to display easily readable text.

In order to assist with resolution differences I have created three sets for these images; a 360p, 720p and 1080p set. It is my hope that the textures will not appear distorted, regardless of resolution.

Adding the Background Textures:

I started my project by creating three scripts; 'Inventory.cs', responsible for drawing the inventory, 'StaticVariables.cs', responsible for informing the inventory when to draw and 'TextureBank.cs', responsible for loading in textures and their positions.

I always begin my projects by selecting a target resolution, the resolution I will develop my project in, which becomes the benchmark for how the project should be displayed. Logic dictates it's far simpler to scale around a resolution than attempt to develop for multiple resolutions.

I use a variable called 'screenMultiplier' to calculate texture pixel values. To my knowledge all screen resolutions are divisible by sixteen therefore I use this number as my multiplier. Using my target resolution I can calculate sixteen pixels for the screens width and height, which I set to the 'screenMultiplier'.

This allows for pixel perfect textures at my target resolution which will scale to look exactly the same on all resolutions. 

To avoid texture distortion on images when there is a radical difference in screen size I change the textures loaded in depending on the screen size.

In order to ensure the 'TextureBank.cs' is loaded into the project before any other script, especially any script referencing it, I set the scripts execution order to the lowest value to ensure there are no problems.

All that's left is for the 'Inventory.cs' script to be able to gain access to the textures and display them. To gain access I must add the 'TextureBank.cs' script to a gameObject. This allows me to search the project for that gameObject and find a reference to the script by locating it as a component of the gameObject.

With the script reference I can get a reference to the textures and positions I need to be able to draw them to the UI. Assuming the player has their inventory open, which the 'StaticVariables.cs' will inform the 'Inventory.cs' script, I cycle through the background textures list and draw them, one by one, to the GUI.

There I have the first, small step, of my project achieved. It may not be anything significant yet but it proves the UI I am developing will scale nicely, without texture distortion, for multiple resolutions which is a nice platform to build from. See the results below...

360p Resolution 

720p Resolution

1080p Resolution

Item Sorting Buttons:

There are four ways to sort my in-game items. An item can be a standard item pick up, such as consumable and merchant items, a weapon, such as a sword, to be equipped, wearable gear, such as armour and rings, and an important quest item. 

Therefore the four buttons I need to design will contain the tags 'items', 'weapons', 'gear' and 'quest'. The player will be able to toggle through these buttons to display a sorted list of items which are sub-categorised into the item type they've selected. Each button must have three essential textures and an additional texture I choose to add. 

The first of the three essential button textures is the original texture. This is the texture the button displays before the player interacts with it. In my game this will simply be the name of the button.

The second of the three essential button textures is the button selected texture. This is the texture the button will display when the button has been clicked. It feeds back to the player which option is currently selected and reaffirms the button click event was registered successfully. 

The third of the three essential button textures is the buttons hover texture. This is the texture displayed when the player has their cursor over the button but hasn't clicked it. The purpose for this texture is to inform the player the button is clickable.

The fourth button which isn't essential but I choose to employ into my game is the hover texture combined with the selected texture. This texture is displayed when an option has been selected and the player has their cursor over the button. The reason I will add this is so the player can refresh the options list by re-clicking the button.

Button Designs:

The original button texture will just be the name, positioned in the centre of the background, with the text reprinted twice behind it, to achieve a three-dimensional effect. The colours of the reprinted text will be similar to the background colour to make it subtle but noticeable. The text is white to make it standout from the background more.

The selected button texture will contain the button name within the bounds of a box.

The hover button texture will contain an arrow, to the left of the text, pointing towards the text to inform the player that it's the button they are currently hovering over.

The final texture, the selected and hover textures, is a combination of the previous two textures.

Implementing the Buttons:

In order to implement the buttons into my project I must first add them into the texture bank. As I have shown previously how I add textures into my project I am not going to repeat myself here as the process is identical. Drawing the buttons however is slightly different so I will explain how I do this.

Having four button choices paints an interesting scenario as I need to differentiate the situations in which each button need be drawn. To help decipher this I have created my own enum value. An enum value is a custom variable I can use to set different states for a certain situation.

I have implemented the enum in order to keep track which button has been selected or whether none have been selected at all. The enum has five values to achieve this. The enum has to either be set to 'Unselected', 'Items', 'Weapons', 'Gear' and 'Quest'. 

I used a succession of if else statements to determine which textures to draw for each option. For example if the 'Items' options has been selected I know the only texture I need drawn is either the selected or selected and hover button. I can then find the texture I need from the remaining two by checking if the button contains the mouse position. If true I draw the selected + hover button otherwise I draw the selected button.

If the items button hadn't been selected i'd have been left with a choice of the hover button texture or the original button texture. This again can be solved with a simply line of code checking if the button contains the mouse and drawing the appropriate texture depending on the results. 

As you can see by the following image the results are what I would expect. The colour scheme, in my opinion, work well with the background texture and the white used stands out and is easily read. 

The code executes perfectly and now I can begin working on the item database and sorting code. I will be documenting this section in another post and will continue this part of the blog when I am ready to begin drawing the sorted textures to the GUI.

Drawing the Items:

When the player selects an option I need to update the inventory to display it's specific objects. I retrieve the objects for the selected option by calling the corresponding sort method from the 'PlayerInventory' and store the returned list.

I'm easily able to loop through the list and draw them however I need to adjust the font height to fill the text area. The disadvantage of this technique is that the string may exceed the area width. I need to create a method to prevent overflow and then another to scroll the text.

I have pre-loaded four positions per line into the 'TextureBank' to display the textures icon, name, quantity and hover icon. If the mouse position is over the line position I will need to display the hover icon. If the player selects an item I need to draw a border around the item. 

This code executes in a fairly similar manner to the sub categories therefore I will not go into detail about it.

Scrolling Text

Firstly, I need to determine if an item name exceeds it's area width and crop it to prevent unwanted overflow. I achieve this by converting the name to an array of characters, loop through the array and check if the characters, as far as the index, exceeds bounds. If the loop ends without exceeding the bounds width; the text fits within it's area therefore I can simply return the unedited name.

In order to scroll cropped text I need to create another method which executes whenever the player selects an item. This method acts almost identically except it returns a boolean and sets multiple class variable values. I initiate the string length, character overflow, starting index and set a boolean to determine the direction to scroll. 

I use these values to retrieve a sub-string of the name between the start index and the string length. Increasing the start value will allow the items the appearance of scrolling. I do this within a method, executed within an invoke, repeated every .1 seconds.

This invoke will not stop unless an item is selected, the item is deselected, the category is changed or the inventory is closed.

Description

Displaying the description is similar to cropping the item names. It differs by return a list of strings instead of a singular string. Whenever the characters exceed it's area width I add the string to a list, store the split string index and keep going. This splits the entire description into multiple strings that will fit the description area perfectly.

Ideally, the description area would fit five strings therefore I set the text height to a font size that would accommodate it. I split the description into five positions minimum, increasing this number if the returned string count exceeds five.

I can then cycle through the amount of strings and draw them into the corresponding positions within the bounds.

Game Design Document

Genre:

I will be developing a three-dimensional 'sword and shield' role-play game which adopts an top down isometric camera perspective for two-dimensional visual effects.

Setting:

The game will be set in a fictional kingdom which depicts a medieval environment. The characters are all humanoid and speak in the English language. The player will spend a vast majority of thier time exploring the rural landscape of this fictional land.

Gameplay:

Much like the majority of games of the 'RPG' genre the player will split it's time between going on quests and slaying enemies. The combat will be turned based with the attacker dealing damage first followed by the defender damaging second. The quests can range from simply locating an item to having to defeat a foe. The player can level their character by training in a specified skill which will directly impact the players combat stats. The player will be able to buy and sell items to aid in combat or acquire better items.

Target Platform:

I am developing this game for the desktop and as such will be targeted at Windows PC players. I intend for the game to be playable across all desktop resolutions however I will be developing the game for 720p "1280 x 720" resolution display. The games graphics will be able to scale to the users preferred native resolution.

Influences:

There're many games I draw influence from for the design of my game. I look towards 'Runescape' and 'Diablo' as benchmarks for the look and feel of my projects game play with special emphasis towards their isometric camera perspective and the way 'Runescape' implements turn based combat. When designing the UI elements I draw influence from the 'Dark Souls' series. I love how easy and user-friendly navigating it's menus feels and hope to replicate this in my project.

Software:

The majority of my project will be developed inside the Unity game engine. Unity is a free and easy to use software which is easily the best 3D game engine I have encountered. To create my 3D assets I will be using Blender3D; a free-to-use 3D modelling tool which works seamlessly with Unity3D for importing assets and animations. I will be using GIMP 2.0 to create my UI element textures as I have extensive experience with it and find it much more accessible than Adobe Photoshop. Sound software TBD.

Story:

TBD...