Related, and probably stored in Hotel.
Likely part of the rooms api.
An attempt to capture the core of a constraint-based room design tool.
May include a tileset, a background, a canvas-modulate. Environmental lights.
Basically the 2D side-scrolling look and feel checkboxes as input data.
Fog effects, wind effects, weather. Lighting! Ambiance!
composition
I want to be able to add multiple themes to a room, and have them merge and share some of the expression.
All the fields are optional (i.e. a theme could be a single background or tileset).
This would let themes be small and large, and would encourage adding/removing
them quickly (like at runtime, when the player puts on a pair of shades, any time.)
It'd be nice to also apply this per room to some runner rooms.
Some data dictionary that we can attach preloads and hook-functions to.
Theme Definition?
an idea for a hotel theme api:
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,
}]}
]
Games, especially dungeon crawlers, lend themselves to talking about Rooms.
Rooms have treasures, keys, locked doors, enemies, bosses, etc.
Rooms have puzzles, shapes.
Rooms have look and feel, weather, traps.
All kinds of fun!
--
hotel (dino plugin) for room management. hotel themes for composable room decoration.
--
leaf runner (dino game) and its runner-room api.
Related, and probably stored in Hotel.
Likely part of the rooms api.
An attempt to capture the core of a constraint-based room design tool.
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 ).