4/5-4-18: Bugs, Iteration, and Unreal

I’ve had a lot of progress over the past two weeks. Here are my updates:

Bug Fixes/Iteration (9 hours)

I spent all of the my time on this project on bug fixes and iterations. Among the bugs I fixed/elements I iterated on include:

• Changed the font in the UI to the Greek font picked out by the art team.

• Redesigned the pause menu layout to differentiate it from the main menu

• Created a script that plays a sound when an item is purchased

• Created a Melee meter for the HUD to display the melee charge up

• Created an item count display for the consumables system

• Replaced the temporary icons on the HUD with the ones created by the art department

• Fixed a bug that prevented the player from pausing

• Allowed the item icons and ability icon to change color depending if they have been unlocked

• Created an icon for the dash charge

• Resolved a merge conflict

This is a picture of the HUD:

Unreal Engine 4 Preparation (3 hours)

I have also been focused on preparation work for the next studio project. The WolverineSoft Studio will be hosting an Unreal Engine 4 training over the summer, and I will be assisting Brandon in creating the content for the training. Because I haven’t touched Unreal Engine in almost two years, I decided to do an Unreal Engine 4 tutorial called “Blueprint Time Attack Racer”. It is a 15 part tutorial series on how to create the time trial mode of a racing game. It teaches important Unreal Engine 4 concepts, including actor spawning, the UI system, collisions, particles, and game modes, along with general blueprint basics. Currently, my project is a work in progress, but here are some photos:

3/22-4/4: HUD Redesign and Checkpoint Screen

I’ve had a lot of progress over the past two weeks. Here are my updates:

UI Redesign (5 hours)

Three weeks ago, the skill tree and passive abilities were cut from the final game as a result of scope cuts and design changes. This required me to perform a complete redesign of the HUD and pause menu. Here were the primary changes of the UI:

• Because the pause menu was no longer going to include any of the RPG elements of the game, such as the skill tree and equipment selection screen, I decided to cut out the tab system from the pause menu and make it similar to the pause menu from previous WolverineSoft games.

• Brandon and I worked together to create a redesign for the HUD. He used a website called UXPin to create a mock-up for the UI(here is a link to our redesign).

• I implemented a key counter in the top right (the sprite for the keys have not created, so it is currently a picture of my dog), which turns yellow when a key is unlocked. The primary challenge of this was figuring out how the dungeon objective manager works and modifying it to give me information about the number of keys collected.

• I implemented an XP bar (although it doesn’t seem to work in the current build because the XP system has not been implemented).

• I changed various colors and positions of UI elements as Brandon and I planned.

Death Screen (1 hour)

I created a death screen that appears whenever the player dies in-game. While the death screen is very unpolished, it works. It includes options for going back to the hub, back to the main menu, and quit games.

Loading Screen (1.5 hours)

I fix the level design’s loading screen and implemented it into the main game. It now includes changing …’s after the loading and a series of changing tips. For now, the tips are just inside jokes with the studio, and they will be replaced with more professional tips in the final game.

Checkpoint Screen (4.5 hours)

I created a screen to select a checkpoint. The primary challenges of this were:

• Figuring out how the designers wanted the checkpoint system to work and function, and understanding their design objectives for this system.

• Modifying the level generator to give each checkpoint a unique identifier and store the furthest checkpoint that a player had been.

• Creating a UI screen that automatically generated the buttons based on where the player had been.

• Giving the game the ability to pause when the player enters a door (there were a lot of bugs with this)

3/7-3/21: Skill Tree & Options

I’ve had a lot of progress over the past two weeks. Here are my updates:

Skill Tree Integration (8 Hours)

I fully implemented my skill tree system that I set up a few weeks ago. When my devlog last month came out, my skill tree system had a lot of features, but I had to fully finish it and integrate it into the rest of the game. The specific issues I encountered were:

• The skills could be unlocked without costing anything. The only check for whether the skill could be bought is whether the prerequisite had been purchased. I created the experience system, which consists of three scriptable objects (for each experience type) and an experience manager, which exists on the player prefab. Whenever skills are unlocked, it now actually costs the player experience.

• The skills had no effect on any player abilities or stats. I fixed this in two ways: each skill can modify certain stats, and certain abilities only get unlocked when certain skills get unlocked. For instance, Agility I increases the movement speed and attack speed by a small amount, while the rest of the stats are set to 0. I also made a script that automatically manages abilities (for instance, the double jump is only enabled when “Double Jump” is unlocked.

In addition, much of my time was spent actually making the skills (creating their name, descriptions, and stats) and laying out the skill tree.

FMOD Tutorial & Audio (2 hours)

I also spent time implementing audio sliders and the skill tree sounds. Our audio middleware, FMOD, was not something I had used before, so I completed a basic YouTube tutorial to learn how FMOD and it’s unity API work. I then spent time completing two audio related tasks:

• Integrating the UI sounds into the game. These include skill tree specific sounds (such as onStrengthUnlocked) and general UI sounds (such as onButtonHovered). This mainly involved figuring out how the FMOD API works and how to play single sound effects without a location.

• Creating audio sliders. This mainly involved figuring out how busses work in FMOD and how the busses in this project are named. These sliders are on the options menu of the pause menu.

Pause Menu Buttons (0.5 Hours)

I implemented several buttons on the pause menu, including the Quit Game, Exit to Hub, and Exit to Main Menu buttons. Previous studio projects created this functionality, so this was mainly about reading the documentation of the WolverineSoft General Library and using their scripts to implement the buttons.

Floating Damage Text (1.5 Hours)

I implemented floating damage text. Basically, whenever an enemy takes damage, a piece of text appears in worldspace around the enemies location, displaying how much damage the enemy has taken. The main challenge of this was trying to figure out how to make the text billboard correctly (turns out, the answer was transform.LookAt).

2/21-3/7: HUD

I’ve had a lot of progress over the past two weeks. Here are my updates:

HUD/Pause Menu (13 Hours)

The entire two weeks have been spent implementing the Heads Up Display(HUD) and the Pause Menu. Here is a more in-depth breakdown of what I’ve implemented.

• A significant amount of time of the week involved planning what the UI would look like. In particular, these involved discussions with Brandon S and Paul Young. The main objective was to answer questions like: How should XP changes be displayed? Where should all the elements be placed? How can we go about decluttering the UI? By the end of these discussions, we ended up with a pretty good plan about how to progress on the UI. (This took 1.5 hours)

• My next step was to implement the basics of the pause menu. This involved two steps: implementing the ability to pause the game and translating my work over the previous two weeks into the main game. To pause the game, the game deactivates a number of systems, such as the player’s ability to move the camera, and reactivates them when the game is unpaused. I then transfered alot of my work from the test scene into the main game, including the tab system and the tooltip system. (This took 2.5 hours) Here is a picture of the current pause menu (note that other than the tabs, none of the buttons here work):

• I then started work on the HUD itself. This included a bunch of relatively simple, self-contained elements, such as the health bar, glide bar, charge bar, health text, experience text, and currency text. The main challenge with these components was finding and getting the necessary information from the scripts that controlled them. For instance, the glide script didn’t have an ability to get how much of the glide was left, so I had to read through the code and publicly expose the variables I needed for the glide bar. (This took 3.5 hours).

• Throughout the whole process, I implemented some important player systems. This includes the Experience Manager, which allows the three types of experience points to be accessed in one place, and the Drop Experience system, allowing enemies to drop experience. (This took 0.5 hours)

• I spent much of my time implementing the ability UI. Many of the game’s abilities have certain requirements about how they can be used that needed to be communicated to the player. For instance, Revenge requires a charge, Clairvoyant has a set duration it can be used, and the Dash can only be used a certain number of times. I created several UI components that could communicate each of their abilities. As I searched through the Player scripts, I noticed that many of the ability have a “cooldown”. I created an interface called ICooldown where each of the ability could easily communicate the status of their cooldowns and implemented it for each ability that had a cooldown. (This took 5 hours).

Here is an image of the final HUD:

2/7 - 2/21: UI Essentials & Skill Trees

I’ve had a lot of progress over the past two weeks. Here are my updates:

UI Essentials (3 Hours)

In order to prepare for the task of creating a functional game UI, I realized that the game will need a lot of systems that are not project-specific. The creation of these systems early on ensures that less work has to be done later, as these systems can be reused later in the project and in future projects. Here is a list of some of things I worked on:

• Tab System: A system of buttons that enable/disable game objects on click. This Tab System is extensible and flexible. It would good use for a shop or a pause menu.

• Flexible Grid Component: Unity’s UI Grid Component has a lot of issues (mainly that it doesn’t resize elements and doesn’t do the things developers usually expect). To solve this, I followed a tutorial on creating a Flexible Grid Component (https://www.youtube.com/watch?v=CGsEJToeXmA&ab_channel=GameDevGuide). This will likely be useful for displaying items in the shop.

• Tooltip System: A system that displays a popup near the mouse so players can easily get a feel for what’s going on. A component called a Tooltip Trigger enables and disables the tooltip, and sets the content and color. I considered adding an image compnent to the tooltip, but I ended up deciding it wasn’t a necessary feature yet.

• Drag and Drop System: A system that allows players to drag items onto certain locations. It is currently a bare-bones implementation, but I hope to expand on it in later sprints.

Below, you can see a screenshot of the tab system and the flexible grid component:

Skill Tree (9 Hours)

I created the basic implementation of the skill tree. One of the first challenges was creating the skill system (without it, the tree is meaningless). I spent a lot of time planning out the best way to approach it, but in the end I came with an extensible, designer friendly solution. The data about a skill is represented as a ScriptableObject, which includes the name, description, icon, cost, etc. This object doesn’t contain the functionality of the skill. A SkillManager component sits on the player prefab and handles the locking/unlocking of skills. Other components can query the SkillManager to determine if a skill is unlocked.

With that system created, I spent the rest of the time creating the skill tree system. My primary objective was to make this a designer friendly solution, and one that easily adapts to the content of the tree. Here are some of the features of the skill tree:

• The skill tree automatically sets the tooltip when the icon is hovered on the tree (e.g. if you moused over the skill “Calculus”, the tooltip will be set to it’s name and description).

• When an icon is clicked, an “info” screen about the skill appears. This displays some more information about the skill, including the cost and status of it. If the player can’t purchase the skill, a tooltip will be displayed about why (for instance, if the prerequisites haven’t been unlocked, the tooltip will tell the player the skills needed to unlock).

• The color of the skill tree icon changes based on whether the player has unlocked it or not.

• The designer only needs to specify what skill each node is and where it is placed on the tree, and the skill tree system will automatically figure out the rest (this feature of the skill tree took the most time).

This system has a few flaws (mainly that there are no checks in place for if the player can afford a skill because that system isn’t set up yet), but it is a good showcase of what this system is capable of. Soon, this system will be making it into the builds, but it is currently not integrated yet.

Below are some pictures of the skill tree: