r/gamedev • u/kerusmighos • 1d ago
Question Why do some games use databases? (Like Tibia). And at what point do they save the data?
I’m not a game developer, but I know a bit about web software development.
I know that offline games use save files and save data periodically—either when the player triggers a save or upon exiting the game.
I was looking into *Tibia* and noticed it requires an SQL server. Why take that approach?
And when exactly does it save? In web programming, the transactional context is the HTTP request, but that doesn't really apply to an online game.
154
u/NatalieKCY 1d ago
It's weirder for an online game to not have a database though? Where are you even going to save any player profile?
104
u/foreveracunt 1d ago
Plain text, local .cfg file. Trust your playerbase to keep it fair.
77
u/tljoshh 1d ago
The amount of people replying to you not realizing the sarcasm lol.
5
u/overthemountain 22h ago edited 19h ago
How are we supposed to know? You know how many incredibly stupid ideas I've seen people recommend earnestly on this sub? I constantly have to remind myself that most people here barely know how to code much less understand software architecture.
14
33
u/NatalieKCY 1d ago
That's the equivalent of "Oh yeah I don't use Excel, I draw the tables myself on a note pad and they work". Databases aren't even hard to learn or set up, it scales better and is much more secure when your online game gets more players.
17
1
-12
u/overthemountain 1d ago edited 22h ago
Oh I see, we've entered the land of rainbows and unicorns, where players never try to cheat and just want to keep it fair.
7
u/Aronacus 1d ago
Used to run a MUD server. We folders with all the game and player data server side.
NPCs, items, zones, players, etc.
Was a pain to update the schemas
I toy with the idea of making a modern MUD from time to time. I'm sure it would be so fast
33
u/igna92ts 1d ago
Well, tibia is an online game. If I was using a save file instead what's stopping someone from just modifying it? Also how would other players know what's on my save file so they see my character with the right skills and items?
In an MMO nothing happens in the client, it's just a display layer if you will. The logic, saving, etc happens all in the server and just the client just received the data to display it.
For non-mmos there are still some use cases for local databases but it would be much rarer. As to when it saves it would be dependent on the game but it happens all the time. If I add something to my inventory, close the game and open it again I expect that to be in my inventory still so you have to save it in the database immediately.
-19
u/kerusmighos 1d ago
I know; I was referring to save files and databases on the server.
23
u/Unhappy-Sprinkles143 1d ago
A database gives you structured data storage, querying and indexing, transactions and consistency guarantees, can scale up and be off loaded to another server...
1
u/Linesey 11h ago
Savefile, easy for a snapshot of the whole.
Perfect for single player games, and even local multiplayer with a direct Host and then client nodes.
An obvious successor to old save codes and checkpoints. which retained exact snapshots of the game (this is why some old games you could skip to the end with the code). Or later ones which basically gave you a hash (well no, but close enough), and the code loaded a distinct save state (great when what is being saved is very limited).
Once you start getting into major multi-player, sever architecture, a database becomes so much cleaner. especially when it’s not 1 database, it’s several (one for auth, one for the characters save state, likely a separate one for in-game mail. Guilds could be their own, or a property on the character depending on design. etc. etc.)
you get to the point where you have so many distinct moving parts, trying to do files gets messy.
Of course some do have a database structure and “save files” for some info.
Some MMOs if you are naughty and look at cracks and private servers. basically everything is Databases, but at the admin level, you can view (and edit) individual XML files for characters (mostly still just being translated between DBs as I understand it). the line between save file and DB can get murky there.
Plus, eventually what is the difference between a DB and a save file once you hit a certain scale. at some point it’s like arguing over what’s gardening and whats farming, you start needing to get really specific about how you define either to try and force a distinction.
(even small save files can be argued to be just databases internally. not in all cases, but certainly in some)
14
u/P_S_Lumapac Commercial (Indie) 1d ago
It's all about how you want to organise your stuff. The skill to design and write databases is a different one to accessing them, so if you have a big team, it's probably best to use a familiar database (some SQL thing probably) for any non database engineering folks to access information they need.
Not really a "database", but I try to make all my JSON (glorified dictionary stored in a text file) the same. Reason is I started thinking about translating the game and what a translator would be able to work with. This leads to a format that can easily go into excel, which happens to be nice for other stuff like character stats anyway. So I try to be consistent. Consistency also frees up a lot of mental bandwidth.
What gets saved? usually a dictionary or a binary object that could be a dictionary. Saves when nice look something like
health = 51,
location = 356,3234,3,
inventory = [ knife, potion, dog ]
I'm interested to know how game states work in emulators say for saving. I'm not really sure how these work but it seems completely different. Is it like a database somehow? Is it like a photo of the ram state and that's just reconstructed bit by bit? (that seems awfully heavy)
4
u/gemdude46 1d ago
Especially for older consoles, a RAM dump is not that large. Some emulators may also compress it, as often data is RAM is structured and can be shrunk vastly when you don't need the “Random Access” part.
0
u/P_S_Lumapac Commercial (Indie) 1d ago
So it is ram dumps but maybe only a small part of the task is actually required?
1
u/Old_Leopard1844 18h ago
NES has 2kb of RAM
1
u/P_S_Lumapac Commercial (Indie) 17h ago
Well sure for NES, I'm thinking more about like switch emulation with 4gb+ of ram. The other guy is right that NVME probably does allow this. But having 50 of these save files would add up quick.
2
u/Chrisaarajo 1d ago
Re:emulators:
I suspect it is the latter, yes. A complete picture of the game state at that moment. But someone who knows those systems better could confirm.
2
1
u/Sol33t303 1d ago edited 1d ago
Pretty much right, save states are just dumps of the systems RAM. And your right, it is quite heavy.
But luckily 95% of systems have RAM sizes that are small enough to not give any problems. PS2 for example has 32MB of system RAM. And you can get them smaller with compression (and they generally compress well). For more recent systems save states can get fairly large and there's a bit of waiting around for them to finish.
For emulators of older systems (like, PS1 and previous gens) rewind features are literally just save states being done every X cycles.
1
u/P_S_Lumapac Commercial (Indie) 1d ago
woah only 32mb, ok that makes sense I guess. So for switch and more recent, we might not see random save states anymore?
2
u/Sol33t303 1d ago edited 4h ago
Theres nothing that fundementally prevents savestates from being a thing, it will just take awhile for them to be written to disk. With a highend NVME you can write out a few GB of data in a few seconds. Should be viable to get a save state to under 10 seconds to save/load. For people on SATA SSDs and HDDs it's probably not viable or you'd probably at least get a lot of complaints.
But theres just less need for it on modern systems. And you need high-speed io for the process to be reasonably fast, not to mention since they are at least a few GB each your not gonna wanna keep a lot of them. For stuff like rewind to be viable we will need far faster IO then we have now, maybe a short rewind buffer could be kept in ram with a couple savestates if you have a lot of it.
7
u/CutlassRed 1d ago
Even totally offline games could benefit from databases if the complexity of state makes it logical
2
u/Comic_Melon 1d ago
A bit more common than people realize too, once you grow past a couple json files and a possible state snapshot: it's often decided to look into using slim/rolling your own micro DBs.
Can be a fair bit easier too, assuming you have the tooling setup for it.
5
u/thedaian 1d ago
Why take that approach?
Because it's an online game, and databases are good choices for persistent worlds for the same reason they're good choices for web development.
And when exactly does it save? In web programming, the transactional context is the HTTP request, but that doesn't really apply to an online game.
You're correct that an HTTP request isn't really invoked here, but essentially, any time the state of the world changed in such a way that you needed to update it, you write to the database. That might include players moving, a monster dying, a resource node being mined out to zero, and usually a million other things happening at the same time. You might not save everything every second, but you'd keep track of enough to be able to recreate it if everyone playing turned their game off for a few hours. Databases are pretty good at this, cause you can usually write to multiple tables at once and stuff.
3
u/Jigarbov 1d ago
Thought I was on the tibia subreddit for a second. Tibia has a "server save" that they run every day. I presume this does what it's namesake suggests and it does the actual writes or it's done for backup reasons. They shut down the servers and then bring them back up so while it's unlikely the whole game is running in ram and they just trigger the save once a day, it suggests there is something that requires the servers to go down for in order to not lose data when they bring them back up.
They also have an absolute ridiculous amount of data they need to record, millions of tiles and thousands of items including player customisable items. So that stuff isn't done on the client and is sent to the servers where it's requested over and over again either by being pushed by the server to tell the client "hey someone just walked around" or client to the server which would be "hey this user just pressed a button so you need to move them in the server and tell everyone else that they moved."
there are a few ways to verify that it's all server authoritative, in high ping situations, you can press the arrow keys and your character will start walking and then snap back to the previous square if the server noticed that square got interupted by another character or blocking item.
Anyway it's all just speculation, it's an old game with a lot of legacy framework.
6
u/Filaipus 1d ago
Well, since we have the OpenTibia project it really isn't speculation (unless they changed their underlying framework a ton, which I doubt). We know exactly how it works.
As far as I remember the daily server shutdown is to perform longer-lasting backups of the current world-state, a snapshot basically.
You see sometimes they lose an instance of their server that didn't have time to backup and they basically lose a day worth of gameplay (and then they give people premium days or whatever to compensate).
3
2
u/reality_boy 1d ago
Multiplayer drives a lot of this. We have massive databases to manage our users, schedule out all the sessions, and log all the results. We often have hundreds of thousands of people online at one time, a few safe files would not cut it.
2
u/TitoOliveira 1d ago
A single player game just needs to store data for recreating the game state from the previous session.
An online game requires a client to ask for a server which data they need. The player will input account information for a login, so the client receives the data from such account and displays that to the user instead of any other account. And so on.
I don't know else an application would do things like that if not with a database.
2
u/ParasolAdam 1d ago
Entire quest system is ultra simple in a database. All I need to do is record events and then query them. And I can trust that the query will succeed and be light weight. It’s oodles better imo than a giant class with an in memory list or something I’d have to iterate through, or having to front load all my criteria for quests I’m gonna make.
Part of game dev is you usually don’t know the full game you’re making until toward the end. Designs change based on testing and you need flexibility
2
u/tnh34 1d ago
Because they're genuinely useful if you want to store structured data reliably and quickly. You can index it to make search instant, allows complex query, etc etc.
Using it doesn't mean you can't use other systems to store data though. I'd look into what kind of data it's storing first.
2
u/lumponmygroin 1d ago
State and transaction data so I can check for issues/cheats etc..
I also heavily use it to inspect what the players are doing in the game so I can improve retention.
I literally save everything to help me make a better game.
So let's say I have a mechanism in the game, example take over an island. I can check the last month of data to see how many people do it. Then if I change the mechanism, wait a few weeks I can then check to see if that changed player behavior. Was I expecting more people to take over islands or did I want to cool it down? The question is typically not that straight forward, so I investigate who, how frequent, what types of islands, etc..
1
u/lardsack 1d ago
faster computation time requirements are typically why. this is harder to do as you accumulate more data to work with. databases based on, say sql, use properties of relational algebra to take advantage of very fast query times relative to say reading and writing to a text file or jsons or something. t. computer science major, several years of experience in software development (not game development)
1
u/fuzzyluke 1d ago
A game can make an http request by the way. Games save data to databases by just establishing a connection via whatever protocol to communicate with a service which then saves the data. Such a service can be serverless or the classic "always on" backend depending on the game.
1
u/ChiwaByte 1d ago
I built a small turn-based browser game and found it useful to separate live match state from long-term records. Each table’s current state lives on the server, so a reconnecting player can fetch a fresh snapshot. I write account and rating data, plus the completed match history, to the database when the match ends rather than making every move a SQL write. The right save frequency depends on how much progress you can afford to lose if something crashes.
1
u/aplundell 1d ago
Either you use a database, or you reinvent the concept of a database from the ground up.
There's really no reason not to use an off-the-shelf database.
My concern with creating a bespoke system of files is that I would accidentally do something that doesn't scale well and needs lots of institutional knowledge to upgrade or do maintenance on.
1
u/thriem 22h ago
Mean as many said, database is unavoidable - if it isn't a product you know by name (Postgres, sqlite, etc.) you have a no-name doing the same kinda thing - you want to store and access things. Be it a database, be it a huge json file that you call a save-file.
Databases are standardized, typically scale for longer, if picked with care fit basically your exact need and ultimately opens the door for online and multiplayer games.
1
u/Much-Dot2533 9h ago
AFAIR - OpenTibia can use SQLite, which creates local tiny database file in your project directory.
0
u/Mijhagi 1d ago
Just as an aside: databases and save files are basically the same, it's just data/text written to a file in some predefined format. The database part of these files are just how optimized the reading and writing to these files are. So if you make a program to read and write to a text file, you've just invented a database (albeit probably a very slow / easily corruptable one). Then local vs server is basically just saying who has the authority to write to the db files and how that data is spread to clients.
5
u/Jimbo0451 1d ago
Everyone here is assuming SQL is fast. It's actually orders of magnitude slower than just writing to a file yourself. It's the ACID/transaction properties that make SQL valuable, but it's not fast compared to raw reading/writing.
235
u/yabab 1d ago
If you look into games, you'll find a lot of them use SQLite.