Directory Structure

Directory Structure

./

• build/
• cmake/
• • modules/
• editor/
• pilcrow/
• • dependencies/
• • • <Dependency>/
• • • • include/
• • • • • <Include Path Name>/
• • • • debug/
• • • • release/
• • • • src/
• • engine/
• • • core/
• • • • include/
• • • • • entity/
• • • • • system/
• • • • • world/
• • modules/
• • • <Module>/
• • • • include/
• • • • • <Include Path Name>/
• • • • • • components/
• • • • • • events/
• • • • • • systems/
• • • • lib/
• • projects/
• docs/
• scripts/

Dependency

A dependency is third-party software that is used in the engine. The code and binary files for all dependencies get stored in the dependencies/ folder.

Include Path Name

The include path name is what would go in the C++ source code that is including files. It will be added to the include directory of dependent projects, and can be shortened as a courtesy. As an example, you might have a renderer implementation called My 3D Renderer, but opt to use m3d as the namespace to shorten it. This same short-hand name can be used for the include path. In another project, someone might include a renderable component it defines like this:

#include <m3d/components/renderable.h>

Modules

Modules are how functionality is added to the engine. Modules have 3 primary pieces which interact with the engine:

• Components
• Events
• Systems

Components

A component is a C++ type containing data. Components are used to store the state of an Entity. They could be anything from position in the world to the amount of damage a bullet deals on impact. These components get associated with an Entity, and any Entity with all the components a System needs will be processed by that System.

Events

Events can happen during the course of a simulation and various systems may choose to react to them. When a module is going to produce a new kind of event that may be consumed by other modules, those events should be stored in the events folder so they can be exposed to other modules through code and the editor.

Systems

Systems are where behavior is defined. They can have behavior that falls into two broad categories:

• Event handling - response to an event that occurred such as an Entity spawning, the frame ending, or collision occurring
• Entity processing - Some tasks need to be done every frame to advance a simulation, such as rendering and movement

Event handling is done by listening for events and specifying logic that should be run on occurrence of those events.

Entity processing requires specifying which components are necessary for the behavior to act on. Any Entity that has those components will be subject to the behavior.