Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thinking of games as databases

ajmmertens.medium.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Thinking of games as databases

#61

Post by alpaca128 »

imtringued wrote: post #40
alpaca128 wrote: post #25

Earlier quoted context omitted.

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 thousand…

The problem is that this is hard. Just think about how game engines consist of a graphics engine and a physics engine. You would need various other engines that can just be plugged in. A realistic economy requires a complicated supply chain for example. This means just so your NPC vendors can sell a sword, you would have natural resources that can be extracted, manufacturing processes that require inputs and machiner…

This problem has been solved many times, for example the goal-oriented action planning method allows dynamic behaviour and real games have implemented this. But you are correct in that this means more effort for developers and doesn't sell more lootboxes.

Re: Thinking of games as databases

#62

Post by stuckinhell »

Loveaway wrote: post #42
stuckinhell wrote: post #22

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.

Sure, the mission should always be: shipping fun profitable products. Doesn't hurt have solid code architecture from the get go though. From what I understand ECS are very flexible and probably your best bet. It's often hard to see where a game is headed, which can turn thoughtless code very ugly very fast. Still, many games get shipped like that, but if you're in for the long run you'll eventually have to maintain i…

Absolutely, however game developer forums, discords, etc are full of people who obsess over the "ideal" way to do things rather than ship their game and go bankrupt or destroy their lives doing it.

So it's extremely common polite etiquette in the indie game developer to remind people that the end goal is a fun product that you can sell. Many many people lose a ton of money during indie game dev, and it's always a tragedy.

If you want to use a no code tool like playmaker over coding, then do it. As long as you ship the code. Just keep shipping out your game.

Re: Thinking of games as databases

#63

Post by stevenwoo »

corysama wrote: post #44
stevenwoo wrote: post #35

Earlier quoted context omitted.

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…

If you are ever in the mood to do an unstructured brain dump of superfluous memories, https://old.reddit.com/r/TheMakingOfGames/ would love to read it :)

Thanks, I did a quick search and found alot from whom should be considered the uber sources of information about Diablo development, David Brevik and Erich Shaeffer. I was just in the trenches for Diablo 2. One thing I remember about the crunch per David's piece on crunch, he neglected to mention that when he gave a speech announcing we would crunch until we finished, and if we finished in time for holiday release that year the entire studio would get a free trip to Las Vegas, or we would get fired. Kelly Johnson, a character artist was standing near me during the meeting and mumbled something under his breath but I don't think anyone thought we would generate the content required for that deadline, but I believe he had to give a speech about it I'm guessing for appearances' sake.

Re: Thinking of games as databases

#64

Post by phaedrus »

opyate wrote: post #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

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.

Re: Thinking of games as databases

#65

Post by riksteri »

stevenwoo wrote: post #30
onion2k wrote: post #14

They're more like spreadsheets than databases.

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…

It was very nice how you let users edit those data files, enabling mods. I started my game development career by editing those same spreadsheets.

Naturally, my own games also use user-editable data files. Sometimes very similar spreadsheets, borrowing the structure from you. Paying it forward.

Thanks for Diablo II.

Re: Thinking of games as databases

#66

Post by SanderMertens »

GalahiSimtam wrote: post #47
golergka wrote: post #34

Earlier quoted context omitted.

This is fascinating. Where can I read more about this architecture?

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#... : 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 i…

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

Re: Thinking of games as databases

#67

Post by mtreis86 »

golergka wrote: post #34
mtreis86 wrote: post #4

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

This is fascinating. Where can I read more about this architecture?

Start here https://tes5edit.github.io/docs/15-tutorials.html

Re: Thinking of games as databases

#68

Post by seventhtiger »

stuckinhell wrote: post #23
seventhtiger wrote: post #16

Earlier quoted context omitted.

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

I don't think "gamers" or the general population agree with your definition on true games. Nintendo single player games are often considered the gold standard of games in different genres. Mario, Zelda, Pokemon are all household names. I do think your points were interesting, so thanks for sharing!

Maybe I focused too much on the terms. They certainly don't think of the word puzzle, but they do treat them as that.

Someone playing Zelda doesn't go into it ever expecting Ganondor to try to win. The player either solves the game, or they stop playing. But they can't lose, which is why I called it a puzzle.

In comparison to something like Chess AI where the computer agent is actually trying to win and make you lose.

So you'd find players asking whether it's single or multiplayer and competitive or casual and so on and they're really trying to place the game in that categorization. Is this game just a series of challenges for me, or are there opponent agents trying to win.

Re: Thinking of games as databases

#69

Post by seventhtiger »

arandomhuman wrote: post #37
seventhtiger wrote: post #16

Earlier quoted context omitted.

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

Most single player games are not "true games". They are puzzles. This is also how players perceive them. This is definitely news to me, I have not ever met someone who feels this way who plays videogames.

I put that in quotes because I didn't want to emphasize the terminology but maybe it didn't work. Whatever they call them, players treat games with equal opponents who can win, and games that are only a series of challenge entirely differently. The issue I'm talking about is developers trying to insert competitive agents into games which gamers expect to be a series of challenges.

Re: Thinking of games as databases

#70

Post by ajmmertens »

claytongulick wrote: post #60
kitd wrote: post #58

Earlier quoted context omitted.

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.

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?

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

Post reply on HN