Sprint 36 - Adam-Poppenheimer/Civ-Clone GitHub Wiki
Active Epics
Clean Playthrough
Saving and Loading Maps
In-Game Performance
Risks and Mitigation
While I think adding user stories and epics and whatnot is a useful organizational technique, it's not yet clear to me how I move from them into actual programming tasks. If I'm not careful I could fall back into the disorganized development paradigms that've dominated design for the past month or so.
Ostensibly I'll cycle between an exploratory phase where I look for problems and create issues, and an execution
phase where I attempt to resolve those problems. Whenever I'm out of meaningful problems in the epic's backlog I can
go back and check to see if its conditions have been satisfied. I should probably also spend some time elaborating on
these epics, possibly creating additional sub-epics for components of this task (unit management, city management,
the exchange of turns, etc). The point is to create a tree.
Part of achieving a clean playthrough will mean stamping out major bugs. But a single individual running through the game by themselves is not likely to reveal all the major problems with the game.
This is what the user stories are supposed to help me do, right? Especially some of the smaller ones. I can define
procedures for certain actions that players need to do and then use those to inform my testing. How I will create a
comprehensive list of those procedures isn't clear to me at the moment. I should probably spend a fair chunk of time
at the beginning of the sprint imagining what those might be (perhaps as user stories).
I now know that material switching is something fundamental to the Terrain system and cannot be avoided. That leaves me with a major performance bottleneck I can't get at directly, which could limit how far I can push the performance of the game.
While I can't prevent material updating or make it faster, I can decrease the number of times it's called. Culling
texture prototypes from chunks that don't need them will cut their total draw calls in half. Reducing the heightmap
resolution of chunks that don't require it will reduce polygon count, which should reduce draw calls considerably and
might reduce the burdens of material updating.
It's been a long time since I've touched map composition and decomposition. It's not at all clear to me that I can make that system tolerant of newer versions or how to prevent small changes to the simulation from wrecking old saves.
Version tolerance is a low priority right now. More intelligent, perhaps, would be to add a system that gracefully
handles incompatible map types. A Try/Catch block should suffice for now.