Here we are in the final week of GDD730, where the ultimate aim was

To cultivate ways of collaborating and managing creative projects effectively in a distributed multidisciplinary context.

(Falmouth n.d.)

Our product

The 10-minute pitch:

The 3-minute demo:

A selection of docs can be found on our Drive.

Some highlights:

• the pitch
• the pitch planning
• team charter

What do I think we did well?

Everyone owned their own area of work

We kept spirits high through-out and none of us ever harboured ill feelings towards another. I think it helped that we had a diverse team where each member could own their piece of work without interference. Where there was skill overlap, we divvied up the work so individuals could own well-defined and demarcated pieces of work.

For example, I focused on the Twine (2009) prototype, and didn’t get involved at all in the Unity aspect of it, or Josh/Luis discussed the UX/research work amongst themselves, and it worked out well.

Recall that I did quite a deep dive of Twine in the early weeks of the project, and I wrote extensively about my Twine-focused learning and experimentation during week 2 and week 4.

That said, Twine is now well and truly a part of my future toolbox. I’m also glad that my general experience as a programmer has been a boon for my Twine learning, as I could read and grasp the documentation quickly, and incorporate 3rd-party tools like SugarCube (“SugarCube v2 Documentation” n.d.), jQuery Mobile (js.foundation n.d.), and Apache Cordova (“Apache Cordova” n.d.) to bolster the Twine base.

We kept the scope small

I’m a big fan of the Essentialism mindset (McKeown 2014), which helps one focus on what’s important, and working backwards from a stated goal and only doing those critical things for its success. In the early stages of our project, there were a lot of big, wonderful ideas, but I made an effort to communicate to the team to apply the essentialism mindset. I also came up with various escape hatches in case we ran out of time, for example:

• the plan was always to prototype in Twine, then make the polished product in Unity, taking advantage of the audio spatializer SDK (Technologies n.d.) as a replacement for expensive binaural audio equipment, so the escape hatch was to use Twine if the Unity stuff didn’t work out
• I found audio synthesis services, where an AI voice reads any text you give it in a convincing manner. This was our escape hatch if we ran out of time recording the narrations
• one of the team raised the idea of building a distribution platform as part of the project, where we can release our episodic content. This was going to be too much work, and it’s a better idea to see if the story has legs on established distribution platforms first

We pivoted on tools

We initially thought to use Microsoft Teams (“Microsoft Teams \Textbar Group Chat, Team Chat & Collaboration” n.d.) for all our product collaboration needs, as it has all the tools in one place (task tracker, docs, text/video chat, scheduling). However, we soon found out that the task tracker add-on lacked a lot of features that we were used to coming from tools like Jira, Pivotal Tracker, Trello, etc.

So, Josh moved us over to Pivotal Tracker, and visibility on work was increased greatly.

What do I think we didn’t do so well?

Not everyone communicated well

This is probably just due to this being a uni project, and everyone has a job and life to crack on with. Not everyone added their updates to the daily checkins (which Josh created). Not everyone updated their Pivotal Tracker tasks (even though everyone delivered their work, save for the Unity stuff, which I’ll discuss next).

I miscommunicated on the Unity deliverable

One of my escape hatches I mentioned earlier is using Twine as a backup plan, in case we didn’t have time for the Unity polish. I think this was misconstrued as the Unity being a “maybe” (update: I clarified this with Oli, and in his mind the Unity stuff was indeed a “maybe”). That’s a shame, because we lost out on a product we could actually ship to platforms and marketplaces for feedback from the wider community.

We were especially looking forward to getting our USP - the 3D spatial audio - into our product, using the Unity audio spatializer SDK. The Twine stuff lacked some features in this regard.

Perhaps the mistake here was making it feel to the team that Unity was taking a back-seat, where-as I really just wanted the Twine to be an escape hatch. None of the Unity stuff ever got made or prototyped - oh, well.

Yay, team

We had a really good team, and I was proud to put us front-and-center on the pitch deck, where it belongs (Cremades n.d.). Investors invest in teams, not ideas, after all.

Did my team like the project?

Team members can sometimes be in love with a different idea of what the game would be like (Schell 2019: 461). I was aware of this pitfall early, which is why I tried to make it clear in the very beginning what the game/product was going to be.

I think in the end everyone liked what we made, and was massively proud of it.

As team-work worth it in the end?

Game design and development are hard. Unless you are multitalented and your project is tiny, you can’t do it alone (Schell 2019: 468). People are more important than ideas, because, in the words of Pixar’s Ed Catmull

If you give a good idea to a mediocre group, they'll screw it up. If you give a mediocre idea to a good group, they'll fix it.

(Stanford Graduate School of Business n.d.)

Our team pulled together and delivered on both pivotal occasions (week 6 demo pitch, and week 12 final week). They really brought their own wealth of knowledge and experiences to the project.

Did everyone have fun?

In the book by Jesse Schell which I cited before, he recommends reading about Valve Software’s Cabal:

A game filtered through a large number of people would be anything other than bland. As it turned out, the opposite was true; the people involved were tired of working in isolation and were energized by the collaborative process, and the resulting designs had a consistent level of polish and depth that hadn’t been seen before.

(Birdwell 1999: 2)

And then furthermore

People with strong personalities, people with poor verbal skills, or people who just don’t like creating in a group setting shouldn’t be forced into it. We weighted our groups heavily toward people with a lot of group design experience, well ahead of game design experience.

(Birdwell 1999: 4)

I’m used to doing my creative projects by myself, but this project was an eye-opener as to how working with other creative individuals can bring special flair to a project which excites me, and inspires me to work on it more, and to do a better job (as I want to impress the others).

Luckily, none of us have anything against group work, or had poor verbal skills. It felt like folks spoke when they felt the need to, which is great, instead of just yammering, maybe due to some insecurity.

Working virtually and trusting totally

I’ve been a pro-remote worker since before the pandemic, having spent most of my working time in a home office, or a coworking space of my choosing. Having been a company founder myself, I’ve seen remote workers and different ways of communication “from the other side” so to speak (as the “boss”/client for whom the work is being done), and it has opened my eyes to how to be a better worker and better communicator.

Dhawan (2021) discusses a “digital body language”, of which one of the concepts are “trusting totally”. To foster such an environment, one has to show vulnerability, but also empower others to take ownership of their ideas.

An example of showing vulnerability is not being the know-it-all, but being able to put your hand up and say “I don’t know”. And example of empowering others is to trust them with a task, and if there’s been a mistake, then not telling the offender(s) off but rather saying “How can we learn from this?”. (I’ve done/run many a “blame-less post-mortem” (Atlassian n.d.) in the industry in the past to learn more from mistakes with my team.)

Once your team can trust totally, they can take calculated risks, knowing that your team mates will always be there to support you, come hell or high water.

I’ve made special efforts to empower others, e.g. not trying to be controlling of the idea (the audio-first branching narrative idea was mine), and letting another developer take full ownership of the final product coding (I quickly prototyped the demo in Twine, but let Oli have all the fun of implementing the final idea in Unity using 3D spatial audio SDK and whatnot), and encouraging the youngest, most-inexperienced member of our team to be team leader (when everyone presumed I would be, due to my experience, and I guess age 😂), etc.

PS I’ve said this many times here now, but Josh was a sterling team leader, and project manager. He’s got a maturity and insightfulness I’ve not seen in folks many years his senior. He’s onto a very good career as UX practitioner indeed!

PPS not being team leader does not mean that I didn’t take initiative when I deemed it necessary, e.g. like pulling the team together on a subject, running team retros, etc.

My next steps

The Bhagavad Gita, a Hindu holy scripture says that a person who is happy has achieved the self (Davis 2015).

In other words, authetically being yourself brings joy.

So, note to self:

Be myself. I am my happiness.

And for goodness’ sake, make more games!

Weekly development log

2021-08-16 Monday

Worked some more on cutting the 3-minute demo video tonight. Published draft #3 of our 3-minute demo video. I do sincerely hope this will be the final draft, as this is submission week, and I don’t want to be working on this in the few days leading up to D-Day.

I ran a quick retro before the supervisor catchup.

During the supervisor catch-up, it became clear that none of us had really understood one of the assignment deliverables, which was the “pitch planning doc”. After the catch-up, I created the doc right way, adding placeholder sections, and filling out those sections I was responsbile for.

(I thought the planning docs were the intermediate work-product that leads up to the final doc, but I was wrong.)

2021-08-17 Tuesday

We had an all-hands webinar (all the students, Jamie, and some of the supervisors). In my free moments, I helped out with the pitch planning doc, e.g. finding citations for some of our content, or converting some of our existing sources into citations.

2021-08-18 Wednesday

I made some final modifications to the team charter, adding a section on Conflict, and clearing up the Future Of Product section, now that we’re all a bit more au fait with intellectual property, etc.

2021-08-19 Thursday

I my spare moments through-out the day (before work, at lunch time, etc), I helped with making some final modifications to the pitch planning doc. Submission was at 5PM, and we were all very relieved to be done with this piece of work.

Bibliography

1. “Twine / An Open-Source Tool for Telling Interactive, Nonlinear Stories.” 2009. Available at: https://twinery.org/ [accessed 10 Jun 2021].
2. “Apache Cordova.” n.d. Available at: https://cordova.apache.org/ [accessed 8 Aug 2021].
3. “SugarCube v2 Documentation.” n.d. Available at: https://www.motoslave.net/sugarcube/2/docs/ [accessed 8 Aug 2021].
4. “Microsoft Teams \Textbar Group Chat, Team Chat & Collaboration.” n.d. Available at: https://www.microsoft.com/en-gb/microsoft-teams/group-chat-software [accessed 20 Aug 2021].
5. ATLASSIAN. n.d. “How to Run a Blameless Postmortem.” Atlassian. Available at: https://www.atlassian.com/incident-management/postmortem/blameless [accessed 20 Aug 2021].
6. BIRDWELL, Ken. 1999. “The Cabal: Valve’s Design Process For Creating Half-Life.” Gamasutra. Available at: https://www.gamasutra.com/view/feature/131815/the_cabal_valves_design_process_.php [accessed 27 Jun 2021].
7. CREMADES, Alejandro I. n.d. “How To Position The Team In A Pitch Deck.” Alejandro Cremades. Available at: https://alejandrocremades.com/how-to-position-the-team-in-a-pitch-deck/ [accessed 16 Aug 2021].
8. DAVIS, Richard H. 2015. The Bhagavad Gita: a Biography. Princeton: Princeton University Press.
9. DHAWAN, Erica. 2021. Digital Body Language: How to Build Trust and Connection, No Matter the Distance. First edition. New York: St. Martin’s Press.
10. FALMOUTH. n.d. “Falmouth University Courses and Modules - GDD730 - Co-Creative Design & Development Practice.” Available at: https://falmouth.akarisoftware.com/index.cfm/page/module/moduleId/93154 [accessed 20 Aug 2021].
11. MCKEOWN, Greg. 2014. Essentialism: the Disciplined Pursuit of Less.
12. SCHELL, Jesse. 2019. The Art of Game Design: a Book of Lenses. Third edition. Boca Raton: Taylor & Francis, a CRC title, part of the Taylor & Francis imprint, a member of the Taylor & Francis Group, the academic division of T&F Informa, plc.
13. TECHNOLOGIES, Unity. n.d. “Unity Real-Time Development Platform \Textbar 3D, 2D VR & AR Engine.” Available at: https://unity.com/ [accessed 10 Jun 2021].
14. JS.FOUNDATION, JS Foundation-. n.d. “JQuery Mobile.” Available at: https://jquerymobile.com/ [accessed 8 Aug 2021].
15. STANFORD GRADUATE SCHOOL OF BUSINESS. n.d. “Ed Catmull, Pixar: Keep Your Crises Small.” Available at: https://www.youtube.com/watch?v=k2h2lvhzMDc [accessed 20 Aug 2021].