City: Content
Written: 2016-01-05 The last few sprints added a number of interesting features to the game, but I've been unable to determine how much I like them becuase the game only had enough content to be able to ensure that the features work, not to see if they play well (you can read those posts [here](/blog/city/towerLife) and [here](/blog/city/personInfo)). Overall, the addition of the content seems promising. The game is still flawed in many ways, which I will cover later, but the simulation aspects have continuously overperformed and that's the side that carries the majority of the risk. With that doing well, I think that it is safe to continue working on this game for another sprint. ## Feature Overview The purpose of this sprint was to put in some content so that it would be easier to evaluate the features recently added. This is not going to be an actual feature audit, I think that doing so now would be premature. This is just addressing the design debt that the previous few weeks have accrued. Focus System ([described here](/blog/city/personInfo)) - fail. This still doesn't do much of anything and is finicky to keep track of. I really like the metaphor here and the game needs something like this for gameplay purposes, so I'm not just ripping it out right now, but this is on my list of things that need to be fixed or replaced. Times of Day ([described here](/blog/city/personInfo)) - medium. Spacing out the generation of will (the currency used to build towers) over the day is definitely a success. The pacing is still not perfect, but it is far better than getting it as a lump sum. I found the time of day affecting towers to be unnecessarily dense before though and additional content has only made that worse. Goals ([described here](/blog/city/personInfo)) - success. Having the towers generate goals does a lot for the storytelling and for the gameplay. Having performing an action spark other actions translates well from real life to a game mechanic and the game needs to guide you to your next action. Towers Generating Events ([described here](/blog/city/towerLife)) - success. Pretty much everything said about the previous feature holds here. Tower Output ([described here](/blog/city/towerLife)) - success - This does two major things. The first is that it helps the player structure the city that they're developing. You build towers to deal with existing issues and then build more towers to deal with the issues your new towers create. This causes building to happen radially outwards very naturally. The other thing this does is help differentiate between pieces. When getting angry at the designers in your team produces anger from the design source, it makes the game clearer than if all emotions came from a centralized source. Tower Controls ([described here](/blog/city/towerLife)) - untested - I haven't really been able to test this feature as it requires a reason to control which towers are active and better UI for these controls. Right now, there is little reason to turn towers on and off and doing so is a pain, so I just ignore the feature. ## What's Going Well This game remains remarkably easy to write for. When I started this project, I thought that the hardest thing to get working would be to be able to get my mind around writing systems instead of text and that has proven surprisingly easy. The systems are very communicative, which makes this much easier. The systems do a lot of what they are supposed to, just not quite to the degree that I require. Additionally, the game remains very easy to program. I'll write about this in greater detail later, but it boils down to a few points: - Good tools help a lot in keeping your code clean. Being able to keep most of the parameters in their own format instead of having to hard-code saves a lot of time and makes the code much more readable. - Using standard patterns. I have standard patterns that I use for common game issues like structuring flow between game states. This makes coding and debugging faster as the coding style is very consistent. - I'm using a weak ECS, a number of components have code attached to them, but the core of entities, components and systems remains. I personally feel that this is better than a pure ECS in terms of code clarity and power as it allows polymorphism in your components. I am not concerned about performance at this stage. ## What's Going Poorly The first category of problems is the gameplay. My points for this are: - The game is not fun. - There's no real challenge. - You just build the towers the game tells you to build. - Decisions do not have trade-offs. For a game like this, interesting decisions can make the game substantially more engaging. Many simulation games do not rely on game difficulty and systems for this, but instead give the player a lot of things that are intrinsically cool to make and let them choose which they want to make right now. This is also a point that deserves a longer article to really explain. The second issue is that the model lacks depth and so the game feels flat and the storytelling feels very controlled. The systems that are in place do a fair bit already to help with this, but they do not do enough just yet. There are a number of additional systems that I want to add right now, there are aspects of the game that are hand-designed, but would be better coming out of systems and there are things that I want to represent but do not have the tools to do so just yet. The third set of issues just revolve around the fact that the game is still in development. - Information is not communicated well. - The game needs more toys. - The game lacks challenge/reward mechanisms.