[avolcano]

I was looking at EnTT's API when building a little toy ECS of my own in JavaScript. Since I'm working in JS, I haven't really tried to copy its internal architecture since it doesn't quite make sense for a higher-level GC'd runtime, but I think the public API was a really handy reference for the kinds of things a practical ECS needs to have. It's a really impressive and robust project, and the documentation is super thorough and worth a peek if you have any interest in game architecture.

(slightly off-topic, but I'm excited to have a venue to ramble a bit about this:) ECS is really cool, and I'm excited about using it more for my games. The "cheap" (de)serialization by moving all state into pure, data-only components is really fascinating - I've been playing around with building networked multiplayer games for a while now, and I'm currently experimenting with rollback netcode.

A key part of rollback is saving your state every frame so you can load it if you need to roll back, and ECS makes saving/loading easier to reason about, since you can "just" grab the components and their associated entity IDs and load if needed (EnTT, for the record, has an API for this[1], though they leave the actual (de)serialization up to you). Of course, JS's lack of a memcpy equivalent makes this much harder than what you could do in C++, which has lead me to experiment with immer[2] in my ECS, which uses structural sharing to avoid mutation, so you can get a "copy" of your state by just keeping a reference to it, as future updates will make new objects. This, of course, theoretically could make a ton of garbage (e.g. updating your position every frame would create a new Position object every frame), which is not great for high performance games. I'm not sure how bad this will be in practice - JS GC is relatively smart and fast these days, but I haven't tried doing much beyond little pong or platformer demos yet. I'd also imagine that, like, doing a deep clone of my state tree every frame (or doing the whole JSON.stringify/parse dance if I stick to primitive values) probably generates just as much garbage. Maybe if I could integrate immer with some kind of object pool it'd avoid these issues, but I have no idea how useful object pooling is in practice in JS...

[1] https://github.com/skypjack/entt/wiki/Crash-Course:-entity-c... [2] https://github.com/immerjs/immer

[nicoburns]

> but I have no idea how useful object pooling is in practice in JS...

I'm pretty sure most JavaScript games use object pooling extensively. GC is definitely an issue if you want to hit 60fps. Even for non-games actually.

[fenomas]

I've been doing a lot of gamedev and performance tuning in JS, and I do a fair bit of object pooling, but I don't think I've ever found a case where I was able to measure any actual impact on performance from it. It seems like either modern JS engines (well, v8) are incredibly good at dealing with small short-lived objects, or maybe my specific use cases aren't heavy enough for pooling to be meaningful.

[avolcano]

Yeah, I suspect this is one of those things where when you Google it, people are mostly like "why would you ever need pooling in JS," but then it turns out pooling is used under the hood in a lot of game frameworks.

I know Ecsy[1] is using it, which makes sense because that's targeted at apps building for WebVR which really cannot afford GC pauses, so I guess it must have some merit.

I guess I could try monkey-patching immer to have it pull from a pool when creating new objects? Theoretically if it just used nominal typing (re: classes) to pick objects out of the pool and overwrite all the fields on it, as I assume it normally would do with a brand-new object, this could work out okay. Could just do pooling on the top-level component objects and deal with GC on any nested objects to simplify things (especially because nested objects probably wouldn't have classes associated with them).

[1] https://ecsy.io/docs/#/manual/Architecture?id=components-poo...

[gameswithgo]

and 60fps is not even the gold standard anymore, 140+ is, the pickiest people for competitive shooters will want ~200+

You don't have a lot of ms

[whateveracct]

1) Isn't that tick rate not frame rate? Is there really a tangible benefit to rendering 140fps over 60? I always read that beyond 60 had huge diminishing returns and was hard to detect as a human.

2) Is it really necessary for anything beyond a competitive shooter with bullets flying around? Outside of the bullets, fighting games are as or more precise than the average shooter and 60fps continues to be the standard there and I don't think >60 tick rate would bring any big value to a fighting game. A 60fps game with no buffer can already yield situations that are close to or beyond human execution (see: Melee)

[avolcano]

I'm not actually sure requestAnimationFrame() in a browser ever gets you >60 fps. At that point, honestly, you'd probably need an independent render thread (doing some degree of interpolation) and stick to a 60fps logic tick. Which you can theoretically do in JS using web workers, though I know message-passing incurs some serious overhead in that case.

[detaro]

Depends on the browser, but at least in Firefox and Chrome it should match actual refresh rate if the graphics stack plays properly. (i.e. I don't know if it does if GPU acceleration doesn't fully work)

[modeless]

requestAnimationFrame absolutely supports higher than 60 FPS. You can also do all rendering off the main thread with OffscreenCanvas, though you can certainly hit 144 Hz or higher without doing that.

[pjmlp]

Currently OffscreenCanvas is only supported on Chrome. :\

[BuckRogers]

And the new Edge? Of browsers from major vendors at least, I thought Edge was worth mentioning since it recently overtook Firefox in desktop market share.

[danbolt]

Phaser 3 (and its predecessor Phaser 2) provide helper code for managing object pools[1]. I can imagine any non-toy project takes advantage of pooling for speed when it can.

[1] https://photonstorm.github.io/phaser3-docs/Phaser.GameObject...

[vvanders]

You should do this in both GC'd and non-GC'd languages. Obviously C/C++/etc give you more options for arenas and the like. If you have a well bounded upper limit there's a while lot of good reasons to preallocate(locality of data, GC pressure, etc).

Some engines I used to work with would assert() on malloc/free if it happened outside certain safe regions of execution.

[fenomas]

I made an ECS in JS and have been using it for some time. It's not particularly designed for the kind of rollback you're talking about, but you might find it useful as a comparison:

https://github.com/andyhall/ent-comp

In mine I store each entity's state for a given component as an object (e.g. `{ mass:1, velocity:[0,0,0] }`, so the internal storage of the ECS for a given component is an array of such objects. To really optimize for the "cache and rollback" kind of behavior you're talking about I guess it would be ideal for the internal storage to be flat arrays of numbers, but at first blush it seems like that would make the implementation of the ECS itself kind of hairy.

[mtsr]

Since you generally want to keep a set number of time steps the commonly used data structure for this is a ring buffer. No garbage and all you do is increment the index (with wraparound) every step.

Not a lot of technical details, but this video has a great general overview https://www.youtube.com/watch?v=W3aieHjyNvw