Noid Post-Mortem

Developing Noid, a short horror point-and-click puzzle game, presented both challenges and successes. This project allowed me to refine my understanding of puzzle mechanics and apply my coding skills effectively. Initially developed in Unreal Engine, I transitioned to Twine, a decision that proved essential to completing the game on time. This post-mortem reflects on what went right, what went wrong, challenges faced, and the key lessons learned.

 

What Went Right

Switching from Unreal to Twine was one of the best decisions I made. Unreal’s complexity caused delays in implementing basic mechanics like character movement, and I found myself spending too much time troubleshooting rather than focusing on the game’s core puzzles. By moving to Twine, I was able to quickly implement key features, such as item-based puzzles. For example, the puzzle requiring a hammer and sheet rope to escape from a window was straightforward to build with Twine’s variable system, allowing me to track item usage and guide player progression smoothly.

Another success was the implementation of a code puzzle where players unlock a diary with a four-digit code. This puzzle enhanced the challenge, requiring players to search for clues and think critically.

In terms of the visuals, I embraced a 90s pixel-art aesthetic, converting drawings and photos into bitmaps to create the art efficiently. This style fit the retro atmosphere I was aiming for and allowed me to maintain consistency in the game’s look while saving time on asset creation.

I’m particularly proud of my ability to independently develop the game, building on my coding knowledge and implementing mechanics without relying on tutorials. I set up variable checks and item states that drove the puzzle mechanics, which gave me more confidence in my coding abilities.

 

What Went Wrong

Unreal proved too complex for the simple mechanics I had planned. Despite trying to use an AI controller for character movement, I ran into persistent technical problems, such as camera issues and significant progress loss due to running out of disk space. These setbacks ultimately prompted me to switch to Twine, where I could focus on building puzzles rather than fixing technical problems.

Though Twine allowed me to develop more efficiently, the user interface didn’t turn out as polished as I wanted. I didn’t have enough time to give it the attention it needed, which left it feeling functional but less visually appealing.

 

Challenges

One major challenge was my initial choice to use Unreal. I spent too much time troubleshooting problems with the engine, such as issues with the camera not following the character correctly. Additionally, a lack of disk space caused me to lose a significant amount of progress, which set me back even further. These difficulties consumed valuable development time, forcing me to cut back on planned features and delay progress on the core mechanics.

Switching to Twine helped solve these technical problems, but the transition came with its own learning curve. I had to quickly adapt to Twine’s limitations while still implementing the mechanics and features I had originally envisioned. Time became an increasing challenge as I had to make up for lost development hours by focusing more on the puzzles and less on polishing certain aspects, like the user interface.

The decision to focus on puzzle mechanics rather than more advanced features like complex animations or detailed art was necessary due to time constraints. While I’m happy with the pixel art style I used, I didn’t have time to create unique visuals for every interaction as I had hoped.

Ultimately, balancing ambition with practicality was the biggest challenge. Letting go of the work I had already done in Unreal was difficult, but it allowed me to finish the game and meet my core goals within the remaining time.

 

What I Would Change & Lessons Learned

The most important lesson I learned is the value of adaptability. Switching to Twine allowed me to focus on the essential puzzle mechanics and meet my deadline. If I could start over, I would choose Twine from the beginning to save time and avoid unnecessary complexity.

Additionally, selecting the right tool for the job is critical. Unreal, while powerful, wasn’t suited to this project. Twine, on the other hand, provided the right balance between functionality and ease of use. Moving forward, I’ll make sure to pick the appropriate tool for future projects from the outset.

Finally, I would spend more time refining the user interface. While the puzzle mechanics worked well, I would have liked to enhance the UI to make the overall experience more polished and visually engaging.

Conclusion

Overall, Noid was a rewarding project that helped me grow as a developer. Although I faced technical setbacks and time management challenges, switching to a simpler approach with Twine allowed me to focus on the game’s core elements. The lessons I’ve learned—especially about choosing the right tools and adapting to obstacles—will guide me in future projects. Balancing creativity with practicality will be essential as I move forward and apply these insights to my next game.