Can be broken down into:
Essentials (spawn, shop, tutorial)
Basic (enough to make a game out of)
Extra/Secrets

entering a room displays the room descr

give the room description upon entering, at least the first time you're in a new room.
Partially exists atm, but I'd like to also have it print out the available exits.

it's good, but it needs to be BETTER
also maybe implement that reaction combat....

Add status effects to the game!

Some guidelines:

• status effects should be in their own table, for simplicity
• should also be stored in player state, as an array of ids, allowing for multiple effects, and by default of this idea, stacking of effects(might want to not have this)
• maybe they're combat only?
• items should be able to apply them when used in combat, or at all. (so item usage outside of battle needs to be added before this issue)

generalized data shape for table data:

{
  id: 'effect name',
  description: 'what it do',
  action: 'a value that can be eval'd, so this gets done when the effect activates',
}

currently there is a magic slot in Attack for player choice, but that's just a placeholder.
If this is deemed too large in scope, it can certainly be atomized

• need a mana system(maybe? not uber necessary)
• need a place to put spells (their own table?)
• are spells learnable? do they require scrolls to cast?

quests: {
    active: {
        quest1: 0,
        quest2: 5
    },
    completed: [
        quest0
    ]
}

something like this as a subset of the player infrastructure

undo the hard coding on throw, and make it so that a thrown item does some different damage calc unless it's of a throwing type. Items not meant to be thrown(non-weapons that aren't key items) should do like, 1 damage or something.

in the future, perhaps implement a toggleable game flag that turns on a hyper-detailed physics calculation for damage, based on the weight of an item and the base amount of force needed to throw it in a 10ft arc.

We need to find out how discord bots are hosted and actually run

Admins may not be tech savvy, so we need to make a series of bot commands, and Admin Toolset, for world creation.

The exact types of tools and functionality are up for debate atm.

The process should be fairly user friendly.

health should automatically fill up by the +5 per level up. It doesn't.

redo the current talk system (almost) completely

npc replies should be parsed into 3 types of states:

• starts – the only allowable dialogue options for npc talk initiation, and the player cannot return to them without restarting npc dialogue completely. They have a priority field to determine which is shown if a player meets requirements for multiple.
• intermediates – reachable at any point in a conversation, assuming requirements and proper dialogue tree traversal
• terminals – sent when a player chooses a terminal option of dialogue, or universally sent when the player uses the leave subcommand

which have the general structure of:

{
  "starts": {
    "1": {
      "reply": "Hi there!!! I hope I feel better soon!!",
      "prompts": [
        {
          "prompt": "[0] Ask how he is",
          "progression": "5"
        },
        {
          "prompt": "[1] Ask where you are",
          "progression": "6"
        }
      ],
      "reqs": ["player.inventory.keys[6].used"]
    }
  }
}

where the reqs array is sent through a forEach, and evaluated using template literals(which might not work, we'll see) to see if a player meets the reqs. This allows for Very dynamic dialogue.

Addditionally, all 3 types of dialogue should be able to have reqs.

All types of dialogue should be able to set flags as well

"flags": [
  { 
    "property": "player.inventory.keys[6].used",
    "value": true
  }
]

We need a database to store inventories, attributes, and descriptions

currently:
-look and describe need their param check back, likely any others

anytime the bot restarts when a player is doing an action that sets them to a "busy" state, they get stuck in that state until the ?notbusy command is used.

solution:
the proposed idea is to have a function that resets the busy status of all players on bot start/restart

players should be able to set descriptions of themselves for RP purposes

I'm keen on ?describe, followed by keywords like nickname or self, that way players can change their nickname or their self-description with ease.

we should allow players to set a nickname at the beginning of an adventure. My recommendation is to add that as part of ?start, and then make a secondary ?describe command that can also be used to modify a players self-description later (#72 ).

Need to include:
Health
Strength
Level
Defense

Fill dynamo with an entry for each type of object we'll have in the game.
Something in a room like a chair, an entity, an exit, and a room.

each should be Look-able and therefore have an associated description and name. We also might want to do something like ID generation if that helps(we can just hardcode, although making an automated section for that might be nice).

This issue is part of #9

https://discordjs.guide/improving-dev-environment/pm2.html#installation

add a command that allows an admin to auto-gen all the necessary rooms and roles for a server, per rooms in the db.

• it should iterate through all rooms, checking for their existence, creating them if they don't
• it should also create roles for those rooms.

add one

playerlist here vs playerlist global?

Dynamo has a web interface, but we need to be able to access it on the host, so there should be some way to passthrough that connection.

hearthing does not remove the player from the room they leave

convert the bot to have the player's current room stored in their state, and then allow all references to player location to reference that instead.

the last part is moving all messages to send to DMs, although there is the issue of getting all relevant players for a room and perhaps the simplest solution is to keep a list of players in each room, the only side-effect then will be the duplication of info, players and rooms will store player location, but for different access reasons.
Rooms store players to dissemenate player actions to all players present, players store rooms to have a cohesive movement structure.

this also raises the issue of, players should be able to set themselves as online/offline to avoid getting dm pings when not playing the game.

the solution to that is a pair of connect/disconnect commands would be useful, to toggle a player state in the room object.

so the likely structure for the playerlist in rooms is

{
  "playerID": "asdfasdf",
  "online": false
}

and for players, just a simple

{
  "room": "aroomID",
}

😃

it's currently exceeding the 2000 character limit, so we need some way of making it not do that

like how u did item

A “search” command would be great, to interact with items in a room

implementation:
let's players find items within objects in a room. i.e. ?searching a pile of rocks gives the player a key that was buried in them.

get a dynamodb local instance running.

it's a logical mess , and also needs to work on items and self inside of DMs

idea:
generate object list of all things that the player can look at:

• the player, and other players in the room
• things in player inventory
• items, enemies, and npcs in the room

it should be a list of aliases and ids

requirement: be able to invoke a /move command

so this should reassign a user's role. First it should add the room the user is to move into, and then remove the room role for the room the user is in. This will force discord to change the user's room.

So, we already have an outline. A good place to start.

Now we need to figure out which pieces should be made in what order. We also need to determine some finer foundational points, like:

• which API implementation we're going to use (my preference is either the python one, or the javascript one). Those can be found here

• How we'll be implementing DynamoDB. From what I understand, we can host it locally or directly on AWS (someone will likely become our backend/project expert on this). Maybe we'll host locally for dev and then setup an AWS instance for production? That's up to everyone to decide.
  So I've got the locally hosted dynamo up and ready mostly. Haven't tried to interact with it, but it runs.

• What kind of development system are we going for? I've already setup a Kanban project board, and my preference is definitely scrumban, but you guys may have better/different ideas.

This is a large project, but I have no doubt that given enough effort, we'll pull through.

PVP!
A lot of people have requested this, and it's going to require some sort of handshake logic prior to implementation.

• do we set it as a per room basis?
• or maybe it's dependent on player 1 asking player 2 for a duel?

The ability to start, check stats, check inventory, and equip items through DMs.

message collectors are used throughout the codebase, but I think they all use the same filter, and more or less could be simplified with a wrapper that takes parameters/callbacks/timeout.

Make it like a traditional text-based game, with the following basic commands to start:
Look
Talk
Attack
Help

And make sure these commands are understood by the bot we're implementing

needs implementation such that items are usable inside and outside of combat

• health potions are the first thing to get working but
• also make sure stuff like stat modifying potions are also available
• does this include adding status effects to player state?

additionally, fix room movement modifications to the playerlist

try to maintain the current combat system, and swap in a global variable that toggles a new functionality of using emoji reacts instead of word inputs.

requirement: be able to invoke a /look command

we can likely just use a placeholder return for now, and worry about having it return a description from dynamo later

take the old talk functionality and add it as a new command called shop

depends on #80

list active and finished quests.

if someone could fix the warning that vagrant gives on vagrant up where it talks about the NIC interface being vulnerable, that'd be great. IF that isn't happening for anyone else, that'd be useful info as well.