Spiderweb development is similar to spiral development, but with several key differences. While in both systems, you could stop at any point and find a complete product, in spiderweb, different segments of the product are developed in parallel and may be at different levels of completion when development is finished. To begin spiderweb development, we planned finite scope endpoints at the beginning, as opposed to planning for infinite scope increase with the only constraint being time. We defined one end goal for each “segment” of the final product: the end goal for the game’s map was a node-based map that spanned multiple visually distinct areas, the end goal for the combat was a deep turn-based combat system with many types of effects beyond dealing damage, and the end goal for the narrative was a narrative that changed gameplay as the characters developed over multiple runs. These goals were daunting, but were more like guidelines pulling us along than features we planned on completing. After defining our end goals, we planned out the assets, programming structures, and design considerations we would need to create to get there. The asset lists and scrum tasks that we created made up the “spokes” of the spiderweb, the guidelines that we could use to eventually achieve our end goals. Using the spokes, we began adding the most fundamental features to the game, analogous to the first and smallest spiral in spiral development. However, because spiderweb development divides the project up into segments, different people on our team were able to work on different segments at the same time. Certain segments were often further along than others, but at any given point, the segments combined formed a functional game. If the work in a segment was unstable, like a strand of webbing only attached to one spoke, it could be cut off and the web returned to a finished state. For workflow organization, we initially utilized an agile scrum approach, with frequent scrums and short sprint-lengths, tracked on a Miro. We additionally used spreadsheets for tracking certain development pipelines such as audio, items, art, bug-tracking, etc. Using spiral development is difficult when you want to build systems to support all their future functionality at once. It would be technically possible to go back and change non-modular, non-reusable code made for spiral one into reusable code in future spirals, but neither core programmer felt like that was a good or efficient idea. Everyone working simultaneously in-engine with spiderweb development allowed our production pipelines to exist in parallel with fewer bottlenecks and dependencies slowing the process. While this caused the project to have a slower start, it created a solid foundation upon which the rest of the game was built.