Designing Level Sets

The idea for the levels created this sprint was tailored toward mixing puzzle and combat elements together.  Each level requires the player to use the proper type of ammo on the blocks impeding their progress to reach the goal.  This was reiterated upon a total of three times with each level getting progressively harder.   To go along with each level were enemies that fit the theme of the ammo type being used.  This idea was used to reinforce the importance of using specific ammo types in scenarios other than puzzles.

This sprint came with the challenge of quantity versus quality.  There was originally going to be a total of five to six level.  Each level was going to get progressively more difficult as the three submitted ones already do.  However, while creating the levels, a new way to rehash the same mechanic that looked like a proper evolution of the previous level became a time-consuming challenge. It was decided, therefore, to leave the set at three levels and continue evolving the level set concept in the coming weeks.

For future sprints, work will continue on this idea of progressive overload (difficulty) with other mechanics to make an enjoyable, puzzle/combat experience for the player.  Creating levels that require more thought into figuring out the puzzle rather than running and gunning the whole thing.

Boss Climb Level Design

The concept for the design of the boss level was inspired by the intro to Skyrim when the Dragon bursts through the wall as the player runs up a staircase. To focus on the game’s strengths, we opted to use Zelda style puzzle-battle mechanics rather than straight forward combat.

To get the level functional, we were able to quickly implement several new mechanics thanks to the programming department. One of the new features we’re working on is the camera follow system used in the level. While the camera’s performance in the level doesn't currently reflect how we envision the final version, we will continue to make improvements. The dragon head prefabs are working well as well as the mechanical advantage variable added to the “dustpan” script which allowed us to create the first dragon head encounter with the heavy boulder.

Using our puzzle mechanics to create a functional boss level went well, and I am pleased with the progress we’ve made so far. We will also continue to improve the design until release. The downside of focusing on a single scene like this that requires new mechanics, and a lot of testing, is that it can be a very time intensive process. However, I think this was a productive sprint and the quality of the game has improved. Next sprint we will be focused on level creation with an emphasis on sets of levels with similar themes and mechanics as well as creating a SHMUP-style level.

Art Refinement and Creation

During this sprint worked progressed on creating new tile pieces to help spice up the standard gameplay. New tiles were created that affect the player’s movement (slowing them, bouncing them, etc.), tiles that can damage them, and special tiles that the Player is able to break through with powerful melee attacks. Alongside these new tiles, existing tiles were adjusted to remove and minimize empty space in the graphical sprites to help reduce awkwardness when placing tiles and during player collision.

Moving forward, more background art will be created including different types of level tiles, unique pieces of decorative art, and managing/adjusting animations as needed/requested by the rest of the team.

Making It All Work

Making New Enemies and Explosives

One of the new enemy types that was designed and implemented this sprint was the FireFly enemy.  While the enemy doesn’t exist in our current in-build levels, one of the genuinely new features it required is in the current build:  explosive enemy projectiles.  The FireFly design calls for the enemy to fire a projectile that explodes upon contact dealing damage within a blast radius.  Since the code for this behaviour already existed for the exploding boxes, it was simple enough to adapt that code for inclusion in EnemyProjectile script.  This projectile is also used in the Boss Level for the DracoLux heads that protrude through the side walls of the level.

The exploding boxes previously only applied damage to the player if they were near enough.  Now, the exploding boxes damage the player and nearby enemies, and detonate nearby boxes.  The ability to detonate nearby boxes allows the designers to create options for making detonation chain reactions.  One other new mechanic added to the explosive boxes is the ability to create a camera shake effect when they detonate.  Right now, the shake behaviour only jitters the translation of the camera, not the rotation.  We will investigate whether it is desirable to jitter the rotation for larger explosions in the coming weeks.

Improved Combat Feedback

One of the consistent criticisms of our combat design was the lack of visual and aural feedback when the player or enemy landed a successful strike.  This sprint, a new sprite animation was developed that plays only when a projectile strikes its intended entity target.  If the projectile strikes a wall or other non-entity object, its small splatter animation is played.  A short burst sound is also played when a successful strike is landed.  This provides much stronger feedback to the player that they are indeed damaging the enemies, or that they are being damaged.

Camera Refinements

The CameraFollow behaviour was originally designed with a long, horizontal style level design in mind based on the original concept of the project.  As the project has evolved the level design has become more diverse, involving more verticality.  Because of this the CameraFollow behaviour was completely redesigned and made to be more flexible.  The camera will now follow the player in 2D by default, but parameters can be selected in the inspector by the designers to restrict the camera to only follow horizontal motion, vertical motion, or not follow the player at all.

Control Rebinding Being Reevaluated

Initial control system construction is making the rebinding process more challenging.  Progress has been made, and we had a goal of being able to demonstrate at least one button rebinding process, but we’re discovering that using the InputSystem-generated C# script as opposed to using the Player Input scriptable object requires modifications to much of our existing code where we are subscribing to the various InputSystem events.  We are going to continue investing whether this is still a feature we wish to include, but it’s beginning to appear that the effort to redesign many of our existing controller scripts may require more time than we’re willing to invest given our rapidly approaching deadline.  We also are reluctant to modify scripts that drive core behaviours that already work very well.  We will have a decision on whether control rebinding is retained at our next sprint review.

The To-Do List

There are several new mechanics that we wish to develop and implement for this coming sprint.  The easiest to implement are trails behind the player when they dash or glide and trails behind the player and enemy projectiles.  This will add visual flare and value with a minimal cost of effort.

For the prototype, we were able to develop sound effects for one of each enemy vulnerability type, but now we have a larger array of enemies, all of them requiring custom sounds.  We have a plan in place to collectively iterate of various sound themes to create the unique effects required.  We have the audio hardware and software to achieve this, and we have a time schedule to record the raw audio tracks.

With the addition of new enemies, work needs to be done to get these new enemies properly scripted and configured so that their behaviours match those specified in the GDD.  Once properly configured, new enemy prefab objects will be created so that the designers can simply drop the enemy prefab into place in their levels with minimal need to adjust any settings.

As our level designs become more diverse, the way in which enemies launch their projectiles must also become more diverse.  The initial philosophy was to simply have the enemies fire either right or left depending on the position of the player relative to the enemy.  By our next review, we will have a system in place whereby the enemy projectiles will be aimed more directly at the player making the system more flexible and practical for use in levels with greater verticality.