Welcome to my Development Log. The second course in my Indie Game Development masters degree called Co-Creative Design & Development Practice has started and it is time to dig into it.

Forming the team

The first order of business in the course was to set up a team. I had already spoken to the coursemates who participated with me in the Ludum Dare 48 Game Jam in case they want to collaborate again. Some of them agreed and we formed The Cake is a Lie team. During the initial webinar, I also advertised the team and got our final member - Mary.

Click to view full size

In retrospect, in such situations might be better to be part of a team that is comprised of random people as you get to collaborate with more people and learn from more people. I reached this conclusion after forming this team, however, I don't regret forming the team with the people in it as they are all great people. Instead, I have decided to take this to the way I handle future game jams or course teamwork and I plan on applying it to the GMTK Game Jam 2021.

Image from GMTK Game Jam page

I am really happy that we have Mary in the team. She is from the User Experience masters course and will be able to contribute knowledge to the team which we as game developers lack. Additionally, she will help us create an impactful and accessible experience.

Ways of Working & Ideation

The first week was spent mostly sharing videos and articles on Discord (2021) to inspire us and help us narrow down the prototype we will be creating in the course. In our first team meeting, we started with filling the Team Charter document. I took the role of the scribe and we completed a good chunk of the document, however, we spent a lot of time trying to figure some details out and decided to postpone the completion and move to the ideation.

Click to view full size

The team was formed with a central idea - Level Editing. This could be interpreted in two ways - as a mechanic (player using the level editing to complete levels) or as a feature (player creating content for other users). We had a solid start with a ton of influences and potential directions for the game. However, due to time constraints, we had to end it there and continue asynchronously adding ideas to the Miro board (2021).

Click to view full size

I would have preferred if we figured out the idea we want to work on in the first week, however, we did decent progress towards figuring it out. One major factor was that we had all members of the team towards the end of that first week, hence the time to collaborate was rather limited.

Tools Setup

Apart from the communication and collaboration tools we agreed on in the team meeting, I went ahead and created the Git repository (2021) for the project. Of course, I had put in place all the game development tools I have developed on the side during the Development Practice course.

Image from Noxdew.com

Firstly, the repository is configured to use the Noxdew LFS Server - a Git LFS server I developed, which stores data in DigitalOcean Spaces. DigitalOcean Spaces is an object storage product similar to the popular AWS S3 (DigitalOcean, 2021). The catch is that it is extremely cheap compared to GitHub's LFS pricing. This will allow us to create assets without worrying about rising cost or bloating the size of the repository and slowing down the workflow. Additionally, the Noxdew LFS Server authenticates through GitHub, which means there is zero setup for people who use the GitHub Desktop client.

Image from Noxdew Game Demos

The second tool I integrated is Continuous Integration and Continuous Delivery. I have used the guide on Game CI (2021) to set up the GitHub Actions config, however, I added a little twist. Once a build succeeds it gets uploaded to a DigitalOcean Spaces bucket and automatically gets picked up and displayed by my Game Demos website. This setup will allow us to have the latest build always playable on the website to see our progress and get feedback from testers, as well as serve as a backup in case we have issues just before the submission deadline.

Image from Git Locks Manager Repository

Originally I set up a third tool - Git LFS Locking. It is used to simulate the binary file locking workflow typical for other version control systems such as Perforce (Exclusive File Locking, 2019). I also developed Git Locks Manager (2021) - a user-friendly GUI to make the Git LFS Locking API more accessible to non-engineers. However, I later disabled the file locking as I felt it would add too much friction to the members of the team who are still not fully versed with Git. Instead, I will try to teach all members how to best work in Unity to avoid conflicts and help them resolve any conflicts that arise.

References

Digitalocean.com. 2021. DigitalOcean. [online] Available at: https://www.digitalocean.com/ [Accessed 6 June 2021].

Discord. 2021. Discord | Your Place to Talk and Hang Out. [online] Available at: https://discord.com/ [Accessed 6 June 2021].

Game.ci. 2021. Game CI. [online] Available at: https://game.ci/ [Accessed 6 June 2021].

GitHub. 2021. Noxdew Git Locks Manager. [online] Available at: https://github.com/Noxdew/git-locks-manager [Accessed 6 June 2021].

Git-scm.com. 2021. Git. [online] Available at: https://git-scm.com/ [Accessed 6 June 2021].

Miro. 2021. Miro | Online Whiteboard for Virtual Collaboration. [online] Available at: https://miro.com [Accessed 6 June 2021].

Perforce Knowledgebase. 2019. Exclusive File Locking. [online] Available at: https://community.perforce.com/s/article/3114 [Accessed 6 June 2021].