so that's why one of my future goals is to be able to construct subcomponents inside components

this would allow converting generated objects (building and decal) to components that do the same thing

I'm however not entirely sure what this would do to actors and actor templates - maybe they'd need to be constructible at a component level instead, maybe an actor could just be any component inserted directly into a map, and a group component could have actor's structure

#gamedev #programming

I'm also not sure how to handle component references and searchability within a root group

a flat component array does make searchability very easy

maybe subcomponents could be used only in cases where subcomponent addressability is either not needed or could be done with a path string

local UIDs seem incompatible with the concept of competing allocators anyway

in any case, got some exploratory work to look into, like - how to do subcomponent-compatible registration

#gamedev #programming

while looking into using a mesh component as a subcomponent, I was reminded that a lot of use cases involve lazy-generating meshes

I'm revisiting the idea and thinking that it's not actually that useful to preserve any kind of caching behavior

usually there will be no changes, so one update after serialization should be enough

editor UI can also trigger updates

thirdly, there's runtime changes but those would be clumped together so update can be made explicit there

#gamedev #programming

makes me wonder how much time generally in software is spent on doing lazy updates when it would instead be sufficient to replace them with minimal automation + manual updates

the error case for when something doesn't work is fairly obvious once you get used to it - nothing happened means the update function wasn't called

also, "proper" invalidation requires a custom setter for *everything* with the same invalidation code everywhere - that seems like a ton of code waste as well

#programming

while reviewing old code to figure out where to add the UpdateMesh call, took me a really long time to notice these serialization-adjacent callbacks

never been used, never been needed

they're only useful with fixed-function serialization, which isn't the case here

why were they added? no idea 🤷
are they correctly called? (always and symmetrically) no idea 🤷

removed them (in both component and spawner classes)

#gamedev #programming

another issue with components inside components is the ability to reference subcomponents

fixed-length IDs can be stored on the stack so I really want to avoid string paths

but it may require either having an ID allocator or limiting nesting depth

currently leaning towards the latter since that would be cheaper and should let me keep most of the code (in the short term at least)

in practice depth should be at most 3-4

#gamedev #programming

my first subcomponent experiment - beveled box mesh

got to remove about 60 lines of duplicated and not-completely-synced mesh rendering/query code

is there value in this specific case? not sure yet

maybe I could just inherit from a whole mesh class here and leave the internals exposed - that should save like 50-100 bytes per instance

the ultimate value would be from generating multiple components inside one - but that will require figuring out the ID issue

#gamedev #programming

managed to "lock in", as they say, and write a >400 LOC hole component

it inherits from a mesh component but also has a physics mesh and two polygons (metadata for wall clipping) as subcomponents

still need to make a thing that detects walls from nearby meshes and adjusts side planes to fit them, and some keyboard shortcuts for both that and regenerating nearby objects

also need to consider syncing portals from this component

but it should help with my hole problem

#gamedev #programming

added portal sync to the hole component

it might make sense for it to be done while moving the portal around as well (since portals use absolute coords for speed)

need to think about all the ways hole editing can be streamlined

#gamedev #programming

tweaked the lighting to match light levels on both sides of the portal

makes the texture mapping across the hole look perfectly smooth

also, while testing portal updates, it became clear that the shape of the portal has to match the mesh, otherwise things will look wrong due to room lighting being largely directionless, especially near the hole

unfortunately that might mean that non-rectangle portals might need to be rendered into textures

#enginedev #graphics #programming

added a keyboard shortcut to resync selected actors/components

already much easier to move holes around

now will also need to have a keyboard shortcut for resyncing everything likely intersecting the selection *except* the selection

either that or a shortcut for A automatically followed by B, so that only one keyboard shortcut needs to be invoked for a full update in the correct order

created the combined keyboard shortcut where first the selected thing is updated and afterwards the overlapping things are updated

need to do some integrations soon to see to what extent this might solve the hole problem

#gamedev #programming

added a button to find adjacent aligned faces and copy materials from them

unfortunately the UV mapping cannot be copied over as well so things don't auto-align as perfectly as they did in floor plan (which simply added a quad using the existing floor mapping) but it's a passable first attempt

need to figure out how to share a coord space across systems for UV gen to fix that

still yet to do a proper integration of the hole component in one of the test maps

#gamedev #graphics #programming

the first test done with a "real" (preexisting) map

initial hole setup took some time but actor templates/prefabs will take care of that

found a bunch of issues with AI navigation data and how to generate it

among those - holes need nav.links but I haven't yet provided them

but the nav.links also require 2D portal shape data and I'm moving to 3D

need to think about what's the best approach for moving to 3D before I can do much there, maybe could reuse vis.portals now

#gamedev #programming

while looking into refactoring the navigation system to prepare it for future upgrades, found a "room ID" inside the navigation area component which has existed since 2022-09 (3.5 years ago), basically from way back when I was still messing around with the code and there were no concrete plans to make a specific game yet

turns out it's been shipped despite having no use whatsoever anymore

it was used to place the components in an array for easy lookup

🚮

#gamedev #programming

transferred all nav link (🚮) functions to the portal component

the volume/portal components will probably need to be generalized so that various components could be attached to them, allowing the minimum viable world partitioning definition to be reused as much as possible

in corpo/ghost the overlap was at 100% (visibility volume = sound volume = navigation area = room visit tracker volume = light zone)

I can imagine other cases but divergence is more of an exception

#gamedev #programming

the way those components are currently generalized is that any component that wants to attach to it, has to maintain its own mapping (e.g. volume->nav area) to optimize access

(the other direction is not an issue since the metadata component keeps a reference to the volume/portal)

ideally there's a better (and faster) way but it's unclear what that might be

in the case of nav areas, one may want to have more than one agent type, is that still one component or several?

#gamedev #programming

added the basic hole component to the [make portal] command

it's a bit janky in that I don't have full control over the emitted component, which is a broader thing of how generated objects work

also came up with a possible partial solution to the problem of objects having generated parts

a "rootable" (can be placed in the map directly) object could inherit from a component, thus actors/spawners/prefabs/gen.objects etc. could become special cases of a rootable component

#gamedev #programming

added door holes to my placeholder door prefab that was used in the spatial sound test map

also converted an old "styles" map (plain room styling test)

it's quite a bit of work to convert the rooms by hand and automated conversion probably doesn't pay off for the <20 remaining maps

improving rectangle editing should be universally useful though

thankfully it seems the holes are finally working as intended though - separate objects that I can move around and integrate with 1 keyboard shortcut

added a new projection mode to deal with the issue of putting doors and windows between rooms

projection is basically doing a raycast to figure out where to place an object

there is an invisible volume whose side faces are in the middle between rooms

so I figured that I could just raycast that volume instead of the visible meshes

and the raycasted point is snapped to the edges so that doors (with origin at the bottom) can be quickly and easily placed on the wall-floor edge

#gamedev #ui

added drag handle support to gen.objects, which should also help a bit with porting the data, as well as designing new content

currently only the rectangle supports these but the plan is to add them to some other things (e.g. polygon edges) as well where useful

it is a bit annoying however that editor upgrades are bottlenecked by having many different forms of scene data, which is why I'd like to consolidate them into fewer forms to require less supporting code

#gamedev #programming #ui

attempted to replicate one aspect of the 0-thick separator by writing a quick hack that connects tagged vertices of a polygon

currently the only way to visualize it is by using a light since they're assigned individual light spaces at the moment

also figured out that it ✨ just works ✨ (no need to filter out the outside loop) if you use directed edges for inner loop finding and only add both directions of the interior (cutting) edges, keeping the outer edge unidirectional

#gamedev #programming

for cases like this eventually I'd still want to have a mesh (like what the floor plan tool has) so that

1) interior edges can be more complex
2) individual interior faces can be filled/styled independently
3) stable identifiers can be assigned to those mesh faces (to propagate them to generated components)

not sure how to structure the runtime data yet however

there could be a fight between nav/sound areas and envmap volumes on how such a space should be split up

#enginedev

moving light portal data into the main portal component so that there isn't a second component at all

also planning to remove light space components entirely

they only have one parameter - an array of volume component refs - so I figured out that in all use cases the light spaces can be inferred from flood-filling the volumes through portals that explicitly allow such light transfers

this will avoid all the issues associated with linking components together

#gamedev #enginedev #programming

spent a lot of time replacing volume-adjacent components

already turned light space and nav area components into dummy skeletons that await data cleanup so that they can be removed

could need a volume component system if I don't want to go through upgrading the data multiple times (not sure yet)

upgraded the baked asset ref key (a name for looking up external files) but can't shake the feeling that I have a fundamental issue with trying to persistently name generated things

- got rid of light space/nav area components entirely (scene framework and actor templates seem to be handling nonexistent components in data well enough)

- created a "volume component", first impl = navigation component, second impl = room visit tracker

- only one remaining legacy component having its own copy of a world volume (light zone), not sure if I want it to be a volume component however - there's some benefit in overlaying detailed lightmaps where needed

#enginedev

also I've been noticing that volume components have some things in common with regular components, but also some crucial differences

thinking about whether it's possible to unify them into one type system

e.g. room visit tracker needs "begin play" and "runtime serialize" callbacks

do we just run all of them from the volume, turning volume into an omni-component that signals the capability to do everything, only to be able to pass the signal along? or can we reduce signal passing work somehow?

on a related note, thinking of separating some "begin/end play" work

e.g. editor needs interlinking of components but doesn't need any preparation work for game updates

it's kind of like there should be several distinct passes instead of trying to mix things together

sometimes "begin play" work even relies on having all the links (including from other components)

also, "end play" outside of unlinking doesn't seem to be much of a thing (there's some deallocs but dtor can do those)

#enginedev

in addition to all that, there's been a need to perform various stages of init in a specific order

e.g. updating light on/off state before updating emissive materials or NPC vision based on that state

normally game updates handle this, except for the first frame which sets the initial values after which changes may be tracked

I had a "map post init" callback but it only works for map actors

I should look into unifying these before-first-update callbacks

#enginedev

it's not even that complicated conceptually btw - having a callback where per-type lists of upcoming components can be iterated

it's just that when loading a map, there's currently a natural list of all map components (since these lists are stored per-map)

when spawning actors manually, there's no such list

arguably manual spawning isn't that useful though, so designing for it can be a waste of time

I would however like to have per-world component lists to simplify iterating them

#enginedev

addressed the issue while working on v2 map streaming (partitions: https://mastodon.gamedev.place/@archo/116291337841878255)

seems like a lot of the things generalize well when what was previously a "map" is now a "component container", and there's a few more of those

manual spawning ended up being handled by the "pending set"

the "per-world component list" is basically the "run set" - other sets of components are either copied (maps/partitions) or moved (pending) into this one

#enginedev

was thinking about spawners in the context of actors/rootables

there were 3 options for spawners:

1️⃣ spawners and actors coexist in separate arrays, spawning = creating an unassociated actor (current solution)
2️⃣ spawner as a property of actor, replacing most fields
3️⃣ spawner as parent/owner of the actor

I managed to entirely eliminate 2️⃣ by considering one of their highly beneficial features - custom root transforms

#gamedev #enginedev

a player spawner doesn't have the usual position+rotation+scale transform

it only has position+angle (around the up axis)

this makes it physically impossible to accidentally edit the spawner into a situation where a player would be spawned slanted, sideways or scaled

not even by editing the spawner data manually in the text editor

this eliminates a whole category of errors

in some cases, actors could have their own root transform, which would conflict with the spawner

#gamedev #enginedev

tbf it's not a hard limitation at the moment and you can just update the transform one-way (always spawner to actor) in the editor

however I also considered the possibility that actors could have their own root transforms instead of requiring a root transform component, at which point it becomes a lot more difficult to justify and consistently enforce having a 2nd (override) transform in the spawner, especially if it's a partial replacement (angle ➡️ rotation only)

#gamedev #enginedev

leaning towards putting existing actors inside other actors instead of broadening what's considered a rootable

maybe there's a way to combine all that but

actors have the beneficial properties that:
- all changes are minimal - component deletion, relinking (even hierarchial reordering) and other data edits don't require the reshuffling that hierarchialized unserialization would need
- actor is a logical unit (can render - or skip - just one) and I want to preserve this

#gamedev #enginedev

technically it's still possible to put an actor inside a different rootable but that has another issue with subactors - the hierarchy could change between runtime vs in editor (runtime doesn't need to retain prefabs/gen.objects/etc.)

and I really want the "if cur_actor is test_actor" exclusion test for raycasts to be really fast

with subactors that means having a one-type parent pointer (no inheritance/interfaces), which also means no sandwiching of random types in between

#gamedev #enginedev

I probably wouldn't want spawners inside other actors anyway

it makes no sense for e.g. players/NPCs (though arguably for my upcoming project spawners aren't useful for those anyway)

but prefabs/gen.objects could in theory fit inside other actors

another interesting thing to consider is how actors interact with visibility groups

e.g. a door could be a subactor of a door frame - that's like the main (only?) reason why visibility groups aren't merged with actors atm

#gamedev #enginedev

however, from a design perspective, it's helpful to design the door together with the door frame

and yet gen.objects can only produce a single actor (without subactors since those don't exist currently)

I guess there's also a case to be made for having one vis.group be inside each actor, but then also being able to create additional ones in some way

further still, one could imagine having vis.groups for each streamed partition too - could make outdoor culling cheaper

#gamedev #enginedev

and looking from the opposite direction, actors currently have no runtime use for most (static) objects

they're a way to manage a pile of components that are interlinked

once the components of a single actor are linked together, it only serves to provide a world pointer where it's otherwise unavailable

so either most actor objects could be thrown out at runtime, or they could be given a new use case of a default vis.group (but it will hurt the non-visual actors)

#gamedev #enginedev

as I've unsquished the cached actor def json, another problem has become clearer

a lot of this is effectively just fancy spam

I don't intend to tweak per-object decal visibility basically ever, this should just be handled automatically based on mesh flags

the visibility group is a "group" that consists of just one mesh

the "actor" is also one mesh, never to be drawn individually

the vast majority of cases should just be a single mesh with the basic data attached

#gamedev #enginedev