Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Thought Experiment: Using the ECS Pattern Outside of Game Engines

adventures.michaelfbryan.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#61

Post by p_l »

billfruit wrote: post #37
p_l wrote: post #35

Earlier quoted context omitted.

There's a game that already did that, Sword of the Stars 2. Widely panned at release due to being forced to release old code after VCS failure, though I'd argue the only problem after patches were left was that movement logic change didn't play out well (it was a brave attempt though). Had some bad performance issues but I never tracked down whether they were related to SQLite or issues in their engine.

Are you referring to the rougelike Sword Of the Stars:Pit or to the base game itself

No, I'm referring to 4X Sword of the Stars 2 itself. The Pit happened later, on a different engine (SotS2 is heavily windows-specific .NET code with DX10 dependency, iirc)

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#62

Post by heretoo »

TeMPOraL wrote: post #23
fulafel wrote: post #21

In the Clojure world, this used to be a popular way to structure backend apps: https://github.com/stuartsierra/component > Components provide some basic guidance for structuring a Clojure application, with boundaries between different parts of a system. Components offer some encapsulation, in the sense of grouping together related entities. > Each component receives references only to the things it needs, avoiding un…

Used to be? What replaced it? I used it in my last Clojure project, and I'm about to start expanding it further; should I replace it with something else?

try integrant

https://github.com/weavejester/integrant

You can move from using component's functions/macros to using a map and cross references using reader literals.

Having used both, I find integrant to work better for me.

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#63

Post by p_l »

TeMPOraL wrote: post #38
p_l wrote: post #35

Earlier quoted context omitted.

There's a game that already did that, Sword of the Stars 2. Widely panned at release due to being forced to release old code after VCS failure, though I'd argue the only problem after patches were left was that movement logic change didn't play out well (it was a brave attempt though). Had some bad performance issues but I never tracked down whether they were related to SQLite or issues in their engine.

Well, of course there is. Here I thought I'm doing something somewhat original... Fortunately, existence of prior art doesn't invalidate any of the goals I had for this experiment, so I'll just carry on with it.

Of course it does not invalidate your experiment, but I wanted to suggest maybe looking at save files from the game.

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#64

Post by aliswe »

spankalee wrote: post #60
aliswe wrote: post #55

Earlier quoted context omitted.

Are you saying that this is different from mixins?

Absolutely. Single inheritance is a degenerate form of mixin inheritance, where a subclass has a single, fixed superclass. Mixins simply fix single inheritance so a subclass's parent class is parameterized, and so concrete classes can be composed of several non-related mixins (which will often seem like multiple super-classes). ECS is a much different and bigger beast. It's a runtime composition pattern, and has almo…

I get that they are different "in action" (I also appreciate that ecs is implemented differently in various places), but conceptually, and for all intents and purposes, they should be regarded as quite similar if I'm not missing something?

Is it the fact that (some implementations of?) mixins' members could collide and conflict with eachother?

Your 3rd paragraph, did you miss "nothing" or perhaps another word?

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#65

Post by Razengan »

5cott0 wrote: post #42

Apple 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

#66

Post by Razengan »

TeMPOraL wrote: post #9

Which ECS? :). Despite "clear" definition from Wikipedia, ECS as a pattern suffers from multiple personality disorder. There are several different goals that all share the same name, and different implementations pick a different goal set, ending up looking not quite the same, and getting different kinds of benefits. So outside games, if you pick "ECS as composition over inheritance", you get something like here, or…

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 more than arrays, and components can query their entity for other components at runtime.

So there may be a MouseEventComponent or a TouchEventComponent, added by the engine depending on your device, then a PointerEventComponent to provide a layer of abstraction for OS-independent player input, and finally some PointerControlledShootingComponent etc.

Or a KeyboardEventComponent feeding a generic DirectionEventComponent, and you can swap the keyboard for a gamepad at runtime, or have different input sources for different entities.

To my understanding, doing stuff like that did not seem as intuitive in the more "traditional" ECS patterns, as opposed to just editing a list of classes to update every frame, or components holding references to other components in other entities (e.g. to share an input stream, or to implement a self-playing demo mode.)

It's meant to be for 2D games only and I haven't hit a wall with it so far, performance or otherwise, but some things like serializing the object graph for save/load or parallel execution might be a little tricky when I get to those.

My goal is to eventually be able to describe game scenes with a declarative SwiftUI-like syntax, where you'd add components like view modifiers and so on. Come to think of it, SwiftUI might be considered as an ECS for apps, or is that stretching the definition a little too far. :)

[0] https://github.com/InvadingOctopus/octopuskit

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#67

Post by skybrian »

spankalee wrote: post #59
skybrian wrote: post #46

Earlier quoted context omitted.

Yes, ECS is usually about runtime changes in behavior. It also uses IDs rather than hard references, like in a database. Deleting an object makes references to it invalid, rather than references keeping objects alive like in a functional or object-oriented object graph.

But the complaints about OOP in the article are all about the difficulty in modeling orthogonal traits in a single-inheritance hierarchy. That is definitely addressed with mixins. Nothing in the "Inheritance isn't Always the Best Tool for the Job" section talks about runtime changes in behavior.

It does touch on it towards the end:

> Most object-oriented languages are designed so that an object's underlying type will be the same for its entire lifetime. This makes things interesting when users want to scale a Circle without maintaining aspect ratio.

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#68

Post by ncmncm »

Who are these people who think that inheritance is the solution to every architectural problem, or any?

I didn't think that Java coders were especially well represented in the gaming world. It has been over 20 years since C++ programmers learned that inheritance is just a way to dress up function pointers (not that that does no good, but function pointers are pretty specialized machinery).

Seriously, you don't need to use a named style to write programs. Your language offers lots of different facilities you can put together in any way that is useful to achieve your aims. Functional, OO, ECS, MVC, procedural, data-oriented, reactive, whatever -- it is all just code.

You have only three problems: code needs to be organized well enough that you can understand it, code should run fast enough, and you should be able to change one thing without rewriting everything else. Nothing else matters.

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#69

Post by TeMPOraL »

Razengan wrote: post #66
TeMPOraL wrote: post #9

Which ECS? :). Despite "clear" definition from Wikipedia, ECS as a pattern suffers from multiple personality disorder. There are several different goals that all share the same name, and different implementations pick a different goal set, ending up looking not quite the same, and getting different kinds of benefits. So outside games, if you pick "ECS as composition over inheritance", you get something like here, or…

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 provided places to hook component mount/unmount code.

To me, doing stuff like this seems more intuitive than more "traditional" ECS approaches, but perhaps that's because I was never comfortable with the idea of Systems.

Eyeballing the code, the only slight architectural drawback I see is that the code must always belong to a particular Component, even when that code operates on multiple Components as equal partners (this is the ECS eqiuvalent of "your language doens't have multimethods" problem in OOP). If I understood correctly, you solve that by creating a Component composing other Components.

One particular thing I like about your overall architecture is that it explicitly covers state machines - both at the game (scene) level and at per-entity level. Various other ECS examples I saw on the web tend to completely ignore this topic, and it's pretty much the first thing I hit when I start using them: where do I put state machines?

Overall, OctopusKit looks like a solid piece of work. Congratulations, and do a Show HN: if you haven't done it yet!

--

[0] - https://invadingoctopus.io/octopuskit/documentation/architec....

Re: A Thought Experiment: Using the ECS Pattern Outside of Game Engines

#70

Post by fulafel »

BubRoss wrote: post #33
codetrotter wrote: post #16

Earlier quoted context omitted.

> If you go for "ECS as a performance optimization" - a frequently touted benefit - you'll end up storing a lot of global arrays (perhaps arranged in structures), each packing every instance of a component's property across all entities. This is basically what I am doing in the backend I am writing for an app that I am working on. (Also not a game btw.) No database, no overhead :D You really can fit a lot of data in…

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).
Post reply on HN