Earlier quoted context omitted.
New NVMe drives claim 5GB/s on PCIe 4, is memory mapping something like that not good enough for you already?
In these applications you primarily care about latency. Even these new SSD's have latencies 3 orders of magniture higher than DRAM. The 20 usecs is access time is about 100k executed instructions (scalar + single thread).
A Thought Experiment: Using the ECS Pattern Outside of Game Engines
71–75 of 75 posts
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#72Earlier quoted context omitted.
I could use some critical feedback on my system [0]. I went with what felt to be the most intuitive pattern for my own brain, but later found that it was apparently against the grain: making everything plain old classes and keeping all the logic inside components. When I need a particular behavior, I just create a new class and keep everything related to that behavior in a single file. Entities and systems are little…
That's an interesting take. I read the README and the architecture document at [0]. Based on that, the way I see it, your approach is different but essentially equivalent to the typical non-performance-oriented ECS architecture. Entities are still runtime-configurable, Component updates are done in batches and in appropriate order. You've thinned out Systems, moved their code to their corresponding Components, and pr…
> the ECS equivalent of "your language doesn't have multimethods" problem in OOP ... you solve that by creating a Component composing other Components.
I'm not sure about having solved that, but yes, a component may check its entity for other components to inspect and/or modify, even add/remove components from its entity, or add/remove entire entities from the scene (like a ShootingComponent asking a PhysicsComponent to simulate recoil, and spawning bullet entities.)
If a dependency is missing, a component alters or omits parts of its behavior or silently skips its frame update.
I'd really like to try the SwiftUI idiom in games, where the code is a declarative description of a scene, that an engine can take to construct the actual scene using whatever architecture it wants under the hood.
I also wonder how far you could take SwiftUI itself for making games without using any other framework.
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#73Earlier quoted context omitted.
In these applications you primarily care about latency. Even these new SSD's have latencies 3 orders of magniture higher than DRAM. The 20 usecs is access time is about 100k executed instructions (scalar + single thread).
In what applications? The parent didn't even say what they were working on. Everyone wants ideally wants a perfect memory technology with no latency, large sizes and persistence, so I'm not sure what you are talking about exactly. If something needs less latency, you cache it or load it into memory. You seem to be saying that this current technology, that actually exists, is not good enough for a mystery application…
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#74Apple provides an ECS in gameplaykit that can be used in iOS/UIKit apps, not sure why anyone would want to though. https://developer.apple.com/documentation/gameplaykit
> not sure why anyone would want to though. What do you mean by that? GameplayKit has its limitations, but I've been building an entire engine around it, and I like it so far, especially for the ability to stick with pure Swift and native APIs: https://github.com/InvadingOctopus/octopuskit
Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines
#75Earlier quoted context omitted.
> not sure why anyone would want to though. What do you mean by that? GameplayKit has its limitations, but I've been building an entire engine around it, and I like it so far, especially for the ability to stick with pure Swift and native APIs: https://github.com/InvadingOctopus/octopuskit
Not sure why anyone would want to use GameplayKit ECS as a replacement for MVC/MVVM arch in a UIKit based app.