Project type: C Simulation

Timeframe: 2022

The program is split into a set of distinct submodules. The ecs, adb, ui, engine and sim modules. Of these modules the adb and ecs modules are entirely standalone, the ui module depends only on SDL2, the engine is dependent on all others except sim, and sim is dependent on engine.

Code

NOTE: Most of these modules were developed separately and as standalone libraries. As such, they have vastly differing naming conventions. Still, each module is internally consistent about its own naming scheme. I just tend to switch style every project. For clarity, the ecs and ui modules use camelCase while the adb, engine and sim modules all use snake_case.

Engine

The engine module provides the program's entry point and update/render/event loops. It communicates with the sim by declaring three functions as extern without defining them. The sim then defines them allowing the engine to call functions from the sim. The functions in question are:

• sim_config, which allows the sim to configure important parts of the engine by adjusting a settings struct.
• sim_init this is called after all other modules are initialized and allows the sim to initialize its components, systems and entities, as well as load assets.
• sim_quit which gives the simulation the chance to clean up any allocated resources after the main loop ends but before the other modules are terminated.

Sim

The sim module is the only module that actually interacts with anything boid-specific. Whereas the other modules are more so supporting of the simulation. The sim can be divided further into the part that interacts with the engine module, and the part that actually models and simulates the boids. The part that interacts with the engine is responsible for registering components and systems with the ecs, loading assets, and spawning the boids.

The second part of the sim module are the functions that make the boids behave the way they do. The ones that run as systems from the ecs all follow the signature of an ecs system function. They take in a list of entities, a list of the corresponding component masks, the number of items in both lists, and the delta time of the current frame. They then loop over the entities and perform specific actions for each one. In order to avoid looping over every boid in the simulation every frame, for every boid. The boids cache boids that are within the range of the behaviour with the furthest range.

When the boids that are close enough to interact have all been cached, the actually modifying systems start running. As a demonstration is the separation system, which keeps the boids apart from eachother to avoid all of them forming a singularity. For each boid, the system loops through all nearby boids, keeping a running average of the positions of each boid nearby enough to be within range. After all nearby boids have been accounted for, the boid's velocity is adjusted to move away from the calculated average.

Cohesion and alignment are similar enough that i wont place them here. Cohesion is the opposite of separation, and alignment is practically the same but with velocity instead of position. The mouse does the same as cohesion but with the mouse, and thus without the need for an average. The wall behaviour pushes the boids back onto the screen when they exit it.

ECS

The entity-component-system (ecs) module manages the runtime object model where Entities are numbers, Components are blocks of memory attached to an entity and Systems are function pointers with a component requirement. This is the library that the boids where made to test. The below code consists of snippets showing initialization and uses of components systems and entities.

Asset database

The asset database (adb) module is the module responsible for managing asset data. So it has functions for loading data from files, getting loaded file data, and releasing data after it is no longer needed. To keep this module generic, it has runtime defined rules for managing files through file handler functions.

UI

The ui module is based on the immediate mode graphical user interface (imgui) paradigm. This is a paradigm where there is no intermediate storage between the gui and the data. The gui directly modifies the data and vice versa. In my implementation this is done by sending the gui functions pointers to the data they represent as parameters.