feat: Player Data Storage

[KingTimer12]

Currently, my proposal is to leverage the same database used for world storage (LMDB) and persist player data there. This follows the general idea from Bukkit/Spigot/Paper, where player data is stored inside the world folder.

But I'm still considering whether storing all player data inside data.lmdb is the best approach, or if a dedicated playerdata folder inside the world directory—where each player's data would be stored separately by UUID—might provide better organization and flexibility.

For now, the implementation will move forward with LMDB, but I’m open to feedback on which design would be preferable long-term.

Todo (work in progress, will update as needed):

• Implement player data serialization/deserialization.
• Store player data in LMDB under a dedicated namespace.
• Load initial data and create the first player entry.
• Update data of player.
• Implement SQLite.
  • Add SQLite support.
  • Change database to SQLite.
• Player Data
  • Position
  • Rotation
  • OnGround
  • Health
  • Hunger
  • Saturation
  • Inventory & Ender Chest contents
  • Abilities (flying, invulnerable, instabuild, etc.)
  • Attributes (movement speed, attack damage, max health, etc.)
  • Spawn point (bed spawn, forced spawn)
  • Status effects (potion effects, fire, air, absorption, etc.)
  • Advancements / Statistics
  • Recipe book state
  • Misc (score, shoulder entities, last death location, etc.)

[ReCore-sys]

Hey thanks for getting started on this! My general plan for storing entities as a whole is to use sqlite (or turso depending on it's progress) to store them all in a normal sql database, as opposed to the kv format of lmdb. If you'd be comfortable starting on that that'd be great, otherwise just use lmdb for now and I can move it over later.

[KingTimer12]

Ok, I'll switch to SQLite and use the idea of ​​the playerdata folder but in a SQL database (playerdata.db) 👍

[ReCore-sys]

Mostly good changes, but a lot of OOP patterns that don't really fit the project, especially the PlayerData stuff since that can actively harm bevy's parallel processing capabilities.

[ReCore-sys]

Implementing this as a trait doesn't make much sense since it has quite a different use-case as the KV store, especially since we'd like be storing entities in here as well.

[KingTimer12]

I separated them because both are banks and have, in my view, common functions and, if they decided in the future to change the bank that stores the players, I think it would make things easier...

[Sweattypalms]

I've reviewed what I could. Not that experienced with database, @ReCore-sys would be able to review that section properly. But is SQL Injection a thing we should be worried about? I reckon not, since we have control over the database. And also traits for database seems interesting, again, not an expert so recore will have to check that out.

[ReCore-sys]

@KingTimer12 how's progress going with this? Development has really picked up recently and we are starting to need this stuff implemented so if you aren't interested in finishing it off, lmk and i'll take over

[KingTimer12]

@KingTimer12 how's progress going with this? Development has really picked up recently and we are starting to need this stuff implemented so if you aren't interested in finishing it off, lmk and i'll take over

yes, I'm interested, I've just been busy with university exams