Boot Sequence is a co-op, procedurally generated dungeon crawler for up to four players. In Boot Sequence you play as a medieval fantasy knight or mage who has found jet powered boots that allow you to hover and dash around with ease. Armed with your boots and your staff or sword, you set out to find the bottom of a dungeon with no end, populated by mechanical drones from a civilization long past.
This game is a collaborative effort between three designers, three artists, two other programmers and myself. It was developed in the Unity engine and uses the Rewired input and Wwise audio plugins.
The AI system for this project was a collaborative effort between me and Josh Mahler, while the procedural generation was the primary focus of our third programmer. We combined my RRT* pathfinding algorithm with Josh’s finite-state machine implementation to form the basis, and then expanded upon these with a ‘unit mobbing’ system that coordinates groups of up to four enemies and allows them to flank the player, among other strategies. This proved the speed and scalability of the RRT* implementation, with the inclusion of limits on the effects of fail states. This was also an exercise in pair programming, as we worked with that method to link together our systems and lay down a steering architecture that functioned with both. In the end the system functions but isn’t perfect. The non-deterministic nature of RRT combined with the need to frequently update paths caused issues, and the architecture of the AI system made it hard to debug.
I also was the primary programmer behind the ‘chip’ power-ups, which add effects to the player’s hover, dash, and kick abilities. The conception of these started out with rather disparate effects, including flat stat bonuses, which meant that the system had to have it’s fingers in every pie, so to speak. This necessitated an architecture which allowed it to not cause everything to come crashing down if something went wrong, otherwise I’d create hours and hours of work for myself and the other two programmers. The solution I found for this was to make every different chip inherit from a base class that held all the necessary variables for every different gem, but with them all set to zero (or one, if it was used for multiplication). From there, the child class would read in only the numbers it needed from a data file.
The other task I focused was creating custom shaders for our damage feedback on both enemies and players, as well as for the eyes of enemies changing color when they notice you. These all use Unity’s MaterialPropertyBlock functionality that allows for the changing of shader values while maintaining batching of draw calls. This was an absolute necessity due to the sheer number of enemies on the screen at a time. If their materials were all instanced, then performance on later levels of the game would suffer drastically.
Working with so many people on the same team was a new experience for me. Communication was a constant struggle, and people’s tendency to work in different places at different times lead to us being ‘siloed’ more than we should have been. The other problem was the breakdown of daily scrum stand-ups that happens when there’s so many people. If we got sidetracked for even small things, we tended to end up with meetings that lasted twenty or more minutes. This game was also my first real exposure to the truly never-ending deluge of bugs that happens when a project gets large. Whether it’s things breaking on the repository side or just stupid mistakes that don’t get caught until later, the constant firefighting operation was something that I’m glad I had a chance to experience before actually entering the industry.
How to play:
Extract folder from zip file to anywhere on computer.
Run BootSequence.exe
Plays using 1-4 of any type of standard gamepad (xbox, ps4, switch pro)
Avery Dibble's Hobbit Hole 