As of late 2024 I’ve been incrementally teaching myself how to do this Rust Language coding thing and it has somehow started to emerge as a game. My first love is and will always be words, tho, so here begins many, many words on the topic of building a game from scratch.

So.

Thing is, as of this week my efforts have come full circle.

Kinda.

An early attempt to build a game tick time loop was a factor of trying to create a series of nested loops that managed random things in a database. It would count off the seconds and if sufficient time had passed it would tell the database to +1 to the age of a game object —the game is about running a little [redacted] and [redacted] exists [redacted] but age consistently across all [redacted] blah blah—I’ll explain it more as we go, later. Needless to say I was leaning pretty heavily into the database design as an active tool to manage all my game variables all the time, including during the current screen gameplay.

That was silly.

So I started learning about this game engine called Bevy.

Bevy handles all sorts of things. Or, essentially, it wraps all the regular pieces you would use—should use—for a game into objects that are then managed by the game engine. This means it can spawn a player and a board and objects and they can exist as virtual game pieces, but also as things that can display on the screen or whatever. It’s all neat and tidy.

I wrote a bunch of code to use a bunch of array data, essentially an x and y grid of tiles that maps out a player area in the game. I call these simply, obviously rooms. A room can be something like the back store room where you keep and get new products. Or there are storefront rooms which are basically all the same across dimensions but may look slightly different or have different texture files, that type of thing. But the core here is that as much as a player can move around inside each room, there will be doors that take them to other rooms.

Hense, the full circle.

Aaaaand—now I am back to the database.

I started encoding a bunch of database functions just this morning that are updated at various times during play. When a room is exited, I am thinking, the database will slurp up all the room data, store the state of all the objects in that room and essentially create a kind of mapped overlay of the base map for each room, but at coordinates there may be products or tools or other things that despawn out of the active play but can be respawned when the player re-enters that particular play area.

I lean heavily into database driven design online and I am very comfortable thinking about things that way, but in many ways it this is because databases are virtually a necessity for web based stuff if only because you need preserve a lot of data between pages and across sessions. Each page is essentially a little app that builds itself dynamically from the data in the database and doesn’t rely on a system loading the entirety of the site into memory and keeping track of everything across every session then passing all of it from page to page. Now that would be silly,

I figure, too, that this approach may really work to my advantage in the roguelite game plan that I am contemplating. Certain data can always be persisistent across runs of the game and just doesn’t get purged from the databse on initiation.

I sat down here to write something about the abstractions of learning this language but now that my ideas are actually starting to take shape and form I’m noticing that I can write in more than abstractions. And that’s a good thing, right? Maybe silly. Maybe more.