Split the character's inventory up into wielded items (in one or both
hands) and the backpack, and display wielded items when drawing the
inventory panel. Currently there's no way to actually *wield* items
though, so this is all unused/untested.
Also, add the ability for items to be "wieldable", which gives specific
descriptions for when attacking with them and also modified damage.
Make it so that opening the eat menu but not actually eating anything
(either because you cancel, or because there's nothing to eat) doesn't
step the game
Add support for a "GroundMessage" entity type, support for a Read
command to read them, and randomly place an initial, tone-setting
tutorial message on the ground near the character at the beginning of
the game.
Fix an injectivity issue with JSON-encoding the entity map that was
causing the game saving to not properly round-trip. As part of this,
there's a refactor to the internals of the entity map to use sets
instead of vectors, which should also get us a nice perf boost.
Refactor a bunch of stuff around to allow for polymorphically surfacing
an EntityChar for all entities, and use this to write a generic
`entityMenu` function, which generates a menu from the chars of a list
of entities - and use that to fully implement (removing `undefined`)
menus for both attacking and picking things up when there are multiple
entities on the relevant tile.
Add a newtype, GenericArbitrary, which can be used with -XDerivingVia to
derive Arbitrary instances for types with Generic, via patching
generic-arbitrary to expose the underlying typeclass it uses for
surfacing the type information.
Implement the PointOnMap prompt type, which allows the player to move
the cursor around and select a position on the map, and use this prompt
type to implement a "look" command, describing all entities at the
selected position.
Implement ToJSON and FromJSON for all of the various pieces of the game
state, and add a pair of functions saveGame/loadGame implementing a
prism to save the game as zlib-compressed JSON. To test this, there's
now Arbitrary, CoArbitrary, and Function instances for all the parts of
the game state - to get around circular imports with the concrete
entities this unfortunately is happening via orphan instances, plus an
hs-boot file to break a circular import that was just a little too hard
to remove by moving things around. Ugh.
Call hercules-ci's gitignoreSource on the src path before passing to
nix, which both prevents spurious rebuilds and also makes compilation
via `nix build` (which under the hood uses cabal v1-build) work while
also doing development using `cabal new-build`
Rather than blindly taking one entity from the list when we have
multiple entities on the same tile, add a `drawPriority` method to the
Draw typeclass which allows individual entities to request to be drawn
on top - this avoids the "noodles floating over your head" bug we saw
before.
Because of the way lines are drawn, a specific configuration of
positioning for gormlaks would have them decide they desperately wanted
to walk *inside* a wall, which they would then both fail to do but also
always collide with whenever they tried to go anywhere else.
Gormlaks now move 1/8th the speed of the character, which means we can
run away from them - yay!
Unfortunately this also introduces a bug where they'll eventually get
stuck and not do anything, so I'll be tackling that next.
Stepping the game after updating the vision could allow creatures like
gormlaks to move *out* of the character's pre-calculated lines of sight,
causing gormlaks right next to the character to be invisible.
Allow specifying the seed for the game's global RNG on startup, and
print the seed when the game exits. This'll allow us to more reliably
reproduce bugs - yay!
Previously the isUnit function was falsely returning `True` for
positions that were one tile off in *either* direction from the
character, when it should've been *both*. Oops.
Add menu support to the prompt system, and an "Eat" command that prompts
for an item to eat and eats the item the character specifies, restoring
an amount of hitpoints configurable via the item raw type.
When tracking message history, save messages associated with the turn
they were displayed on, which allows us to have the notion of the
"current turn's" messages (provided via a MonoComonad instance).
When gormlaks see the character, they step towards them and attack
dealing 1 damage when adjacent. Characters have hitpoints now, displayed
at the bottom of the game screen, and when the game is over they die.
- Don't let gormlaks run into things like walls or each other
- Add a small element of randomness to gormlaks' motion
- Increase gormlaks' vision by a large amount
Add a (debug) command to reveal all tiles on the game regardless of the
character's vision, which'll make it easier to debug creature's behavior
while they're not visible.
Add a Brain class, which determines for an entity the set of moves it
makes every step of the game, and begin to implement that for gormlaks.
The idea here is that every step of the game, a gormlak will move
towards the furthest-away wall it can see.
Add a Door entity and an Open command, which necessitated supporting the
direction prompt. Currently nothing actually puts doors on the map,
which puts a slight damper on actually testing this out.
Add the beginnings of a generic prompt system, with exclusive support
atm for string prompts, and test it out by asking the character for
their name at startup
Add a new "Item" entity, which pulls from the previously-existent
ItemType raw, and add a "PickUp" command which takes the (currently
*only*) item off the ground and puts it into the inventory.
As the character walks around the map, progressively reveal the entities
on the map to them, using an algorithm based on well known
circle-rasterizing and line-rasterizing algorithms to calculate lines of
sight that are potentially obscured by walls.
Add support for converting generated levels to walls, and merge one into
the entity map at the beginning of the game.
There's nothing here that guarantees the character ends up *inside* the
level though (they almost always don't) so that'll have to be slotted
into the level generation process.
