Today, we’re thrilled to take you behind the scenes of FishingLTD and dive into the evolution of our data storage system. It’s been quite a journey, from our humble beginnings as a proof of concept to becoming a fully-fledged, immersive minigame. Along the way, we’ve encountered challenges that pushed us to rethink how we handle user data.
Starting out small
In the early days, simplicity was key for FishingLTD. We relied on good ol’ YAML files to store player data. New players were swiftly set up with default values, and as they left, their progress and stats were saved back to their respective YAML file. It served its purpose initially, but as our player base grew and our game got more feature-rich, we quickly realized that relying solely on file-based storage had its limitations and headaches.
The perils of file-based storage
File-based storage had its fair share of challenges that needed attention:
- Housekeeping: With players joining and leaving, unused YAML files started piling up, cluttering the server’s storage. It was like opening your closet and finding an avalanche of outdated clothes falling on you. Not the best experience, trust us.
- Data loss: Picture this: an abrupt server stop, and all the progress made by players since the last YAML save goes poof. It was like having your favorite catch slip off the hook right before you could reel it in. Heartbreaking for the players, frustrating for us.
- Availability challenges: As we expanded into a clustered server environment, mounting network drives to attach those YAML files to the Minecraft server became a necessary evil. More complexity, more potential points of failure. Ugh.
Embracing the power of databases
Realizing the need for a more robust and scalable solution, we decided to hit the reset button and rethink our approach. Enter databases!
Currently we are running SQL databases in our other projects like RandomRumble (running on SQLite) and our Moderation AI, Detoxic (utilizing MariaDB).
After careful consideration, we opted for a document-based NoSQL database, MongoDB. We already had the experience in handling different data types and structures, and the document model was a perfect fit for our needs.
We wasted no time in setting up a replicated MongoDB setup within our cluster. This move ensured data durability and near-instantaneous saves whenever an event occurred. No more lost progress or frustrating crashes wiping out hard-earned achievements. And hey, even if the primary MongoDB instance decides to take a nap, automatic failover mechanisms have got our backs.
This shift to a more sophisticated and scalable data storage system marks a significant milestone for FishingLTD. By harnessing the power of databases, we can now provide a more stable and reliable gaming experience for our amazing community. And guess what? This transformation opens up exciting possibilities for future growth and the introduction of new features that will make your fishing adventures even more epic.
What’s next?
We’re not done yet! We’re constantly looking for ways to improve our game and make it more enjoyable for everyone. We’re currently working on a new feature that will allow you to keep track of your fishing stats and progress. Stay tuned for more updates!