ElixirConf 2023 - Andrew Berrien - ECSx: A New Approach to Game Development in Elixir

Learning Resources Talks
,
1

ElixirConf: ElixirConf 2023 - Andrew Berrien - ECSx: A New Approach to Game Development in Elixir

Comments welcome! View the elixirconf tag for more ElixirConf talks!

4 Likes
2

If anyone has any questions please don’t hesitate to let me know!

9 Likes
3

Very cool!
I will remember to use it if I ever start a personal game project.
Adding first-class support for turn-based mechanics will be very welcomed too. :slight_smile:

1 Like
4

So, I’ve done a ton of automation over the years, and I have a big interest in AI’s and flight simulators. I am wondering about the limits of the framework in terms of units managed. I am sure the framework can handle a very large number of “small” units, but as they get more complex the physical limits of the PC become an issue. Have you ever run the numbers?
I did an AI years ago using a finite state machine. I am tempted to see if I can design one in your framework.

5

Hi @oldpond ! Yes, of course there is a limit for each app where you will max out your hardware capabilities, but there are a few things in ECSx which can help with this.

First, we’ve kept all data writes and reads in-memory (implemented with ETS) for best performance. With this approach, we get constant-time operations regardless of how large your app’s data layer gets. In my experience, ETS is plenty fast enough, but it’s the complexity of algorithms used in System logic which will bottleneck performance first, so it’s important to optimize this logic as best you can.

Second, the ECSx framework adds very little overhead to its underlying data operations, so the performance should be in-line with existing ETS benchmarks. The main performance concern within ECSx itself, is that Systems are serialized via GenServer (the “Manager”) to avoid race conditions and preserve data integrity per-tick. This means by default, you’re running on a single thread without concurrency. To squeeze the most out of your hardware, it’s important to add concurrency within each individual System, if possible. An example of this would be a System that checks the velocity of each entity and adjusts the position coordinates appropriately. Instead of

  • fetch velocity components
  • for each entity: fetch position component(s), run the mathematical calculation(s), update position

we ideally add concurrency like:

  • fetch velocity components
  • split them into batches
  • spawn an async process/Task for each batch which does the previous step 2
  • System waits for all Tasks to finish before completing

which will ensure all your hardware is being put to use, and should be significantly faster for Systems with expensive logic.

Then there is the ECSx Live Dashboard - this will monitor each System individually, as well as the app’s overall performance, and provide a comparison to the “limit” which would cause slowdown/instability. There is always a hard limit of how much time can be used on computation, because each server “tick” is a set length of time. e.g. a server with tick_rate: 20 will expect to run the System logic 20 times per second, creating a time limit of 50 ms. So if you check the dashboard and see that it takes 45 ms for each tick, you know you’re at the limit, and will need to attempt one of the following before adding more load:

  • Lower the tick_rate setting to allow more time per-tick
  • Further optimize System logic to reduce the time it takes (adding concurrency may be helpful here, as described above)
  • Upgrade the hardware

Hope this helps! If you move forward with ECSx for your use-case, I’d love to hear about it, and happy to answer any further questions you might have.

2 Likes