Technically Clean
Role: Gameplay Programmer
Team size: 13
Time: 4 weeks
Made in Unity with C#
Game project made at Futuregames with the theme "Cleaning Checklist".
You had a party last night, with only two minutes left until your parents come home, can you clean the place in time? Technically Clean is a challenging, fast paced, arcadey puzzle game. There is a way to clean and a way to make things look clean. Find the best way to "Technically Clean" and reach the highest score.
Nominated for Best Art, Best Narrative and Best Tech at Swedish Game Awards 2022.
Items and stations
The biggest parts of this project was the items (ChoreObjects) and stations (ChoreStations) to put the items in. All four programmers worked on this together at the start of the project to make it so that everyone knew how things worked and could make changes on their own later.
An issue that came from this was that most changes were made in the base classes, making them bloated, instead of inheriting from them in new classes. In some cases we made scripts that were separate but connected with events through code or the inspector.
Station visuals
We wanted to make it so that certain stations could change appearance depending when a certain of items were put into it or when the player finishes interacting with the station.
To make this I made a new class (VisualUpdater) which updates the station visually by enabling and disabling child GameObjects when enough progress has been made. This is done by subscribing to the stations UnityEvents that get invoked whenever an item is added and when the stations task is completed.
Progress tracking
One of the challenges during this project was to track the players progress which in this case means finding out how much has been cleaned up in the level. This would also be used to stop the game and display the end screen when there's nothing left for the player to clean up.
In a recent course before this one we were taught how to use ScriptableObjects to store and share values in Unity and I decided to try to make the tracking using Runtime Sets; ScriptableObjects that contains lists for objects to be added and removed during runtime.
To monitor all items in a level I made Runtime Sets for each item type. For the items I made it so that they add themselves to the Runtime Sets when enabled and are removed when destroyed.
To calculate how much progress the player has made I created Tasks; ScriptableObjects that keep track of how many items currently are and have ever been in one of the Runtime Sets and are updated whenever something changes.
A problem that appeared was that items that are put into a station are destroyed which meant that they would basically count as cleaned items. To fix this problem I added tracking for the stations to make it possible to get how many items they contain. The progress percentage is then calculated in a UI script whenever anything changes.
We also wanted to track individual item types progress in the mobile phone UI in some way. The first thing I did was making it like a checklist by using the tasks to display messages in the mobile phone like "Clean dirty plates 0/10". This was later changed for narrative reasons to be more like a message from the parents with words corresponding to the item types being highlighted in green or red if that task is finished or not.
Score UI script that takes ScriptableObjects to calculate the current percentage.
Score UI script that takes ScriptableObjects to calculate the current percentage.
Takeaways
I feel like us programming items and stations together was a very good choice because it made it so that all programmers knew how the most important parts of the game worked and could easily make changes and add new functionality.
The item and station classes did become a bit bloated because of most changes being made directly in them. If I were to remake this project I would definitely like to try to break out some functionality that only applies to certain items/stations to other classes.
Working with ScriptableObjects was something that I personally really enjoyed because it made things very easy to customize and look at grouped data about the gameplay in the inspector. Although it was clear that a lot of the other programmers had difficulties understanding the use of
ScriptableObjects even after trying to explain how they were used.
Overall I think that this project was a huge success. We were able to make the game we wanted and had a lot of fun together. I think it was very important that we played some games together the first weeks for team building.