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

41–50 of 70 posts

Re: Thinking of games as databases

#41

Post by Twisol »

CyberDildonics wrote: post #9

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.

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.

Re: Thinking of games as databases

#42

Post by Loveaway »

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 it. So why not consider the advice from industry veterans and read about a few proven design patterns.

Re: Thinking of games as databases

#43

Post by corysama »

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…

Game designers really like Excel —for good reason.

I’ve set up the tech for many games over the decades where we had designers write tiny snippets of code in the cells of Excel spreadsheets. First in a custom assembly-like language (for an N64 game) then in SmallC, actual C++ and mostly in Lua.

The general theme was to use the grids to define state machines. Rows are states. Columns represent events. Cells define what to do at the intersection of an event in a certain state.

Later games also used Lua code cells as active spreadsheets in the game. The Lua statements would calculate results when queried. The charts didn’t just know about raw numbers and strings. They also could load and manipulate assets in the game. So, a designer could describe which UI asset to put next to the health bar based on the player’s current health stat without bothering a programmer or artist.

In the last case, we shipped two very different 3D mobile games using the same executable but different assets. Live hot-reloading of the Lua charts, the UI XML and all the other assets meant that we didn’t even need to bother making an editor for our custom engine. A good text editor window next to the game window was productive enough.

Re: Thinking of games as databases

#44

Post by corysama »

stevenwoo wrote: post #35
onion2k wrote: post #31

Earlier quoted context omitted.

Diablo 2 was a lot of fun. It's cool to hear about how it was made. :)

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

Re: Thinking of games as databases

#45

Post by claytongulick »

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.

Re: Thinking of games as databases

#46

Post by raincole »

doctorpangloss wrote: post #39
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.

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

> Jonathan Blow is excited about Jai. That makes him wake up every day and commit. Intellectual stimulation helps you ship.

Yes, it's a good one. Since he started working on Jai he hardly shipped any game. Thanks for providing examples that supports the parent comment.

Re: Thinking of games as databases

#47

Post by GalahiSimtam »

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?

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 interested https://en.uesp.net/wiki/Skyrim_Mod:Mod_File_Format

Re: Thinking of games as databases

#48

Post by stevenwoo »

corysama wrote: post #43
stevenwoo wrote: post #30

Earlier quoted context omitted.

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…

Game designers really like Excel —for good reason. I’ve set up the tech for many games over the decades where we had designers write tiny snippets of code in the cells of Excel spreadsheets. First in a custom assembly-like language (for an N64 game) then in SmallC, actual C++ and mostly in Lua. The general theme was to use the grids to define state machines. Rows are states. Columns represent events. Cells define wha…

As part of the push to involve the designers more in production, I made a scripting engine and language to drive the quests in Diablo 2 roughly as you describe. By the time we go close to the end, none of the designers bothered to use it (we officially only had one at our studio but many people dabbled) so for my convenience I just took it out and replaced it with a function table that was there originally, I really regret that because I imagine the unofficial mod scene would be even more amazing if I left it in. The objects and monsters worked roughly as you describe, adding new ones (without new features) meant just adding and customizing a new line in the appropriate spreadsheets.

Re: Thinking of games as databases

#50

Post by imtringued »

jstarfish wrote: post #3
Khelavaster wrote: post #2

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…

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.
Post reply on HN