Welcome to Snurder Game!

This is an open map puzzle game in which you, as a snail, explore a residential property. The goal is to kill the human that is living on the same property without getting yourself killed within the time limit of 15 game hours, which is approximately 4 real-life minutes. To do so, you must collect and combine items to take down the human living in your home.

Hint* The snail is small, so to reach higher places, there is a stool that you can push to get to higher elevations in the house that would otherwise be inaccessible. 

Good luck in trying to kill the human, and have fun!

Controls

Postmortem Video

Postmortem Write-up

What went right?

Early on, we decided to have two programmers, two level designers, one artist, and a project lead who supported across different areas. This structure worked out at the beginning of planning and prototyping our project. By having bi-weekly meetings/check-ins, it kept the motivation alive and running. The programmers worked on core mechanics and quality control, while the level designers planned how the player could take out the human, what items would be available, and what challenges the player would face. They also designed the house layout, UI buttons, and inventory system, while contributing to music, sound effects, and tutorials. The artist led the art direction and created all of the assets, giving the game its unique look and feel.

What were we proud of?  

The aesthetic direction of our game and the overall implementation of assets really tied the game together, as well as the core mechanics of the human and snail. Since the program, Gamemaker, did not have a set elevation, one of the programmers, Dean, spent a good amount of time figuring out the elevation for the snail getting on top of furniture. The other programmer, Gabe, spent most time with the pathfinding and the motion of the human, which made the game feel unique. 

What worked better than expected?  

When Infinite Fishing discussed the direction of the game, the actual implementation from idea to code worked better than expected. In the early stages of development with filler sprites made by the programmers, it did not convince everyone that the game would turn out well from the ideas that were written down. After the art assets started to roll out, the vision started to show clearly, making it more interesting than expected.

What went wrong?  

 As the semester progressed, the team's motivation and organization began to slip. Communication shifted from Trello to Discord due to the lack of updating tasks, and so the workflow became messy. Being new to game development, members also struggled with scaling assets, implementing mechanics, and coordinating effectively. Some of our members started to run out of tasks to do, and it put a strain on our teamwork overall. Our first check-in was what woke us up to our difficulties. 

How did you overcome those problems?  

We regrouped the weekend right after the check-in to regroup. By using Codecks, an organization's site that was more engaging, it increased the team's communication. We reinforced regular meetings to stay on track. We also had to cut back on ambitious ideas like multiple levels and a wide variety of kill methods to focus on polishing one solid level and a smaller set of reliable mechanics. By improving communication, narrowing our vision, and prioritizing quality over quantity, we overcame these challenges.

What changes were made and why?

To keep the project manageable, we shifted our focus toward polishing the core mechanics like human pathfinding, snail interactions, and item functionality rather than expanding into multiple levels or complex systems. Some features we were excited about, such as crafting through mouse holes or a lure system to draw the human to certain areas, had to be cut because they were too ambitious for the time we had. Instead, we added an arrow that helps indicate where the human is. We reduced the number of kill methods, choosing to refine a smaller set that worked reliably instead of spreading ourselves thin with buggy or incomplete ideas. By simplifying the design, we ensured the game was cohesive and playable within the deadline. 

What did you learn? 

One of the biggest lessons was how to use GameMaker to its fullest potential in creating a complete game. We also learned the importance of organization and version control, especially with GitHub. Early on, merging different versions of the project caused problems, which taught us how critical it is for programmers to coordinate closely and communicate often. Another lesson was about pacing. At first, we thought we were on track, but our first check-in showed us we were actually behind. That experience taught us how to better measure progress and set realistic goals. Instead of three levels, we focused on delivering one solid level, which helped us finish on time while still keeping the game playable. On the art side, we learned how to make tiled backgrounds and scale objects properly so they fit together seamlessly in a room. Overall, we discovered that struggling is part of the process, but by supporting each other, asking for advice, and adapting to challenges, we were able to grow as developers and deliver a game.