So a little while ago I mentioned that I was finding I’ll need to write a proper database system to manage the data I’m storing (and adding) to Colonies. An example of this is with making buildings useful. As it currently stands, to the game, every building is exactly the same with the same meaning, use, upkeep, and cost. Adding variety in becomes an issue because even as things currently stand, Colonies doesn’t know how to save building data.
In order for the server to save something, I have to tell it “hey, get all of these, put them here, in this form, at this place, and save it” which doesn’t sound -too- bad, but if I mess up even one entry being saved, that might ruin the whole database and that’s just no good. Another issue, which may initially sound good, is that I can save very odd data into the backups, or the sources of data may be anywhere in the server’s state. I can currently grab some information from the user, some from some state information the server runs on, some from the map, and throw it all together. Change one of those things and I may inadvertently break saving. Throw the wrong data in? Possible to code and something I don’t want to play with.
Forcing myself to use a centralized storage for Colonies’ data lets me do a few things that help with this. First, it internally stores the information how it wants. It doesn’t care how it’s given, it just guarantees that when I tell it to save “the quick Brown fox Jumped over the lazy dog” I will get exactly that back when I ask for it. This lets me save the data however I feel is most effective, and disregard the contents of what I’m saving so long as I preserve that guarantee of sameness.
So, reexamining the costs of adding variety to Colonies with a nice system to store the data:
- Adding things becomes a different issue. Instead of “what should store this data”, it becomes “how does this data sensibly fit with what else is already present?”
- Saving things becomes trivial. database.backup(), the server is done. There’s no mucking with -what- is being saved, the database knows where it is, how to access it, and how to save it safely.
- Getting data in the game is more consistent. I no longer ask “what hashmap held that information again..?”, but instead look up which table held the relevant information and what field it is. I can name anything to be anything because it doesn’t clutter up the names of used variables.
But on the downside I lose one thing that I greatly appreciate.
Compile-time error checking on data use.
By this I find (very quickly) that I mistyped “usreMap”, the compiler doesn’t know what “usreMap” is, and it tells me. I say “Oh! Mistyped, meant userMap”, fix it, and everything’s great.
But since all the data fields are built when the program is run, the compiler can’t tell when I did and didn’t mean database.getString(“Usre”, “Iximeow”, “Username”), it’s all just values it’ll handle however it wants. I can sort of fix that by redefining “User” as a particular string on its own, which the compiler can check, but it’s still some extra work.
Anyway, that got a bit rambly. I’m talking about this because over the past few days I have in fact written that database code. And it works! I’m still working on integrating it with Colonies, but the first priority right now is making the chat system work. The daunting task of how to save the chat server’s information nicely is taken care of by the database. Input/output is just relayed by the Colonies server (for now, I’ll separate it out later on but piggybacking it is easiest to make it run now), and the only real logic is deciding who gets what messages. I might even have it usable between arbitrary players by Friday evening!