- Added boost-atomic and boost-thread as dependencies for concurrency support
4.5 KiB
fennec
Table of Contents
Introduction
This file outlines the core engine structure and all necessary systems for the engine to run.
Systems
This section outlines core systems to the engine and brief overviews.
Events
fennec will be largely event based, the system should be able to handle multiple event types without having any type-specific code. There will be a few categories of events, predominantly on-demand and delayed events. On-demand events are fired immediately, which is useful for events related to graphics and audio. Delayed events are fired at the next tick or after a certain period of time, this is useful for physics events which can't be handled immediately without potentially harming the state of the physics engine. Events should be optionally able to be handled with multithreading.
Scene
The core structure of the engine and its levels will be a scene hierarchy. The hierarchy will be implemented using a rooted-directed tree (rdtree, not to be confused with rbtree). Each element in the tree will be a node with a name and some very basic flags. Component dependent behaviour must be handled in systems to avoid the overhead of an object-oriented scene hierarchy. This is predominantly caused by the recursive nature of parsing an object- oriented scene hierarchy where each node records its children and updates them accordingly.
Scripts
Scripts won't be handled the same way scripts are in other engines, they will be translated as a system which will be data-oriented. This is to reduce the overhead of the object-oriented approach in C++ while maintaining the appearance of being object-oriented.
AI
AI will be a fairly multi-parted system as we need to handle different use-cases. The first use case is characters that can "walk" and "jump" on surfaces. The second use-case is characters that "fly" in some manner. The static path generation will be the only difference between 2D and 3D.
Physics
Physics, like other systems, will be separated into 2D and 3D specific implementations. This system should be able to handle both Newtonian Rigid-Bodies and Soft-Bodies. The 2D and 3D systems should be able to co-exist but not interact. This is for such cases where one might decide to have a minigame with physics enabled in a 2D environment.
Graphics
Graphics, like other systems, will be separated into 2D and 3D specific implementations. Graphics will exist on a separate thread that handles "frames" vs "ticks," see definitions below for more information. From an abstract, the graphics system should be able to handle static models, dynamic models, skeletons, materials, lights, lighting models, and post-processing effects.
Audio
Audio may actually be implemented generically since the principles of spatial audio apply identically in both 2D and 3D. The only thing that may change for 2D is which axis is "up" and which axis is "forwards," for example side-scrollers vs top-down. However, this does not mandate specific implementations and rather just aliases which axis is "up." The X-axis can always be "left" and "right" while the Y axis may be interpreted as "up" or "forwards." Audio also won't be handled in the same manner as other systems which have explicit ticks and frames.
Core Game Loop
The core game loop is divided into Ticks and Frames. Ticks represent updates in the engine state while Frames represent the generation of the visual output of the engine.
Tick
- Update
- Events
- Scripts
- AI
- Physics
- Newtonian Commit
- Apply Forces (Updates Accelerations)
- Acceleration (Updates Velocities)
- Apply Velocities (Updates Position and Rotation)
- Constraint Resolution
- Collision Detection
- Collision Resolution
- Collision Response
- Calculate Forces & Velocities
- Queue events for next tick
- Newtonian Commit
Frame
- Physics
- Physics Interpolation
- Graphics
- 2D Graphics
- Generate 3D Mask
- 3D Graphics