By Bait or By Bullet
Team Size: 23
Project Duration: 4 months
Software Used: Unity
Languages Used: C#
Primary Role(s): Design/Accessibility Lead & Programmer
By Hook or By Crook is a bombastic 2D fishing rogue-lite where you fish for your loadout.
You can play the WebGL or download it on our itch.io below!
Contributions
Technical Design
-
Designed and implemented Boss Movement system.
-
I built it with circle sprite targets to allow it to be visualized and more easily debugged.
-
Boss can transition between moving towards random targets centered on the player & set targets in world space.
-
After prototyping the random movement early, I continued to work on this throughout to account for edge cases and new requirements.
-
Documented system with a ReadMe.
-
Created Boss 1's Drill Attack.
-
Worked with animator to ensure there was a good wind-up/anticipation.
-
This unshieldable attack keeps the player moving because it can target the floor and the bottom row of platforms.
-
-
An early prototype: the Boss follows a moving target that's moving towards random targets.
Click on a gif to get a closer look.
Attacks rain down as the boss does its drill attack.
-
Designed and implemented basic Boss Attack Spawning, Boss Health, and Boss Phase systems.
-
Ease-of-use: drag and drop prefabs from inspector.
-
Simplicity of this Prefab instantiating system allowed it to be adapted.
-
Where it fell short: Did not provide fine control over attacks spawned within each phase.
-
Necessary to avoid undodgeable combinations when there's a long list of attacks & the attack spawn rate is increased.
-
-
The boss hovers animatedly hovers around the moving player.
-
Used existing assets to create a smooth, skippable, boss intro template as well as an outro on player/boss death
The player's controls are locked as the intro plays and the boss enters from the right.
Accessibility/Design Lead Work:
-
Created and presented slides on games accessibility
-
Opened anonymous form for developers to open up about their experiences with disability and accessibility features/design choices they benefit from
-
Emphasized that accessibility is a mindset rather than a list of features
-
Using and encouraging others to use games accessibility guidelines.
-
Briefing art team often and getting their input on design solutions.
-
Working closely with programming team on concepts for weapons.
-
Implemented invulnerability dev keybind for testing, feature later turned into an assist mode option
-
Helped plan other assist mode and in-game difficulty options
Detailed Gameplay Loop Made in Miro
Some of My Slides From Team Presentations
Post-Mortem
What went well:
-
This game has the most accessibility-minded features of any game I've worked on! This wouldn't have been possible without buy-in from my teammates.
-
We focused on what was integral to the gameplay loop from the start.
What went wrong:
-
As a design lead, I did not communicate a big change to the art team which led to some frustration.
-
Because of scoping issues and delays, the 3rd boss required last-minute work and received much less playtesting.
What I learned:
-
I gained a better understanding of what makes a good team lead. It's important to filter unnecessary information out and ensure other disciplines have input.
-
I had first-hand experience with the importance of documenting bugs appropriately.
-
I couldn't answer questions about the circumstances surrounding bugs I found. I started liberally taking screenshots to ensure we had details about the conditions that caused the bug.
-
-
I have a better understanding of how to scope a project. It's important to "content-lock" and focus on polishing and bug fixing sooner rather than later.