DEVS: Input on GS game execution "pipeline"
rebump
Member Posts: 1,058
Without going into too many details myself, I was wondering if you could provide an overview of how the behaviors/rules are parsed, or supposed to be parsed, within actors. I ask as I see various results for what I think should be one result.
Some rules, even with only one condition, appear to evaluate over and over as you would expect...especially the event driven (i.e. keyboard, mouse, touch, collision, etc.) rules. While other rules tend to evaluate only once but once evaluated, don't appear to evaluate again once they were traversed even though they or their "otherwise" condition should (and I'm pretty good with logic/conditionals).
So does execution rely on any of these sort of design considerations:
1) only rules with "dirty" attributes (i.e. ones that have changed) are evaluated again
2) only certain rule types are evaluated again from some arbitrary list
3) only so much is evaluated in a rule/timer before some internal time-out to reduce the load on the engine (I bring this option as I see the "run to completion" checkbox everywhere and noticed in 0.7.0 I had to use it in timers with "after 0 seconds...do all this to completion" to get all the steps to complete)
4) still buggy on (some) behavior/rule execution
5) ...?
It would probably provide all of us some good info, especially newbies, if they knew the intention of the developers on how the rules/behaviors/timers were intended to work and how they actually work.
I've seen Joe (FMG) and a few others complaining about things working 99% of the time (as have I) and I think some of that comes into play here as well.
I know in the 0.8.3 release notes, you stated that "inner behaviors" should execute more reliably so maybe there are still some issues with these!? I think it did get better at 0.8.3 but I am still seeing inconsistency.
I think a prime example is the actor who fires or jumps and the firing/jumping just stop working for a bit (even though the event rules tend to be the more reliable ones).
Even if the answer to all this is "bugs" I still think an overview of how the "pipeline" runs would be helpful to us all!
Some rules, even with only one condition, appear to evaluate over and over as you would expect...especially the event driven (i.e. keyboard, mouse, touch, collision, etc.) rules. While other rules tend to evaluate only once but once evaluated, don't appear to evaluate again once they were traversed even though they or their "otherwise" condition should (and I'm pretty good with logic/conditionals).
So does execution rely on any of these sort of design considerations:
1) only rules with "dirty" attributes (i.e. ones that have changed) are evaluated again
2) only certain rule types are evaluated again from some arbitrary list
3) only so much is evaluated in a rule/timer before some internal time-out to reduce the load on the engine (I bring this option as I see the "run to completion" checkbox everywhere and noticed in 0.7.0 I had to use it in timers with "after 0 seconds...do all this to completion" to get all the steps to complete)
4) still buggy on (some) behavior/rule execution
5) ...?
It would probably provide all of us some good info, especially newbies, if they knew the intention of the developers on how the rules/behaviors/timers were intended to work and how they actually work.
I've seen Joe (FMG) and a few others complaining about things working 99% of the time (as have I) and I think some of that comes into play here as well.
I know in the 0.8.3 release notes, you stated that "inner behaviors" should execute more reliably so maybe there are still some issues with these!? I think it did get better at 0.8.3 but I am still seeing inconsistency.
I think a prime example is the actor who fires or jumps and the firing/jumping just stop working for a bit (even though the event rules tend to be the more reliable ones).
Even if the answer to all this is "bugs" I still think an overview of how the "pipeline" runs would be helpful to us all!
Comments
Knowing how things work enables us to write behaviors that will do what we intend them to do.
I'd love to see this written.
I've had if statements that check if the x value is blah and they are constantly checked, but then some that I've had to enclose in a timer because they weren't working the same way.
But I too have run into what I can only describe as a buggy.
everything since 0.8.x executes in parallell now, EXCEPT that Actions evaluate before Behaviors. Only dirty attributes rules are re-evaludated but branch conditions "stick" that is to say that once a Rule executes it continues to execute until an attribute in it's condition causes a change.
So I look at it like this:
There are 3 phases:
Actions
Behaviors
Groups
The A, B, G's
Things are executed in that order.
Actions, within a group, execute in sequence top to bottom. Behaviors always execute in parallel.
Now, i'm not a dev, so i could be totally wrong about this stuff.
Just my observations...
Definitely not consistent and not conducive to getting things done quickly the first few go arounds. This is especially pertinent on time sensitive gaming or games with lots of moving parts.
What's up with that? Great questions. Important concepts.
I'm sure they get to it eventually, when time permits.
(bump)
...so are we
It has been a trial and error development process for me as soon as one of my projects got a little bigger than the first small experiments. I would like to have control over the "code" even it's in a drag and drop IDE. It's very frustrating when your code is "randomly" executed...
The problem with the game engine as I see it is its "free for all" aspect. While this makes it a bit more friendly to novice users and to those developing games without alot of action, it is a headache for those making more involved games or games with lots of action.
As it stands now, you can develop a fairly complex actor on its own and it works solidly. Then add more things going on in the game (i.e. static objects, sound, more actors, particles, etc.) and the execution of the logic in the rock solid actor starts to decay due to timing issues. Now that is understandable given that all things compete for resources but there has got to be a better way.
And by better, I mean:
* - ensuring an execution order (i.e. top to bottom) in the rules/behaviors of an actor - if I can be sure they will execute in an order, I can ensure things are done in a proper sequence
* - make "Run to completion" the default behavior for all sub-rules in a timer, rule, group, etc. and only use early/lazy termination in rule conditionals (as in C) - we should expect all code to be run as planned. maybe make an "optional" checkbox for each behavior so if time is tight, those items that are checked will be ignored thusly we can help control our own performance (i.e. little flashes, sounds, spawned point indicators, particles, etc. are all great things to make optional if peformance is lagging...also, some internal sensing of device could be tied to this!!!) Or instead of a checkbox, make it a performance/preference number (i.e. 0-must run, 1 through 9 being some indicator of need with 9 being least needy) - although that could add overhead to each rule so maybe not...unless some sort of parse-ahead or pre-built at startup state table for code execution).
* - increasing performance to delay even further the issue of running into the performance wall where things degrade
Keep up the good work DEVS but please respond with how the engine is supposed to work in your eyes and how it is actually working just so we know what we are working with. I think it may help reduce trial and error testing to some extent. I think I have a pretty good understanding of it but I think others could benefit from such info. Also, in putting that info into a document, it may help clarify your goals and bring to attention some areas that need a tune-up (although they are likely on your radar already).
* - ensuring an execution order (i.e. top to bottom) in the rules/behaviors of an actor - if I can be sure they will execute in an order, I can ensure things are done in a proper sequence
* - make "Run to completion" the default behavior for all behaviors in a timer, rule, group, etc. and only use early/lazy termination in rule conditionals (as in C/C++)
Its basic information that would help users to design better games, and should have been up there in the Wiki from the start.
To be honest, documentation for GameSalad doesnt look to be a priority, and the Wiki and How To's seem to be lacking info or have gaps all over the place. Most information or help seems to come from other users on the forums.
Im loving the engine/tool, and loving the GameSalad community. Im not quite as enamoured with the lack of information from the GameSalad Developers though....
Although in reality all things follow a consistent pipeline, since there is no hard-documentation on said pipeline, you should probably just conceptually view GameSalad to have a non-deterministic program path when a lot of things are "happening at once". If you want things to happen "In Order" then you need to setup rules, timers, and groups to ensure that happens explicitly.
Although, this is just my opinion. Sorry if it is TMI!!!
`If you want things to happen "In Order" then you need to setup rules, timers, and groups to ensure that happens explicitly.`
It is not that simple, even to do that, you need to know how things work so you can come up with a plan rather than assume it is similar to other programming scenarios only to discover it isn't. There should be some sort of preconceived notion by the Devs of how the engine works even if it comes down to admitting it is non-deterministic and/or buggy.
I believe, like rebump mentioned, that they may use "dirty (i.e. changed) attributes" to trigger non-timer enclosed rules/groups. You can set up a simple rule (with only one condition and possibly an otherwise section) not enclosed in a timer and if that rule is executed once, it appears to never execute again unless one of these things happens:
- it's condition value actually changes
- it is enclosed in a timer that is set for repeat (whereas you would think it would re-evaluate next time through even if the value didn't change)
- or another rule whose conditions may themselves may become dirty
However, I have run into a couple instances where they *do* repeat when I didn't really expect them to given how things appear to work. I have been coding since I was eleven (decades ago) so I think I have a pretty good grasp on programming logic.
They may even use early exit/termination from a rule/group based on performance need. If this wasn't the case, then I wouldn't have to wrap some code in a "After 0 seconds...run to completion true" timer. If I don't include that timer, I have seen many instances where the enclosed code is not run in its entirety.
Throw all that into the probable existence of behavior/rule bugs and the mixing of fast behaviors (e.g. change attribute, etc.) sequenced with slow behaviors (e.g. move-to, etc.) then it gets even more crazy.
If you get to the point where you are experiencing a slow down in your app due to taxing the device with quite a bit, then you can expect all this behavior to get even more erratic and irrational rather than just slow down even more.
Things need to happen in a sequence at times (especially in more complicated games) and if there is no sure fire way to do so, then you will get funky results.
I am now getting pretty good with the GS engine and have a few design philosophies that seem to work but I know most newbie types would love it if the Devs provided this information from the start.
The Devs should also at least acknowledge known issues more often than they do. They don't have to say they are working on it but at least show they know about it (maybe a list of them somewhere in the Wiki). If this was done, you may spend quite a few hours less scratching your head for no reason. Nothing like wasted time.
Here is a fun little thing to try: If you ever have a sophisticated sequence of code where some stuff needs to happen after other stuff before the cycle repeats again and again, try adding a "Change Attribute" behavior to the actor in one of the sequence rules that changes the actor's transparency/alpha from its current value to its current value with 0.1 subtracted from it.
`self.Color.Alpha = self.Color.Alpha - 0.1`
Be sure to put it in a sequence rule that runs pretty quickly but you expect it to run only once during each cycle/repetition of the sequence. You may see your actor fade out more often than you thought it would before the other steps in the sequence run.
If you cannot rely on reliable sequencing or completion of your code, then you will be limited to simpler game play mechanics like lots of the physics type games employ or the generic/simplistic shooters employ.
Until we hit 1.0, we're still optimizing execution and adding new features. This may involve moving bits of the pipeline around (part of what caused the problems with early 0.8 releases).
So what may be correct today, may be horribly incorrect tomorrow. As you've noticed, documentation often lags behind releases. So we want to minimize leaving bad documentation lying around, especially if it's conceptually external to the system.
We're constantly trying to improve our testing process to ensure minimal heartache for our users, but we're leaving the beta designation there for a reason.
And while it often cost more, we're now better geared towards answering questions our users ask after a release than pre-documenting against the myriad ways our users have stretched the GameSalad engine.
So I guess I'm saying, sorry we're not documenting better and expect it to get better as our engine settles down during our approach to 1.0.
And thanks for bearing with us.
Also, this is my bad (I'm on the web team, not the tools/engine team) I broke the wiki a while back, which is another reason some of our documentation is behind. Expect it to be fixed soon.
Hello Adent! Nice to see you, and thanks for the response.
I can't help but be concerned about the "what may be correct today, may be horribly incorrect tomorrow" line.
I think a lot of us experienced this with the .8 update. As you know, I'm hoping you fix what went wrong there, rather than break everyones games again!
Keep up the good work, it *is* appreciated. I guess I fear change...
*hits rubber hand with a hammer*
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io