timjen3 / ttrpg-engine Goto Github PK

There should be a way to do checks on one line. "Is the Player dead?" or "Does the Player have any Potions left?"

In preparation for implementing "roles" we need to rename the existing Role class to Entity.

A sequence has some implicit conditions. For instance, if you want to quaff a potion you have to HAVE a potion. Sequences should have a list of conditions that determine if the sequence can be ran at all.

Add a CanProcess() method to sequences that have the same inputs as Process() but returns a bool whether process can be called with the given inputs.

This can't be done until after #103 is complete ✅

Some details about Roles:

• Roles will serve as templates for building entities.
• Contain a list of attributes with metadata related to each one. Such as valid ranges of values
• Would be cool to be able to "sub-class" Roles. Subclass would get all attributes from parent with the ability to override some. Would be useful for relationships like Lifeform => Human => Fighter.
• A factory can build an entity from a role definitions.
• Add a parser to build an entity according to a command.

Entities should be supplemented with data from roles like:

• derived attributes; these don't contain values but formulas for calculating values. the derived attributes live on the role but are available to the entity
• categories should live on the role, not on the entity.

Cases where it would be useful to resolve 1 sequence item:

• getting text for an entity's health. ex: "almost dead" or "fine"
• getting text for entity's exact hp. ex: "15 / 20"
• getting text for how many potions entity has. ex: "5".

Currently all sequences are built from scratch every time they are invoked inside of the EquationResolver class.

This is very inefficient according to the mxParser documentation:
https://mathparser.org/mxparser-tutorial/expression-pre-compilation/

Since the equations don't change after the application starts, they should be built once. Only the arguments should change each time they are invoked.

Move the command parsers from the demo into the Engine.

Currently InventoryCommandParser returns messages from GetExampleCommands that are specific to the demo:

return new string[]
{
	"Equip [miner] {itemName:stone pickaxe,equipAs:pick}",
	"Unequip [miner] {itemName:pick}",
	"Drop [miner] {itemName:stone pickaxe}",
	"Pickup [miner] {itemName:pebble}"
};

The default should be more generic.

Additionally you should be able to pass settings to override the defaults with settings.

{
	EquipExampleCommand = "",
	UnequipExampleCommand = "",
	DropExampleCommand = "",
	PickupExampleCommand = ""
}

Scenario:

• Player tries to harvest some crops.
• A global condition on the sequence prevents harvesting because the crop is not yet mature.
• Since the sequence has the "Temporal" sequence category time progresses.

It would be great if there was a way to optionally suppress triggered sequences from occurring. It should be optional, because in some cases you might want to go ahead and pass time with a message like "You tried but it was too hard!". But in other cases you might not want to pass the time like "[Before trying to harvest] You looked at the crops but they just aren't ready yet.

mxParser is great, but just to keep licensing simple I need to switch to something with an MIT license.

Probably going with this: https://github.com/pieterderycke/Jace

A common use case that is currently cumbersome is writing out a message when the user can't do something.

For example:
You are too tired to do <action>!

To accomplish this you need to carefully configure the conditions on several sets of sequence items:

1. Add sequence item for the "you can't do this" message and add a condition associated with that condition.
2. Repeat for any other conditions you want to give a message about...
3. Add another condition with the inverse requirement, and add it to the first sequence item in the actual sequence.

Tags can be a simple way to drive actions from sequence items. A sequence item can have multiple user defined tags.

An example tag is "UpdateAttributes". The consuming application can listen for sequence items with an "UpdateAttributes" tag and knows what to do with it.

Examples:

• After any sequence with the 'Player Action' category, run the "Advance Turn" sequence with the Global role automatically

Here is another example. This one is trickier, because it relies on having some kind of life cycle. How is a turn composed? What triggers the start/end of a turn?

• Run sequence with any roles matching the following criteria (entity, enraged, not player controlled)

Currently if you observe the demo you will see many usages of the CloneAs Role method. This is done in code to map roles into sequences.

In order to move beyond the need for this manual in-code mapping, roles need to have categories, and possibly sub-categories.

For instance:
Player[Category = Entity]
Bandit[Category = Entity]
Sword[Category = Equipment]

After a short reflection, we actually need an array of categories.
Player[Categories = (Entity, Hero)]
Bandit[Categories = (Entity)]
Sword[Categories = (Equipment, Weapon, OneHander, Sharp)]

Management of these categories will likely need to be done outside of the library layer, but categories will allow for it.

1. Move logic out of classes and into a service layer.

2. Refactor methods for Sequence Items, Mappings, and Conditions to be on multiple items instead of 1 at a time.

For example: When taking damage check if HP < 1/2 HP. If so, check if critical wound is received.

When the sequence has a role category filter assigned to it, the sequence will be resolved for all roles passed that have that category.

There are various result items:

• ResultItem: configures a result SequenceResultItem
• SequenceResultItem: jankily pieced together logic around producing more useful results
• SequenceItemResult: Complete information for understanding the sequence that was processed

These are all half baked because they were added before the TTRPGEngine itself. Now that there is the beginning of a framework for doing something with sequence results it's time to rethink these various "results".

Q: How are results currently used?
A: Updating attributes. Publishing a formatted message.

Q: Any other uses not currently implemented?
A: See #106.

It makes sense for the engine to update attributes. That needs to be done in a cleaner way. It makes sense to publish events for both of these cases. Then apps using this library can tie into those events however they need.

The engine needs a new layer to perform higher level functions:

• Implement a command parser inside the engine layer so it can take in a text command and parse it into what should occur. A similar feature was implemented in the demo.
• Register Roles, Sequences, and Sequence Items. These can be referenced in commands and the engine will look them up.
• Implement functionality for updating attributes as a result of a sequence being processed. The demo currently has a mechanism for this but it's clunky.

Later:

• Register sequences to run automatically. for instance: "After any sequence with the 'Player Action' category, run the "Advance Turn" sequence with the Global role. Run sequence with any roles matching the following criteria (entity, enraged, not player controlled)

Inventory is represented by Roles just like entities. Inventory would be given different categories than entities to help the developer differentiate them.

Entities have inventory.

Knight (Entity Name)
    => List of Inventory ("Inventory" is the Role Category)
        1. Steel Sword (Entity Name)
        2. Steel Shield (Entity Name)

Inventory items affect sequences.

• A role can be required to have certain item(s) to execute a sequence. For instance, bows to shoot arrows. Reagents to cast spells.
• Inventory sub-types may have different attributes. For instance, a MeleeWeapon could have damage calculations.

Current Demo

Changes:

• Initiative queue with random order
• 2 allied players
• instead of specific enemy details just show general health

Currently there are a fixed number of animals in the area and once they are hunted they disappear.

Enhancement:

• There should be a list of animals to hunt, with each one being a repeatable process. Ie: instead of Deer1 and Deer2 there is just "Deer" and you can hunt it as many times as you want.
• It should be random whether the player was actually able to catch anything
• Some animals, like the bear, should do some damage to the player (based on randomness)

Currently it is complex to parse through sequence results. It should be simple.