11 ms·

Thinking of games as databases

99 points by ibobev 3y ago

Khelavaster 3y ago
This is the essence of MVC/MVP architecture!
- jstarfish 3y ago
  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? Examples were always pretty esoteric or contrived. Didn't help that they were all written in C++. One day it clicked that this revolutionary idea sure looks a lot like a series of queries/views ("Systems") on a bunch of database tables ("Components") foreign-keyed to a single object ID ("Entities"). Some people can overcomplicate anything...
  - CyberDildonics 3y ago
    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.
    - afiori 3y ago
      On the other hand gears, wheels, and fans are all wheels.
  - imtringued 3y ago
    I once wrote an ECS for a game and it was literally a database without WHERE clauses (write your own if statements, indexes are too expensive). Each component was a table and your systems used left joins or inner joins to query the tables. The join algorithm was quite simple as well. Just a binary search to find the next element by its ID.
mtreis86 3y ago
The backend of Skyrim (and other Bethesda games) is largely a database. Bethesda calls them .esp files, but they're relational in a way. There has been a large open undertaking to produce tooling for this, such as xedit (Pascal) and z-edit (JS). 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.
- golergka 3y ago
  This is fascinating. Where can I read more about this architecture?
  - GalahiSimtam 3y ago
    In the context of the OP article, a similar functionality to querying a database is "Find matching references" kind of quest alias filling https://www.creationkit.com/index.php?title=Quest_Alias_Tab#Fill_Type https://www.creationkit.com/index.php?title=Quest_Alias_Tab#...: However it is not 100% documented what kind of optimization this "query engine" has implemented, there are some vibes that sometimes it could be faster than a full scan. A serialized data format is here if you are interested https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format
    - SanderMertens 3y ago
      Author here: I’m working on another post that describes the inner workings of the query engine in depth! It’s definitely faster than a full scan ;) In case anyone’s interested, this is the source for it: https://github.com/SanderMertens/flecs/tree/master/src/addons/rules https://github.com/SanderMertens/flecs/tree/master/src/addon...
pjc50 3y ago
Well, yes. Anything with "stats" or "inventory" looks very much like a database to me. This kind of thinking could also help avoid the risk of object-duplication bugs that occur in games which haven't been entirely rigorous about transactions.
- alpaca128 3y ago
  Like the good old Dark Souls glitch that lets players drop a negative amount of items or consume a single item multiple times if triggered from some graphics options menu.
KevinChen6 3y ago
Of course, a game is a virtual world, and the player's behavior in this virtual world can express his inner thoughts to a certain extent, including good and malice, and some sociologists have conducted sociological research through the player's behavior in games.
- CyberDildonics 3y ago
  What does this have to do with game state being a database?
xwdv 3y ago
If you use an entity component system then you’re basically already there.
samsquire 3y ago
In 2013 I wrote about "game interfaces for work" where work interfaces should act like games. Real time strategy games make you feel empowered, if you could queue up real work in a units runqueue. Of course you'll have actions besides "build" and "attack" to map to the richness of the world. https://github.com/samsquire/ideas#71-gaming-interfaces-for-work https://github.com/samsquire/ideas#71-gaming-interfaces-for-... Even the mouse is a database https://queue.acm.org/detail.cfm?id=2169076 https://queue.acm.org/detail.cfm?id=2169076 I want a graphical representation of the spatial properties in a database
CyberDildonics 3y ago
Any time you put data somewhere, organize it and give it an interface for efficient retrieval you have a database. Game state, generic data structures and practically an organization of data in software can be thought of the same way, so this is not exactly any sort of revelation.
- Twisol 3y ago
  The thing about a "database", relative to any other assembly of data, is that it typically has a universal query system whose particulars are not dependent on the schema of the data you're querying over. This is pretty much the focus of this article.
sovietmudkipz 3y ago
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 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.
- the_gipsy 3y ago
  Exactly, there is no point in the system being "intelligent" and "emergent" for the sake of it, if the gameplay is buggy or boring.
  - bentcorner 3y ago
    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.
    - alpaca128 3y ago
      It depends on what kind of game you want. In many games scripted events are fine, but a game like Skyrim would feel much more alive if NPCs could do more than walk back and forth all day. In those cases scripting becomes a lot of work very quickly - the Mass Effect series had a lot of different outcomes based on player choices, in the end the final game was disappointingly linear and predictable and handling thousands of possibilities turned out to be a bit much. Immersive game worlds could use a lot of improvements.
bob1029 3y ago
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.
deleted 3y ago
[deleted]
onion2k 3y ago
They're more like spreadsheets than databases.
- dmd 3y ago
  found the Eve Online player
- stevenwoo 3y ago
  This brings back the memory of how we used Microsoft Excel to generate the .csv files to drive the game engine in Diablo 2 and stored the .xls files in version control, by the time we started work of production on the expansion we only needed about 3 of the 10 programmers (at our studio) to support the work because most of changes could be done by adding lines to the spreadsheets. This might sound rote today but the original, Diablo 1, had a bunch of hardcoded tables in the source code. I still used the Diablo 1 source code as a starting point for a lot of stuff, though. :)
  - onion2k 3y ago
    Diablo 2 was a lot of fun. It's cool to hear about how it was made. :)
    - stevenwoo 3y ago
      Here's more useless trivia, my brain is cluttered with superfluous memories, I can't remember every algorithm but I remember the minutiae. I remember our producer Matt Householder telling me the bad experiences they had outsourcing the development of Diablo 1 expansion and ports meant they really wanted to make the Diablo 2 expansion in house. So at one point early in production on Diablo 2, our lead programmer, Rick Seis, had the .csv importing functionality as his primary task which seemed kind of mundane even at the time and now probably standard in most language libraries, and we transformed the Diablo 2 hard coded tables ( we were mostly following Dave Brevik's examples in Diablo 1!) into Excel spreadsheets. Then afterwards Peter Hu was on an optimization crusade towards the end, he made a .csv binary compacter/reader to save runtime.
i_c_b 3y ago
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.
opyate 3y ago
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 https://github.com/ncannasse/castle
- phaedrus 3y ago
  I didn't know about CastleDB. The fact it uses JSON to store the DB data and schema itself is a nice feature. I've been using Sqlite for a similar purpose to store structured data and load configuration, but the biggest downside is having configuration in a .db file that's a binary blob doesn't play nice with Git or other source control.
stuckinhell 3y ago
This kind of approach maybe good for very big companies, but it absolutely kills small companies and indie devs. 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.
- soderfoo 3y ago
  > Indie Devs should be thinking of games as products to complete first and foremost. Large studios should keep this in mind as well. Lately, the trend seems to be: live service is 100% at release, core game play and narrative are wanting.
  - ecshafer 3y ago
    AAA studios have shipped a lot of games with broken online services, gameplay, matchmaking, etc. No AAA studio has ever shipped with a broken cash shop. Its all about priorities.
    - soderfoo 3y ago
      Sadly, there is no shortage of folks willing to hand over their money. In my experience and based on convos with friends at other studios, good producers (product owners) are hard to come by. Of course devs would pin the blame on ops/production, but I think it's a really interesting problem that has plagued studios of all shapes and sizes.
  - mhuffman 3y ago
    Well, I mean, software in general is one of the only items I can think of where you can intentionally sell someone something that is broken and promise to fix it in the future if they keep paying you, otherwise make it unusable for them.
- doctorpangloss 3y ago
  > Indie Devs should... Just ship it. "Make games that are fun to make." Sometimes that means "thinking of games as databases." 100s of games released every day across Steam and the App Store. Who cares? I guess they shipped, but then what? > Don't get bogged down in articles like this, or what's the best tech. Jonathan Blow is excited about Jai. That makes him wake up every day and commit. Secularly Jai will not make the game better. But intellectual stimulation helps you ship. So your advice is a negative sign in front of the right answer: it's pithy and simple, but it's 200% wrong. It's so far off the mark and so steeped into the exact kind of hustlebro culture that is responsible for the 100:1 ratio of bad games to good. > ...maybe good for very big companies Big companies struggle to innovate. They worry way too much about shipping, deadlines, whatever. So they wind up with the least risky and conservative game design. They are interested in deep tech because, if you're making the 100th CS:GO clone, it makes the work intellectually stimulating enough to make you wake up every day and grind 65h/wk for Riot's garbage pay, not just because it makes some kind of secular sense.
ignitionmonkey 3y ago
The title is misleading. Most large enough games do use databases in some form, just like a lot of software. 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.
throwaway290 3y ago
Anyone knows how DF does it?
claytongulick 3y ago
I wonder how well SQLite would just handle this whole thing. 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.
- kitd 3y ago
  One of the reasons for using an ECS is cache coherence. All your game state is lumped together in one chunk or memory. Lookup times are near instant as a result. Moving to SQLite makes theoretical sense, but you lose the benefit of cache coherence as a result. Though you probably do gain other benefits.
  - claytongulick 3y ago
    I'm not familiar with the guts of SQLite enough to say, but wouldn't this be true for an in-memory database too, if you structured the "tables" properly? Also, I'm not sure I understand how cache coherence would be relevant in the context of what the article is discussing, querying across all game entities to answer complex questions. Wouldn't cache coherence matter more in the case of single object access?
    - ajmmertens 3y ago
      The query engine works on top of an Entity Component System (ECS) storage that stores entities and their data in cache coherent (SoA - https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA) data structures. With any kind of database - even in-memory SQLite - there is a query interface between you and the data. In ECS you access data directly, which is at least an order of magnitude faster.
nayuki 3y ago
The title makes me think of "MySQLgame - a game that just is a database" https://news.ycombinator.com/item?id=5964816 https://news.ycombinator.com/item?id=5964816 , https://hackaday.com/2008/08/23/mysqlgame-playing-with-database-queries/ https://hackaday.com/2008/08/23/mysqlgame-playing-with-datab... . I think it's no longer being hosted.
sdwr 3y ago
Been playing Dyson Sphere Program lately. It's quite well-optimized (not quite MGS5-level, but pretty damn good!). Would love to know what performance savers they do under the hood. My guess is they are hard in the data-driven direction.

99 points by ibobev 3y ago

Khelavaster 3y ago

This is the essence of MVC/MVP architecture!

jstarfish 3y ago
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? Examples were always pretty esoteric or contrived. Didn't help that they were all written in C++. One day it clicked that this revolutionary idea sure looks a lot like a series of queries/views ("Systems") on a bunch of database tables ("Components") foreign-keyed to a single object ID ("Entities"). Some people can overcomplicate anything...
- CyberDildonics 3y ago
  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.
  - afiori 3y ago
    On the other hand gears, wheels, and fans are all wheels.
- imtringued 3y ago
  I once wrote an ECS for a game and it was literally a database without WHERE clauses (write your own if statements, indexes are too expensive). Each component was a table and your systems used left joins or inner joins to query the tables. The join algorithm was quite simple as well. Just a binary search to find the next element by its ID.

mtreis86 3y ago

The backend of Skyrim (and other Bethesda games) is largely a database. Bethesda calls them .esp files, but they're relational in a way. There has been a large open undertaking to produce tooling for this, such as xedit (Pascal) and z-edit (JS). 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.

golergka 3y ago
This is fascinating. Where can I read more about this architecture?
- GalahiSimtam 3y ago
  In the context of the OP article, a similar functionality to querying a database is "Find matching references" kind of quest alias filling https://www.creationkit.com/index.php?title=Quest_Alias_Tab#Fill_Type https://www.creationkit.com/index.php?title=Quest_Alias_Tab#...: However it is not 100% documented what kind of optimization this "query engine" has implemented, there are some vibes that sometimes it could be faster than a full scan. A serialized data format is here if you are interested https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format
  - SanderMertens 3y ago
    Author here: I’m working on another post that describes the inner workings of the query engine in depth! It’s definitely faster than a full scan ;) In case anyone’s interested, this is the source for it: https://github.com/SanderMertens/flecs/tree/master/src/addons/rules https://github.com/SanderMertens/flecs/tree/master/src/addon...

pjc50 3y ago

Well, yes. Anything with "stats" or "inventory" looks very much like a database to me. This kind of thinking could also help avoid the risk of object-duplication bugs that occur in games which haven't been entirely rigorous about transactions.

alpaca128 3y ago
Like the good old Dark Souls glitch that lets players drop a negative amount of items or consume a single item multiple times if triggered from some graphics options menu.

KevinChen6 3y ago

Of course, a game is a virtual world, and the player's behavior in this virtual world can express his inner thoughts to a certain extent, including good and malice, and some sociologists have conducted sociological research through the player's behavior in games.

CyberDildonics 3y ago
What does this have to do with game state being a database?

xwdv 3y ago

If you use an entity component system then you’re basically already there.

samsquire 3y ago

In 2013 I wrote about "game interfaces for work" where work interfaces should act like games. Real time strategy games make you feel empowered, if you could queue up real work in a units runqueue. Of course you'll have actions besides "build" and "attack" to map to the richness of the world. https://github.com/samsquire/ideas#71-gaming-interfaces-for-work https://github.com/samsquire/ideas#71-gaming-interfaces-for-... Even the mouse is a database https://queue.acm.org/detail.cfm?id=2169076 https://queue.acm.org/detail.cfm?id=2169076 I want a graphical representation of the spatial properties in a database

CyberDildonics 3y ago

Any time you put data somewhere, organize it and give it an interface for efficient retrieval you have a database. Game state, generic data structures and practically an organization of data in software can be thought of the same way, so this is not exactly any sort of revelation.

Twisol 3y ago
The thing about a "database", relative to any other assembly of data, is that it typically has a universal query system whose particulars are not dependent on the schema of the data you're querying over. This is pretty much the focus of this article.

sovietmudkipz 3y ago

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 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.

the_gipsy 3y ago
Exactly, there is no point in the system being "intelligent" and "emergent" for the sake of it, if the gameplay is buggy or boring.
- bentcorner 3y ago
  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.
  - alpaca128 3y ago
    It depends on what kind of game you want. In many games scripted events are fine, but a game like Skyrim would feel much more alive if NPCs could do more than walk back and forth all day. In those cases scripting becomes a lot of work very quickly - the Mass Effect series had a lot of different outcomes based on player choices, in the end the final game was disappointingly linear and predictable and handling thousands of possibilities turned out to be a bit much. Immersive game worlds could use a lot of improvements.

bob1029 3y ago

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.

deleted 3y ago

[deleted]

onion2k 3y ago

They're more like spreadsheets than databases.

dmd 3y ago
found the Eve Online player
stevenwoo 3y ago
This brings back the memory of how we used Microsoft Excel to generate the .csv files to drive the game engine in Diablo 2 and stored the .xls files in version control, by the time we started work of production on the expansion we only needed about 3 of the 10 programmers (at our studio) to support the work because most of changes could be done by adding lines to the spreadsheets. This might sound rote today but the original, Diablo 1, had a bunch of hardcoded tables in the source code. I still used the Diablo 1 source code as a starting point for a lot of stuff, though. :)
- onion2k 3y ago
  Diablo 2 was a lot of fun. It's cool to hear about how it was made. :)
  - stevenwoo 3y ago
    Here's more useless trivia, my brain is cluttered with superfluous memories, I can't remember every algorithm but I remember the minutiae. I remember our producer Matt Householder telling me the bad experiences they had outsourcing the development of Diablo 1 expansion and ports meant they really wanted to make the Diablo 2 expansion in house. So at one point early in production on Diablo 2, our lead programmer, Rick Seis, had the .csv importing functionality as his primary task which seemed kind of mundane even at the time and now probably standard in most language libraries, and we transformed the Diablo 2 hard coded tables ( we were mostly following Dave Brevik's examples in Diablo 1!) into Excel spreadsheets. Then afterwards Peter Hu was on an optimization crusade towards the end, he made a .csv binary compacter/reader to save runtime.

i_c_b 3y ago

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.

opyate 3y ago

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 https://github.com/ncannasse/castle

phaedrus 3y ago
I didn't know about CastleDB. The fact it uses JSON to store the DB data and schema itself is a nice feature. I've been using Sqlite for a similar purpose to store structured data and load configuration, but the biggest downside is having configuration in a .db file that's a binary blob doesn't play nice with Git or other source control.

stuckinhell 3y ago

This kind of approach maybe good for very big companies, but it absolutely kills small companies and indie devs. 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.

soderfoo 3y ago
> Indie Devs should be thinking of games as products to complete first and foremost. Large studios should keep this in mind as well. Lately, the trend seems to be: live service is 100% at release, core game play and narrative are wanting.
- ecshafer 3y ago
  AAA studios have shipped a lot of games with broken online services, gameplay, matchmaking, etc. No AAA studio has ever shipped with a broken cash shop. Its all about priorities.
  - soderfoo 3y ago
    Sadly, there is no shortage of folks willing to hand over their money. In my experience and based on convos with friends at other studios, good producers (product owners) are hard to come by. Of course devs would pin the blame on ops/production, but I think it's a really interesting problem that has plagued studios of all shapes and sizes.
- mhuffman 3y ago
  Well, I mean, software in general is one of the only items I can think of where you can intentionally sell someone something that is broken and promise to fix it in the future if they keep paying you, otherwise make it unusable for them.
doctorpangloss 3y ago
> Indie Devs should... Just ship it. "Make games that are fun to make." Sometimes that means "thinking of games as databases." 100s of games released every day across Steam and the App Store. Who cares? I guess they shipped, but then what? > Don't get bogged down in articles like this, or what's the best tech. Jonathan Blow is excited about Jai. That makes him wake up every day and commit. Secularly Jai will not make the game better. But intellectual stimulation helps you ship. So your advice is a negative sign in front of the right answer: it's pithy and simple, but it's 200% wrong. It's so far off the mark and so steeped into the exact kind of hustlebro culture that is responsible for the 100:1 ratio of bad games to good. > ...maybe good for very big companies Big companies struggle to innovate. They worry way too much about shipping, deadlines, whatever. So they wind up with the least risky and conservative game design. They are interested in deep tech because, if you're making the 100th CS:GO clone, it makes the work intellectually stimulating enough to make you wake up every day and grind 65h/wk for Riot's garbage pay, not just because it makes some kind of secular sense.

ignitionmonkey 3y ago

The title is misleading. Most large enough games do use databases in some form, just like a lot of software. 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.

throwaway290 3y ago

Anyone knows how DF does it?

claytongulick 3y ago

I wonder how well SQLite would just handle this whole thing. 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.

kitd 3y ago
One of the reasons for using an ECS is cache coherence. All your game state is lumped together in one chunk or memory. Lookup times are near instant as a result. Moving to SQLite makes theoretical sense, but you lose the benefit of cache coherence as a result. Though you probably do gain other benefits.
- claytongulick 3y ago
  I'm not familiar with the guts of SQLite enough to say, but wouldn't this be true for an in-memory database too, if you structured the "tables" properly? Also, I'm not sure I understand how cache coherence would be relevant in the context of what the article is discussing, querying across all game entities to answer complex questions. Wouldn't cache coherence matter more in the case of single object access?
  - ajmmertens 3y ago
    The query engine works on top of an Entity Component System (ECS) storage that stores entities and their data in cache coherent (SoA - https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA) data structures. With any kind of database - even in-memory SQLite - there is a query interface between you and the data. In ECS you access data directly, which is at least an order of magnitude faster.

nayuki 3y ago

The title makes me think of "MySQLgame - a game that just is a database" https://news.ycombinator.com/item?id=5964816 https://news.ycombinator.com/item?id=5964816 , https://hackaday.com/2008/08/23/mysqlgame-playing-with-database-queries/ https://hackaday.com/2008/08/23/mysqlgame-playing-with-datab... . I think it's no longer being hosted.

sdwr 3y ago

Been playing Dyson Sphere Program lately. It's quite well-optimized (not quite MGS5-level, but pretty damn good!). Would love to know what performance savers they do under the hood. My guess is they are hard in the data-driven direction.