Character model

[jtkaufman737]

Things that need to be persistent/universal I'm trying to include, things that aren't/don't I'm trying to leave to the frontend logic. There's some grays areas in that though so chime in.

• character id: unique UUID field
• user ID: FK UUID string
• name: varchar
• abilities: I can't tell if this, and the other random stuff like equipment, might be easier dealt with by sticking them in a normalized table where the different attributes could be grabbed. That would look sort of like the attached image, where the data would be collected through the mechanism of the pointer ID for the character (in this case, we'd grab the appropriate record under 6 for that character, and look up the values we need ad hoc)
  
  We could have a trigger on character creation that would create those records from random values and insert them into the normalized table. Or, it could I guess be a frontend function to randomize abilities and just write to the db through a POST.
• languages: not sure what the most appropriate thing here is. May also be a candidate for normalized table
• equipment: same deal, this will be multiple things and isn't well suited to a character table I don't think. Its going to change and have varying numbers of values throughout game play

The alternative I guess to dumping them in normalized tables or one big normalized table would be just having smaller other tables for each of these things - abilities - equipment - etc and dealing with it through joins as it comes up. (Although may be six in one, half dozen in another - both kind of get at the same point).

A SECOND alternative mentioned is that abilities may be an exception - they are going to be pretty universal to characters so maybe including them as additional columns is fair game. But maybe not the other stuff

[angelocordon]

Just a bit of brain dump here:

character: {
  name: String,

  # to reference back to a User
  user_id: Int, 

  # I think `stats` and `abilities` are the same thing in this context, though we should 
  # settle on verbiage early on
  stats: { ... },

  # similar to `inventory` or `equipment`
  inventory: []
}

re: Abilities: I think abilities are more like skillsets, like spells or other things - not sure if that's something we want to implement (cc: @tyberious-1 )

re: Inventory: I feel that inventory should be the stuff that a character is carrying and equipment or item are the singular things that's in an inventory. Thoughts here?

I like the idea that the Inventory should be a separate table + model. Any cons to this you think? I'm just trying to think of when we load up a character, how big are these query calls going to get...?

[jtkaufman737]

Yeah, I can see that - we could have an inventory model and then maybe a bool for "currently equipped?"

[jtkaufman737]

So that is the long and short: I guess I either see us splitting a lot of this stuff out from character into different tables linked on Character ID with a one to many relationship, or lumping them into a flat(ish) data structure that could be dealt with uniformly (the normalized option). I'm ok with either.
That leads to an interesting question, I had originally pictured money as part of the character model - but it is closely functionally linked to the equipment obviously.

[angelocordon]

I think this is really great and there's some long term thinking here that we might not be ready to cross just yet. What do you think we'll need / should nail down from the super early release perspective? I think for me it may be just:

character: {
  name: String,
  role: String, default: 'fighter',
  race: String, default: 'human',
  user_id: Int, 
  stats: { ... }
}

I'd be open to getting stats nailed down but I'm not sure what that entails from the rule book perspective. Thoughts?

PS:
If we're going to nail down stats - maybe think about how we define the values or does everybody have a default baseline?

[angelocordon]

PPS:
Also loved the money idea - there's so much we can do there...