I have some optimisations in mind FOR WHEN this system becomes too simple to function (e.g. broadcast a message to literally everything in the game"
@Almo I kind of feel you-ish, I do love all sorts of coding but I don't think it's for me profesionally
which only makes me feel like reinforcing the idea that I REALLY REALLY LOVE PROGRAMMING
But it's clear that programming is so varied that you can fully hate it somewhere and love it somewhere else
To the point where someone saying they like programming is as informative as them saying "I like making things". A good start, but I still have no idea what that means
But yes, tree optimisations... I could make the add/remove operations a tiny bit more complex, so that every node has "listensTo" as a property, the kind of messages it cares about. When I add a child to a node (a unit to a squad, in a unit < squad < tile < battlefield hierarchy for example), its "listensTo" property is merged with the parents'. So, an empty tile listens to almost nothing. If I move a squad into it, that tile listens to what the squad listens to. Then, if I spawn a new unit in there, the unit, squad and tile all listen to a new type of message
listeningTo something means that a node either processes a message or propagates it downwards
Or, the second idea, is making messages more "local". It's tough to say what nodes should propagate a message, but it could be easier to say which ones shouldn't. An AoE attack targeted at a tile that affects the surrounding tiles could have this nonpropagation condition: "a tree node that is a tile and further than 1 away from the target will not propagate the message"
Both of these being things you eventually feel like doing with a big tree: pruning it
Im trying to create my game component based... my game communicates with a database... i thought about a table which stores different components ( as class names ) ... each item can have multiple components ... when this item is used it will iterate over those components to instantiate them by their name and call their certain function. Do many games do something like this ?
As in, any given node on the tree only listens to what its children listen to
For example, any unit, as well as graphics and achievement systems, listen for "damage", but only necromancers and achievements listen for "death" messages
entire rooms full of normal enemies never even receive the message
Which means I can make the trees deeper, even by arbitrary standards like actual rooms or half-rooms in a roguelike, to increase pruning
user92578
2:53 PM
Are these scene object trees? Why are they so deep?
user92578
As someone who's scene object lists are simply flat, I have a hard time understanding the need for incredibly deep parent/child hierarchies
It can make composite objects easier to deal with. Like artist makes a gun, another makes a turret, another makes a battleship with 10 turrets 2 guns each.
@AlexMitan i'm going to second tyyppi's reaction in that scenes don't usually need very deep trees
like if you're going 5 or 6 levels deep you're doing something very special
and just because something belongs to a group, doesn't mean we organise it that way in the tree. in a TF2 map, we have a scene map with 24 players on it. there are no "teams" in this map. that there are 2 sides doesn't change how we organise our players, the 2 sides are a property of the players and not a structural property of how the world exists.
often it'll be because you have things like: - an aligned segment of the screen (e.g. the top-right health bar or bottom-center hotbar) ↳ the row-based layout container for that part of the HUD ↳ a row in that container for our items ↳ decorative features around that row (which might be 2-3 layers all on its own), with a subcontainer for... ↳ the actual row of items ↳ one specific item ↳ the item's image ↳ a glow, a border, and a number indicating how many you have
because GUI code is nice to work with at all times and excellent and is not a problem ever 👌
Yeah, it's not so much nesting that I'm INTERESTED in, or the depth, as much as exploring this system
In this case, only some of the subpartitions are significant, and are labelled as such: "squad", "tile", "battlefield"
it's for "localising" events
instead of iterating through all of the entities and seeing which ones are on the same squad as you or galaxy as you or within proximity, you have a rough partitioning that helps with over-broadcasting
and also, yeah, component systems
I can just not add the graphical components to the ships and I can simulate a fight with zero changes to the code
A component reacts to an event, and adding extra components and events should be as much of a purely additive process as possible
you can just have a "squad" component that handles broadcasting between squad members in its own isolated tree that has no relation to any other communications tree
Yeah, but for example if you have a "death" event, it might be important for graphical components, your squad, the opposing squad, the nearest "warp gate whose cooldown is lowered on ally deaths", and the achievement systems
I'd rather pour all communications into everything, and then try to prune rather than add and modify systems one by one
I especially like the "listenHash" experiment, where I had a roguelikey hierarchy simulated in a few lines of things whacking each other, where it's game > tiles > units in tiles > minions of units, and there's a melee hero and goblin fighting each other
while an archer and necromancer sit in two other tiles
