Hello again everyone. Some time has passed since I've published Row champion and I decided to try my hand at game dev once again!
I've started working on a new prototype a few weeks ago and, while seeing some progress, I feel like I'm missing something and I'm not sure what to do next with it. So I decided to take a step back and write down my goals, ideas, and thoughts. I think it will help me clarify what game I want to make. I'm publishing everything as blog series, hoping it will also help somebody else.
I would like to set a few goals for myself to help me focus on the important stuff and not waste to much time on irrelevant things (which I tend to do again and again...)
This time is all about designing fun gameplay
I haven't thought a lot (sometimes at all) about the gameplay/core mechanic design when I was working on my previous games. My first game was a match 3 game and for the second one, I borrowed game mechanics from UGH! without really thinking if it fits a mobile game or my theme. My last game was designed by me, but I don't think I thought about it hard enough. Rather, I just went with the first idea I got.
This time I want to focus mainly on designing fun gameplay. I know it's not everything there is to a game, but I don't want to spend a lot of time polishing a game that just isn't fun to play.
This project will be done mostly in my free time, so it can't be anything too grand. I might fit a few hours here and there between my other projects, but that's not granted. I know that a good game needs some depth and complexity, but I hope I can get away with a minimal set of features as long as it's still fun to play.
Iterative design and prototyping
It's really rare for the first idea to be good - it usually falls short when turned into a prototype. It happened to me before multiple times and, unfortunately, it usually took me too long to notice. I think I often fall for sunk cost fallacy and I just continue working on a project even when I should stop, or at least cut it short.
This time I want to focus on prototyping and identifying bad designs early on. If a feature or mechanic is bad, I need to quickly decide if it can be fixed or it needs to be dropped like a lump of hot coal!
Creating the game, not the source code
Creating a game is the purpose here, not having pretty code or smart algorithms. I tend to jump into coding right away. I see a problem with code and start fixing it only to realize that it's a waste of time and the code was good enough. Other times I spend time coding some smart algorithm or idea only to realize that it doesn't affect the game that much or isn't that important for the game. In some cases, a much simpler, abstract code that just pretends to do some smart, complex, things are more than enough.
It's not to say that I will be ok with bad code. Poor code is hard to work with and can be as big timesink as trying to get a perfect code.
Right theme for mechanics
Having the right theme for the mechanics is pretty important. I made a mistake of not matching those before. Silly Ghosts used mechanics from UGH!, where the player had to pick up cavemen from one platform and place them on the other. Kind of like caveman taxi. In Silly Ghosts the player was a taxi but for ghosts. In UGH! the player could hit the caveman, who would then fall into the water and had to be rescued. It makes sense for humans. Not so much for ghosts... but it didn't occur to me until someone pointed it out in the comments!
While it's nice to figure things by yourself, you need a lot of time to do that. With this project, I'll try to learn from external sources as much as I can - podcasts, youtube, and books. Whatever might help me with the game. I also would like to write down what I'm learning to remember it better.