Post-Mortem: Town Developer
Post-Mortem: Town Developer
So I've made a game!
No, not the one I've been working on for the last 10 months or so. My main game, which will remain publicly untitled for the time being, is still in works. But after closing a milestone at the end of June I was in the mood to get a distraction from it. Incidentally, an idea just got into my head at that point in time: what if there was a reversed tower defense game; a game where you don't kill blobs, but you enhance them and help them reach the end better and in a specific state. If you think about it for some time, you'll realize that it a game like that feels less like a tower defense, and more like a management type. Which is how I've arrived to the city management theme. And with those two ideas in hand I started to work on a prototype.
I'm not that smart of a person, but I do have a tendency to look for a systemic solution rather than ad-hocing something up. When faced with a problem, I always start to drift away from its specific characteristics and try and imagine a system that would solve this and every other possible related issue. And that's not how you do prototyping. In fact, this hurts your progression in game development a lot. We don't actually know what would work well for people. We start with some ideas we would like to try and we give them rough shapes and then we release the monkeys. There is no way around it, because you cannot finish a decent game without experimentation and try-and-error with real users. I was thankfully able to force myself into a new routine of making things that work right here and right now. I had a deadline.
The initial goal was to make a prototype and give it away to people in a few days or a week. But after a few days of development I saw a good enough result that I thought I just might turn it into a rough, but complete product. So I've extended the deadline to two weeks. But it still was a hard limitation. And that helped me get to the important experimental parts first, and only when sure that they are worthy convert them to full systems. It turns out, Godot is extremely friendly to this approach too. So a personal lesson here: fight the urge to make everything perfectly scalable the first time you try. Yes, you can probably imagine a good enough system, but the time you'll spend working on it is the time wasted not making sure the game actually plays properly.
What is the gameplay here, anyway? Well, the idea was based on the tower defense genre, but the goal would be to manage a town by building stuff that helps various traffic to reach the end base. I quickly had a few of the sprites ready to represent the traffic: cars, trucks, pedestrians, and bikes. Then there were several ideas on how to make their interactions interesting. Any modern city aims to reduce car traffic in favour or pedestrians and public transportation. So some ideas were flying around the balance of what types of vehicles can reach the end, and how would that affect the state of the world. I had an image of a tram or a metro station, that would provide means to switch cars into trams and pedestrians, reducing their environmental impact, or making huge masses of people move together instead of one or two per each car.
But the first thing that I've actually implemented was a very basic concept of pollution. Cars add pollution. Parks reduce it. Cars make money, parks cost money. Cars have lasting effects, trees are vulnerable and can decay. Just one level, a straight line, and some extensive zoning allowing for free tower placement. It was enough to send it my friends for their feedback. And the game was playable! I actually had something to it. The only issue was, I had no idea how it was supposed to be played. I needed people to invent the solutions first. My friends are pretty smart, and we have spent a lot of time in various puzzle games, so they were creative. They were able to quickly exploit all the systems in place, one way or another.
My job at that point was to both add new mechanics based on what I had planned and to use their experience to make small changes across the board. First, the trucks were introduced, slow and dirty. Then the field has changed enough to limit their abuse of zoning. The playing field was shaping up. Yet I had a very hard time figuring out the balance for each level. I still have very little idea about how to approach the balancing in these types of games. I've tried to make some calculations in spreadsheets, but it didn't give me any insight. The problem is, user interactions can be unpredictable and there are time-dependant effects within levels. How do you calculate that? I don't know. But with the hindsight I'm sure, that I should've invested more time into this. It might seem easier to just randomly mash together levels and playtest them until they are beatable. But in reality, if a level is supposed to be hard and you don't have a reliable approach to solve it quickly without making it easy for the player, you'll spend eternity playtesting everything. So, in the future, I will make mathematical models to make sure you can create beatable levels based on the data alone.
Eventually, my friends came up with the ultimate tactic to beat the levels. And I liked it so much, I've based the rest of the game on it. It was a bold tactic, but not the one you come up with immediatelly. I believe that my friends got to it only because they were playing the game for some time already. That, or they are natural at playtesting. Either way, it was a nice way to approach things, making levels less of a bore and more of a living system with constant challenges. However, after the game had been made public, I found out that people can't arrive at that solution by themselves, get stuck at the first, introductory level and feel stupid. The root of it is in the fact that this game has no tutorials and explains very little. It is so partially by design and partially because of the deadline. I don't like puzzle games starting slow and giving you extremely primitive levels to work with. There is of course balance to it, but there are still many examples that tend to grab you by your hand and guide you through the first couple of puzzles too strictly.
And I, personally, don't enjoy it. Which is why the easing of the learning curve was one of the things I've decided to sacrifice when trying to make it within 2 weeks. My initial thought was that it would be part of the fun to try and break the game until you arrive to the solution that works. I've also believed that if a puzzle game is hard and requires a lot of investment to finish, there is little point to start it very very slow. Those who are going to finish your game will be annoyed by easy puzzles. And those who need easy puzzles won't ever finish your game. But I realize now how faulty this opinion is. First impression makes or break any experience, but it's not just that. There are a lot of people who would never finish your game whatever it is. Steam achievements for some titles tell ridiculous stories sometimes. The reality is that you have to provide solid and accessible experience within the first third of the game regardless of the later difficulty. If your game is too hard to play and enjoy from the very first level, you won't even benefit from giving it away for free. People just won't progress and give you any further feedback!
Overall, I feel contained by this game. It was a positive experience in the middle of some very taxing development. I mean, I made a game! In two weeks! And enjoyed it a lot with my friends! Mass appeal was never the goal here and that still gave me a lot of thoughts to consider. I will be sure to make another little game before our main release sometime in 2022.
You can get Town Developer for free on Itch: https://yurisizov.itch.io/town-developer