This is taking longer than expected, thank you for your patience, meanwhile:
When i try to code a game without using behaviors in construct so that the mechanics better suit my needs and I don'T need band aid fixes, my options are:
- make every state a condition of every object. every single object has to go down a
if {
}elseif{
}elseif{
}else if{
}
kind of thing. States sorted by how often they are in that state from top to bottom for efficiency
this only works if objects cannot have multiple states. Code is pretty annoying to write this way because if you change something in one state, you may have to edit other similar states too (not using functions because they lower performance, so they put a ceiling on complexity of the game). To make this method more flexible, instead of using elseifs, every object has to check every state on every tick, that's not very good.
- Don't use conditions (except for exceptions) and instead jam pack all of your code into actions like this
with a megaobject that contains all possible states.
this code is more flexible and faster than the previous method, in the example, the velocity of the object on the x axis is set correctly, regardless of state, all at once for each object, and like previously, the action is optimised to exit early and not check for states if the correct one is already found. All velocities are set in one fell swoop without having to return to this variable later down the line, removing overhead for calling multiple engine functions that basically do the same thing, but at different times.
- what i want to do is to not have to loop through objects to check for states altogether, when the state changes, a new object is created, variables are passed, and the old object is deleted. Then, this object's code executes unconditionally until it passes to another state. The problem with this is it creates a lot of garbage ( especially with containers) and isn'T as flexible as the previous model, and code isn't as reusable, since in the previous one, all objects passed through the same code so bugs were easy to fix, but now the bug may be in multiple places.
-
The solution I theorized is a combination of both previous models for my events, with a main game object that can be given components (the new empty object type) Components run the big code inside of action without conditions like before, but can be removed or added to main game objects at will. The roadblock with this method is that, within the construct 3 architecture, it'S actually slower than the good second method because while it does not have to do conditions and saves cpu there, it adds cpu by needing a main game object UID property saved to it and then it needs to be looped and pick main game object by UID to do its job,which ends up being slower because while picking by UID is fast, a loop to pick by UID has to be invoked, removing the CPU time benefits for this method unless the state is rare (like the wall sliding example from my previous post),
So basically, I know that you keep saying that performance doesn't matter
Ashley but that's not exactly the case.
I Consider performance a complexity Ceiling, and I discovered all of these weird ways to use events to raise that complexity ceiling for my game, it being multiplayer and 3D/isometric with lots of sorting and collision detection
Containers should in theory be able to do this because containers are great for avoiding picking, but one of the big problems I encounter is that containers are immutable, so if I would, say, create a "gravity" object and put it in a container, and then do an action on gravity, it picks everything in the same container so I can add gravity to my objects without any picking, and that'S great! BUT! Families and containers are incompatible.
IF i try to do "gravity family" and "gameobject family", then nothing gets picked which means if I create a gravity object for every object type combination and try to put them all inside a family and do an action on that family, it will not pick objects in the same containers, so this method is a dead-end. Similarly, making an event for every possible gravity object for each object type without using families adds a lot of unnecessary code complexity and makes maintaining your code a nightmare, so, also a dead-end.
So for my suggestion:
I don'T actually know what you'Re willing to accept as a suggestion Ashley, and you're actually way smarter than me and got more experience, but it'S really hard to have a discussion together because you are so busy, and what I need is probably very niche within the community because most people are focused on ease of use and behaviors, which is great!!! it'S what got me into using this engine in the first place, but maybe niche very experienced users like me aren't really a focus.
I'm still working on the example project, but making an example project that shows that complex games struggle is more difficult than anticipated, I can'T just use quadisperf for this one.