Live data from Hacker News

Thinking of games as databases

ajmmertens.medium.com

11–20 of 70 posts

Re: Thinking of games as databases

#11

Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade. 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 financial…

Exactly, there is no point in the system being "intelligent" and "emergent" for the sake of it, if the gameplay is buggy or boring.

Re: Thinking of games as databases

#12
I've played around with using SQLite to store the scene graph for a game and using SQL to query/manipulate it. Very elegant and interesting ideas start to emerge, but performance quickly becomes a monster problem even if you run it in-memory. For simpler scenes, it definitely works though.

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.

Re: Thinking of games as databases

#15

Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade. 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 financial…

Exactly, there is no point in the system being "intelligent" and "emergent" for the sake of it, if the gameplay is buggy or boring.

Thinking back to the example in the article, there's no reason why the game designer can't just script in a player ambush, since it's a plausible thing to have happen next. I don't think you need any kind of "game intelligence" to tell a compelling story.

Re: Thinking of games as databases

#16

Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade. 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 financial…

There's a solid game design framework underlying that choice, beyond just being smoke and mirrors.

Most single player games are not "true games". They are puzzles. This is also how players perceive them.

As defined by Chris Crawford a game requires competition. Multiple agents who play, which creates the possibility of win and loss.

In most single player games, the game agents are not equal competitors who can win. They are only obstacles and challenges for the player. Even if the game is built with difficulty in mind.

So the mistake of thinking of actually intelligent game agents is like thinking why doesn't the Rubik cube ever win. It's not why someone plays it.

Notable exceptions are where software is used to substitute a player in a multiplayer game, where they do usually maintain the game structure and compete.

Re: Thinking of games as databases

#17
There are serious aesthetic ramifications for running with the idea of games (and especially game rules) as being primarily composed of databases.

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.

Re: Thinking of games as databases

#18

Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade. 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 financial…

The researchers behind the project have since moved on, but the idea of a db underpinning a game engine came up over a decade ago in Walker White's work at Cornell. Unsurprisingly, there's a whole lot of ways in which expertise from the db community can be commoditized to allow game devs to focus on the game, rather than hand optimizing code. For example, query optimizers can make it easier to scale up complex agent behaviors [0]. The project also spawned some interesting work on checkpointing, distributed replication, and computation over uncertain state.

https://www.cs.cornell.edu/~wmwhite/papers/2007-SIGMOD-Games...

Re: Thinking of games as databases

#19

This is the essence of MVC/MVP architecture!

When I first tried to learn ECS (recently!), I couldn't wrap my mind around how arcane it seemed to be. What "components" should there be? What properties should each Component track? How do I organize it? What if I move things around? I have to write handlers that load and unload the damn things, and a System that somehow knows where to find certain properties on the various Components enough to operate on them? Exa…

When you reinvent the wheel you can't call it the wheel or people will know it isn't new. 'Entity component' makes no sense for being a kind of spreadsheet, but at the very least it is a good approach to the problem. It should have been called 'state tables' or something like that.

Re: Thinking of games as databases

#20
Haxe has CastleDB [0], which I've used once, and it's great (it only powers your game assets statically, and isn't written to during gameplay, or used by the running game itself (I think)). (On Godot now, so mostly using Resources, which can be structured data on steroids.)

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

Post reply on HN