Taking Inventory

Development Blog #1 

This week I'll be discussing lore, some important art direction changes, additional passes of inventory UI, optimizations made to object pooling, and Shobi!

 

LORE:

Since this is the official first development blog for Sentinels, I thought it would be great to give you a low level overview of the whole project, lore and all.

Sentinels is a rogue-like shoot em up with an emphasis on class-based gameplay and collecting unique weapons and upgrades. There are currently 8 different classes in the game, each with a distinct set of properties and legendary weapons. Each character has a unique loot pool, with class specific items and legendary weapons. Weapons are divided into four tiers, white (common), green (uncommon), blue (rare), and orange (legendary). White, green, and blue weapons are available to all classes, while legendary weapons are distinct to a specific class. For example, legendary shotguns and grenade launchers are unique to the Patroller class, while legendary revolvers and rifles are unique to the Bounty Hunter class. Player can earn boxes, which contain weapons and items, by either finding them in missions or defeating bosses. When a box is opened, the player has a choice of one of three possible rewards. In order to complete the game, the player must survive 5 procedurally generated levels. If the player dies during any of these levels, they must restart the game. However, there is some persistence between playthroughs.  Upon earning achievements, the player can unlock different classes and items that will be added to the game. When unlocking a new character, all weapons an items distinct to their character are added to the loot pool.

The story of Sentinels is pretty long and complex, so I'll try to keep it nice and short. The game takes place in a world where biological computing has evolved to the point where code could be stored through DNA. This lead to the creation of an organic operating system known as CatalystOS, which eventually leads to the end of humanity.The player can chose to play as one of eight robots who have gained sentience through CatalystOS. Each robot has created a unique personality for themselves through their experiences with their newfound sentience. For example, the Patroller class is a tanky security robot who values nonexistent human life over his own. Another example is the Squire class, a agile butler who thinks that his sentience was gifted to him through a divine power. These unique personalities play a vital role in their journey, and their eventual demise. 

NOTE: Since I've been writing these blogs for quite some time now, I will release some older, unreleased development blogs over the next few weeks. Stay tuned for more!

Art Direction:

After spending a lot of time reflecting on how the inventory system works, I had decided that the current art was much overdue for a revamp. Back when I began drafting bosses, items, and enemies the art direction for the project wasn't fully planned, which resulted in a huge amount of inconsistencies in my art work. Specifically, was my failure to recognize how certain colors can compliment each other. This resulted in an odd design choice where I would add artificial noise to a sprite, which although making the sprites look more complex, made the game seem cluttered and hectic. Although the project aims to be incredibly hectic, I would rather achieve this through other means, rather than just a poor direction decision. Of course this does mean a lot of work will be required to recreate these assets, but, it was a decision that I felt was incredibly necessary.

The Elementalist

With this new direction, I also felt the need to redesign some of the weapons that were originally planned. In some cases, the weapons have simply had their art changed, while others received complete mechanical changes. The biggest example of this, so far, is with the Elementalist class. The Elementalist class uses a variety of elemental weapons (duh) which consisted of "throwers" (which were flamethrowers, tesla beams, freeze rays, etc) and "capsule pistols" (basic projectile weapons with elemental properties). These weapons were each categorized by their element type, whether it be fire, electric, poison, or ice. However, the poison element was nearly impossible to work into this class. This is because poison felt incredibly boring compared to the other types. For example, electricity damage could chain damage to nearby enemies, while poison damage would simple cause damage over time. In a SHMUP scenario, damage over time isn't always the best route to take with weapons. With this discovery, I decided to remove all poison weapons from the game. It was a tough decision, but I hope it makes the Elementalist class much more fun to play. In addition to these big changes, capsule pistols were completely revamped. In order to add variety to the Elementalist's gameplay, the following changes have been made to capsule pistols:

1. Fire-based capsule pistols now behave like flare guns. They have high damage, a permanent chance to ricochet, and relatively small area of effect around the projectile. 
2. Electricity-based capsule pistols now behave as rapid fire submachine guns. These weapons now behave similarly to the SMG class of weapons, but can chain damage to near by enemies, as well as quickly stun larger targets.
3. Ice-based capsule pistols now behave like shotguns. These weapons multiple ice shards at once, while having a chance to freeze targets. 

 Of course this is not the end of these sorts of changes, as there are a lot of classes I would love to change fundamentally (like the Squire and the Reactor).

UI Changes:

Holy moly. Over the past few weeks, I felt the UI was in massive need of a rework. Not only was the system horribly unoptimized, but it felt incredibly static. In order to help convey the magnitude of these changes, the following paragraph will be a rough overview of the old system, and a more in-depth overview of the new system.

The old inventory system was much more versatile as it was clunky. I had designed the system so that you could have an infinite number of named properties per item, and through the wonders of reflection you could easily display these values or apply changes to the player. This was a neat system at first, but soon became incredibly difficult to work with, and I eventually just used it as a way to cosmetically display data. Next there was the manager system. There was a static number of item slots, ones specifically set to contain weapons, and another set to contain upgrades. Due some poor design choices, these slots had to always remain active to be found, and could never be disabled. This meant that in some cases, there was over 200 active inventory slots. Also, this meant that when the inventory has hidden, all the slots were still active. This lead to some terrible performance issues in many cases. Furthermore, the inventory system was divided into a system of panels. These panels consisted of weapons, upgrades, and statistics. As stated earlier, these panels could not be disabled. Meaning, if I wanted to hide them, the scale had to be changed to 0. Yeah, not really my magnum opus.

After I had realized all of the horrible rookie mistakes I made, I decided it was time to completely change how the inventory works. The first step was designing an effective way of determining between weapons and upgrades. Now there are two specific classes for both weapons and upgrades, each deriving from a item interface. The item interface contains a number of basic fields, such as item ID, name, description, flavor text, icon, and a boolean value representing if the item is equipped. Weapons now contain a static number of fields, including damage, fire rate, and accuracy. Upgrades also contain a static number of fields, as well as a newly created "On Use Effect". In the previous system, upgrades had to technically be equipped to have an effect on the player, which meant any upgrades coming into the inventory had to be immediately equipped as well. In the new system, whenever an upgrade is added to the inventory, it triggers its "On Use Effect". This is a reflection based event that can trigger/modify any method/property in the scene. All of the newly created properties are now serializable and are created using a configuration template, instead of storing all items and pulling from a "pseudo-database". Also with this system, I had developed an editor script to create a nice GUI layout of the inventory system.

Additionally, the inventory manager was completely overhauled. This meant that the specific tabs (no longer panels) could be disable/enabled, slots could now use a basic pooling system to prevent instantiation, and item serialization could be done directly from the manager.

In addition to the massive amounts of back end changes made, I also decided to use this opportunity to completely overhaul the visuals of the inventory screen. The biggest change made was how items are displayed in the inventory. In the old system, weapons were displayed as a single icon in a massive vertical list of weapons. To the right of this list was a screen which would display information about the weapon you selected. The number of taps required to access and equip a weapon was 2 taps at default, increasing by 1 tap every 4 weapons. This meant that after the player acquired 4 weapons, they would have to tap a scroll arrow to access the next set of 4 weapons. Since the system was organized by color, it would take up to 8 taps to access and equip a legendary weapon. If the player were to achieve all 248 weapons in the game, it would take them nearly 70 taps to access the last weapon.  


The new system now displays weapons in a card-like fashion. The current inventory screen can display 9 "weapon cards" at once, while each card displays the weapon's damage, fire rate, and accuracy. The weapon system is now no longer color coded, meaning weapons are added to the inventory in the order you find them. Displaying detailed information now uses a tooltip system, which saves a huge amount of room on the screen. The number of taps required to equip a weapon is still 2 taps at default, but now will only increase by 1 tap every 9 weapons gained. Meaning it would only take the player nearly 30 taps to access the last weapon. Which is a 50% decrease from the previous system!

Hopefully I can continue to make enhancements and performance increases down the road!

Object Pooling Optimization:

This is just gonna be a short little section about the object pooling system. I found a few fundamental flaws with the current pooling system, and were able to flatten out those issues rather quickly. It might not be a lot, but I did see a small performance increase during the scene generation. Which is great!  Also, I added the ability to instantiate (*ugh*) new objects to the pool if no more objects are accessible. Since the project is aiming to be as hectic as possible, I felt this is a good backup in case scenes get too heavy. For example, if by some reason, there are over 500 active default projectiles on the screen, it will add as many projectiles to the pool as required. This will only impact performance if I make a mistake in estimating the number of projectiles that can be active at once. The number will set to abnormally high amounts, which should prevent this from being used at all.

Introducing Shobi!

Since I had decided to overhaul the graphics for the inventory screen, I felt the need to add character to the then bland inventory screen. With this realization, I created Shobi, a figment of your characters newfound imagination. Shobi is pretty much this universes version of Microsoft Clippy. Shobi helps guide the player when first booting up the inventory screen, as well as represent their characters mental state. I am currently working on the behaviors for Shobi, as he will eventually be able to move, sleep, talk, etc. Also I am currently working on the triggers for changes in Shobi. Since Shobi represents the sentience of the character, when the character begins to become an organic being, Shobi will start to change as well...

Anyway, here's a first draft at our lovely boy!