All the most important stuff that happens in the game should be alternatively parseable by means of a written-word console panel.

A great example: https://github.com/Adam-Diehl/rust_strategy_rpg

# --- ROUND 1 --- #
The Good Archer is attacking The Dragon! The Dragon took 20000 points of damage (78% HP remaining).
The Good Archer is attacking The Evil Swordsman! The Evil Swordsman took 20000 points of damage (73% HP remaining).
The Good Swordsman is attacking The Dragon! The Dragon took 12000 points of damage (64% HP remaining).
The Good Swordsman is attacking The Evil Tank! The Evil Tank took 12000 points of damage (83% HP remaining).
The Evil Swordsman is attacking The Good Tank! The Good Tank took 8000 points of damage (87% HP remaining).
The Evil Tank is attacking The Good Tank! Critical hit! The Good Tank took 14000 points of damage (63% HP remaining).
The Good Rogue is attacking The Evil Mage! The Evil Mage took 18500 points of damage (59% HP remaining).
The Good Tank is attacking The Dragon! The Dragon took 7000 points of damage (57% HP remaining).
The Dragon is attacking The Good Tank! Critical hit! The Good Tank took 10000 points of damage (47% HP remaining).
The Dragon is attacking The Good Swordsman! The Good Swordsman took 5000 points of damage (88% HP remaining).
The Dragon is attacking The Good Rogue! The Good Rogue took 5000 points of damage (92% HP remaining).
The Dragon is attacking The Good Archer! The Good Archer took 5000 points of damage (80% HP remaining).
The Evil Mage is attacking The Good Tank! The Good Tank took 12000 points of damage (27% HP remaining).
The Evil Mage is attacking The Good Swordsman! The Good Swordsman took 12000 points of damage (57% HP remaining).
The Evil Mage is attacking The Good Rogue! Critical hit! The Good Rogue took 24000 points of damage (55% HP remaining).
The Evil Mage is attacking The Good Archer! The Good Archer took 12000 points of damage (32% HP remaining).

# --- ROUND 2 --- #
The Good Archer is attacking The Dragon! Critical hit! The Dragon took 40000 points of damage (12% HP remaining).
The Good Archer is attacking The Evil Swordsman! The Evil Swordsman took 20000 points of damage (47% HP remaining).
The Good Swordsman is attacking The Dragon! The Dragon took 12000 points of damage (0% HP remaining).
The Dragon died!
The Good Swordsman is attacking The Evil Tank! The Evil Tank took 12000 points of damage (66% HP remaining).
The Evil Swordsman is attacking The Good Tank! The Good Tank took 8000 points of damage (13% HP remaining).
The Evil Tank is attacking The Good Tank! The Good Tank took 7000 points of damage (2% HP remaining).
The Good Rogue is attacking The Evil Mage! The Evil Mage took 18500 points of damage (18% HP remaining).
The Good Tank is attacking The Evil Tank! The Evil Tank took 7000 points of damage (56% HP remaining).
The Evil Mage is attacking The Good Tank! The Good Tank took 12000 points of damage (0% HP remaining).
The Good Tank died!
The Evil Mage is attacking The Good Swordsman! Critical hit! The Good Swordsman took 24000 points of damage (0% HP remaining).
The Good Swordsman died!
The Evil Mage is attacking The Good Rogue! The Good Rogue took 12000 points of damage (37% HP remaining).
The Evil Mage is attacking The Good Archer! The Good Archer took 12000 points of damage (0% HP remaining).
The Good Archer died!

See Bots AI doc.

Make a bot script for a Leader that doesn't have one yet, or make an alternate script to create a new bot behavior.

PR example: #19

Dependent on Leaders. See #6

WIP.

https://www.notion.so/erlendsh/Modding-system-7634b7cd978241ccbadfbf5e5ee407eb

Our current map looks like this:

It has to look this way right now because of a pathing quirk:

To fix the pathing issue, we'll need to entirely rethink the algorithm that chooses where the creeps wants to go. Currently it goes towards the closest enemy, but due to the shape of the map (before the above), sometimes enemies in the center are closer than the towers in the assigned lane. To fix this, for now, I changed the map shape and it works much better.

For the future, we might need to implement the algorithm in a way that the creep follows a predetermined path until it is in aggro range of an enemy, at which point it will start going towards it. That isn't strictly necessary for now as the new map shape seems to work very well for our needs:

Once we’re no longer blocked on the above, we’d like to get closer to this:

The game map can be changed by doing like this: 1b37ca9

With some clever arrangements, it might already be possible to achieve a diagonal layout that works within our current constraints.

See MVP issue.

We'll most likely use https://github.com/lemunozm/message-io

Overview of different netcode solutions here:
lemunozm/message-io#11 (comment)

A demo game quite similar to Shotcaller is available here:
https://github.com/lemunozm/asciiarena

All prospective community participants should read CONTRIBUTING.md.

If you're interested in contributing to this project but need help getting started just leave a message here, join the #shotcaller channel or contact @erlend_sh#4477 directly on Discord

All participants must abide by the Amethyst Code of Conduct.

Shotcaller MVP 3:

• minigene add panic hook to fix panic getting eaten by rawmode
• move kenney.nl/content/3-assets/2-micro-roguelike
• Load tileset in minigene
• Add tiles to entities
• Create amethyst(or other) window
• Fix issues with tiles
• add item inventory to leaders
• add ItemDefinitions to resources
• add Vec to Items
• add handling system of stats effectors for items
• tutorial creating leader
• tutorial creating item
• (optional) get tiles to work on wasm

The first version will just be a fixed gain in skill points over time, equal on both sides. So essentially, we come up with three levels for each skill. And then over the course of, say 5 minutes, all Leader abilities will go from lvl1 to lvl3. Probably increase to lvl2 at min2, and increase to lvl3 at min 4.

Part 1: Design

Here is an example draft of an item specification:

"A cup of coffee. Drinking this will double attack speed for 5 seconds."

Suggest your item ideas below, in an issue that refers here (#8) or in chat.

Part 2: Code

Make a new equippable item.

Example PR: #14

Docs: https://github.com/amethyst/shotcaller/blob/master/doc/create_item.md

See also: 🦹 Make a new leader.

Setting ActionPointRefillRate to a nonzero fraction of the default should slow a given unit, and this would make sense given that units move normally at 100 and stop at 0. Occasionally this does work, but more often than not units very quickly speed up back to a normal pace.

I have additionally noticed that units move oddly and often back up away from opponents when ActionPointRefillRate is set to a value <40. This likely involves irregularities in the rates at which targets are added and cleared from AiDestination.

The implementation of Generic Hero 2 is currently dependent upon this being fixed.

Part 1: Design

Here are two example drafts of a leader specification:

Generic-person 1

Default: Melee attack, every 3 attacks deals 200% damage.

Special: Deals damage in an AOE around it for 100 damage whenever >3 units are within range. Cooldown: 12s.

Mechanics notes:

AOE: should be able to basically take whatever the minimum distance to attack another enemy is, multiply that by 1.5x and you have your radius.

Passive is triggered automatically, IF at least one enemy is present.

Generic-person 2

Default: Ranged attack. Increased attack speed by 10% with every subsequent attack up to a 100% increase.

Special: Deals damage in a large AOE around it for 50 damage and MS-slows all enemy units by 50% for 4 seconds whenever >3 units are within range.

Suggest your Leader ideas below, in an issue that refers here (#6) or in chat.

Part 2: Code

See the Leaders (aka Heroes / Champions) doc.

1. create the skill definitions (see current SkillDefinition)
2. create the handler systems for any skill interacting directly with the world (see AoeDamageSystem)
3. create a hero entity (See the bottom of main.rs)
4. assign the skills to this new hero (See the bottom of main.rs, just before the entity creation of the hero

Full documentation available here:
https://github.com/amethyst/shotcaller/blob/master/doc/create_leader.md

This is a repeatable task.

For reference examples see all leader PRs.

See also: 📦 Make a new item.

Player can purchase items for a Leader, using the Coins the Leader has in their inventory. Leaders do not share coins.

In iteration-1, a Leader will be able to equip only three items:

1. Weapon (sword, staff, spear etc.)
2. Armor
3. Consumables

UI styling mockup:

UI elements mockup:

Resources:

• https://cyangmou.itch.io/inventory-designer-kit
• https://cyangmou.itch.io/menu-gui-hud-health-bars

Upon purchasing an item, the item will appear in the Leader's inventory after 10 seconds.

Weapons

Leaders have different competencies with types of weapons. For example, Archer-person might get bonus attribute when using any ranged weapon like a bow, slingshot or crossbow. Whereas if they equip melee weapons like a sword or an axe, they suffer an attribute penalty.

In iter-1 however we'll probably just set some Leaders to melee and others to ranged and entirely disallow them from using weapons not in their competency.

Armors

Straight forward attribute boosting, focused on damage mitigation.

Consumables

Items with limited number of uses. See for example Coffee.

The first key UI addition in the game will be the sidebar menu, featuring all the Leaders in play.

Each leader is listed with a number of UI elements:

⚔️ 🛡️ ⏳ 👜

• Avatar
• Coins
• Level (not yet present in mockup)
• Name
• Health Points
• Mana Points
• Experience Points (maybe this would be a plain number next to coins instead)
• Offensive items
• Defensive items
• Consumables
• Store button (won't be functional until #16 arrives).

UI System Basics

The ui system will draw any entity that has either a Sprite or SpriteIndex Component.

SpriteIndex is used to hold the index of the 2d sprite in the spritesheet.

Sprite is used for text-based rendering (it holds the letter and colors).

For the rest of the ui, we are just using BTerm's rendering (term.print("text content", position_x, position_y").

Rust's current front-end is not very mature,
but the stability and performance of the back-end is yearning.
Is there a way to provide a simple example of this project as the back-end,
Unreal or Unity as the front-end?

Run our simulation at least 100-1000 times, and make a printout of the results. We wanna know which lineup of leaders tend to win.

The games should be played out following some automated rules:

• No more than 3 leaders per lane is allowed.
• Every major tick (the time between pawn (creeps) spawns) there is a “random” roll to see if any Leaders are changing their lanes. It should be >50% likely that the lanes will remain the same. Maybe more like 80% likely.

Here is what I posted on the rust discord server. Still waiting for a reply.

I have some issues getting SharedArrayBuffer to work properly on newer firefox versions.

I did the changes required from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes but had no success in using post_message in a web worker.

I did verify that both headers are set and that the window is in a secure context. The SharedArrayBuffer does work, but when using post_message from the web worker, I get a panic.

My project uses the web_worker crate, which is itself based on the wasm_bindgen/examples/raytrace_parallel.
This example is also broken.

Anyone knows who is the current maintainer of the wasm_bindgen examples?

Bring SC-level input (micro-play) to Shotcaller. We’d like to enable this “abstraction of play” as its own module. I.e. controlling an individual Leader unit (and often their summons/copies/..) in the game.

This may not be part of the standard mode of play in Shotcaller, but it’s very useful for enabling alternative modes that more closely resemble the traditional way of playing MOBAs. This will also help us think more carefully about what types and amounts of actions should be available to a bot’s micro-play.

Input still wouldn’t be instant. Playing at the most granular micro-level, controlling a Leader around, all players are subject to the same 2-second latency. As such, you’ll rarely have to rely upon your reaction skills. What really matters is your shortest-term foresight.

Milestone 1

Implement most of text-rts features in Shotcaller:

• Select units (left click)
• Deselect units (left click empty space or another unit, or press Esc)
• M-move (move to destination, ignore enemies)
• A-move (move to dest., fight if meet enemies)
• Stop order.
• Hold position order.
• Focus order (move to and attack specific unit)
• Auto-groups & quick-selection (see below).

As an example we have a TreePerson leader who can summon a small group of units. Once that group is summoned, the player should be able to hit Tab to switch control over to that group of units (quick-selection). Hit tab again to switch back.

We do NOT need:

• drag-selection.
• build mode
• select all nearby
• add units to current selection
• Control groups (or rather, control groups should be hardcoded. E.g. Lone druid would come with two control groups).
• Camera movement

Milestone 2

• Use & targeting of abilities.
• Moving camera
• ...

The way I see movement system at the moment, it has 2 problems:

First. Currently there are 3 systems for movement: leader1_simple_movement.rs, leader2_simple_movement.rs and simple_movement.rs. 3 systems for essentially the same thing is little bit too much.

Second problem, which is more relevant for me personally, is the whole architecture and logic of the movement as a whole. Currently it looks like this:

1. System checks if unit has enough action points to move. If yes:
2. Runs the logic to find a target destination.
3. Adds AiDestination component.
4. On minigene side, this AiDestination component is used to compute AiPath component.
5. On minigene side unit gets moved to the next point on AiPath.
6. If on step 1. unit had not enough action points to move, then both AiPath, and AiDestination components get removed from entity (thus preventing movement).

Now this implementation has potential performance issues, because pathfinding gets computed every time a unit moves a single step. But I see there a much bigger "architectural" issue that causes problems with code scalability. In my view movement system should would something like this:

1. Find where unit needs to go. Set AiDesination.
2. Run pathfinding (don't run if it was already computed and AiDestination didn't change since last frame)
3. If unit has enough action points, move it 1 point forward on AIpath.
4. Repeat steps 2 & 3. (step 2 to take into account moving targets)

The way I see it now is that steps 1 and half of step 3 (checking for action points) are now in a single system. Another half of step 3 (actual change of position) is in another system in minigene.

I also dislike the constant adding/removing of AiPath, and AiDestination components. I think it would be more consistent if all units had these components for all times, and if they don't have anywhere to move, then their destination would simply be their current position.

Now to implement this refactor, we would have to rewrite the architecture, and then implement all three leader1_simple_movement.rs, leader2_simple_movement.rs and simple_movement.rs into a single system that sets destination based on various conditions.

Does not run, even after manipulations.

MVP Doc.

Pending

• Final camera & resolution overhaul
• Art assets implementation
• XP system #50
• 10 items
• Online & local multiplayer #18

Finished

• drawing a background map
• spawning creeps
• moving creeps around the map with a* pathing
• collisions with the map
• stats system for health, mana, attack and defense
• game speed control (trying to finish that as we speak)
• general purpose input mapping
• general purpose renderer
• Load tileset in minigene
• add item inventory to leaders
• add handling system of stats effectors for items
• tutorial creating leader
• tutorial creating item
• get tiles to work on wasm
• Publish to web
• Leaders (aka Heroes/Champions): two generic Leaders should be created.
  Give each side 4 melee and 1 ranged Leaders. Preset lane designations.
• Fighting & Basic AI: When creeps/leaders encounter each other, they must engage in combat. Leaders will go away from enemy tower when they don't have friendly creeps around. They should probably seek out the nearest allied creep in their lane.
• Buildings: There should be Towers, Barracks and a Core (the win condition)