Refactoring the entire game and trying to create a solid framework has involved lots of steps, and I realized a roadmap would be a great way to manage those many elements. It was actually the naming conventions of revisions that first inspired me to make the roadmap. After I started having folders of REV11, REV11A, REV11B... Now it neatly follows numbering conventions, and I'm a fan of organized conventions. It starts at 0.1.0 with my original command prompt and ends with 1.0.0, the finished game, at least as I intend it right now.
Here is my current roadmap, complete with progress and my current state at 0.5.0, which I just got to.
CC:D Roadmap
• 0.1.0 CC:D Alpha ✅
• 0.2.0 Pygame Experimental ✅
• 0.3.0 Foundational Systems: ✅
- Graphics ✅
- Managers ✅
- Grid ✅
- Chunk Mapping ✅
• 0.4.0 Simulation Framework ✅
- Structures ✅
- Heatmaps (Canceled)
- Chunk Based Density Scores ✅
- Weighted Movement System ✅
- Support Entities ✅
• 0.5.0 Dynamics and Effects (In Progress 📝)
- Background Effects
- Structure Heart Behavior
- Mortar Cannons
- Explosions
- Fire
- Visual Effects
• 0.6.0 Advanced Gameplay Mechanics
- Advanced Entities
- Party Cohesion, Objectives, and Leadership
- Endgame mechanics
• 0.7.0 User UI
- Win Condition and game end
- Title Screen and Developer intro
- Game menu and settings
• 0.9.0 Beta Testing
- Bug testing
- Game balancing
• 1.0.0 Release
Since my first post I have added a lot of core gameplay elements and ended up scrapping a feature from CC:D Alpha.
Heatmaps were originally a part of CC:D Alpha. In addition to the display grid, I had a couple heatmap grids that only stored numbers based on tracked factors. The main use was the Structure Heatmap. Wherever a wall structure appeared it would create a high value on the map that would then step down in value based on distance. These maps were used to inform entities what direction to move in. Humans that were not actively fleeing from zombies would move toward the highest point on the heatmaps, naturally making them move inside buildings, where the effect of the walls overlapped and was strongest. This was a key element that allowed for some of the emergent gameplay of CC:D.
But while at first I thought I could implement this into my refactored version, I quickly found that the larger maps and entities was an overwhelming load on the game's processing power. I had plans to use heatmaps not just to guide humans to structures, but also zombies to humans, and for humans to evade zombies. I did not want to fully scrap density measurements but it became clear the old method was not the answer going forward.
The answer I came up with was obvious in retrospect, the chunk system I had already built to prevent excessive processing drain. Now the game only creates a local density score of cells being inspected by entities. It quickly tallies up all entities within their chunk, within range, that are the specified type, and uses their value score, divides it by their distance, and adds it to a total sum of density for that type. This creates much less processing drag and also allows me to make whatever density scores I feel like I need at the time.
The purpose of the heatmaps and local density scores is to inform my Weighted Movement System, which is a new feature of the refactor. When entities move now, they have no particular command or direction to follow, instead they tally up the impact of the various items around them and choose the direction that is the most beneficial. The weights of movements change from each entity. For humans, structure density has a positive weight, zombie density has negative weight, and immediately nearby zombies have a highly negative weight. What is interesting is that since these all just end up being one number for each direction it can move, it creates very natural and emergent behaviors. A human that is fleeing from a zombie will now curve their path towards structures to hide inside and can weave in between crowds of zombies. Soldiers position themselves in crowds of humans to be ready to protect them, but when humans spot zombies they become alarmed and become (!) symbols and the soldiers will prioritize moving towards them to better identify threats. There are many other applications of the Weighted Movement System, but it is a core part of the game.
Speaking of soldiers, the final part of version 0.4.0 was "Support Entities". These already existed in CC:D Alpha, but its exciting to see them in this new and more powerful platform. This specifically refers to Soldiers and Greater Zombies. Soldiers are armed human protectors represented by at signs (@). They deal a random range of damage to enemies. They rush towards zombies to attack them, but flee if a zombie gets too close. As I mentioned earlier, they try to move towards higher human densities to be ready in case of a seige and do not care much about structures. Speaking of seiges, the Greater Zombie (X), represented by a capital X, is a slower moving zombie with high HP that does extra damage to structures. It has not been fully added yet, but unlike regular zombies which just roam around, Greater Zombies will move towards structures captured by humans. They also have a trait that makes regular zombies follow them. As they slowly lumber across the screen the begin to pick up any stray groups of zombies along the way, creating unexpected seiges on human structures.
This is a relatively fun place to be in for the project, though I've been enjoying the whole process, as now I am moving past infrastructure and into gameplay details. 0.5.0 will focus on visual effects, which will be interesting to see. I am very proud of the math I made to create the gunsmoke line for when soldiers fire using the Alphagrid, but I'll maybe get into that in my next blog.
[BLOG]
[G4M3]
