-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add System Priority Option to decide Order of Execution #11
Comments
Hi @EriKWDev, thanks for your suggestion! I can see this fitting in quite well with the current control flow options.
Yes, that makes sense. Systems would be ordered by the
I don't know if this helps you in the mean time, but you can Another approach is to import modules with
Thanks! Performance is one of the stand out features of the ECS pattern in general and it's nice to hear that Polymorph is doing well there! There are also a number of features and improvements in the pipeline (ahem) for speeding things up further as well, so things should only be getting faster! |
Thank you for taking the time to respond. I will experiment with Maybe I should just use templates like the documentation proposes.. xP |
Yes, the import order would matter for defining systems if you're not using templates as the order is set when they're first seen. It might be easier to use # Module1
makeSystem "sys1", [A]: discard
makeSystem "sys2", [A, B, C]: discard
makeSystem "sys3", [A, B]: discard
# Group previously defined, ungrouped systems in the order they're defined.
# Here this would be sys1, sys2, sys3.
defineGroup "module1" # Module2
makeSystem "sys5", [B]: discard
makeSystem "sys4", [B, C]: discard
makeSystem "sys6", [A, B, C]: discard
# Specify order for this group.
defineGroup "module2a", ["sys4", "sys5", "sys6"]
# ... define more systems
# Group the next set of systems in this module as they're seen.
defineGroup "module2b" # Module3 (creating the ECS)
import componentdefs, module1, module2
export componentdefs
makeEcs()
commitGroup "module1", "module1"
commitGroup "module2a", "module2a"
commitGroup "module2b", "module2b"
commitSystems "runUngrouped" # If any. # Main module
import module3
# Execute module groups.
while true:
module2b()
module1()
runUngrouped()
module2a() Hopefully this helps! |
Yes, after some testing the groups are really useful and the most versatile. It's very nice because now I can run game logic systems on a quick loop with fixed timestep and have rendering in a separate group which can run on a variable rate. I still think the order^ option could be useful for simpler setups. |
Excellent, good to hear! I will definitely keep in mind the ordering/priority for a future release. |
From the docs it says
It woul be nice if I instead could add something like a
priority
ororder
integer as an option upon creating the system. For example:I can see some problems though with this approach such as "What to do when a system isn't given an explicit priority?". I do not have a good answer to that. I suppose systems should be primarily sorted by the priority, and if none is given simply when they were defined like how they are now, though I do not know what that would look like in implementation.
This feature would help me if I define systems in different files and don't want to have to create a template each time and make sure the templates are put in place in the correct order.
I was working on my own macro ECS system when I discovered polymorph and you guys have much better performance than what I had managed xP So congrats and thanks for the module! I will switch to using it for my game :)
The text was updated successfully, but these errors were encountered: