Creating storage for points in the DB

[JackUrb]

Overview

Creates a method to store and load the xp and reward_xp fields on agents when in the main game. This is done directly through the purgatory call to fill a PlayerSoul, so after the call is made these fields should be accessible directly from the player object available in the frontend!

Sorry @JustinPinero, it seems the easiest solution here was to avoid server calls as much as possible, so no remaining python changes.

NOTES

This requires deleting the users_table inside of the LIGHTDatabase to be functional. I'll do this for our core dbs once this is merged.

Implementation

• Moves the LIGHTDatabase to be accessible throughout all of the web controllers
• Creates the scores_table to actually store scores. Here we have a global score per player, as well as a character score per player (though at the moment our game doesn't link up to the DB characters by ID yet, so we're only tracking the main score).
• Creates the initialize_agent_score and store_agent_score methods, which load up the current scores from the database to attach to the current agent (wherein they can be accessed on the frontend!), and then stores them back based on the delta so that we don't run into issues in the future if people are saving from two different worlds.

Testing

Ran locally, gave myself some points, found I still had them later

[klshuster]

cool stuff - most of my questions stem from possibly some lack of context

[klshuster]

when does this happen?

[JackUrb]

This happens if we dump the cookies on the backend to reset auth issues. I'll put a note here to that effect.

[klshuster]

what is extern_id?

[JackUrb]

It's whatever an external provider may be identifying the user as. With login with facebook, this will be PSID

[klshuster]

nit: could be good to have safe access to these private attrs

[JackUrb]

So I'm really not sure what to do about this. The current design isn't my favorite, but GraphNodes have a set of attributes that we know they'll have in all cases. These extra attributes (which are more game-dependent) aren't necessarily going to be present in all cases, so the _ is referring to the fact that they're not always present. I'd imagine that these attributes would belong in a mapping from the World, but they're always accessed at the level of the node. May be worth discussing this more.

[klshuster]

ahh i understand. if you're sure that these specific GraphNodes will always have these attrs, is it possible to define these as like XpGraphNodes? or will that end up exploding the space of types of nodes

[JackUrb]

Well, the difficulty is more that these attributes are only expected to exist when:

1. We're using a World that has exp enabled in some form
2. The given GraphAgent is a player.
   Unfortunately the GraphAgent already exists by the time we'd want to mix in these attributes, as they're NPCs until the moment a player takes over.

Even worse, we have other attributes of this sort that Souls choose to attach to agents as 'metadata' of sorts, and they're all going into this _ view.

Perhaps the right call is to extend GraphAgents with a interfaces attribute, and then we can do something like:

@dataclass
def XPInfo():
  base_experience
  base_class_experience
  base_reward_points
  xp
  reward_xp

...

  some_target_agent.interfaces['xp'] = XPInfo()

And then later places can do optional things with this.

if 'xp' in Agent.interfaces:
   # do EXP stuff
if 'partner_heuristics' in Agent.interfaces:
   # do partner heuristic stuff

How does this look?

[klshuster]

sorry for the delayed response, yes this looks great, thanks!

[JackUrb]

No worries, I'll be addressing this in a refactor soon!

[klshuster]

this is a bit confusing - how does the db_id map to a character_id?

[JackUrb]

The db_id of a GraphAgent should be the id of the character that spawned that GraphAgent.

[JustinPinero]

Looks great, I think this will be a great way to manage exp across multiple worlds.