21–30 of 90 posts
I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense. But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practic…
Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.
I'd say this is something that can be done on a driver / GPU level; if the inputs to render the next frame are the same, it can just reuse the previous one. That's probably oversimplifying it, I don't know anything about graphics programming.
fwiw: The downvotes are not from me.
Your game will get done if you work on it, not necessarily if you pick ECS!
Earlier quoted context omitted.
I wrote a game engine that did that, because it was for a very simple, largely static scene. You would implement it almost the same as a standard Windows GUI -- using an event handler loop that marks the screen as "dirty" and needing a refresh if it has changed. Where it would immediately break down is ongoing animations. If you stopped moving your mouse, then animations would stop. Of course, you can set up the even…
Well, if those animations are things such as camera smoothing, it won't have such an impact. But I see your point. Thanks for entertaining the idea!
To any budding game developers, my advice would be to not rush into ECS and try to accomplish your goals with structs and loops first and understand the fundamentals of how a video game 'works' under the hood. Your game will get done if you work on it, not necessarily if you pick ECS!
I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense. But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practic…
Earlier quoted context omitted.
> “the bug goes away as soon as the mouse is moved, so it's usually not a big deal” This reminds me of: https://thedailywtf.com/articles/Hidden-Tax-Moves "Wait, let me try," Bruce said, grabbing the mouse. "Whoa, what just happened?" a teammate exclaimed. "What did you do? A ton of traffic just came through!"
> After several meetings, it was decided that it wasn't the best idea to put critical code in an app's MouseMove event. Prove that the story is real ;)
At one company we had a deployment script written in English. That support from India would execute. Except they would occasionally inject their undocumented codes to fix their own issues.
That and the component oriented distributed monolith that ran on single machine. It was monolith architecture but it was made to run on multiple machines. However it was never distributed and starting the components was an arcane science.
Any idea what a game loop would look like for an ECS engine that only renders a new frame when some animation is running or when the user is manipulating the camera, but not otherwise? Let's not argue "why". Most obvious would be saving battery.
Event queues are used to track things in long duration across multiple frames, like user input, animation sequences, sound sequences, pending state update, pending physics update, pending AI update, etc.
In each frame, check the event queues. If they are empty, sleep. Otherwise, process the events in the queues. For user input, do the state update corresponding to the input, like updating the camera position.
For ongoing animations, advance the steps in the sequences (the drawing is done in the rendering step). When an animation sequence completes, remove it from the queue. Same for sound.
For pending state update, run the update. E.g. the ship is moving, do the state update on its velocity and position. For ECS, you might end up calling or not calling the systems for the item type for batch update. E.g. when the bullet queue is not empty, you might just run the bullet related systems over all bullets for simplicity. When all the bullets end and the queue is empty, the bullet related systems can be skipped.
The physics queue has the items being simulated. Run those. Physics could run at a slower rate like 5fps, so the queued items would be skipped most of the times. Same with the AI items in the AI queue.
Whenever there's a state update, mark the screen as outdated. At the rendering step, run rendering if the screen is outdated. It's simpler to just run the whole rendering for any change. Ideally, when there's no event in the queues or the state updates are not triggered, there's no need for rendering.
This applies to using ECS or not. ECS is for tracking states of entities and do batch update with systems.
I'm working with an ECS at $dayjob. But I'm starting to question one aspect of them. Composition of functionality makes sense. And systems acting independently and only on objects with related components makes sense. But dynamically updating the set of components for an entity in order to "send it" to some other system, and relying on the ECS as a query database to coordinate all this, seems like questionable practic…
Inter-entity/system communication without a bunch of tooling to support it is always going to be a bit cludgy and hard to follow as it's by necessity dynamic at runtime. It is really useful though so writing tooling for it is a good idea.
Perf impact could be pretty big if your ECS uses archetypes and needs to do a lot of copying data around as components are added and removed. But in my experience these sort of events tend to be low frequency so probably not terrible. Always good to measure though!
Don't feel hide bound to stick within the confines of the ECS setup. It's a tool not a way of life! Straight forward message passing might be much cleaner and clearer or there might be a better data sharing strategy that can live outside the ECS itself. All frameworks provide fun puzzles of how to fit functionality into them when going round them is sometimes simpler and clearer!