Hacker News new | ask | show | jobs
by TeMPOraL 730 days ago
This. In my testing some years ago, trying to make a basic Roguelike game with the state stored entitely in SQLite, the in-memory db could support reading the visible portion of the map and positions of entities at 60 FPS with time to spare, on a modest machine, and with slight FFI penalty as the code was written in Common Lisp (SBCL). So while you may not want to do this for a first-person shooter, there are many types of games that could in fact live entirely in SQLite, save for some transient visual FX.
1 comments
semi 730 days ago
I'm pretty far removed from game dev but curious.. is the in mem sqlite DB the only representation of game state or is it just 'mirroring' the 'real' values in ram? like if there's a Score on the HUD, are you doing a SQL select to read the value on every frame?

Or is this just a way to serialize and deserialization the game state to automatically save the game so it could be reloaded if it closed/crashed without explicitly running a 'save game' function?

link
TeMPOraL 730 days ago
> if there's a Score on the HUD, are you doing a SQL select to read the value on every frame?

Yes. That was the point of my experiments, after I realized that good chunks of the data structures I set up for my game look suspiciously similar to indices and materialized views. So I figured, why waste time reinventing them poorly, when I could use a proper database for it, and do something silly in the process?

In a way, it's also coming back to the origin of the ECS pattern. The way it was originally designed, in MMO space, the entity was a primary key into component tables, and systems did a multiple JOIN query.

link
nathanfries 730 days ago
I followed this line of thinking last week due to curiosity w.r.t ECS & SQLite. I found that the bottleneck was not on the reads, but on the complexity of the writes (iterating each entity and subsequently you have num_systems X num_components writes). You can actually avoid this entirely if you write your systems in SQL.

Since I had already thrown out logic & reason for the sake of curiosity, I took it a step further and learned that the Bun JS runtime actually has SQLite baked in, which allows you to create a :memory: db that can be accessed _synchronously_ avoiding modification of most ECS implementations. (I'm not familiar with the larger SQLite ecosystem, but being a largely TS developer this was very foreign to me)

link