jac0bdeal / pikamon Goto Github PK

Some items should be rarer than others (e.g. potion vs. master ball).

• Design rarity tier model
• Update persistence layer model to account for rarity model
• Implement rarity model logic in item spawner

• Add command catch (called as p!ka catch)
• First call of catch with correct spelling awards pokemon to that user (not storing it right now)
• Bot returns a congratulations message with user's tag

This depends on #17

Implement the design of the evolution part of the leveling system. This should only include the code:

• to determine whether or not to evolve a pokemon
• evolve the pokemon
• reflect the evolution in the database

The bot currently just fails to start up if it can't connect to discord right away. Their should be exponential backoff retry logic on startup to make the bot more robust.

Need to determine how we want to be able to level up the pokemon. Perhaps if you can "trade" excess pokemon of a species you own to grant exp or levels to another pokemon you own of that species.

Example:
Suppose you have 3 Charmander's. You could "trade" or give up 2 of them to get 2 exp (or 2 levels?) to use on your remaining Charmander. You would not, however, be able to use that exp on your Pikachu (not saying this has to be the case, but this is just one idea).

Just need to design the mechanics of how we want this to work that allows the users to level up the pokemon. The challenge I see here is being able to give the user a way to level up the pokemon without making it on of the following extremes:

• impossible without grinding/high pokemon spawn rates
• way to easy to making levels functionally meaningless (and therefore not rewarding)

• Need to rework the use of the current global bot cache.
• Should also adjust the utils package to be at the base level. The base commands handler should be adjust to follow the pattern of the spawner so that we can pass in the bot cache information like we do for the spawner.
• Need to adjust the naming convention used to refer to the different cache types: #23 (comment)

This is a result of #23.

A Frosmoth was spawned in a server, and the bot returned a failed to catch message repeatedly even though the proper name was spelled correctly.

We need to attempt to reproduce this bug locally, then isolate why the bug is occurring before fixing it.

The p!ka help command returns a list of all the commands, what they do, and example usage. This command needs to be updated to reflect all of the current commands.

Add a command that lists a user's pokemon.

• Add p!ka list pokemon command
• Bot queries for all of user's pokemon
• Bot returns list of user's pokemon

Items should be randomly awarded to users. This system requires the persistence layer to be updated to include a user's items, as well as a spawner on the bot with the logic for distributing them.

• Update persistence layer model to include items
• Add spawner to bot that randomly drops items to users
• Add notification to user when an item has been awarded to them

Once the trade has been accepted it needs to be executed. For this the program should:

• Remove the primary trader's offered pokemon from their collection and add them to the secondary traders collection
• Removed the secondary trader's pokemon from their collection and add them to the primary trader's collection

Where the primary trader is the user who initiated the trade and the secondary trader is the user who accepted the trade. This should be reflected in the database.

We want to be able to trade Pokemon between two parties. The following should be implemented:

• The primary trader needs to be able to initiate a trade with another channel member. Syntax:

  p!ka trade <trader 1 pokemon list> with @<user> for <trader 2 pokemon list>
  

• The secondary trader, listed in the above command, should be able to accept or decline the trade

  p!ka accept @<user> trade
  

For the purpose of this issue, the trade does not have to occur. Instead, it should just print a success message along the lines of

successfully traded pokemon!

or

<user> denied the trade request! womp! womp!

It should however verify that the pokemon both traders are offering are owned by those traders. This may depend on the list functionality in the Catching System milestone.

This depends on #17

Implement the base design of the leveling system. This base design should only include:

• Mechanism to level up your pokemon
• Updating the level of the pokemon in the database for the user
• Any other aspects (such as "trading" pokemon in to level up another pokemon) based on design

This would not include:

• selecting moves a pokemon knows
• evolving a pokemon

A user will want to be able to look up their pokemon and do things with them, in order to do this we need a persistence layer.

• Pick a persistence layer solution (DB, KV Store, etc.)
• Design persistence layer model
• Implement model in code
• Wire up persistence layer to catching mechanism

Need to agree on the structure of the battle system. We know (generally) what we would like to support. However, we are unsure of the mechanics. As an example, we know we want to:

• support selecting pokemon for battle
• selecting pokemon sequence order
• using items
• taunt the other trainer
• more

However, we need to decide on the following:

• How to select pokemon and their order (preferably without the other user knowing if private messages are available like in slack)
• How to select order
• how to use items
• how to use attacks
• how to forfeit

Dependencies:

• This will depend on the Catching System implementation
• Likely will need database for advanced queries

Users need a way to see what items they have, and what quantities.

• Add item list functionality to bot commands (p!ka list items)
• Bot queries for list of items (with quantities)
• Bot returns list to user with notification

Design and implement the DB schema for storing what pokemon is active. Perhaps this can be as simple as a foreign key reference to a pokemon on the trainer's table.

The user needs a method to set their active pokemon. The syntax should be p!ka set active <id> where id is the id of the pokemon desired. This should update the active pokemon for that trainer in the persistence layer to the chosen pokemon.

Additional consideration: Since pokemon ids are currently an autoincremented integer and not specific to a trainer, care should be taken to ensure that a pokemon not belonging to a trainer can't be their active pokemon. A future code change could potentially take care of this by having each trainer's pokemon have their own domain of ids. But for now a simple check that the pokemon belongs to the trainer should suffice.

Users need a way to use their items.

• Add use command to bot p!ka use
• Bot checks that user actually has the item, returning notification if they don't
• Bot applies item, then removes it from user
• Bot notifies successful use

The user needs a way to view their current Pokemon along with it's current stats.

The command for doing this should have the syntax p!ka view active and should display a UI of their active pokemon. Some basic things that should be on this UI:

• The name of the pokemon
• The pikamon id of the pokemon
• The id of the pokemon in the pokedex
• A picture of the pokemon (should be an embedded link, similar to what is done in spawning)
• Perhaps the date caught?

Could be potentially cool to have the highest rarity items be picked-up in a manner similar to pokemon being caught (e.g. p!ka pickup masterball), where it is a race for users to pick up the item first. Thoughts?

The general idea is that the catching system will allow for different types of balls to be used, each with their own set of pros and cons.

For example, the basic pokeball would require the exact spelling of the name to be correct, whereas other balls could allow for varying degrees of spelling accuracy. Other ideas so far have been for a ball that gives advantage based on speed of reaction, a ball that just requires the correct type(s), etc.

This issue is to document ideas for ball mechanics, and subsequent issues will be opened to implement them.

Need a way to for a primary user to initiate a battle with a secondary party/discord user. It should be something like the following:

• Primary user initiates battle

  p!ka battle @<secondary user>
  

• Secondary party/discord user accepts or declines

  accepts

  p!ka accept battle
  

  or

  p!ka decline battle
  

For this item it should not start a battle. Instead, it should simply print a response of either:

Starting battle between <primary user> and <secondary user>

in the case of accept or

<primary user>'s request to battle <secondary user> was declined! <secondary user> is scared!

in the case of decline