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

31–40 of 70 posts

Re: Thinking of games as databases

#31

Post by onion2k »

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…

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

Re: Thinking of games as databases

#32

Post by ecshafer »

soderfoo wrote: post #24
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 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.

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.

Re: Thinking of games as databases

#33

Post by mhuffman »

soderfoo wrote: post #24
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 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.

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.

Re: Thinking of games as databases

#34

Post by golergka »

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?

Re: Thinking of games as databases

#35

Post by stevenwoo »

onion2k wrote: post #31
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…

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

Re: Thinking of games as databases

#36

Post by soderfoo »

ecshafer wrote: post #32
soderfoo wrote: post #24

Earlier quoted context omitted.

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

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.

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.

Re: Thinking of games as databases

#37

Post by arandomhuman »

seventhtiger wrote: post #16
sovietmudkipz wrote: post #10

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

Re: Thinking of games as databases

#39

Post by doctorpangloss »

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

Re: Thinking of games as databases

#40

Post by imtringued »

alpaca128 wrote: post #25
bentcorner wrote: post #15

Earlier quoted context omitted.

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.

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 machinery/tools and labor and all of this for something that the player clicks "buy" on and never looks back.
Post reply on HN