Kia ora! Pang here. I'm one of the developers of the game Taiaha.

Taiaha is the second game I submitted for a game jam. I've learned so much through the development of this game and I would like to share my journey through this post.

The Decision to Join

I was depressed when I was developing the first game I submitted for a game jam. I turned my thoughts into written dialogues and written dialogues into an interactive game. It was cathartic. It was therapeutic even. My therapist was proud of me when I shared how instead of ruminating with my thoughts under a blanket, I released them creatively through game development.

When I heard of the Pirate Software game jam, I knew I wanted to join to feel what I felt back then. It was a selfish desire and perhaps most game developers can relate to this feeling. I asked accidentallyc to be my partner. He then asked me what my goals were for this game jam. I never thought much about a deeper reason for joining a game jam other than making a game. But after much contemplating, I told him that I want to learn Godot and that I want to commit to game development because I want to tell stories through my games.

Acknowledging these goals turned out to be a critical stage because during the two weeks of development, I often felt frustrated about my own expectations and pressured to follow the “usual route” of making games.

Is it fun for others? Is it exciting? Is it funny? Will others like it?

Then I go back to the conversation with my partner. “I’m here to learn and tell a story. I’m here to learn. I’m here to tell a story," I reminded myself.

(.づ◡﹏◡)づ.

Ideation

We spent a lot of time brainstorming (till past midnight!) and here are some of the ideas that we thought of:

• A girl (or a cat) carrying a deadly virus who can choose to be contagious around certain people. She hears conversations from people around her to decide who to contaminate.
• A sword that refuses to be pulled out unless the person is worthy. Think of it as a dating simulation but you are choosing your wielder.
• The road to becoming the next Excalibur. But you begin as a banana.
• A sentient banana that would be used as a murder weapon in a psychological thriller game.

We went to bed thinking we would go for the murderous banana, but I woke up the next day feeling unmotivated. A banana in a murder story is not exactly the kind of tale I want to write. Sure, it’s a fun concept and maybe one day, I will end up writing such story. But not that time. I wanted to tackle this theme head on. So I asked my partner to give me just another day to think about the game.

I started a philosophical journey thinking about why humans made weapons to begin with. For hunting? For war? For peace? For accessory? For surveillance? And the popular, named weapons such as Mjölnir and Excalibur? What did their stories contribute to humankind? 

Then I remembered a particular show I watched last year. It was a show set in pre-colonial Aotearoa (New Zealand) and the first episode I watched was about a chief and his weapon, rumoured to be unbreakable. The weapon called Taiaha. The legacy of such weapon almost forgotten in history.

That was when I decided that this is the story I want to tell. The story of a mighty weapon almost forgotten. The story of the Taiaha.

Game Design Document

Writing a Game Design Document (GDD) is perhaps the biggest reason I joined Pirate Software game jam. 

I enjoy writing. It's a useful method to organise one's thoughts. When developing any creation, not just games, writing ideas, requirements, obstacles, ideal timeline, etc. is a significant process. As a teacher of pubescent human beings, I emphasise this in class. Having a plan is good. Having it written down is tantamount to success. However, I rarely meet students who actually put the effort in documentation. I especially detest when students make me read AI-generated document.

So, when I heard that Pirate Software requires a GDD, the teacher in me was giddy. Sure. It's additional work on top of creating assets, coding, script writing, researching... but documentation is a great tool to plan, to manage, and to reflect.

The template had repetitive sections, based on my understanding of the given example. But it was a great start. I hope other young developers of this game jam took the GDD seriously and learned from writing it.

Here's the one we wrote for the game jam: Taiaha - Design Document

UI Design and Software Architecture

Once accidentallyc (who is well-versed in project management) finished setting up the tasks and timeline, we got on with the project.

We used Figma to develop the User Interface (UI) designs and to visualise the game loop and architecture. I was a clueless baby chick in game development (still growing) and accidentallyc spent an afternoon explaining "game loop" to me. After a heated deliberation, I told him if a "flowchart" would suffice to properly convey my game idea. The final output didn't follow the flowchart exactly, but I understand now why a game loop would be necessary when designing a game.

The software architecture was designed by accidentallyc and I tackled the UI designs. The first design was bland. But of course, they were just wireframes. I stepped out of my computer and after doing some chores, I had an inspiration. I redesigned the UI and the second design became the basis for the final game interface.

(There was supposed to be an image and an explanation of the design here but I got an error saying "YOU WRITE TOO MANY WORDS!" or something along those lines.)

Coding and Godot Development

The first time I downloaded Godot was to help accidentallyc develop levels for his puzzle game. My inexperience with the UI was a huge obstacle and so accidentallyc ended up developing a level editor as well. He is still developing and fine-tuning it.

The second time I opened Godot was to help a student debug her code. I am not new to programming (I teach it!) so I was able to help resolve the issues and get the game running. I did think that it uses a different paradigm than I am used to.

Then the third time is during the Pirate Software game jam. This time, I spent time reading a book about Godot (turned out it was outdated but the main concepts remain), watching tutorials on YouTube, and reading the Godot docs. I also have accidentallyc explain concepts and debug alongside with me. I enjoyed writing the scripts, rethinking about the architecture, and evaluating my code so I can do better next time.

I love it. I love developing on Godot.

There are still a ton of features I'm excited to learn (animation, camera, particles!) and I hope to implement them on future games. Having a skilled (and patient!) Godot developer was a huge advantage (thanks, partner!). He also told me that he learned a few tricks developing with me

ദ്ദി ˉ͈̀꒳ˉ͈́ )✧

Fruits of our Labour

Less than 7 days before submission. We had a working prototype without the major encounters added in. I was starting to doubt the game at this point. I felt that my writing was sloppy, rushed, uninteresting. I wanted to share this magnificent culture with others but I felt inadequate. I told my therapist about this feeling of ineptitude. She reminded me of the story I told her about my first game. How I followed by instinct to create. It didn't matter what others thought. I wanted to tell a story. I had to follow the storyteller in me. The success of the game is the resolve I have in telling the story. He who hears, let him hear. 

I'm glad to have spent these days growing in game development with my partner. I'm proud of what we created together. I'm excited to share this with my matua (an address of endearment for a teacher) and my classmates in Māori class. I hope I'll hear more stories about the taiaha and update the game.

In the end, I'm just pleased to have come this far.

(⁀ᗢ⁀)