Halfway through the course, it is time for a mock pitch.

"Will pitch for money"

Pitching is something every professional has to do in one way or another in their profession. I like to look at it in a more general way, however - promoting one's ideas. With that definition, I think of our ideation at the start of the project as a form of pitching ideas to one another. The importance of it grows exponentially and it makes it no longer an activity only for those "at the top" but rather applicable at all professional levels.

We started creating our pitch deck quite early - in week 3. However, little progress was made with only some ideas being written down. It was only 4 days before the pitch date that we started working seriously on it. I've mentioned in previous blogs and in our retrospectives that it is difficult for the whole team to get together for scheduled meetings, let alone ad-hoc collaboration sessions. This has been one of the main reasons for this delay from my point of view, together with the lack of a clear picture of what needs to be included in the pitch.

To get us going, I dig up a list of example game pitch decks (Karr and Kramer, 2016) I've shared some weeks ago with the team. With them as a starting point, we defined what categories need to be included in the pitch and started working on them. At first, we worked asynchronously and I was focusing on chasing people to contribute to the pitch. However, the Sunday before the pitch was one of the few times we managed to get everybody together in a call, collaborating on the presentation. We split the slides based on specialism and got to work on populating them with information and presenter notes.

While everybody contributed with a couple of slides, images, fonts, etc., we faced a new problem - consistency. Everybody has their own style and way of creating presentations as well as different levels of experience in it. This meant that the presentation slides had different styles, different levels of detail (some too verbose, some not verbose enough) and the presenter notes didn't have a consistent tone of voice. Unfortunately, at this point, the team had ended the meeting and most were away, so I had to go over the presentation and work on the consistency. This was a new problem as in my past experience I was creating my own presentations or I have been presenting presentations made by a single person.

As the mock pitch day came near, it turned out most people won't be able to attend. Combined with the difficulty in getting the whole team together to practice the pitch, I realised I will have to present it myself. I practised the pitch around 10 times before the meeting and ended up quite happy with my flow. The feedback we received was also great - the people liked my presentation style, however, pointed out that we should include more examples of the game in the presentation. This feedback is very fair. I wanted to include more images and gifs showcasing the game, however, we didn't have a game. The demo included in the pitch was created and uploaded literally 5 minutes before the pitch.

Generally, I am a huge believer that pitches make the most impact if they are presented consistently throughout with a lot of emotion and enthusiasm. This can only be achieved through a lot of practice. Adding more people to a presentation makes the practice more difficult and creates more variability in the presentation style. However, this is a university course, so getting more people to present could be better for the final pitch. That said, currently, I don't see us succeeding in that.

List of topics I worked on for the pitch:

• Arranging the work
• Theme and formatting
• Slides: story, influences, state of the prototype, project scope
• Presenter notes for the intro and the slides above
• Consistency of style, level of detail and tone of voice across the pitch
• Presenting

Features, Features, Features

The first feature I implemented this week was the ability to save data. It was an easy one to put in place. While I followed a tutorial (Brackeys, 2018) to make sure I am doing things correctly it turned out that most of the work is handled in Unity the same way as it would in any other standalone application.

Next on my agenda was water. The main limitation we put in place was that it will only be shallow water. We made the decision in order to keep the implementation as simple as possible. Originally I started following a tutorial by Unity on the topic (2020), however, I couldn't find the textures used inside or a decent replacement for them. To go around the issue I went to the Asset Store and found a very neat asset (BitGem, 2021) that can create different types of water extremely easily. I don't regret the time I spent trying to follow the tutorial as I keep learning a lot on how to create cool shaders with the Unity Shader Graph, however, I keep finding easy to use free assets on the asset store for many of the problems I am trying to solve.

Last, I worked on implementing a button that needs a certain weight to be applied to it. This was an interesting problem to solve as I needed to figure out where a collision was happening from (Rifai, 2018) as well as figure out what was the mass on the button based on the impact applied (StaticRich, 2018). Both resources I used don't directly solve the problems I had but gave me the information I needed to put together the logic. This task was fairly lengthy and tricky to be done right, however, it is difficult to convey that through images or lengthy in-depth text.

Collaboration

Everywhere I go, I get asked questions about Git. While it is a fairly easy program to use, the learning curve is quite steep and most people haven't used it enough to be confident with it. Our level designers came to me with some complex merge conflicts they were getting. I helped them with those, however, I found they weren't following the "Prefab workflow" (Unity, 2021) in Unity correctly which was the cause for their conflicts.

We spent around an hour together where I ran them through an example so that they know what they were doing incorrectly and avoid future conflicts with their work. Once again, I was surprised that my knowledge of Unity and game development was more than what I thought. This does make me question whether I am getting enough value from the course. Looking at the Dunning-Kruger effect (Mazor and Fleming, 2021), I might have signed up for the course because I was in "Valley of Despair". Hopefully, this course isn't for nothing and would take me past the "Slope of Enlightenment".

Personal Retrospective

I wanted to look back at the project so far as we are halfway through it. We started very slow for the first two weeks, which has impacted our timelines a lot. Following that low, we had a period where people were very active and progress was very quick, but it seems we are again in another low period. As a team leader, I am trying to prompt people to keep Trello up-to-date and to progress different parts of the prototype, however, this is not always successful. I am trying to stay away from being a manager for the team and only trying to lead as I don't feel comfortable doing that and it doesn't seem right for a university course. Out progress so far makes me think we aren't going to complete a prototype by the end of the course.

Potentially, we were wrong with the scope of the project. However, I think the lack of communication at the bigging to find out what are the strengths and weaknesses of each member of the team made it impossible for us to know what we can achieve. I was the person pushing for the reduction of scope at the start, so our scope is based on what I think 5 people of my skill level can achieve, which of course is not accurate. The learning from this is that an initial team-building exercise before starting the project to understand what each person experience is and their strengths and weaknesses could significantly help with the project scoping. This is even more important when there is such a strict deadline. The benefits of such activity of course are limited by the participation of each member.

References

BitGem, 2021. URP Stylized Water Shader - Proto Series. [online] Unity Asset Store. Available at: https://assetstore.unity.com/packages/vfx/shaders/urp-stylized-water-shader-proto-series-187485 [Accessed 12 July 2021].

Brackeys, 2018. SAVE & LOAD SYSTEM in Unity. [online] Youtube.com. Available at: https://www.youtube.com/watch?v=XOjd_qU2Ido [Accessed 12 July 2021].

Karr, E. and Kramer, F., 2016. Pitch Decks - Founder's Toolkit. [online] Notion. Available at: https://www.notion.so/Pitch-Decks-f56e38c13fe6417f8379859e74367e1a [Accessed 12 July 2021].

Mazor, M. and Fleming, S.M., 2021. The Dunning-Kruger effect revisited. Nature Human Behaviour, 5(6), pp.677-678.

Rifai, 2018. Snap vector direction to nearest axis - Bocil Mania. [online] Bocil Mania. Available at: http://bocilmania.com/2018/04/26/snap-vector-direction-to-nearest-axis/ [Accessed 12 July 2021].

StaticRich, 2018. Stacking Objects on a Weight Button. [online] Unity Forum. Available at: https://forum.unity.com/threads/stacking-objects-on-a-weight-button.547010/ [Accessed 12 July 2021].

Unity Technologies, n.d. Unity Shader Graph | Build Your Shaders Visually with Unity | Unity. [online] Unity. Available at: https://unity.com/shader-graph [Accessed 12 July 2021].

Unity Technologies, 2020. Making a Water Shader in Unity with URP! (Tutorial). [online] Youtube.com. Available at: https://www.youtube.com/watch?v=gRq-IdShxpU [Accessed 12 July 2021].

Unity Technologies, 2021. Prefab Workflow - Unity | Unity. [online] Unity. Available at: https://unity.com/prefabs [Accessed July 2021].