Sprint 13 - Adam-Poppenheimer/Civ-Clone GitHub Wiki
Goals
- Rivers that run along the edges of cells.
- The ability to fortify.
- The ability to pillage.
- Unit maintenance.
- Better terrain textures.
- Better trees with more sensible distribution.
- The ability to raze cities when capturing them.
- The ability to spend culture on social policies.
- All social policies up to the Medieval era.
Risks and Mitigations
- Rivers have already taken up a considerable amount of time, and it's possible they could take a lot more. I could end up sinking dozens of hours into this issue and let other important tasks fall by the wayside.
- I don't have a clear idea what would make trees "better" or more "sensibly distributed." That could make any improvements elusive and any time spent resolving that issue a waste.
- The fact that I can't come up with more risks for this sprint make me think that I'm underestimating the difficulty of the tasks I've set before me. This implies that I'll be ambushed by a bunch of unforeseen problems.
Review
I established the infrastructure for social policies, though social policies aren't a substantial part of the game as it stands. I also built a reasonable first approximation to edge-based rivers. Most of the simulation-side of rivers remains unimplemented, and rivers can still flow in absurd directions that don't make any sense. But I at least have first-order solutions for all of the major cases.
Retrospective
What went well?
- I managed to get a reasonable first-pass for edge-aligned rivers, accounting for nearly all possible cases. It doesn't look amazing, but it is a start.
- I managed to work my way through a bunch of graphics and geometry problems and got some valuable experience reasoning about geometry and performing it through code.
- I've got a solid base for social policies.
- I now have a very thorough understanding of how the map's meshes are generated, which should make it easier to refactor and expand what I've already got.
- Despite the considerable difficulty of edge-based rivers, I did not set that issue aside and focus on lower-priority tasks. I managed to hold myself to my prioritization schema despite the pressures to ignore it.
What could be improved?
- Apparently I completely forgot to perform risk mitigation. I don't know how that slipped through the cracks. I guess I was under the impression that the sprint didn't have very many risks? Which is absurd, given how much I struggled during this stint of work. I need to develop a better understanding of what risks are and what risks I'm likely to face so I can make this analysis more useful.
- I really felt the lack of comments in HexGridChunk. The fact that it's so complex and such a large chunk of code makes it hard to figure out what's going on. I should spend some time going back through my codebase and reviewing it, figuring out what pieces of code are easy to understand and what pieces need extra explanation. I can establish issues for adding comments to specific classes for specific reasons. Probably the first item on that list will be HexGridChunk itself.
- Rivers running along edges was not a single task. As soon as I started getting a feel for how complex it was, I should've stopped what I was doing, divided it into a bunch of subtasks, and then attended to those tasks in isolation. The enormity of the task made it overwhelming at times, and certainly made it harder to reason productively about what I needed to do.
- The method by which I developed edge-based rivers was very ad-hoc, and thus very inefficient. I was constantly running into new cases I'd not anticipated, or realizing that the cases I was building out were unnecessary, or that a particular case was actually two separate cases. I didn't have a clear plan for developing my triangulation code at first, which made it difficult to reason about. For complex tasks like these, I should spend more time analyzing the problem, trying to imagine where the complexity is and how much time things will take before I start writing any code. I could've saved a lot of time if I had reasoned about the problem ahead of time.
- My mesh triangulation code's poor organization hurt me a lot this sprint. I need to figure out a sensible division for that code to make it easier to reason about.
- The lack of regression testing in HexGridChunk and related classes is starting to hurt me. There were several times when I ran over existing solutions without realizing it and had to remake the solution. I don't know if full test coverage of every vertex placement would be useful here, but I can surely add some tests. At the very least case-selection tests would be useful, so I can know if I'm even in the right block of code. There's a bunch of things I can do to provide test coverage for HexGridChunk, RiverTriangulator, and related classes. I should do these things, since I'm sure this won't be the last time I modify the appearance of the map.
- The collection of tasks I chose for this sprint was a somewhat absurd hodgepodge of unrelated things. It was also far, far too ambitious. I should make sure Sprint 14 is more focused, probably on reorganizing, clarifying, commenting, unit testing, and improving the HexMap namespace.