Previously, we were using `smallestNotIn` for selecting new characters
for menu items with duplicate chatacters - this uses the 'Bounded'
instance for the type, which for Char meant the first character we would
always select was \NUL - making it look like the menu item had no
character, and making it impossible to actually select the menu item.
This introduces an AlphaChar newtype, which is a wrapper around Char
whose Bounded and Enum instances only use alphabetic characters (a-ZA-Z)
and uses that for menu characters instead.
Change-Id: If34ed9e9ce84f2bcb1cb87432cc6273f40b69f72
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3229
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
When describing items in the inventory, both in detail and when
producing menus from those items, describe not just the item itself but
also *where* in the inventory the item is (either in the backpack, or
wielded in either or both of the hands). This uses a new
InventoryPosition datatype, and a method to get a list of items in the
inventory associated with their inventory position. When *removing*
items from the inventory (to wield, drop, or eat them), we want to make
sure we remove from the right position, so this also introduces
a `removeItemAtPosition` method to make that happen correctly.
Finally, some of the tests for this stuff was getting really slow - I
narrowed this down to runaway arbitrary generation for message
Templates, so I've tweaked the Arbitrary instance for that type to
generate smaller values.
Change-Id: I24e9948adae24b0ca9bf13955602108ca9079dcc
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3228
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new DescribeInventory command, bound to I, to prompt for an item
in the inventory (anywhere in the inventory, including wielded) and
display a (new) panel describing it in detail. This description includes
the description, the long description, and the item's physical
properties (volume, density, and weight).
Change-Id: Idc1a05ab16b4514728d42aa6b520f93bea807c07
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3227
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Generate random volumes and densities for items based on the ranges for
those two quantities in the raw when building instances of items.
Since this is the first time creating an item is impure, this also lifts
entity generation into a (random) monadic context
Change-Id: I2de4880e8144f7ff9e1304eb32806ed1d7affa18
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3226
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Allow the itemType raw to have density and volume fields, both of which
represent *intervals* of both density and volume (because both can
hypothetically vary a bit). The idea here is that when we're making
an *instance* of one of these items, we pick a random value in the
range.
Lots of stuff in this commit is datatype and typeclass instances to
support things like intervals being fields on datatypes that get
serialized to saved games - including a manual definition of Ord for
Item since Ord isn't well-defined for intervals
Change-Id: Ia088f2f75cdce9d00560297e5c269e3310b85bc3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3225
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
2000 ticks after the character damages their fists by hitting something,
the character now develops calluses on their fists (scaled by *how*
damaged they've become) that reduce the chance of them receiving
additional damage from hitting things - up to a max of 5, which
prevents *all* damage from fistfighting.
This is all tracked in a new "Knuckles" struct in a new "Body" struct on
the character datatype, which manages stepping itself forward as part of
the Brain impl on the character.
Change-Id: Ica269f16fb340fb25900d2c77fbad32f10c00be2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3222
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a command that automatically rests (essentially just stepping the
game forwards) until the character's hitpoints are back to full.
Currently due to the time it takes for the character to heal this takes
a bit too long - my thought there is to make the per-step delay for
autocommands different depending on the specific autocommand.
Change-Id: I40378c29d3d9d19e9787af1f015bde65fd08868c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3221
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Allow configuring the natural attacks (eg, part of their body rather
than an item) of a creature. Each attack has a description and a damage
associated with it.
Change-Id: I69698a8ac4ee2da91e4c88e419593627519522a5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3220
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This required making sayVerb optional, as oozes don't say anything
Change-Id: I2c7f425ca26d92beef1097eda49d84f00c84c482
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3218
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This gets us the zlib-flate command line utility, which is useful for
decompressing our zlib-compressed save files and poking around in the
JSON
Change-Id: Ia0d8259d261c4313322d68cc8409ba13f9fb570c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3217
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
If the game steps forward, entities could be moving around, so we need
to wipe the memoized character vision.
Change-Id: If6ea6a8c4bed7aefef90a0a2ab17eff0af9b9bbe
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3215
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "greetedCharacter" field to the creature hippocampus type,
which tracks whether or not that creature has greeted the character
yet. In the gormlak AI, when the gormlak sees the character and starts
running towards them, if that field is set to False send a message that
says that the gormlak yells a single randomly-generated gormlak word at
the character, then set the field to true
The gormlak yells "gukblom"!
Change-Id: I17a388393693a322c2e09390884ed718911b2fc4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3207
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I didn't end up using this directly for the thing I was doing, but it
still seems generally useful enough that I'm keeping it around for now
Change-Id: I05c8902d75845f2230ec2373a9677d61cfaafafd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3206
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "language" field to the CreatureType raw type, which
references the *name* of the language that creature speaks (this is so
that different creatures can speak the same language without having to
duplicate the language definition in the raws). At some point this
should change to not hardcode the sets of languages and instead define
them in data files like we do for creatures, but this is fine as a
start.
Change-Id: I6708570175e23472cb37e0061a329e54e8eac9c0
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3205
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
This is generally just good practice for foundational data-types like
these
Change-Id: I88c5b6b73dad6665cf25837b8d6a9e0ea66f2b0b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3204
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Wrap up the Phonotactics type into a Language type including both the
phonotactics and a distribution of the number of syllables per word, so
we can generate arbitrary words in addition to just arbitrary syllables
Change-Id: I8a37ce9c0eec019c9b84d21b0f2b3b9f5fd319eb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3203
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Add a new "speech" generator module, with the beginnings of the vague
definition of the phonotactics of the language (there's one in here for
English based on the wikipedia article for English phonology, but it's
less than ideal as it has generated words like "sprurlkt") and the
ability to generate random syllables of a language by picking an onset,
nucleus, and coda from the list for that language (within a range of the
number of allowed of each syllable part). This will be used down the
road to automatically generate utterances from various
non-english-speaking creatures (so the accuracy is less important, just
that it "feels real").
Change-Id: I7b81375ec595239c05c5c800cbde1a2a900e38ac
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3202
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
I'm going to start adding generators for things like text soon, so it
makes sense to specifically sequester level generators as their own
thing
Change-Id: I175025375204fab7d75eba67dd06dab9bd2939d3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3201
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Memoize the return value of characterVisiblePositions to a new,
semi-abstracted "memo" field on the GameState, recalcuclated if the
character position ever changes. I'm 90% sure that the perf issues we
were encountering were actually caused by characterVisiblePositions
getting called once for *every tile* on draw, but this slightly larger
change also makes the game perform relatively-usably again.
Since this is only recalculated if the character position changes, if we
ever get non-transparent entities moving around without the characters
influence (maybe something building or knocking down walls?) we'll have
an issue there where the vision won't be updated as a result of those
changes if they happen while the character is taking a non-moving action
- but we can cross that bridge when we come to it.
Change-Id: I3fc745ddf0014d6f164f735ad7e5080da779b92a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3185
Reviewed-by: grfn <grfn@gws.fyi>
Tested-by: BuildkiteCI
Since 473604f567 (CL/2910), depot hasn't
been directly exposing `pkgs` as an attribute, instead exposing it via
third_party.nixpkgs - the xanthous shell.nix isn't checked in CI, so it
was missed as part of that refactor - this updates it to be in line with
that
Change-Id: I12b081c16d53c6798f51ec6660ffa6d345870580
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3176
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Since we need to override random to 1.2.0 globally for xanthous
(otherwise propagation causes two versions of random to be propagated
for xanthous) evaluating haskell related stuff using import from
derivation can be very expensive since utilities like hpack and
cabal2nix need to be built for that. This means that for every channel
bump we potentially need to do a world rebuild of haskellPackages first.
To solve this we check in the cabal2nix-generated nix expressions for
owothia and xanthous.
Change-Id: I8fff70b4b6c303d1920f8bcac53520a09999b206
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2921
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Rename my //users directory and all places that refer to glittershark to
grfn, including nix references and documentation.
This may require some extra attention inside of gerrit's database after
it lands to allow me to actually push things.
Change-Id: I4728b7ec2c60024392c1c1fa6e0d4a59b3e266fa
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2933
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: glittershark <grfn@gws.fyi>
