loehnertz / pokeclicker-backend Goto Github PK

The store in the frontend needs to display the available booster packs which should be fetched from the PokéAPI

A user should not be able to connect to a different socket while an existing socket is still open for that user.

Steps to reproduce:

1. Buy a bunch of boosterpacks
2. Read/write down the current gather rate
3. Erase the gather rate key from Redis
4. Wait for the update
5. Compare the new gather rate with the one you wrote down, it's much lower than the previous

I'm assuming the gather rate hincrby command that is sent to Redis is not the same as the sum of XP over all bought pokemon.

In the API responses, the CORS headers (Access-Control-*) should be set appropriately in order for the front end app to be able to access the API. Access-Control-Allow-Origin should be configurable via environment variables.

It should expect the format Token xxxxx, not Token: xxxxx.

The .env file and how to build and scaffold the application, in general, can still be improved.

We will utilize a Kotlin ORM called exposed.

We decided to base the booster pack editions on the regions of the PKMN games since each region offers a list of PKMN that can be encountered there. Thus, a random selection of five PKMN will be part of a booster pack.
Additionally, legendary PKMN which do not have natural encounters should randomly be added to booster packs with sub-10% drop chance. Moreover, items could be used to temporarily increase this percentage.

PokéAPI has an endpoint for getting the stats (HP, Attack, Defense, Sp. Attack, Sp. Defense, Speed) of a pokemon, given the type and its level.

A formula should be defined and implemented that uses these stats to calculate a fair gather rate.

For example, one of the Pokémon it replies with is:

{
    id: 6,
    pokeNumber: 120,
    owner: {
      id: 3,
      ...
    },
    xp: 816,
    aquisitionDateTime: { 
      ...
    },
    fatApiInfo: null,
    thinApiInfo: {
      id: 1,
      name: 'canalave-city',
      xp: 0,
      sprite: null
    }
}

We probably want to use Docker.

Preferably with Sentry.

We already constructed some first database models during #2.
The next step of this issue should be to test if the exposed ORM is actually fulfilling our purposes.

We decided that we don't want to store any redundant data from the PokéAPI in our own database.
Thus, an adapter that essentially maps the internal IDs of the API is mandatory.

Preferably, WebSockets should be utilized for this enhancement.

It is planned to use Google (or another service's) OAuth to create a new user account and to log in respectively.

The increase in funds per boosterpack is currently to high.

Create a class that wraps the API and offers public methods for the features we will use.

Due to the fact that there are very many locations in the PKMN games, we need some automatic design for each booster pack. This could e.g. be based on a mapped hash of the location's ID.

Location-Area's in the PokeApi have a reference to the Location they are in. The location has a reference to the Region they belong too. Every region has their own counting of the game_index field, which determines how late in the game you'd encounter these pokemon. This is valuable for determining booster pack value and level of the pokemon inside. We should create different regions the user can travel in between, to make the user able to collect different generations of pokemon in a structured way.

I own pokemon of 700 million xp or more. The balance update manager sums the XP of 5 pokemon together, and casts that to a double, so 5 * 700 million = 3.5 billion, resulting in an overflow.