Thinking of games as databases

When you open a container in the game, and it doesn't have a specified set of contents, the contents get loaded by picking randomly from a category linked to in the database. If, in one of the db tools, you follow the link from the container you can see what objects could load in it and by what likelihood. You can then follow those links through the db over to the object itself, which is also made up of db entries.

From the scripting system you can access the db for some amount of functionality. Their db doesn't contain the models or textures or strings. But it does contain the location of every tree in the game. If you wanted a mod with a dozen golden crates to go find, you would use the db system for the logic.

Any system that could be queried needs to be built and maintained. Creating game entities that have models of feeling or have opinions about the groups of people they belong to has to be modeled and built. Unfortunately game dev is very informationally and financially sparse so creating these systems is a huge undertaking.

I heard a joke once about OOP: if you want to create a form that accepts payment information you must first create the universe. The joke speaks to a danger of overdoing your conceptual modeling. The real trick of a true craftsperson is to create a model that is excellent at solving the problem on hand.

What I’m saying is we’re a long way away from game entities behaving like west world hosts and embracing the ECS paradigm isn’t the answer. Just like how switching from OOP to functional doesn’t actually solve creating a profitable business.

If the title was a bit more accurate to its content, it would avoid a lot of disagreements here.

"Building games with AI agents? Use a graph database." -- or something like that.

https://github.com/samsquire/ideas#71-gaming-interfaces-for-...

Even the mouse is a database https://queue.acm.org/detail.cfm?id=2169076

I want a graphical representation of the spatial properties in a database

The reason I went down this path - I was thinking about streaming gaming and how we could potentially keep 1 representation of everything in memory and service hundreds or thousands of players with the same data set. Think tables like Scenes, Entities, Viewports, etc. Big picture, I felt like you might be able to pull off something at scale with a bunch of read replicas over a big boy SQL database.

Indie Devs should be thinking of games as products to complete first and foremost. Don't get bogged down in articles like this, or what's the best tech. Just ship it.

0. https://github.com/ncannasse/castle

Seriously.

Compile a bunch of prepared statements at load time to take the parsing and execution planning out of it, keep it all in memory... On the surface it seems like it would work.

And of course, saving the entire game state would be as simple as just flushing the DB to disk.

Specifically, at least in my experience, foregrounding database thinking when making game rules tends to make it easier for designers to add more rules and rule variations, or a lot more "content" generally, that tends to be more shallow and less novel in terms of surprising interactivity.

Now, that can be a desired kind of game design! If you look at something like, say, Gran Tourismo, where the pleasure is in having hundreds of real cars modelled, that can be really enjoyable to a certain kind of player. And of course most static level data is just a giant collection of non-interactive data variations as well. There are certainly other examples.

But if you sit down with, say, the original NES Legend of Zelda, with a paper notebook in your lap, and every time you encounter a new enemy, you write down the enemy's name, what is interesting about them, and what you might have to do to implement them, what you're going to notice is that the lion's share of enemies have custom behavior and interactivity that will need to be special cased, and that that is all the meaningful work of implementing that enemy.

Now, obviously, you COULD still use something like a database as the central repository for distinguishing the identities of all of the monsters and their properties. But in practice, the property of "it gets on top of you and eats your magic shield" is only used by the Like-Likes, the property of "it grabs you and drags you back to the dungeon start" is only used by the wall hand guys, and on and on and on, and _aesthetically_ the game benefits from the fact that each interesting enemy property is only used by each unique enemy (or so I would very, very strongly argue).

I've sat down and performed that "notebook in the lap" exercise with a bunch of games in the past, with Half-Life, Castlevania:Symphony of the Night, and Mario 64 being particularly fruitful (the same exercise works for items and weapons in a game, and interactive objects in game levels as well). One of the big traits that makes SOTN the game that it is is that a fair number of the weapons and items in the game have all sorts of strange, surprising, extremely special case game code, like the Shield Rod.

My personal experience from working on game dev teams as a game programmer/designer is that, as game programmers are drawn more into database thinking as the lens for expressing game design, the kinds of sparkly, jagged, surprising rules I just gestured at start feeling more and more like violations of the architecture of the system, gumming it up and making it ugly, instead of the actual wonderful desired point of the entire enterprise of game making.

And so instead you get games where much of the variations between items or weapons or enemies are things like statistic percentage variations - this weapon has +20% critical hit chance compared to that weapon, this enemy absorbs that kind of damage, this weapon has that attack speed, this enemy has that running speed, this enemy can or can't throw grenades, and so on.

I feel like I encounter this kind of design a lot in more recent games made by large teams. And it makes sense. Often management needs tighter control over game rule possibilities because they have large teams and novel surprising custom game rules are legitimately unpredictable and hard for teams to control or reason about - especially in the context of long-lived games that are going to be maintained by lots of random people coming and going over a long time frame. Having weapons/items/enemies that vary only by properties make it easier to add or remove them to hit deadlines without breaking the critical path of the game, they're much easier to apply analytics to for balancing, and they're much easier to use as DLC without affecting games in potentially show stopping ways, too.

But there are absolutely aesthetic ramifications to this approach. At any given moment, when a player is playing a game and deciding, without consciously recognizing it, whether they're going to continue sticking with a game or whether they're bored, the question of what new kinds of new stuff they might still encounter if they keep playing is definitely a factor. And what kinds of rules a game designer can and does vary heavily affects that.