armandfaux/kaelinn-engine

An engine for building 2D games and simulations

Kaelinn Engine - v-1.0

Kaelinn Engine is a 2D engine for building games and simulations

Prerequisites

The engine is fully self-contained which means you don't need to worry about the dependencies. Instead, you'll just have to install Conan, a packet manager that will download all the necessary libraries for you See : https://docs.conan.io/2/installation.html

👥 The Team

- Armand Faux - Lead developer, Project manager

[email protected]

Contributors (until v-1.0) :

- Hugo Eschlimann - Devops engineer

[email protected]

- Luca Orelli - Network developer

[email protected]

- Thibault Bernuz - QA, gameplay developer

[email protected]

kaelinn-engine's Issues

Performance optimisation

The current way to reach entities and components is too slow and must be optimised
Areas of improvements are :

• The way we represent entities
• The storage of components
• How entities and components are reached by systems
• How systems could work faster with the data they are given
• Entity "chunks"

Any major change here MUST be preceded by performance tests and FPS measures to analyse the actual performance gain.

Compilation process check

• Check that the sample project successfully compiles with the engine source files
• Fix any compilation error
• Improve the CMakeLists and "games" folder architecture if needed (coherent pathing)
• Add documentation in the CMakeLists

Client-side prediction

This issue is mandatory to #22
No due date is planned

• Add Physics prediction to reduce the amount of data sent to the client

[SpriteComp] Automatic rect assignation when no value is given

When no value is given, the rect of the sprite is set to (0, 0). Thus, it won't be displayed by the render system.
The engine doesn't give any feedback to the user about this issue, and this can lead to bugs that are annoying to deal with.

Implement a file-reading image size detection mechanism for when no rect is given to the SpriteComp ctor.
Then, assign the rect to the image dimensions

Delete all DS_Store files

rm src/.DS_Store
rm sample/.DS_Store

Kaelinn CLI

Context

This CLI is a global idea that I've had to make the engine easier to use

For a first iteration, it could include basic commands like such :

• Init game (generate project files, CMakelists, templates ?)
• Build engine / game (compilation)
• Help
• And more...

[PhysicSystem] Do not emit position events if no active NetworkSystem

SfRenderSystem tries to load missing files infinitely

When an asset is missing, the render system will try to load it every frame
This bug might cause potential performance issues

Suggested fixes :

• Add a "blacklist" to the system to make sure it won't check a resource twice
• Change the way system works by giving them their own list of entities - refreshed on creation and deletion only (instead of once a frame)

SDL Render System

• Rename current RenderSystem to SFRenderSystem

• Rename current InputSystem to SFInputSystem

• Create a SDLRenderSystem

• Create a SDLInputSystem

Basis of a sample project

Develop a game or simulation using the engine tools
This game will be included in the source files and would serve several purposes :

• Showing how to use the engine properly as a part of the documentation
• Testing the compilation, building process and stability of the engine
• Testing the new features in a real environment (functional test)

This example shall be updated as the engine evolves, and demonstrate as many features as possible, while keeping it simple enough.

[RenderSystem] [SpriteComp] Add x & y scale

Rename the game class

Since the Kaelinn Engine is meant to be used for varied sorts of projects, its main class should be renamed in a more generic way
"Core" would be a good candidate for that matter.

Entity representation rework

Entities were first designed to be a class in the engine, because classes are easier to visualise and understand.
Each entity currently owns its own components. While this is a simple and easy to use method, it's not optimised and causes much overhead.
I want Kaelinn to be faster and a rework of the entity management seems mandatory at this stage.

• An Entity will no longer be a class, but rather a mere "id" (unsigned int)
• This id will also be an index for accessing the entity's components and its signature

This is likely the biggest change ever made that deep in the engine structure. However, significant performance improvements are to be expected.
This rework will cause many side effects, since every module will be affected. The most critical parts of the code that need refactorisation are the following :

• How and where are the components stored (no more entity objects to store them)
• How system interact with entities and components
• How we create, delete, and modify entities
• How we keep a track of the entity "type"

See #19, #20

Components storage

Since components are no longer stored in the entities (see #18), we need to find a way to store them efficiently
std::unordered_map<> seems like a good candidate
it will map an entity ID with the shared pointer to a component

In the original design, a Scene was defined as a set of entities and some responsability on the creation and handling of those entities. The Scene class will now entirely bear this "Entity Manager" role.

Implementation :
UM = std::unordered_map

• UM<CompType, UM<Entity, std::shared_ptr>> _allComps
• All comps, or comps of a specific type can be accessed via the getters

Vector2 utilitary methods

Implement key concepts of 2D geometry as public methods of the Vector2 class

• double Vector2.magn() // Return the magnitude (length) of the vector
• double Vector2.distTo(other) // Return the distance between this vector and the one given as parameter

Define and implement standardised units

In prevision of the advanced gravitation system, define the required unit standards to simplify the computation within the engine.
The systems and components that use length, time, or mass data, will be updated to match the new units

• unit of length
• unit of time
• unit of mass

Simulate a high number of entities

Enhance the current sample project with a high number of entities with random velocities and basic interaction
This will serve as a reference to execute performance tests and measure the engine speed : the main objective of v-1.1

• Moving entities on screen at different scales (50, 100, 500, ...)
• Entity generator (through scripting ?)

NetworkSystem restoration

Requires #21

Refactoring 'Vector2' into 'Vector<N>'

Possibility to create any dimensional vector from a template class

Macro instead of std::string as window mode parameter (SfRenderSystem)

The SfRenderSystem ctor should not take a std::string to decide of the window mode.
Instead, add macros in the header file.

The naming convention is still to be determined
FULLSCREEN
FULLSCREEN_WINDOW
FULLSCREEN_MODE

Unit testing on new Entity and Components

Scripting system

A scripting system was first implemented before v-1.0 but removed during the release

Entity signature

Keeping a track of the components an entity have or doesn't have is crucial for the engine to work properly and smoothly.
Since we are getting rid of the Entity class in v-1.1 and its methods to handle components, it's necessary to implement an Entity signature that will do the same job, but faster.

See issue #18