Story

I really like the A* pathfinding demo here, so it'd be cool to replicate it as a demo within Downdelving.

Acceptance Criteria

• [x] An A* pathfinding demo has been created and is accessible from the Demo menu (see #22 ).

Implementation Notes

Story

City should have a different name. Like, say, "Downdelving."

Acceptance Criteria

• [x] Bracketon is no longer Bracketon. It is Downdelving.

Implementation Notes

Story

It's tedious to test when you're starving to death.

Acceptance Criteria

• [x] A cheat option exists that allows the character to eat.

Implementation Notes

Should be straightforward.

Story

• As a player, I want my PC's experience to be based on more than just killing monsters, so that I am encouraged to explore more aspects of the game.
• As a developer, I want to be able to trigger experience gain easily so I can test the leveling system.

Acceptance Criteria

• [x] The process of gaining experience levels is factored out of the death effect.
• [x] A cheat action has been added to allow adding experience.

Implementation Notes

I think this can just be done as another effect.

Story

Bracket's RGB/RGBA and BearLibTerminal's Color aren't cleanly compatible and that's screwing up my lighting.

I think it'd be better just to write my own color system and then implement everything in terms of that.

Acceptance Criteria

• [ ] Color system has been written.
• [ ] All code currently using RLTK's color system has been rewritten to use my own.

Implementation Notes

Story

The RLTK FOV system seems to be a bit quirky, as noticed in #54 . The current state of the art appears to be symmetric shadowcasting. I should use that instead.

Acceptance Criteria

• [x] The visibility system uses a symmetric shadowcasting algorithm instead of the RLTK algorithm.
• [x] A demo has been created that allows a direct comparison between the two algorithms.
• [x] [Optional] The visibility code has been refactored to allow easier use in other sections of the code.

Implementation Notes

Story

I should add a demo for just walking around. This would then be modified to serve as a test bed for lighting effects, etc.

Acceptance Criteria

• [x] I have a demo for just walking around.

Implementation Notes

Story

There's Vendor-related code in the GUI, in the runstate, as a mode of a specific runstate value, etc. It's not a terribly large or complicated system, but it's pretty spaghetti.

Ideally, it would all exist in a single module. I don't really know how to break it out cleanly, but maybe I'll figure it out.

I'll timebox this at two hours. Hopefully it'll take a lot less time than that.

Acceptance Criteria

• [x] Vendor code exists in a vendor module.

Implementation Notes

Story

The control text is not aligned with the bottom edge of the menu box.

Acceptance Criteria

• [x] Control legend is aligned with the bottom edge of menu box.

Implementation Notes

Story

When a game is in progress, the main menu should have an option entitled "Resume Game" that resumes the current game.

Acceptance Criteria

• [x] The main menu has a "Resume Game" option when a game is in progress.
• [x] The main menu does not have a "Resume Game" option when a game is not in progress.

Implementation Notes

Story

There should be a menu, accessible from the main menu, that gates off demonstration technology, etc.

For instance, it'd be useful to show map generation, pathfinding, combat, etc demos.

Acceptance Criteria

• [x] A demo menu item has been created that permits access to demos.
• [x] The demo menu can be exited, whereupon the player should be presented with the main menu.

Implementation Notes

Story

There was a massive performance issue when I attempted to debug the lighting system. It appears that the lighting is recalculated each tick or frame. It would be preferable if this is only recalculated when necessary, i.e. "dirty" state.

Acceptance Criteria

• [ ] Lighting is only recalculated when the viewshed (or map?) has been marked dirty.
• [ ] Existing effects and other code has been audited to ensure that this does not cause issues with lighting effects.

Implementation Notes

Story

This should be fun.

Basically, just draw a map with a lot of color to ensure that colors are being processed correctly.

Acceptance Criteria

• [ ] A demo has been created that allows me to evaluate the creation of the Color system and refactoring the existing codebase to use that system.

Implementation Notes

Story

I don't like the linear level system. It's straightforward and easy to deal with, but the linearly increasing difficulty does not really match my intended direction.

Instead, I'd like to devise some notion of biomes. These biomes would ideally be parametric to some degree, so that I could create or derive variants of them, store them as raw data to be interpreted at runtime, etc.

I like a lot of the current system, so some of the pondering will be focused on how to keep and reinterpret that code.

Acceptance Criteria

• [ ] I've pondered this idea at length and have devised some plan of attack.

Implementation Notes

Story

Now that I can demo FoV, I wanna demo lighting systems.

Acceptance Criteria

• [ ] A demo is constructed that permits easy switching between different lighting models for evaluation.

Implementation Notes

Story

It'd be cool to enable a sort of pack or herd behavior model. Flocking! That kind of thing. Or hunting behaviors like a wolf pack might show.

I should see how feasible it might be to implement this and come up with a cool demo or two.

Acceptance Criteria

• [ ] I have pondered this at length and created at least one followup issue with details to pursue.

Implementation Notes

I might use the Actix library.

Story

See #47 . Vendors should adjust the price for which they are willing to purchase items based on the seller's charisma.

Acceptance Criteria

• [ ] Vendor purchase price is modified per charisma.

Implementation Notes