Gloom and Broom

Team 3 Studios

Austin Holweger – Artist and QA
Michael Knapp – Designer
Doug Patterson – Engineer
Brian Tromba – Writer and Designer

Level Design

New level templates were created including the Long, Long (Flying), Vertical (Climbing), and Vertical (Falling) levels.  New level concepts are being tested including the Boss Climbing level, an idea designed around the new EnableCameraFollow script courtesy of our lead programmer that will allow us to start and stop tracking the character with the main camera for a multi-stage boss battle.  Continuing to test new ideas and receiving feedback is a valuable part of our process and continues to improve the game.  The Slopes level didn’t work out as planned on paper initially, but we quickly discussed a possible solution to be implemented next sprint.  The ability to quickly iterate upon and implement new ideas is constantly adding new value to the game, and the in-class atmosphere is fun, creative, and productive.

Unfortunately, every rose has its thorn, and I keep forgetting to do specifically required details like Ignore Raycast layer on trigger volumes, and I had proposed creating an internal FAQ for reference to replace the post-it on my desk.  However, our lead programmer went above and beyond yet again and used this as an opportunity to improve the built-in quality of life features for the design team by including code that will automatically place trigger objects on the correct layer.

We’re looking forward to the next Sprint as we continue to test new level ideas and mechanics, as well as work to meet the expectations of our publisher, our players, and ourselves and aim to deliver a proof of concept for a boss battle scene next sprint.

Narrative AND PUZZLE TUTORIAL DESIGN

Focus shifted this Sprint away from enemy testing and toward the creation of new tutorial levels.  These new levels include the rainbow lock, dustpan, and ninja eyes tutorials.  The reason for this focus change was so the designers could start creating “sets” of levels based off our mechanics demonstrated in tutorials.

Over a dozen different dialogue options have been created for our antagonist Xander.  These banter options will be used as a motivation tool for the player to complete the levels out of spite for their nemesis who trapped them in this labyrinth.

Enemy testing was a promise for this sprint however this task has been deprioritized.  This task has been pushed back to future sprints, but it has not been thrown to the wayside.  We will continue to improve on our enemies’ capabilities and make sure issues that are present will be quashed for smoother development of levels.

Creating “sets” of levels based on our mechanics scaling in difficulty is now in the works.  This coincides with enemy testing as our enemies will be instrumental in creating difficulty for our levels.  These sets are planned to be five to six levels each and designed so the next level is supplemental to the previous level, not completely different.

For future sprints, we will record voice overs for our nemesis so our player can both read and hear the enemy trying to manipulate them into giving up.  We believe this will provide more emotional attachment to finishing the levels and keep our player motivated.

Enemy Art and Animation, and quality assurance

During this Sprint focus was placed on creating, rigging, and animating several new enemy sprites called the “Fire Fly”, “Candy Tower”, and “Broken Tips”.  Animating the first two enemies was simple and went smoothly.  The only sprite that required reworking was the “Fire Fly” enemy after receiving feedback from the rest of the team, but this was easily done as the files had not yet brought it into the game project, so there was no time spent redoing work.

The last of these, the “Broken Tips” enemy, went smoothly for the most part but a certain animation proved to be more problematic and required a bit more fine-tuning to animate the entity as intended.  Afterwards I made sure to update the GDD with the new enemy designs and how their mechanics are intended to work.

Going forward, new levels will be tested as they are created by the designers and more background and midground elements will be created to help improve the visuals of the game as they are currently just white squares and a blue background.

Making It All Work 

Dialog System Icons

Current Icons

The dialog UI elements have been fully converted to TextMesh Pro elements so that they can incorporate icons inline with dialog text.  To enable that functionality, a sprite asset containing an array of indexed icons needs to be created so that the designers can reference an individual icon by its index number.  Currently, all pick-up items are in the sprite sheet for the current build.  Icons that can appear in game in a variety of different colours are in the sprite asset as white so that they can be appropriately tinted in the dialog text using a hex RGB triplet specifier.   These icons can be incorporated into the dialog text so that players can quickly asset what object are being referenced by the dialog.  Below is an example of the style of dialog text made possible by this mechanic.

Future Icons

For the next Sprint, the controller button icons and the keyboard button icons will also be included.  Other game objects may be included as well if their inclusion is deemed to be beneficial by the team.  The team will also view feedback from those who have played and provided comments about the current iteration of the game.

Control Rebindings

The controller rebinding process has made some progress.  An initial framework exists, but it requires additional work given our initial design choices.  There are a couple of different ways to implement the new Unity Input System.  We chose a method that generates a custom C# script and enables the use of the Unity Event System.  This enables us to create methods to be executed when a specific input action is performed.  However, this makes run-time rebinding more challenging.

Connecting the Input Action C# script and the Player Input scriptable object can be made to talk to each other, but it will require more consideration and careful planning.  This is made especially challenging since many actions have multiple bindings.  For example, horizontal movement can be performed by default with A/D, Left/Right Arrow, Left/Right D-Pad, or Left/Right Left Stick.  A goal for the next sprint is to have the Run button reassignable so that the base functionality can be demonstrated.

Improved Combat Visuals

One of the consistent themes in most of the comments we’ve received so far is the minimal feedback to the player when an enemy is successfully struck with an attack, either ranged or melee.  We have an animated sprite that will serve as a visual indication of the enemy or player being struck and damaged.  We will use the same animated sprite for melee attacks and its incorporation to the project will be accomplished next sprint.  The addition of a specific visual for a successful strike will aid the player in knowing that they have hit an enemy or that they have been hit by an enemy.  Aural feedback for when an enemy is struck will be an additional goal for the next sprint.

Bug Fixes

Save System

As was referenced in our previous document, the bug which inhibited players from being able to save their games in multiple slots was fixed.  The issue was fundamentally unrelated to the save system itself, but to an issue with how the UI buttons were structured.  The root cause of this issue was identified and resolved and in the current build, the save system works as designed in both the WebGL and PC versions of the game.

Unconnected UI Elements

There are multiple systems that are interconnected in the game.  As much as possible, prefabs have been created such that connections between dependent systems are pre-established.  This is possible when the systems are all part of the same prefab, but in the case of the HUD portion of the UI systems and the Player GameObject, these connections cannot be predefined.  They are part of separate prefab object. 

When placing the Player prefab in a level, the designer needs to connect the appropriate UI elements to the PlayerCombat and WeaponUI script that are attached to the Player prefab.  If these connections are not made, then when the Player GameObject enters the scene, it will search for the appropriate UI element and attempt to assign them appropriately.

Incorrect Layer IDs

An additional source of erroneous behaviour is the result of inappropriate assignment objects with a trigger area to the “Ignore Raycast” layer.  Objects managing the level logistics such as the timer start and stop objects, dialog triggers, and level advancement triggers need to be on the Ignore Raycast layer or the player could end up standing on top of them and projectiles could explode upon contact with them.  This is undesirable.  To ensure that these various level-logistic elements are behaving appropriately, the scripts that manage these various prefabs mandate that the game objects to which they are attached are on the appropriate layer.

Character-Wall Conflicts

During the last sprint, a bug was discovered in which the player to would experience extreme jitter when moving up next to a wall.  This behaviour was the result of the default PhysicMaterial2D that was placed on the walls.  In the Physics2D global settings, the default material was set to one that has zero friction and zero bounce.  This resolved the flickering issue.

Future Mechanics and Functionality

With new enemies being generated and new behaviours being defined, new scripts will need to be developed to handle the new mechanics.  In addition to the standard connection of the EnemyController script to the new enemies, new enemy mechanics will also need to be scripted, including an expanding area of effect attack and an exploding enemy projectile. 

Additional scripted functionality is also being considered for the PlayerController to enable a flying mechanic.  In the current iteration, our designers have the ability to change how strongly gravity affects them while they glide, but there is no ability to move the character up and down while flying at the moment.  The team is currently considering the pros and cons of such a mechanic.