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

51–60 of 70 posts

Re: Thinking of games as databases

#51

Post by [deleted] »

raincole wrote: post #46
doctorpangloss wrote: post #39

Earlier quoted context omitted.

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

[deleted]

Re: Thinking of games as databases

#52

Post by adamrezich »

raincole wrote: post #46
doctorpangloss wrote: post #39

Earlier quoted context omitted.

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

> Since he started working on Jai he hardly shipped any game.

why do you perceive this as a problem?

Braid: 2008

The Witness: 2016

Braid Anniversary Edition (Jai): late 2023

Untitled Sokoban Game (Jai): TBA

also, Jai, even in its incomplete state, is a fantastic product.

Re: Thinking of games as databases

#53

Post by doctorpangloss »

raincole wrote: post #46
doctorpangloss wrote: post #39

Earlier quoted context omitted.

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

> Since he started working on Jai he hardly shipped any game.

That's an opinion. Maybe if you looked closer, you'd see: if it weren't intellectually interesting, he wouldn't ship any games, as opposed to a bunch of really cool and fun ones.

I can only speak personally. As a game designer, I have never regretted "not" "shipping." Spending the time on design instead, I feel my opinions are far more valued by my design and directing customers, who have bigger budgets and thus will have automatically greater success marketing, polishing, "shipping," etc. anyway.

If you think you need to ship in order to find out if something is fun... well, there's your problem. What do you think game design is, an A/B test?

In contrast, my former colleagues who emphasized shipping, in the last decade, they have spent 100-10,000x the budgets on putting kind of dull stuff into the App Store. And it was only marginally more stuff.

Anyway, I wouldn't ever ask them for an opinion about game design, or whether a prototype is going to be fun, but I would ask Jonathan Blow, so there's that.

Re: Thinking of games as databases

#54

Post by afiori »

i_c_b wrote: post #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 surprisi…

I have no expertise in this field but from what I gather many of these special cases (like the Like-Like eating your equipment) is a new component type on the enemy entity in an ECS architecture.

Re: Thinking of games as databases

#55

Post by afiori »

CyberDildonics wrote: post #19
jstarfish wrote: post #3

Earlier quoted context omitted.

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.

On the other hand gears, wheels, and fans are all wheels.

Re: Thinking of games as databases

#56

Post by sdwr »

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.

Re: Thinking of games as databases

#57

Post by sdwr »

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…

That's the dream! Live hot-loading and a text file. I was working on a Lua game a while back, and the feedback loop, although way faster than enterprise development, still got me bogged down when it came to balancing. I was using hardcoded tables for unit stats, and it's a surprising amount of mental overhead to go back and forth tweaking those.

Re: Thinking of games as databases

#58

Post by kitd »

claytongulick wrote: post #45

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.

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.

Re: Thinking of games as databases

#59

Post by raincole »

adamrezich wrote: post #52
raincole wrote: post #46

Earlier quoted context omitted.

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

> Since he started working on Jai he hardly shipped any game. why do you perceive this as a problem? Braid: 2008 The Witness: 2016 Braid Anniversary Edition (Jai): late 2023 Untitled Sokoban Game (Jai): TBA also, Jai, even in its incomplete state, is a fantastic product.

A remaster of an old game in 7 years. So yeah, "hardly shipped any game".

> why do you perceive this as a problem?

It's probably not a problem for him. It's not a problem for you either, if your studio can afford spending 7 years on a tool that doesn't generate cash flow.

Again I have nothing against Blow. But it's a very good example about how much time it takes to make your own tool chain, even for someone who's smart and experienced. For most of us, we'd better utilize boring techs to ship lowkey fun games.

Re: Thinking of games as databases

#60

Post by claytongulick »

kitd wrote: post #58
claytongulick wrote: post #45

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.

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?

Post reply on HN