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) 👍