trisfald / weasel Goto Github PK

The objective it to provide a way to modify the rules (in Battle) from outside the crate, for instance when a user of the crate implements a custom event.

We want to support the following use cases:

• Assign, update and remove statistics to a team.
• Activation of special abilities initiated by a team, not an actor.

However there are some constraints we should keep in mind:

• It would be better to conceptually separate existing Statistic and Ability from the ones of a team.
• Keep it as simple as possible. The fewer new associated types and functions in TeamRules, the better.

An initial idea is to merge both statistic and abilities of teams into a single object (team's Power?).

The goal of this task is to propose a design for this feature.

Events posted on an EventQueue through the Originated decorator should not have their event_id overridden with the id of the event that spawned them.

This happens because when we apply events from an EventQueue their origin is changed without checking if it was already set before.

Hello @Trisfald .
I'm renan and I'm learning Rust, I saw your project and would like to contribute for him. But i never contributed for opensource project and i don't know how to begin. Your https://github.com/Trisfald/weasel/blob/master/CONTRIBUTING.md is more generic and I don't find this project board with tasks.
How to would start help you?

Evaluate if having a graveyard to store dead but not removed entities would be an useful addition to weasel.

Provide sound reasons to justify the choice.

If the outcome is positive, an high level design should be provided to prove the feasibility of the feature.

Create a new type of event, 'Span'. Its purpose is to simply contain one or more events so that all of them can be processed atomically.

Small example to show how to implement reactive actions.
For instance, the example could be a small program (not interactive is fine) with:

• Two teams
• One creature per team
• Creature 1 starts a round.
• Creature 1 performs an ability (attack) on Creature 2.
• Creature 2 does a counter attack.
• Creature 1 ends its round.

In some games you can start a round for an entire team or, more generically, for a set of actors. This is currently not supported in weasel, as the only workflow is:

StartRound (actor A) -> ActivateAbility (actor A) or similar events -> EndRound

Instead we want to support also:

StartRound (actor A, actor B) -> ActivateAbility (actor A) -> ActivateAbility (actor B) -> EndRound

The objective of this task is to come up with a solution to support this new feature while having the minimal impact on the current API.

Add a way to remove an entity starting from an entity id. Currently, in order to achieve this the user must do a match and use RemoveCreature or RemoveObject.

One way could be to introduce a RemoveEntityTrigger struct (the solution is to be validated).

Evaluate if it should be added as an example, as a subcrate or as a standalone project into its own repository.

It might be worth to expand a little the scope and create a proper terminal multiplayer game. Chess or checkers are a possibility, but a completely original game would be fine as well.

Write an user guide to explain the basic concepts of weasel.

The book should be available online in a similar manner as the official Rust book.

Could be useful to have a benchmark to measure how many events can be fired per second.

We could think of running one bench with only DummyEvent and another bench with StartRound and EndRound in sequence.

Keep in mind all events end up in the in-memory timeline and we shouldn't allocate too much for a benchmark.

Make generalize function work for any type of number N.
Expose a function similar to generalize that accepts a profile used to choose a distribution type at runtime.

Create a page (in the wiki) to collect all use cases that might exist in turn based battles not currently supported by weasel.

New methods for CharacterRules to let the user fire arbitrary events when a character enters the battle or dies.

Methods might be named: on_character_added and on_character_transmuted.

Expand the available list of system metrics. Around 10-15 new metrics (the most useful we can think of) is a good start.