Devlog 0: Previously..

Hi Everyone!

I've decided to start a dev log on this project to record my journey on this project. The first one focuses on why I wanted to make this game and what have brought me to this point.

---- Motivation ----

As I've mentioned this on the project page, this project is a gift for my mum. 

Ever since I started making games, I've developed this habit of looking at a game and trying to tell how it's made, and most of the time, even if I know it would be a complicated process, I can grasp roughly how to approach different features. During holidays when I went home and stayed with my parents, I've been watching my mum play games. Which, in a classic middle-aged mum fashion, it's often some type of tile matching game like match 3. And I have realised that, Wait, how do you even start setting this up?

At the start of this year, I wanted to prepare a gift for my mum to show her my appreciation for her support of my childish desire to study in another country, and eventually going into game design. And I was inspired by what our lecturer said about how he always makes party games for Christmas because as a game dev, we have more time than free money. So I decided to see if I can make a match 3 game for her.

It was meant to be a holiday project, but as uni started again, the prototyping class I took have this assignment that is oriented around a technical aspect, so I took it as an oppotunity to jumpstart my project. I am very happy that our classes encourages us to find goals in our project and I was able to take this project how I wanted for the assignment.

---- Previously ----

For the assignment, I spent 2 weeks to build the fundation of a classic match 3 gameplay loosely following this tutorial by catlike coding.

I needed to have a starting point so I found this tutorial. They have introduced ideas like storing individual tile information in a struct, seperating the logic from the visuals, organising tiles into 2D array, and translating screen input to tile position.

Godot is my prefered engine for 2D games so I decided to make this project in Godot as well. It have definitely made my life harder as I cannot directly follow this tutorial because it is based in Unity and these two engines encourage different ways of implementing features. It forced me to understand the logic itself and adapt the pattern to a new engine/coding language which I think is a very useful learning experience.

(If you are interested in more details about the technical setup of match 3 in Godot, I've attached a guide to what I've learned which you can download at the end of the page.)

By week 3 into the project, I already have a functioning match 3 game with the basic "swap => match => despawn => respawn => repeat" game loop. Instead of polishing the game, i've decided to see where else I can take this project as the sprite of the prototyping class is prototyping and iterating. 

I started thinking about what type of game my mum would like to play. And based on my knowledge about her, I've landed on idle/resource management game first as it is a casual and less intensive genre which sounds perfect for my mum. But as I started building the basic of an idle game and did more research on what other idle game does, I've realised that it doesn't make sense to combine idle game with match 3, at least not with what I was thinking about. What makes a match 3 game fun is the matching action, and idle element means it's very likely I would automate this action. I want the match 3 gameplay to remain the center of the game instead of the first stage that can be replaced. The cult classic Cookie Clicker has the same thing with clicking cookies, where you manually click the cookie to collect them at the start, but then you get upgrades that makes manual click action less effective. How they have kept the manual action relevant to gameplay is by adding upgrades that makes clicking more effective, and have golden cookies that pops up that can significantly boost clicking. This means player would still perform this action for actual gameplay reason rather than as a stress ball, but the majority of the time are spend waiting.

This is totally valid as a game, but for this project active engagement is very important, so I started considering why I wanted to make this an idle game in the first place. How my mum engages with games is mostly short sessions in between daily chores so I wanted this game to be easy to pick up and put down, which is a characteristic that idle games have. Classic match 3 games do this with levels so it's easy to break the game down to shorter sessions. I wanted to be more experimental and try something else.

I ended up with a city builder idea where you generate resources by matching resource tiles and you can spend resources to build the city which can speed up your resource collection by either boosting the numbers or provide new mechanics that is directly related to the match 3 gameplay. I imagine it would be like Catan, but instead of rolling dice, you play match 3 for resources.

When I brought the new prototype to the class, people have brought up a new question: Why is player building the city? What are they trying to achieve?  I thought it would be fun to add a loose narrative as an answer which have led to a second stage, an ending, and a loosing state. 

Now at the start of the game, player will be told that there is a prophecy that, in 10 years time, a disaster will happen and the people need to be ready to face it. They need to develop the settlement, stock resources and prepare for whatever it is to come. Then player starts to play the game and build their city. And when time runs out, a dragon shows up and attacks the city. Player only have what they have gathered to defend themself.

Of course if you've played the prototype that I've uploaded, you won't see any of those because i only had 1 week left when I had come up with this narrative. But you can see a progress bar in the middle that represents time in the first stage and dragon health at the second stage. As uni have ended for me now, I think it's time to finish this project.

--- Design Pillar ---

I have tidied up the decisions that I've made during the prototyping stage into these design pillars:

Responsive 

Every action should have satisfying feedback, but not overwhelming. The player motivation I want to target with this game is to distress and relax. This plays into the match 3 gameplay loop more, but to keep it consistant and as good UX design in general, being responsive to player input is a very important factor to the development process.

Casual fun 

Easy to pick up, easy to put down, and still engaging when you play it again. Play sessions can be broken down to 5~20 minutes blocks but one playthrough of the game needs longer to complete. Keeping the mechanics straightforward and well explained.

Strategic 

Player should be able to plan ahead. The game provides required information to make calculated decisions. Having a system that can afford different strategies if possible. The city building system should intertwine into match 3 puzzles, providing different mechanics and outcomes to give different playstyle.

Please let me know what you think about the game, or follow me if you want to know how the project goes.