Add a parser, pretty-printer, and renderer for a new template system,
which should eventually be a drop-in replacement for the current
mustache-based template system, but also supports text filters (which
will be used for things like pluralization and noun casing). Nothing
currently uses it yet, though.
Add a very basic, naive auto-move command, which just steps the player
in a direction until they collide with something, regardless of any
surrounding beasties who might want to eat them.
There's a lot of other stuff going on here - in order to get this
working the way I wanted with a slight (I settled on 50ms) delay between
every step in these autocommands while still redrawing in between I had
to do all the extra machinery for custom Brick events with a channel,
and then at the same time adding the bits for actually executing
autocommands in a general fashion (because there will definitely be
more!) hit my threshold for size for App.hs which sent me on a big
journey to break it up into smaller files -- which seems actually like
it was quite successful. Hopefully this will help with compile times
too, though App.hs is still pretty slow (maybe more to do here).
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.
Rather than having a single sentWelcome boolean, avoid running the
initEvent entirely when loading an already-initialized game. Among other
things, this stops us from re-generating a level and then merging it
with the existing one when the game is loaded (oops).
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.
Prevent closing doors when there's a gormlak or other entity with the
blocksObject attribute set to true on the same tile. There's a message
sent here which is grammatically incorrect - it says "The a gormlak
blocks the door" - should fix that later.
This was a bit of an oversight initially - we should be storing the
positions that the character has seen *on the level*, rather than on the
entire game state, for obvious reasons. This introduces a GameLevel
record, which has this field, the entities, and also the up staircase
position, which we can *also* use to position the character after going
down to a level we've already visited.
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).
Per https://github.com/noinia/hgeometry/issues/28, occasionally
DelaunayTriangulation.DivideAndConquer loops infinitely - in this case,
I was able to consistently use the seed 127624940715530481, to generate
a dungeon which had the following room centroids:
[ Point2 [38.5,3.5] :+ 0
, Point2 [67.0,33.0] :+ 1
, Point2 [46.0,45.5] :+ 2
, Point2 [55.5,42.0] :+ 3
, Point2 [36.0,25.0] :+ 4
, Point2 [76.5,12.0] :+ 5
, Point2 [29.0,26.5] :+ 6
, Point2 [55.0,10.5] :+ 7
]
and cause delaunay triangulation to loop indefinitely (or at least
longer than I cared to wait for). Given the size of our graphs switching
to naive generation should be fine performance-wise, and avoids the
infinite loop.
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.
Rather than having a single function in the Game.Lenses module for
determining what collision type if any an entity has, track it in the
Entity typeclass itself. This is both more extensible and a better
separation of concerns and gets rid of one of the two needs for a
circular import. Yay!
As part of this, I realized nothing was being done to prevent doors from
being placed on tiles that already had walls (since now that was
properly causing a collision!) so I've fixed that as well.
Decouple the definition of the Gormlak AI from the creature type itself
using generic lenses and a "HasVisionRadius" typeclass, to begin to
untangle the hs-boot web of circular dependencies. This
actually *increases* the number of hs-boot files from 1 to 2, but both
of the source imports that use them are single-instance (unlike gormlak
AI which I would expect to grow linearly with the growth of the game),
plus at least one should be able to go away once we remove collision
from the game lenses module and move it into something defined in the
entity class itself.
When the character walks away from or around the corner from entities
that move such that they're no longer visible, stop rendering them.
Still render static entities like walls, doors, and items though. This
prevents entities walking into a "revealed position" after the
character's left being visible despite not being in a line of sight any
more.
When saving the game to a file that already exists, prompt for whether
or not to overwrite the file.
Since this was the first instance of a prompt triggered by another
prompt, this also had to do a minor fix to swap the order of completing
the prompt and clearing it, so that we don't submit the prompt and then
immediately clear it.
Pick a random subset of cells on the level that have a wall on two
opposite sides and are clear on the other two sides, and place closed,
unlocked doors on those cells.
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.
Don't re-send the welcome message when loading the game if it's already
been sent. This is done by just tracking whether or not we've sent it as
a boolean in the game state, which may be a bit of a hack but should be fine
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).
When attacking, use either:
- the message defined on the entity raw of the wielded item, if any
- the generic attack message, if an item without an attack message is wielded
- the fists attack message, if no item is wielded
Use whatever items the character has wielded, if any, to calculate the
damage they deal when attacking. Currently this shortcuts handedness to
just use the *first* item they have equipped, which is fine since it's
currently only possible to equip something in the right hand.
Add a Wield command, which prompts for a wieldable item, if any, to take
out of the character's inventory and put in their right hand.
Eventually we should support other hands, but for now hardcoding the
right hand should be fine.
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
