Softskill Plans and Improvement

As Studio 1 began, I became focused on the work that presented to me. Throughout Project 1 I focused too heavily on creating art assets and throughout Project 2 I prioritised the completion of group work over personal work.

My problem was that I didn’t have any personal management. Whenever I had time free to work on something, I found that I spent a lot of time just figuring out what I needed to work on. I always knew what group work I had to do, thanks to Hack n Plan, but when it came to write Dev Diaries or report my work, I struggled.

To help remedy this, I created a personal Hack n Plan where I listed all of the work that I had left to do. Anything from Dev Diaries to Audio to Scripting were placed in the Hack n Plan. It was a valuable tool for organising my free time and making me far more effective at completing my work.

It allows me to track my remaining work and monitor my week-to-week work ethic. The time spent updating Hack n Plan is more than made up for by the amount of time I save when finding something I want to work on.

I also attempted to use a work calendar, along side Hack n Plan. I found it useful at the start but, once I had memorised the times that I had set aside to work, I found myself not using it very often. I found that I worked better when I kept Hack n Plan opening, using it as a visual reminder of all of the work I had to do.

I plan on using Hack n Plan as often as possible. As it is now, Hack n Plan has been a valuable tool in helping me finish all the work that I needed to do. Additionally, I believe that, once I am more familiar with Hack n Plan, I can gain the benefits of a work calendar from Hack n Plan as well.


Win/Lose Scripting – Scene Change With a Key Press

For Project 3, I implemented a ‘Lose Screen’ and a ‘Win Screen’. At first, it was just a Canvas with a white Panel spread across it with some text and a button that said ‘Restart’ in the centre. This really hindered gameplay however, since gameplay was limited to a joystick and a single button. The button meant that players would have to move a hand from either the joystick or the single button to the mouse and click the on-screen button, Then, from there, they would have to quickly move their hand back to where is was previously.

I decided to fix this problem by writing a script that reloads the current level, if you lose, or the next level, if you win, with the Space Bar, the single button that was used for gameplay. This process involved writing three scripts: one that detects when the player has lost, one that reloads the current scene and one that loads the next scene. The first script that was written was HitDetection.cs and it contains the following:


In this script, lines 7 and 8 are are public references to the Win and the Lose Canvas’. This allows you to drag and drop the appropriate Canvas in the Inspector. The next line is a public reference to the PlayerController script (which contains all the code for how the player moves their character), however this is set in the Start() function instead of the Inspector.

The Start() function disables both the Win and Lose Canvas, then finds the PlayerController script that is attached to the GameObject tagged as PlayerBody. Disabling both Canvas’ is a crucial step because it stops them from appearing as soon as the game starts.

Finally, the OncollisionEnter2D() function. This function detects if the object that this script is attached to has collided with a GameObject tagged either Ground or EndZone. If it collides with the Ground, the LoseCanvas is enabled, however, if it collides with the EndZone, the WinCanvas is enabled instead. Either way the PlayerController script is disabled. This is because, when the player wins or loses, we want to stop them from being able to control the character afterwards.

Now to the LoseScreen script. It is a really small script that looks like this:


The Update() function in this script checks if the player presses the Space Bar and, if so, loads the active scene. Remember to include line 4 in any script that uses the SceneManager. Lines 1-3 are generated whenever you make a C# script in Unity, so you don’t need to worry about them, but line 4 is not.

The only difference between the LoseScreen script and the WinScreen script is line 11. Line 11 in the WinScreen script is this:


Instead of loading the active scene, this load the next scene. The next scene is determined by the order that the scenes are placed in File > Build Settings in Unity.

Importing Assets From Collaborators

When I imported the art assets, that I received from Hayden, into the Unity project, I encountered a problem. The assets could be dragged into the scene and the preview of the assets had some form of artefacting.

It turns out that the cause of this problem is that the assets’ Texture Type was set to Default.


In for the asset to be useable in the way that I want it to, I just needed to change the Texture Type from Default to Sprite (2D and UI). This immediately fixed all the problems that I was having.

However, all the art assets that Hayden sent me were huge when compared the to size of our levels and, well… pretty much everything else.


I tried adjusting the size of the head by changing the scale of it, but that had me working in decimals and it was just a headache to deal with.

Fortunately, there is another way to deal with this problem. It is called Pixels Per Unit.


Adjusting Pixels Per Unit to 2500, instead of 100, shrunk the size of the asset down to the small head that you can see below the big head in the 2nd image above this.

From there on out it was a simple Texture Type change and a Pixels Per Unit adjustment to each assets that Hayden sent and they all became useable.

Creating a Playtest Questionnaire

Throughout Project 3, there were two playtesting sessions where people from all over campus could come and play the games we had made. In order to get the most information that we could from the playtester, every team had to come up with three questions to ask playtesters about their game.

The purpose of these questions is not to see whether they liked it or not or where there could be improvements, but to make sure that the game that we are creating is giving players the experience that we intend them to have.

As such, our questions need to be carefully tailored so that there aren’t subtle indicators that might influence the answers that we are given.

During our teams’ brainstorming we came up with questions such as:

  • How difficult did you find balancing the head? (1-5)
  • Were any parts of the game too frustrating?
  • Does the game have a message?

The above three questions all contain subtle hints toward what we want the answer to be. The first two lead the playing into thinking that we want them to find the game hard and will likely skew their answers, perhaps unconsciously, towards suggesting that the game is hard. The third question leads people to believe that the games has a message just by virtue of bringing it to attention.

So we can’t use language similar to that, but we also can’t use a scaling system that you can see in the first question. The scaling system tells us very little. While it certainly tells us what they thought, it doesn’t tell us why they thought that way and gives us no indication as to whether the rating was a result of design or something else.

After culling a few more questions and having more discussion, we decided that the best way to go was to ask open-ended questions that required an answer that was at least a few words. Asking questions that can be answered with a yes or a no aren’t very helpful and questions that require a paragraph are too daunting to answer, so those types of questions aren’t viable either.

The initial three that the team chose were:

  1. Describe a moment when you nearly lost your balance but recovered.
  2. Describe a moment when you chose not to boast to someone.
  3. Describe a moment in the game where you failed on a ramp. How did that impact your strategy?

When asked what answers we wanted to receive from these questions. They didn’t hold up very well. The answers we gave were fairly mundane and didn’t really tell us much about the feel of the game. Our answers were:

  1. Second time I went up a ramp
  2. Before I went up a ramp
  3. I failed the ramp the first time I took, so I moved slower next time.

All these answers really tell us is that ramps exist and are difficult. Plus it is far too ramp-focused in a game about boasting. Also, the third question was a bit too leading, so the team reworked the questions into:

  1. Please describe a moment where you feel like you boasted too much.
  2. Please describe a moment when you nearly lost your balance but recovered.
  3. Please describe a moment in the game where you changed your strategy – why did you choose to change it?

These questions are far more open in terms of responses that the team believes they will receive.


When it came time to playtest, the team never changed questions between any of the playtesting sessions. The last two questions stayed because they made sure that the changes made to how the player moves and to the levels didn’t interfere with the experience that we were trying to create. However, in hindsight, the first question should have been changed because the team received everything from joke answers to confusion as to what boasting was.

The game, in the state it was in at the time, didn’t properly notify the player of who they could boast to or even the fact that they could boast at all. This means that some players missed that mechanic entirely, leaving the question obsolete.

Project 3 – Post-Mortem

For this third and final project of Studio 1, some of the students in the class were split into teams of three while some students opted to do this project by themselves. I was in a team that consisted of Ben, Ruby and myself. The project required the class to brainstorm as many verbs as possible. Then all the verbs were gathered together in a single document and discussed amongst the class. It is after this that the teams got together to discuss what game they wanted to make. However, there was a caveat. This caveat was that the game must be controlled with a single joystick and a single button. The single button must perform the verb that the team has chosen.

Our team selected the verb ‘Boast’ and decided to make a game in which the player must navigate around a city and boast to people who are smaller than them. Every time to boast to someone smaller than you, your head gets bigger. This, in turn, makes it harder for the player to navigate the level.


What Went Right:


The team used Discord to communicate with each other throughout the project. Since it is available on both computer and mobile, team members were able access each other whenever it was needed. It was an excellent way to communicate who was working on what and when they were going to be working on it. Source control was also very easy since we would be able to determine when people were working and when people were committing their work. As a result, we never encountered a problem that required us to regress to an earlier version of the game.

The reason why this happened was because all members of the team were very willing to communicate with one another and were transparent when it came to their availability. Each member of the team, at one point or another, had approximately one whole week where they wouldn’t be able to contribute to the project and that was told to every other member of the team as early as possible. This allowed the other team members to prepare for the decreased output of the team and adjust the plan accordingly.

What I can learn from this is that communication is the key to a good project. Even though the project is incomplete, but submitted regardless, the team was happy with what they achieved. Being able to adjust plans as early as possible and assign work to different people as need be was a great advantage. With good communication we were able to manage members’ expectations while maintaining a positive attitude.


What Went Wrong:

Communication w/ Collaborators:

For this project the team collaborated with an Animation student named Hayden and an Audio student named Bronte. The team met with them both within the first few weeks of the project and discussed the game, as well as what deliverables the team would need from each of them. After that meeting, all discussion was delegated to emails and it was at this point that things started going downhill. While the team did receive the assets they needed, some required adjusts and it took days for that information to be received.

The reason why this happened is because emails were sent every few days, meaning that it wasn’t possible for a reliable and quick response from any of the involved parties. This resulted in delayed feedback and adjustments. This delay could last anywhere between a few days to a week.

What I can learn from this is that all members of the team, either internal or external members, need to use the same method of communication. The internal team (Ben, Ruby and I) had excellent communication but the external team (Hayden and Bronte) didn’t. Including the external team into Discord and Hack n Plan would allow them to work autonomously, thus removing the need for email and removing the delay in communication. This would also allow the external team to see who is currently working and enable direct messaging and notifications for faster responses to feedback and more.


Work Backlog:

The team entered the project with work remaining on previous projects. This left each team member essentially working on at least two projects at once. Having the team’s’ attention divided didn’t help Project 3 and led to the team running out of time, therefore forcing them to stop working on the project before it was able to be completed

The reason why this happened varies. Each team member might have different reasons for having work left over from projects. At the very least, Project 2 still had work that was left for Strike Teams to complete and each member of this team was in a least one Strike Team.

What I can learn from this is that people will have their own work to do outside of projects that they work on and, if need be, that work should be considered into the planning of the current project.