The test for "one step in each cardinal direction is always visible" was
giving a false-negative for an entity at the same position as a wall -
not only is this something that would ostensibly never happen, it's also
completely reasonable to assume that someone stuck in a wall (due to a
bad teleport perhaps?) wouldn't be able to see anything, on account of
their head being INSIDE A WALL.
Rather than leaning on rasterific to generate filled circles for us,
instead start with an open circle, then fill it by scanning line-by-line
and filling in points that are "inside" of the circle, based on keeping
track with a boolean. Also adds a couple of helper functions for
displaying these kinda "boolean graphics" things we're passing around,
as sets of points.
Rasterific appears to generate some pretty surprising, if not
completely wrong, circles at especially low sizes - this was resulting
in unexpected behavior with vision calculation, including the character
never being able to see directly to the left of them, among other
things. This moves back to the old midpoint circle algorithm I pulled
off of rosetta code, but only for the non-filled circle. The filled
circle is still using the wonky algorithm for now, but at some point I'd
love to refactor it such that empty circles are eg always a subset of
non-filled circles.
Factor out a new EntityAttributes type from some of the methods of the
Entity class, to avoid the proliferation of 1-argument boolean methods
on the entity class that always have to be forwarded through the Entity
instance for SomeEntity if they have defaults (forgetting to do which
has wasted tons of my time up to this point). Currently blocksVision,
blocksObject, and collision are all in there.
New levels need to go at the *end* of the list of levels, not the
beginning - otherwise we jump to the proper position on the new level
but the current level stays the same (oops).
Generate doors at more reasonable positions, by:
- Only generating doors at the *ends* of hallways, where there's a
tee-shaped opening
- Never generating two doors adjacent to each other
Currently we just pick randomly between the cave and dungeon level
generators. There's a lot of bugs here, but it's *sorta* working, so I'm
leaving it as is.
Add a data structure, based on the zipper comonad, which provides
support for multiple levels, each of which is its own entity map. The
current level is provided by coreturn, which the `entities` lens has
been updated to use. Nothing currently supports going up or down levels
yet - that's coming next.
Add a dungeon level generator, which:
1. generates an infinite sequence of rectangular rooms within the
dimensions of the level
2. removes any duplicates from that sequence
3. Generates a graph from the delaunay triangulation of the centerpoints
of those rooms
4. Generates the minimum-spanning-tree of that delaunay triangulation,
with weights given by line length in points
5. Adds back a subset (default 10-15%) of edges from the delaunay
triangulation to the graph
6. Uses the resulting graph to draw corridors between the rooms, using a
random point on the near edge of each room to pick the points of the
corridors
Make raster circle rendering use the Rasterific package instead of
attempting desperately to hand-roll it, and add a method for generating
filled circles.
Recalculate the character's lines of sight every time we step the game,
rather than just every time the character *moves*. I had originally
thought this was a non-contiguous lines-of-sight bug - which there's a
test disproving - but it actually turned out to be that actions like
eating or attacking would step the game forward (thus moving gormlaks)
without re-calculating the positions visible to the character.
Make the setter for the atPosition lens preserve entityIDs for
already-existing entities at the position, so that when we plop
something in the same tile as the character the character's entity ID
doesn't disappear.
Add a drop command, bound to 'd', which prompts the character for an
item in their inventory, removes it from the inventory, and places it on
the ground. Along the way I had to fix a bug in the
`EntityMap.atPosition` lens, which was always appending to the existing
entities at the position on set, without removing the entities that were
already there - the rabbit hole of quickchecking the lens laws here also
lead to replacing the target of this lens with a newtype called
`VectorBag`, which ignores order (since the entitymap makes no
guarantees about order of entities at a given position).
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.
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.
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.
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.
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
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.
Add a "previous message" command, triggered via ctrl+p.
I attempted here to get the message area to still take up a row of space
post-hiding the message, but failed - should revisit that at some point
Implement messages almost the same as in the Rust version, only with
YAML instead of TOML this time, and a regular old mustache template
instead of something handrolled. Besides that, pretty much everything
here is the same.
