Where to save players' game data: `player` vs. `stats` db tables?

[panyakali]

Hi devs,

I've got a development question that I can't seem to find an answer for in the documentation (or maybe I'm just looking in the wrong spot):

There appear to be two ways to save information relevant to a given player during a game (for instance, their money, resources, etc. that are accumulated during the game):

1. 'money'/'wood'/'energy'/'what have you' could be stored as a field in the `player` table of the game db, which would require ADD'ing fields to the `player` table via the game's dbmodel.sql file, and then accessing them via SQL queries (unless there are more efficient ways to access db data that I'm not aware of...)

2. those same pieces of information could also be stored in the `stats` table of the db, which would require adding them as an element to the array at $stats_type['player'] in stats.inc.php; this seems to make it a lot easier to access and transform these pieces of information from the game.php code via init/get/set/incStat


When would I want to use one method over another? Are there certain stats that *MUST* (or at even *SHOULD*) be in one table versus the other (for instance, I assume that the fields 'player_score' and 'player_score_aux' *MUST* be kept up to date in the `player` table for the automated final scoring & ELO point assignment to work)? Does one approach have valid use cases where the other does not? And, is there an easy way to use `stats` fields (and thus, ...Stat functions) to keep track of info for 'player_score' and 'player_aux' fields, and maybe even to sync these `stats` fields with `player` fields?

Or am I going in entirely the wrong direction here? Are these two approaches roughly equivalent, with a push to move away from one of them (what seems to be the older dbmodel.sql `player` approach) to the other (probably the seemingly easier to use stats.inc.php `stats` approach)?

Thanks,
Collin

[Brainchild]

The stats table and stats.inc.php are for end-game statistics tracking only. They are not intended to be used for gameplay. While you probably could use it that way for some things, it's not the reason it exists.

[panyakali]

Wow, really? the ...Stats methods seem so much easier to use than the typical db queries that are required for data in the other tables...

Any reason why I *shouldn't* use `stats` for tracking things like money, resources, etc that will be used during the game? Because it seems like a much more elegant way to do that... Will it be slow? More error-prone?

Also, is there a resource that better explains the purpose of stats (that is, something more informative than the "Game statistics: stats.inc.php" wiki page)?

[fafa-fr]

Also, is there a resource that better explains the purpose of stats (that is, something more informative than the "Game statistics: stats.inc.php" wiki page)?

Yes, you can find this in the BGA Studio Guidelines. Quote:

Using BGA Studio you can define a set of statistics for your game. Statistics will be displayed at the end of the game, and help players to figure out why they win/loose a game, and what they should improve. Try to choose interesting statistics that distinguish the different strategies for your game, in order it can help players to understand their game.

I'll add that they're not only displayed at the end of each game, players can also look at their stats or other player's stats for past games.

Any reason why I *shouldn't* use `stats` for tracking things like money, resources, etc that will be used during the game? Because it seems like a much more elegant way to do that... Will it be slow? More error-prone?

Depending on your game, it may not be a useful stat to display all the money, resources, etc. that players had at the end of the game.

[Brainchild]

In addition to what fafa-fr said, the stats table only deals in integers. As soon as you need another type of data associated with a player, it's back to the player table. Better to keep it all in one place from the start.

[Inaofr]

Stats table can also deal with float and boolean, but I agree it should not be used for in-game data, only for data meaningful as end-game statistics.