flecs VS Boost

I've also been enjoying building My First Game™ in Bevy using ECS. The community around Bevy really shines, but Flecs (https://github.com/SanderMertens/flecs) is arguably a more mature, open-source ECS implementation. You don't get to write in Rust, though, which makes it less cool in my book :)

I'm not very proud of the code I've written because I've found writing a game to be much more confusing than building websites + backends, but, as the author notes, it certainly feels more elegant than OOP or globals given the context.

I'm building for WASM and Bevy's parallelism isn't supported in that context (yet? https://github.com/bevyengine/bevy/issues/4078), so the performance wins are just so-so. Sharing a thread with UI rendering suuucks.

If anyone wants to browse some code or ask questions, feel free! https://github.com/MeoMix/symbiants

Flecs does just that: https://ajmmertens.medium.com/why-it-is-time-to-start-thinking-of-games-as-databases-e7971da33ac3

I'm trying to optimize my workflow as much as possible, and came across this thing called an ECS. After doing a little bit more digging I found some decent guides on how you would make one, I also found one premade called FLECS. FLECS is nice and all, but I was looking for something more simple that just has the bare bones of what I need and is also configurable. I haven't been able to really find anything like that, so I was wondering if anyone had an example of maybe their way of implementing an ECS. I know how to go about it, but I'm unsure of exactly what the code would look like.

Since we wanted a common game simulation that would be on both the server and the client we looked into a few libraries that would fit our ECS needs. It was decided we were going to write this common part of our game in C++, but rust was considered. C++ was a familiar language for us so naturally EnTT and flecs came up right away. I had used EnTT before, writing some small demo projects, so our choice was made based on familiarity. In order to integrate with Unity we created a small C interface to communicate between our simulation code and Unity’s C#. Here’s close to what it looked like. I removed some parts for brevity sake.

Repository: https://github.com/SanderMertens/flecs

This is the project: https://github.com/SanderMertens/flecs (query engine implementation lives here: https://github.com/SanderMertens/flecs/tree/master/src/addons/rules)

There's also a performance question. While we can now use Blueprint nativization to convert Blueprints to C++ the result will be a fairly naive version, fast enough for most purposes but not if you're trying to push every bit of performance. This is where you're looking at making sure you're hitting things such as using the CPU cache as well as possible for an ECS system (Look at ENTT or Flecs if you want to see what they're about and why you'd want one), or a system needing to process massive amounts of data quickly such as the Voxel Plugin.

If I knew C++ and I'd heard about it before I started my current project, I would have been tempted to use this https://github.com/SanderMertens/flecs which can be built to WASM. Of course you still need JavaScript in the front end to link to the WASM part. I've recently been using esbuild to bundle my front end code, which does a pretty similar job to webpack, but is a bit faster.

When do think bevy will support entity-entity relationships ? https://github.com/bevyengine/bevy/issues/3742.

Flecs ECS already supports this: https://github.com/SanderMertens/flecs/blob/master/docs/Rela...

For a modern engine you’re probably best looking at Unity’s DOTS. You may also want to check out some of the different open source ECS libraries such as flecs and EnTT are two popular ones for C++, but there’s lots of them. Largely you’ll see lots of different approaches taken, all with their own pros and cons. Not all of them will be performant (some focus more on the design benefits) while others will be optimised for certain use cases. What you should prioritise will depend on your specific needs.

git clone https://github.com/boostorg/boost.git -b ${{ inputs.branch }} "${{ inputs.boost-dir }}" --depth 1 git submodule update --depth 1 -q --init tools/boostdep python tools/boostdep/depinst/depinst.py --include library_i_want"

Any thoughts on why it has exactly the same name as a popular source available project that's been around since the 1990s?

earliest archive: https://web.archive.org/web/19991011120524/http://www.boost....

latest commit (today): https://github.com/boostorg/boost/commit/7727baea944c6365301...

naming in 2023: "The Boost project provides free peer-reviewed portable C++ source libraries"

naming in 1999: "The Boost web site provides a repository for free C++ libraries"

Hmm...

include(FetchContent) FetchContent_Declare(boost URL https://github.com/boostorg/boost/releases/download/boost-1.81.0/boost-1.81.0.tar.xz ) FetchContent_MakeAvailable(boost) ...

set(BOOST_INCLUDE_LIBRARIES system thread) # enabled libraries set(BOOST_ENABLE_CMAKE ON) # CMake support FetchContent_Declare(boost GIT_REPOSITORY https://github.com/boostorg/boost.git ...

In fact, boost has cmake files now — pretty recent addition and I haven’t got around to testing, but no reason to think it doesn’t work. https://github.com/boostorg/boost. Also, boost is getting more modular with every release — more and more libraries can be pulled independently with mostly only depending on boost.core. Asio has been like this forever, but Boost.math is a recent example to the bandwagon. You can find an independent release package for math on GitHub now.

Do you build boost from sources? If so, maybe get the tar balls from their Github repository?