FOOL’S ERRAND

Sep 2017 - Oct 2017

Fool’s Errand is a 2D single player cathartic experience. It is aimed to evoke loneliness, anxiety, frustration, and hopelessness. I wanted to challenge myself for this project by minimizing the scope to a single sprite, a white circle, and one mechanic, clicking. Through this simplistic scope, I wanted to create an experience for players. 

The goal of the game is to keep the smaller circles from leaving the center. It seemingly lasts forever with no end in sight. Everything in the game is intentional; the colors, audio, the movement of the circles and borders. I wanted to focus on user experience, making everything responsive with plenty of feedback. 

This project was created independently over half the fall semester. It was developed using Unity3D, ITween, Audacity, and audio from Sonniss GDC packs.

 
 

UX/UI DESIGNER

  • Tested constantly through development to find moments lacking feedback

  • Implemented audio and visual feedback for important events

  • Analyzed similar games to find what elements were successful and unsuccessful

SYSTEM DESIGNER

  • Developed the game and modular systems to allow for quick iteration and improvements to be made

  • Balanced the values to create a engaging, yet tense, experience

CONTENT DESIGNER

  • Created the audio using Audacity and sound clips in the Sonniss GDC packs

POST-MORTEM

IS IT WHAT I WANTED?

I am very happy with this project. I knew that I wanted to represent a breakup and the anxiety, frustration, and isolation that goes along with that. Initially I had planned on creating a more resource management -like game where you manage a literal team of squares giving them tasks to do. This was too on the nose for what I wanted to get across and seemed like too much balancing for the time we had to do this project.

In the end, I decided to go with a more abstracted version. Besides the base idea of a bunch of circles running away from you with the walls collapsing in, I didn’t have much of a plan. And because of the small scope I was able to focus on making the experience what it needed to be.

Overall the project progressed further then what I had planned and expected. I think the only real thing I wanted to add in was effects for when the nodes collide with the walls and die.

WAS THE WORK IMPACTFUL?

Absolutely yes. This project was well scoped, and after developing the base mechanic, everything after that was an overall improvement of the game. There was enough time to try new pieces in the game and realize they weren’t working after playtests and make everything polished.

The audio and particles were probably the most impactful part of the game, and after getting them into the project it created the atmosphere and feedback I was looking for. I was afraid that spending so much time finding and mixing the audio was going to be a waste while I could have focused on other parts of the game. In the end, the sounds and music ended up being the most mentioned thing in all the playtests.

WHAT METHODS WORKED WELL?

The scope proved to be the biggest block in my previous project and I wanted to completely avoid that this go around. So, starting with a small scope and clear vision really started me off well. Besides that, it was just constantly tinkering with the project after cramming to get the main mechanic done and working in a short amount of time.

The early start of my project was well organized too. It was easy to work with and tinker, and was a good start. Towards the end, it started getting sloppy but overall the project was quick to iterate because of the modularity.

WHAT WERE FRUSTRATING?

As mentioned above, my code was both messy and inefficient. This was constantly frustrating since I had plenty of times where I would return to code trying to adjust something or fix another thing and I would spend a lot of time just trying to understand what was happening before I could even start fixing anything.

Another thing that I found frustrating was how I tended to avoid new concepts that I hadn’t tried before in Unity. One big reason for this was because I believed it would be faster to go with what I knew but in the end it led me to creating shortcuts that I didn’t fully understand and ended up breaking parts of the build which I would have to figure out how to fix.

 

HOW CAN I IMPROVE?

The first part is easy to say, but sometimes more difficult to execute. To mitigate the low documentation risk on a tool I may be using, I can do more research before diving in head-first expecting things to work a certain way. Finding forums and documentation on the specific tool will be important before I start a project and begin relying on the tool for my entire project.

The Post-Processing effect problem had a very simple solution, just talk to more people about my projects. After going through an incredibly round-about way of getting the effects, and getting them working in the game, I was talking to some friends about it and one of them showed me a simple solution to my problem (a couple weeks after I had been done with the effects, of course). So overall, just talking about my project with other people can be super helpful.