benny-n / gear Goto Github PK

At the beginning, the project tree should look close to this:

gear
___| src
_____|MathEngine
_____|PhysicsEngine
_____|RenderingEngine
_____|ECS //or Entity, Component, System as seperate folders, also a possibility

We can start with creating this tree and filling the folders with dummy modules with meaninful names but no functionality yet (maybe consider writing functions with panic!("Not implemented");)

Learn OpenGL's API and experiment with very small, basic rendering tasks

As of now, it is not clear for me wether a physics engine is something that can be implemented (even in a very simple way) this early. Personally, I think that the physics engine can be a very good candidate for a module that we can import externally and wrap (by using one or more of the physics crates mentioned in the README, for example), instead of implementing it from scratch.
Please offer your opinions and ideas regarding this matter.
Also, any insights about physics engines in general are extremely valued.

The math engine should contain 2 modules (for now):
Vectors and Matrices.

Vector operations:

• Vector addition & subtraction: Allows a character to move
• Dot Product: Determines how much a vector influences another
• Cross Product: Allows for the creation of a third vector

Matrix operations:

• Transformation
• Transpose
• Inverse
• Identity

The transformation operation allows a character to rotate.

Math engine related references can be found in the README file.

Naïve skeleton example:

struct Vector{
  x: i64,
  y: i64,
  z: i64,
}
impl Vector{
  fn add(&self,  other : &Vector){
    panic!("Not implemented!");
  }
}

Do we maintain a development branch and everyone pushes changes to it or do we open a branch per issue? Maybe something in the middle?
Also, should we add some sort of CI pipeline?
Please share your ideas regarding these questions

Creating a simple ECS architecture should be our main concern right now.
This is the core of the game engine.
in TL;DR terms, if we oversimplify it (and we definitely will at the beginning) then it all comes down to:

• Entities - generic objects with a unique ID.
• Components - raw data.
• Systems - functions.

This guide -> https://www.david-colson.com/2020/02/09/making-a-simple-ecs.html
shows how a simple ECS should look like, and gives a lot of code examples in C++.
A good start would be to follow this guide and re-implement some of its examples in Rust.
Naïve skeleton example:

struct Entity<T>{
    id : u64,
}
impl Entity<T>{
    fn get_id(&self) -> u64{
        self.id
    }
}

Side note: this issue is also marked as research because much more investigation is required. Any useful information and insights regarding ECS would be extremely valued.