constraint based api
intro by way of datalog
Datalog is a constraint-based api. These tend to be able to express complex situations in a terse way, and can be solved rather efficiently.
They get leverage by allowing for rules to easily reference eachother, which makes them very expressive.
datalog example:
(d/q '[:find (pull ?player [:db/id
:gunner/health
:jump/power
:position/xy])
:where [?player :hotel/type :type/player]])This would be a nice way to pull game data from the hotel db.
Datalog is really more comparable to SQL, but these query apis are implemented with constraint solvers.
procedural generation is another way to express some constraints
hopefully the implementation/tools you create for yourself make it easy to modify the program's inherent constraints.
With constraint-based room design, I want to be able to easily generate rooms
from expressive ' themes '. The themes should be a list of composable constraints
that can be merged/joined at will (in Godot, an array of dicts. in Clojure, a
vector of maps. It's all the same tho, right? guys?)
We also want to be able to react to constraints based on game mechanics. If a bat can bust through some boxes, a room generator should be able to support a path from the start to the bat without blocking the way with boxes. But also, make sure there are plenty of boxes!
But how to express that?
var bat_theme_rules = [
# defining a path in the world, from any elevator to any bat
# then, an options map for the tile gen algorithm
# `skip_tile` means don't use this tile, please
# tile along this path.
# `width` means the skip-bat-box path we defined here should be at least
# 2 tiles wide the whole way, so we can go ahead an use a window of that size
# to carve it
{path_opts: [ELEVATOR, BAT, {
skip_tile=BAT_BOXES,
width=2,
}]}
]And with that, I realized this is all the same as a rules engine.
constraint apis can be data-driven design/development
I think that data-driven side is key to the expressivity.
Backlinks
A video overview of the components that make up the clawe monorepo.
Relevant April 2023.
I'll post a link here once it exists! For now, if you're reading this, I could stream this any day, so take a look at my schedule or ping me to see when it's going to happen.
A Dino addon.
---
An in-memory game-state database.
Supports booking data from packedScenes and registering data from a nodes' _ready() function at runtime.
Will soon persist and pull saved-state data in at Hotel.register(self) time.
Built up with check_in/check_out as write/read function names.
---
Hotel was originally a Room manager, but it has grown into a full game state db.
It supports 'booking' data based on your static scenes, 'registering' nodes with the hotel when a node is _ready(), and 'checking-in' data as in-game events happen.
The main feature supports reloading zones and rooms that have already been visited, and restoring the state from the player's last visit. Ex: was this candle lit? What was this enemies health? Was this item already found?
Hotel as a UI view that can be used to access game data in a debug overlay or in the Godot editor.
Pulling data from your static files makes it simple to connect nodes together - the initial use-case for this was making it possible for teleporters (elevators) in different rooms/zones to reference eachother as a destination.
Hotel exposes a useful
Hotel.query({})
function as well, which supports several
basic keys (e.g.
groups,
is_player
) and a general
"filter"
key for fetching whatever data you
need.
Hotel also offers a signal for all data
check_ins,
which provides a nice separation of concerns for updating
the HUD or sending out notifications based on changed
data.
Related but not yet implemented: I hope to get to hotel themes soon, which is a step back toward the room management idea, but with a focus on data-driven or constraint-based look and feel (i.e. constraint-based room design ).
Starting early today (12:01am)
working through clawe.org, pulling in some content, writing some new ideas
garden tending