Written: 2016-01-19 The previous sprint added content to the game (and is detailed [here](/blog/city/content)). Doing so showed me a number of ways in which the game felt incomplete. This sprint was about addressing those gaps. ## Creep Generation This feature has the core emotions be completely represented by creeps instead of just being stored as a number. These creeps now bounce back and forth along the path that they are on instead of coming to a stop at the end of that path. This: - Helps build out the city - This causes creeps to be generated from multiple points and so gets the player to build out the city naturally to keep these creeps under control. This captures the idea of aspects of your personality resulting in other aspects that I'm trying to communicate. - Helps the tower defense - This is really the key piece that makes the tower defense part of the game work. Before this, I had considered just ripping that out of the game multiple times. This creates a lot of creeps for the player to build towers to deal with and gives them semantic and mechanical value. I'm also really excited about having the creeps bounce back and forth. Instead of the traditional tower defense goal of killing all the creep before they reach the end, the game now becomes about managing how long they live. - Makes emotions feel more ephemeral - This is the major problem with the feature currently. Before I added this feature, the game did a really good job of communicating the idea of letting an emotion build up and a lot of that is lost with the current iteration of this feature. There was a lot of tension generated by having the emotions rapidly tick upwards and that feels lost right now. I think that I can recapture that with slight implementation changes by having the number of creeps grow and I believe that will be a better mechanical representation with more scope for player interaction as players have more tools to deal with creeps than with an abstract number. So, this feature has one minor benefit, one major benefit and one major issue. This issue seems resolvable though and when I resolve it, I think that this will be a better game than it was before. On balance, I think that I'm happy enough with this feature to keep it for now. ## Inventory Actions I've created an inventory that contains things that can be slotted into towers. This worked out to just be a more mechanical goal system. Now, instead of just having work as a goal, you can slot in different pieces of work to represent doing different things. This allows for a greater degree of expressiveness, but ended up being a much more minor change than I expected. The ECS system of this game made it very easy to pull parts of the goal system into this item system. When I wrote out the item system, I found myself wanting things from the goal system and the ease of pulling that in led me further down that path than if I had to rewrite blocks of functionality. Your tools do a lot to define the design of your game and ECS leads you to try to solve new problems with old pieces. This is definitely a good thing from a programming perspective as it leads to a smaller code base. I think that it is good from a design standpoint as well as the final system is then less complex and more consistent. This new system lets me represent multi-step actions very well. The action of adding a feature to the game that the player character is working on starts as a design problem inventory item, which gets transformed into a design solution item through design work which becomes a feature item through dev work and finally is added to the game through the towers that represent discussion. ## Non-Tower Sources I've added entities to represent sources of emotions that are not activities. This is to represent things like projects and people. These are things that have a tremendous effect on people's lives and are the sources of a lot of the emotions that people feel, but are not in themselves activities. These are merely stubs right now, but I can see using them to unlock towers and actions and also to represent interactions like feeling frustrated at a lack of progress in a game. This is good for representing desires and so things that are caused by a lack of action. ## Next Steps Like the content generation sprint, this work sparked a number of additional features that I can attempt. There are a number of features that are immediately obvious to help streamline the simulation aspects of the game further. The creep generation feature made integrating the tower defense side of the game much clearer and some work there will really help make the game more fun to play. The systems of the game are designed to be interconnected, but the parameters are not, making the game less than fun. I also really want to address some of the technical and design debt that I've accrued thus far. I think that I'm going to spend the next week cleaning up my game instead of adding new features. This is because I feel that features beget more features indefinitely. While the new features excite me, I think that taking some time to look at the state of the game will allow me to make more informed decisions about what to add to it. From this, you can expect an article deconstructing the game from a design perspective and one on the goals of the game. I'm also going to take some time to address technical debt. This is very manageable as of now, but some pieces were built for systems very different than the ones that are in the game now and could do with some smoothing out. I also want to put my ECS compiler on GitHub so that other people can use it if it would help.