Many more combinations of floors and blocks are possible than are currently encoded, and there are many more permutations of directionality.

One solution is a "ChunkDescriptor" flags enum, where each Chunk has an open sized list of descriptors: "River" could be a complete set, but so could "North, River, Cavern".

Another solution is to simply have multiple enums for different Chunk properties.

See Isabelle's thoughts at #57 (comment)

Furnishings need to be Walkable/Non-Walkable.

Furnishings should be lockable.

Move the concept of locked doors from blocks to furnishings.

Bring it in line with MapRegion's and MapChunk's ToString methods.

Behavior, location, health(?), and individual identity need to be distinct from definition.

This may need some unraveling as there will certainly be multiple instances of the same critter but it's possible many NPCs may have a 1-to-1 relationship between status and definition. Also, critters likely reset on map load whereas characters may persist.

How do spawn points fit in?

This models items that exist within the player's inventory.

Subtypes of items might include:
• Tools
• Materials
• Key Items
• Equipable Gear
• Consumables

Note that this probably does not include the collectables:
• Health & Mana
• Money

Enhance CSV Import tool to handle Items.
See #17 .

An Inventory needs to:

• Track arbitrary stacks of arbitrary items.
  • (Including multiple stacks of identical items, i.e. "999 Brick" followed by "183 brick")
• Provide for organization
• Indicate different item types, perhaps by segregating them
• Allow for item disposal (trashing)
• Provide information about items (subtype, description, rarity, sources)
• Allow for item consumption

All mobs/characters should be identifiable game entities.

Current ToString methods are really wordy. It would be better to provide a simple summary of the object, sort of like:
{ Class : InstanceName (dimension x dimension) contains [int] parquets and [int] special points }

So for example~
”RegionMap: Mordor (12x12) contains 38 parquets and 3 special points”

The existing ToString methods are useful for diagnostic purposes, so they should be maintained with some other method name.

This should be done only after CSV serialization has been achieved, since this relies on AllParquets as a palette of parquet definitions.

All configurable game entities (parquets, items, etc.) need to have in-game descriptive text and talk text for the feature Caidence will be helping with.

Serialized form of string has changed, but we may as well wait to update them until after fixing:
#36

Statuses vary per-map location, not per-definition. Find a way to store this information such that e.g. one floor tile may be dug out while others are still filled in.

At a minimum, Biome Keys should be a kind of Item, not a hardcoded value.

Possibly it may also make sense to have Biomes be data-driven like Items and Parquets.

This should incapsulate:
• the item will be crafted
• all materials needed to craft it
• the layout of panels for the crafting minigame

Consider whether CratingRecipes should have fall-offs.
For example, imagine the following recipe;

In: Bucket of Water, Flour
Out: Dough

...but what happens to the bucket of water? Perhaps it comes back as an empty bucket.
If so, this should be modeled, perhaps by having recipes produce multiple outputs.

This will be a basic terminal view using System.Console.

They should reflect recent extensions.

For example, should we use "collectable" or "collectible".

Mostly member variable definitions.

This should include:

• ID
• Name
• Minimum Dimension x&y
• Floor Types Required (normally any)
• Wall Types Required (normally any)
• Furnishings Required (never empty)

The game detects what parquets are present within enclosed spaces and uses that information to assign a room type.

This implies that the game also needs to detect enclosed spaces.

Room detection should happen automatically and immediately on loading a map (for any reason; i.e., game load, map editor load, player movement between regions, etc.).

Ensure DLL is useable in Unity.
This should just be a few basic smoke tests.

CSVConverter fails with "The conversion cannot be performed" on biome text "Swamp".
line 46 of CsvReaderExtensions.cs

How are these different classes of item to be handled in code.

Tools and Key Items (including Biome Keys) may make sense to be hard-coded since that allows them to be easily specified in the definitions of Parquets and other game objects.

After a lot of thinking and tools exploration I feel that this will be the most scalable way to define game elements before we have a dedicated modding tool. (I don't want to get bogged down writing a modding tool until we've moved beyond the Class Library phase to work with a GUI stack.)

Consider this example:

• https://www.contributor-covenant.org/version/1/3/0/code-of-conduct.md

Adding such a document would offer many benefits if the project takes on a life beyond personal learning goals, but it may also bind the maintainers to onerous community management tasks.

In all cases, consider language that would permit honing the focus of the community.

Initially, these should just be "critter" type entities without much smarts or substance.

This must be the last thing done for Pre-Alpha.
Update the Library Version string to 0.2.0.0.

Ensure that this method is working as intended. There are notes in the code.

This needs to be generated form the ground up, but see https://github.com/mxashlynn/Parquet/issues for details and inspo.

Be sure to include Unit Tests (ideally writing them first.)

Collectables need to support multiple collection actions:

• Adding Items to the players inventory
• Awarding Health, Mana, or Money

A lot of recent additions don't have unit tests.

Given a MapRegion, produce a list of all Rooms found in that region.

This process will probably involve image segmentation and labelling:
See https://homepages.inf.ed.ac.uk/rbf/HIPR2/label.htm

One issue to bear in mind is that the list of rooms will need to be updated continually during play as room contents and borders shift.

• Liquids can only exist on the map in Trenches
• Liquids move/spread on their own
• Liquids that border absent floors will pout down to the floor below

• Liquids that pour down create falls on the lower floor
• Falls only spawn new liquid blocks if they exist above a trench

Panels are areas that the player strikes during the crafting minigame.
This should include:
• lower acceptable boundary
• upper acceptable boundary

This should be v simple, used only within the Recipe model.

Create a workflow for exporting the Class Library as a DLL to Unity.

https://docs.unity3d.com/Manual/UsingDLL.html
https://loekvandenouweland.com/content/create-a-class-library-with-unity3d-and-visual-studio.html

This is a simple terminal view using System.Console.
This should allow proof-of-concept testing of all major game features in Sandbox mode.

The game detects what parquets are present in a loaded map region and uses that information to assign a Biome type.

A Room contains:

• its location

Upon request, a Room is able to determine and output:

• its bounds
• its contents

Note that rooms must be reevaluated whenever ParquetStacks within their boundaries are updated.

This should be the "main" controller corresponding to normal play.

Flesh out the project introduction in the README.
For inspo, see:

• https://github.com/noopkat/avrgirl-arduino/blob/master/README.md

A quest needs to contain:
• requirements for its completion (item, maps state, room existence, task completion, more?)
• current status (unknown, unaccepted, accepted, nearly complete, complete)
• effects of its completion (reward item, ability, or plot progress?)

Quests are given by NPCs.

The documentation should describe the purpose of each project in the solution and the overall architecture of the programs. This information could also be included in the repo itself in a series of text documents.

Make changes and corrections according to Isabelle's notes!

Blocks need to support the following collection actions:

• Spawn a Collectable
• Spawn an Item in the player's Inventory

Gather actions should be associated with this.

Turn TODOs in code into Issues.
Turn IDEAs into design notes.

There should be one central place that handles write to disks. Individual objects should not have to worry about how to access the filesystem.

Probably this should be a static class.