Interact System:

• My thought process going into designing an interact system was simple. It needed to be easy to set up, it needed to be usable for a wide variety of content, and it needed to have a priority system built in.

• I was able to tackle the ease of set up by building the system into 2 parts.

  • The Interactable Blueprint Component or BPC for short would be added to any player actor who was going to be able to use interactable objects. Having this logic de-coupled from the player allows for easy re-usability across multiple projects as you do not need to use a predefined character. Merely add the Interactable BPC to a player and it would work.

  • Through the design of an Interactable Interface I was able to create the framework for any object in the game to potentially be interactable. The designer would only need to implement the interface onto the objects they wanted to be interactable and all the important functions would be laid out for them. Once those functions were filled in then the object would be completely interactable, whether that interact entailed opening a door, picking up an object, or executing an enemy it could be handled through this system.

Weapon Inventory System:

• In designing the Weapon Inventory I took heavy inspiration from the big names in the FPS genre. Two guns, one melee, and two types of throwable. Building towards this industry standard greatly assisted in guiding my decisions when building the inventory.

• The Weapon Inventory was also built as a Blueprint Component. This made it easy to use as it could be added to any Player or AI actor and they would be able to begin storing a collection of weapons and calling actions on any weapon they had equipped. That simple, add the Weapon Inventory BPC to an actor, grant the Weapon Inventory BPC a weapon, and their ready to start shooting… or stabbing, or maybe they do nice things like heal… but probably not.

• A final key point to the versatility of the Weapon Inventory’s design is that at no point does the inventory owner need to reference the Inventory, and at no point does the Weapon need to reference the Inventory it is inside of. This level of de-coupling allows for implementation as the inventory could be implemented with completely unique characters and weapons in each project and have no issues.

Weapon Design Tools:

• Building design tools for the weapons was tricky. Things needed to be built so that a new weapon could be implemented in as easy as 20 minutes, but things could not be so specific that the whole system becomes unusable for creating weapon variety.

• I was able to achieve both these goals and enable future designers through the use of a two step approach.

  • Weapon Data Assets:

    • Data Assets allowed me to build a way for to store all of the important variables that designers will want to touch when creating a new weapon. Rather than having to go into the blueprint and move past the code or other unimportant variables, designers are able to see everything in one place and create new weapons by simple filling in the values and attaching the new Data Asset to a child of one of the Base Weapon Blueprints.

    • Base Weapon Blueprints enabled me to create all the in depth functionality of each weapon type (melee, ranged, and throwable) and save designers dozens of hours of set up. I tactically built many of the systems to use easy to override functions and events allowing designers to implement their own logic onto children of these weapon types.

      • An example would be shotguns overriding shoot function on their parent class to make multiple pellets fire at once.