From 5a4c077aecf24da954cf25a175b68b0877c8f6b7 Mon Sep 17 00:00:00 2001 From: Jaro Date: Fri, 13 Sep 2024 08:21:19 +0200 Subject: added reasearch about physics --- research.tex | 97 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/research.tex b/research.tex index ca2afed..6323be0 100644 --- a/research.tex +++ b/research.tex @@ -188,6 +188,103 @@ for audio some options could be: FMOD, Wwise, or iirKlang \subsection{Introduction} +Physics Core Concepts + +rigid body +A chunk of matter that is so strong that the distance between any two bits of matter on the chunk is constant. + +shape +A shape binds collision geometry to a body and adds material properties such as density, friction, and restitution. + +constraint +A constraint is a physical connection that removes degrees of freedom from bodies. A 2D body has 3 degrees of freedom (two translation coordinates and one rotation coordinate). If I take a body and pin it to the wall (like a pendulum) I have constrained the body to the wall. At this point the body can only rotate about the pin, so the constraint has removed 2 degrees of freedom. + +contact constraint +A special constraint designed to prevent penetration of rigid bodies and to simulate friction and restitution. You do not create contact constraints; they are created automatically by Box2D. + +joint constraint +This is a constraint used to hold two or more bodies together. Box2D supports several joint types: revolute, prismatic, distance, and more. Joints may have limits, motors, and/or springs. + +joint limit +A joint limit restricts the range of motion of a joint. For example, the human elbow only allows a certain range of angles. + +joint motor +A joint motor drives the motion of the connected bodies according to the joint's degrees of freedom. For example, you can use a motor to drive the rotation of an elbow. Motors have a target speed and a maximum force or torque. The simulation will apply the force or torque required to achieve the desired speed. + +joint spring +A joint spring has a stiffness and damping. In Box2D spring stiffness is expressed in terms or Hertz or cycles per second. This lets you configure how quickly a spring reacts regardless of the body masses. Joint springs also have a damping ratio to let you specify how quickly the spring will come to rest. + +world +A physics world is a collection of bodies, shapes, joints, and contacts that interact together. Box2D supports the creation of multiple worlds which are completely independent. + +solver +The physics world has a solver that is used to advance time and to resolve contact and joint constraints. The Box2D solver is a high performance sequential solver that operates in order N time, where N is the number of constraints. + +continuous collision +The solver advances bodies in time using discrete time steps. Without intervention this can lead to tunneling. + +Box2D contains specialized algorithms to deal with tunneling. First, the collision algorithms can interpolate the motion of two bodies to find the first time of impact (TOI). Second, speculative collision is used to create contact constraints between bodies before they touch. + +events +World simulation leads to the creation of events that are available at the end of the time step: + +body movement events +contact begin and end events +contact hit events +These events allow your application to react to changes in the simulation. + + + +Box2D + +Description: One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. It powers many games across different platforms. + +Key Features: +Collision detection and response. +Rigid body dynamics, including joints, springs, and constraints. +Support for convex polygons and circles. +Highly customizable, allowing fine control over physics simulation parameters. + +Use Cases: Suitable for platformers, puzzles, and any game requiring realistic 2D physics. + +License: MIT License. +https://box2d.org/ + + +2. LiquidFun +Description: A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It's ideal for games that require both solid and fluid dynamics. +Key Features: +All features of Box2D. +Particle system for simulating fluids, soft bodies, and other deformable materials. +High performance with SIMD optimization. +Use Cases: Games requiring fluid simulations, like water physics or granular materials. +License: Apache License 2.0. +3. Chipmunk2D +Description: A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations. +Key Features: +Collision detection, including circle, segment, and polygon shapes. +Supports constraints, motors, and damped springs. +Built-in support for sleeping objects to optimize performance. +Written in C, but it has bindings for C++. +Use Cases: Ideal for developers who need a simple yet performant physics engine. +License: MIT License. +4. Nape +Description: A 2D physics engine that is optimized for use with the Haxe programming language but has a C++ backend. It focuses on ease of use, with a clean API and features tailored for 2D games. +Key Features: +Provides both rigid body and soft body physics. +Broad-phase and narrow-phase collision detection. +Constraints, forces, and motor simulations. +Integrates well with cross-platform tools that generate C++ code, like Haxe. +Use Cases: Suitable for developers using Haxe or projects that require an easy-to-use API. +License: MIT License. + +liquidfun (fork of box2d) +https://google.github.io/liquidfun/ + +Chipmunk2D +https://chipmunk-physics.net/ + + \subsection{Findings} \subsection{Conclusion} -- cgit v1.2.3 From 4f6a60bac5502c1be731cb5dc30cc161efa9589e Mon Sep 17 00:00:00 2001 From: Jaro Date: Fri, 13 Sep 2024 15:46:51 +0200 Subject: added some research physics --- research.tex | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/research.tex b/research.tex index 6323be0..5181739 100644 --- a/research.tex +++ b/research.tex @@ -187,9 +187,19 @@ for audio some options could be: FMOD, Wwise, or iirKlang \section{Physics/scripting} \subsection{Introduction} +This part of the research explains the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. + +\subsection{Physics Core Concepts} + +\subsubsection{Kinematics} + +\subsubsection{Dynamics} + Physics Core Concepts +https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively. + rigid body A chunk of matter that is so strong that the distance between any two bits of matter on the chunk is constant. -- cgit v1.2.3 From c191f5e193e3ff5ce886b0fbe1efe8d7ddd04183 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 19 Sep 2024 10:59:12 +0200 Subject: added research --- research.tex | 176 +++++++++++++++++++++++++++++++---------------------------- 1 file changed, 94 insertions(+), 82 deletions(-) diff --git a/research.tex b/research.tex index 5181739..422c294 100644 --- a/research.tex +++ b/research.tex @@ -186,113 +186,125 @@ for audio some options could be: FMOD, Wwise, or iirKlang \section{Physics/scripting} -\subsection{Introduction} -This part of the research explains the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. - -\subsection{Physics Core Concepts} - -\subsubsection{Kinematics} - -\subsubsection{Dynamics} - - -Physics Core Concepts +%links +%ragdoll info: https://learn.unity.com/tutorial/creating-ragdolls-2019#649c42abedbc2a04c2145ce7 +%softbody info: https://www.greenfoot.org/scenarios/29502 +. +%2d box concepts: https://box2d.org/ +%liquidfun (fork of box2d): https://google.github.io/liquidfun/ +%Chipmunk2D: https://chipmunk-physics.net/ +% particel systemhttps://learn.unity.com/tutorial/introduction-to-particle-systems# +%rigid body:https://docs.unity3d.com/ScriptReference/Rigidbody.html -https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively. - -rigid body -A chunk of matter that is so strong that the distance between any two bits of matter on the chunk is constant. +\subsection{Introduction} +This part of the research explains physcis concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. -shape -A shape binds collision geometry to a body and adds material properties such as density, friction, and restitution. -constraint -A constraint is a physical connection that removes degrees of freedom from bodies. A 2D body has 3 degrees of freedom (two translation coordinates and one rotation coordinate). If I take a body and pin it to the wall (like a pendulum) I have constrained the body to the wall. At this point the body can only rotate about the pin, so the constraint has removed 2 degrees of freedom. +\subsection{Physics concepts} -contact constraint -A special constraint designed to prevent penetration of rigid bodies and to simulate friction and restitution. You do not create contact constraints; they are created automatically by Box2D. -joint constraint -This is a constraint used to hold two or more bodies together. Box2D supports several joint types: revolute, prismatic, distance, and more. Joints may have limits, motors, and/or springs. +%Physics core concepts: https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively -joint limit -A joint limit restricts the range of motion of a joint. For example, the human elbow only allows a certain range of angles. +%ragdoll https://bluebirdinternational.com/ragdoll-physics/ -joint motor -A joint motor drives the motion of the connected bodies according to the joint's degrees of freedom. For example, you can use a motor to drive the rotation of an elbow. Motors have a target speed and a maximum force or torque. The simulation will apply the force or torque required to achieve the desired speed. +\subsubsection{Kinematics} +Kinematics in game physics involves calculating the position, velocity, and acceleration of objects to simulate realistic motion. It affects everything from character movement to projectiles and vehicles. Collision detection is key, as it determines when objects collide and how they respond, including any damage or effects. Kinematics also helps create lifelike animations, like jumping or running, enhancing the game's realism and immersion. +\begin{itemize} + \item mass + \item speed + \item direction + \item collision detection +\end{itemize} -joint spring -A joint spring has a stiffness and damping. In Box2D spring stiffness is expressed in terms or Hertz or cycles per second. This lets you configure how quickly a spring reacts regardless of the body masses. Joint springs also have a damping ratio to let you specify how quickly the spring will come to rest. -world -A physics world is a collection of bodies, shapes, joints, and contacts that interact together. Box2D supports the creation of multiple worlds which are completely independent. +\subsubsection{Dynamics} +Dynamics simulate object interactions and forces, such as gravity and friction, to enhance realism. It includes rigid body, soft body, and fluid dynamics. For example, it affects car movements in racing games and projectiles in shooters. Balancing dynamics is crucial to maintain performance. Ragdoll physics, a related concept, models a character’s body as interconnected rigid bodies for realistic movement. +\begin{itemize} + \item rigid body dynamics + \item soft body dynamics + \item fluid dynamics + \item ragdoll physics +\end{itemize} -solver -The physics world has a solver that is used to advance time and to resolve contact and joint constraints. The Box2D solver is a high performance sequential solver that operates in order N time, where N is the number of constraints. -continuous collision -The solver advances bodies in time using discrete time steps. Without intervention this can lead to tunneling. +\subsubsection{Collision} +Collision detection is the process of determining when two or more objects in the game world come into contact with each other. There are several techniques used for collision detection. +\begin{itemize} + \item bounding boxes + \item bounding spheres + \item mesh-based collision +\end{itemize} +These techniques involve creating simple shapes around the objects and checking if they intersect with each other. -Box2D contains specialized algorithms to deal with tunneling. First, the collision algorithms can interpolate the motion of two bodies to find the first time of impact (TOI). Second, speculative collision is used to create contact constraints between bodies before they touch. +\subsubsection{Rigidbody} +Rigidbodys deels with the behavior of of non deformable solid objects. it has some physical properties. +\begin{itemize} + \item mass + \item velocity + \item angular velocity + \item orientation +\end{itemize} +To calculate all forces applied to the rigid body the most used algoritm is Newton-Euler equations. The alogritm is about mass an conservation of energy. -events -World simulation leads to the creation of events that are available at the end of the time step: +\subsubsection{Softbody} +Soft body dynamics simulates deformable objects like cloth, fluids, and flesh, adding complexity beyond rigid body dynamics. Key techniques include: +\begin{itemize} + \item Finite Element Method: Divides the object into small elements that interact based on physical laws. + \item Mass-Spring Systems: Uses masses and springs to model deformation and stretching. +\end{itemize} +These methods enhance game realism by creating lifelike clothing, natural water effects, and realistic collision deformations. However, they are resource intensive an require precise calculations to avoid unrealistic results. -body movement events -contact begin and end events -contact hit events -These events allow your application to react to changes in the simulation. +\subsubsection{Particle Systems} +Particle systems simulate numerous small objects to create larger effects like dust, smoke, fire, or explosions. These effects can add an extra layer of realism to a game. +\subsubsection{Fluid Dynamics} +Fluid dynamics shows how fluids move and behave. In game physics, it simulates liquids like water or lava, adding complexity and realism to games with fluid interactions. +\subsubsection{Aerodynamics} +Aerodynamics shows the movement of air and its interaction with solid objects. In video games, it simulates how objects like airplanes or birds move through the air, adding a realistic touch to games involving flight or gliding. -Box2D +\subsection{Implementation of Physics} -Description: One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. It powers many games across different platforms. +To know what the best Physics solution is for a project a list has been created with physics concepts.This list shows how much effort it is to implement a feature and if an engine has the feature available. For this list three physics engines have been found that can provide 2d physics. -Key Features: -Collision detection and response. -Rigid body dynamics, including joints, springs, and constraints. -Support for convex polygons and circles. -Highly customizable, allowing fine control over physics simulation parameters. +\subsubsection{Physics comparison} -Use Cases: Suitable for platformers, puzzles, and any game requiring realistic 2D physics. +\begin{itemize} + \item Rigid Body Dynamics + \item Soft Body Dynamics + \item Particle Systems + \item Fluid Dynamics + \item Collision Detection + \item Aerodynamics + \item Ragdoll Physics + \item Constraints %box2d + \item Joint Limits %box2d + \item Joint Motors %box2d + \item Joint Springs %box2d + \item World Simulation %box2d + \item Solver %box2d +\end{itemize} -License: MIT License. -https://box2d.org/ +\subsubsection{Physics Engines} +\paragraph{Box2D} +\begin{description} + \item[Description:] One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. + \item[License:] MIT License +\end{description} -2. LiquidFun -Description: A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It's ideal for games that require both solid and fluid dynamics. -Key Features: -All features of Box2D. -Particle system for simulating fluids, soft bodies, and other deformable materials. -High performance with SIMD optimization. -Use Cases: Games requiring fluid simulations, like water physics or granular materials. -License: Apache License 2.0. -3. Chipmunk2D -Description: A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations. -Key Features: -Collision detection, including circle, segment, and polygon shapes. -Supports constraints, motors, and damped springs. -Built-in support for sleeping objects to optimize performance. -Written in C, but it has bindings for C++. -Use Cases: Ideal for developers who need a simple yet performant physics engine. -License: MIT License. -4. Nape -Description: A 2D physics engine that is optimized for use with the Haxe programming language but has a C++ backend. It focuses on ease of use, with a clean API and features tailored for 2D games. -Key Features: -Provides both rigid body and soft body physics. -Broad-phase and narrow-phase collision detection. -Constraints, forces, and motor simulations. -Integrates well with cross-platform tools that generate C++ code, like Haxe. -Use Cases: Suitable for developers using Haxe or projects that require an easy-to-use API. -License: MIT License. +\paragraph{LiquidFun} +\begin{description} + \item[Description:] A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It’s ideal for games that require both solid and fluid dynamics. + \item[License:] Apache License 2.0 +\end{description} -liquidfun (fork of box2d) -https://google.github.io/liquidfun/ +\paragraph{Chipmunk2D} +\begin{description} + \item[Description:] A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations. + \item[License:] MIT License +\end{description} -Chipmunk2D -https://chipmunk-physics.net/ \subsection{Findings} -- cgit v1.2.3 From 779764d49e71c7f68508f4dcf3bbca99db359617 Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 1 Oct 2024 09:55:17 +0200 Subject: added notulen --- notulen/wk5-1.txt | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 notulen/wk5-1.txt diff --git a/notulen/wk5-1.txt b/notulen/wk5-1.txt new file mode 100644 index 0000000..2e6064a --- /dev/null +++ b/notulen/wk5-1.txt @@ -0,0 +1,63 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + design document + Discussing top-down + Game design + - + Git + Code standard -> LOEK update + Show updates + Getter and setter wil get: 'set' and 'get' + namespace/ using namespace + + Environments + - + Research (POC) + research eventmanager -> Wouter POC + resource manager -> Niels POC check datatype for conversion + start research renderer + start research scripting + [closed] start research debugging + [closed] start research gameobject + start research physics Starting POC -> Jaro + [closed] Discussed functional physics requirements + More research about physics + research ecs -> Max POC(showed poc design must change asked customer if design can change) + start research particles Starting research -> Jaro (LOEK is sterk tegen particles in physics system omdat loek geen vloeistof wilt) + Design + discussed class diagram + one instance of rigidbody and collider + Gameobject is not the owner of the component but the manager is + and one component type per gameobject. + Functions within a model can they change? + [closed] Adding design audio + Adding design resource manager -> niels met LOEK overleggen + Adding design gameloop + eventmanager -> Wouter toevoegen + Product + Creating 3rd party tool facade audio -> LOEK verder werken + Api class diagram to c++ will wait until some design changes + Test + Add unit test for audio (wait on api) + Discuss about what to test (wait on api) + Question Bob + Mail (waiting on mail for KD) + Tell where these documents are located -> jaro + + + + + + -- cgit v1.2.3 From c26175bfa83d0e3d4269e25ed4e6f06f8e3e4cf7 Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 1 Oct 2024 12:01:44 +0200 Subject: added information about physics --- research.tex | 115 +++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 92 insertions(+), 23 deletions(-) diff --git a/research.tex b/research.tex index 29cee68..abbd5ac 100644 --- a/research.tex +++ b/research.tex @@ -472,7 +472,7 @@ is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}. Due to a severe shortage of libraries that fit our requirements, SoLoud appears to be the most suitable (and only) audio library for use in this project. -\section{Physics} +\section{Scripting} \subsection{Introduction} @@ -480,7 +480,7 @@ the most suitable (and only) audio library for use in this project. \subsection{Conclusion} -\section{Scripting} +\section{Physics} %links %ragdoll info: https://learn.unity.com/tutorial/creating-ragdolls-2019#649c42abedbc2a04c2145ce7 @@ -493,12 +493,12 @@ the most suitable (and only) audio library for use in this project. %rigid body:https://docs.unity3d.com/ScriptReference/Rigidbody.html \subsection{Introduction} -This part of the research explains physcis concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. +This part of the research explains Physics concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. \subsection{Physics concepts} - +Some information about certain Physics topics. second partdescibes what physics we will be able to use and what it is. %Physics core concepts: https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively %ragdoll https://bluebirdinternational.com/ragdoll-physics/ @@ -561,28 +561,11 @@ Aerodynamics shows the movement of air and its interaction with solid objects. I \subsection{Implementation of Physics} -To know what the best Physics solution is for a project a list has been created with physics concepts.This list shows how much effort it is to implement a feature and if an engine has the feature available. For this list three physics engines have been found that can provide 2d physics. +This part shows some phiscics engines an certain physics features that could be needed within the project. -\subsubsection{Physics comparison} - -\begin{itemize} - \item Rigid Body Dynamics - \item Soft Body Dynamics - \item Particle Systems - \item Fluid Dynamics - \item Collision Detection - \item Aerodynamics - \item Ragdoll Physics - \item Constraints %box2d - \item Joint Limits %box2d - \item Joint Motors %box2d - \item Joint Springs %box2d - \item World Simulation %box2d - \item Solver %box2d -\end{itemize} \subsubsection{Physics Engines} - +available physics engines for complex Physics \paragraph{Box2D} \begin{description} \item[Description:] One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. @@ -601,6 +584,92 @@ To know what the best Physics solution is for a project a list has been created \item[License:] MIT License \end{description} +\subsubsection{Simple Physics features} + +There are some features that could be beneficial for this project.a list has been created to show these features. More complex features will be worked out furter. + +\begin{itemize} + \item Gravity + \item Collision (detection + standard handeling) + \item Rigidbody body + \begin{itemize} + \item mass + \item gravity scale + \item velocity + \item body type + \begin{itemize} + \item Static + \item Dynamic + \item Kinematic (User script) + \item Kinematic (standard) + \end{itemize} + \end{itemize} + \item collsion detection mode + \item movement + \begin{itemize} + \item player movement + \item bounce + \item rotation + \item directional force + \end{itemize} + \item particels +\end{itemize} + +\subsubsection{Physics system (engine specific physics engine)} +A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine. + +For simple features as listed above (besides collision and particels) a Physics system is sufficient to provide these features to the game engine. + +These features can be implented using EC and ECS. Both have each own benefits and downsites. + +\subsubsection(Physics with EC) +with EC the component (e.g. Rigidbody) would have some functionality to change its own physics. Besides storing data it would hold function as well for applying gravity, forces, or handle other physics-related logic. + +Preview of Rigidbody +\begin{itemize} + \item Mass (data) + \item gravityscale (data) + \item velocity (data) + \item applygravity (function) + \item update position (function) +\end{itemize} + +With this logic inside of each component the gameloop would look like this: + +step 1: Have a list of components. +step 2: call for each component the rigidbody with the update function (changing its velocity) +step 3: call for each component the update position function (change x and y of each entity) +step 4: check for collsion handeling (would be the collsion component) + +because it is not known with EC if the list contains all object with a rigidbody some overhead is created if the entity does not have a component of the type rigidbody. + +\subsubsection(Physics with ECS) +With ECS the component (e.g. Rigidbody) would only be used to store data. all functionality would be moved to the Physics system + +Preview of Rigidbody +\begin{itemize} + \item Mass (data) + \item gravityscale (data) + \item velocity (data) +\end{itemize} + +Preview of physics system +\begin{itemize} + \item applygravity (function) + \item update position (function) +\end{itemize} + +A seperate sytem would be made that would do all the calculations for the physics. + +With this logic inside of each component the gameloop would look like this: +Step(1): ECS provides a list of rigidbodies (with the enitties) +Step(2): physics system updates all components + +The benefit of ECS is that all physics and collsions are handled by one system. The Physics functionalities would be gathered in one place instead of multiple components. The Physics system could seperate the Physics function creating a correct Physics flow with only one loop. For EC to do this each function would need to have its own loop in the gameloop creating more overhead. + +What EC can not provide compared to ECS is a physics world. A physics world would be the physics that apply to all dynamic physics components. If you want to create gravity you can add the force to the world. The physics system would read all the Physics forces in the world and apply them to all dynamic entities. This would create an easier to use interface for the user and improve the efficiency of the physics because the total forces can be calcualted ones and then applied to all dynamic entities. + + \subsection{Findings} -- cgit v1.2.3 From b4f843faafa0649e96b11e9fa97e31e01bca766d Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 1 Oct 2024 12:19:46 +0200 Subject: added research physics --- research.tex | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/research.tex b/research.tex index abbd5ac..9ef4f43 100644 --- a/research.tex +++ b/research.tex @@ -503,7 +503,7 @@ Some information about certain Physics topics. second partdescibes what physics %ragdoll https://bluebirdinternational.com/ragdoll-physics/ -\subsubsection{Kinematics} +Kinematics: Kinematics in game physics involves calculating the position, velocity, and acceleration of objects to simulate realistic motion. It affects everything from character movement to projectiles and vehicles. Collision detection is key, as it determines when objects collide and how they respond, including any damage or effects. Kinematics also helps create lifelike animations, like jumping or running, enhancing the game's realism and immersion. \begin{itemize} \item mass @@ -513,7 +513,7 @@ Kinematics in game physics involves calculating the position, velocity, and acce \end{itemize} -\subsubsection{Dynamics} +Dynamics: Dynamics simulate object interactions and forces, such as gravity and friction, to enhance realism. It includes rigid body, soft body, and fluid dynamics. For example, it affects car movements in racing games and projectiles in shooters. Balancing dynamics is crucial to maintain performance. Ragdoll physics, a related concept, models a character’s body as interconnected rigid bodies for realistic movement. \begin{itemize} \item rigid body dynamics @@ -523,7 +523,7 @@ Dynamics simulate object interactions and forces, such as gravity and friction, \end{itemize} -\subsubsection{Collision} +Collision: Collision detection is the process of determining when two or more objects in the game world come into contact with each other. There are several techniques used for collision detection. \begin{itemize} \item bounding boxes @@ -532,7 +532,7 @@ Collision detection is the process of determining when two or more objects in th \end{itemize} These techniques involve creating simple shapes around the objects and checking if they intersect with each other. -\subsubsection{Rigidbody} +Rigidbody: Rigidbodys deels with the behavior of of non deformable solid objects. it has some physical properties. \begin{itemize} \item mass @@ -542,7 +542,7 @@ Rigidbodys deels with the behavior of of non deformable solid objects. it has so \end{itemize} To calculate all forces applied to the rigid body the most used algoritm is Newton-Euler equations. The alogritm is about mass an conservation of energy. -\subsubsection{Softbody} +Softbody: Soft body dynamics simulates deformable objects like cloth, fluids, and flesh, adding complexity beyond rigid body dynamics. Key techniques include: \begin{itemize} \item Finite Element Method: Divides the object into small elements that interact based on physical laws. @@ -550,41 +550,42 @@ Soft body dynamics simulates deformable objects like cloth, fluids, and flesh, a \end{itemize} These methods enhance game realism by creating lifelike clothing, natural water effects, and realistic collision deformations. However, they are resource intensive an require precise calculations to avoid unrealistic results. -\subsubsection{Particle Systems} +Particle Systems: Particle systems simulate numerous small objects to create larger effects like dust, smoke, fire, or explosions. These effects can add an extra layer of realism to a game. -\subsubsection{Fluid Dynamics} +Fluid Dynamics: Fluid dynamics shows how fluids move and behave. In game physics, it simulates liquids like water or lava, adding complexity and realism to games with fluid interactions. -\subsubsection{Aerodynamics} +Aerodynamics: Aerodynamics shows the movement of air and its interaction with solid objects. In video games, it simulates how objects like airplanes or birds move through the air, adding a realistic touch to games involving flight or gliding. -\subsection{Implementation of Physics} + +\subsection{Findings} This part shows some phiscics engines an certain physics features that could be needed within the project. -\subsubsection{Physics Engines} +\subsubsection{available Physics Engines} available physics engines for complex Physics -\paragraph{Box2D} +Box2D: \begin{description} \item[Description:] One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. \item[License:] MIT License \end{description} -\paragraph{LiquidFun} +LiquidFun: \begin{description} \item[Description:] A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It’s ideal for games that require both solid and fluid dynamics. \item[License:] Apache License 2.0 \end{description} -\paragraph{Chipmunk2D} +Chipmunk2D: \begin{description} \item[Description:] A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations. \item[License:] MIT License \end{description} -\subsubsection{Simple Physics features} +Simple Physics features: There are some features that could be beneficial for this project.a list has been created to show these features. More complex features will be worked out furter. @@ -615,14 +616,14 @@ There are some features that could be beneficial for this project.a list has bee \item particels \end{itemize} -\subsubsection{Physics system (engine specific physics engine)} +Physics system (engine specific physics engine): A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine. For simple features as listed above (besides collision and particels) a Physics system is sufficient to provide these features to the game engine. These features can be implented using EC and ECS. Both have each own benefits and downsites. -\subsubsection(Physics with EC) +\subsubsection{Physics with EC} with EC the component (e.g. Rigidbody) would have some functionality to change its own physics. Besides storing data it would hold function as well for applying gravity, forces, or handle other physics-related logic. Preview of Rigidbody @@ -643,7 +644,7 @@ step 4: check for collsion handeling (would be the collsion component) because it is not known with EC if the list contains all object with a rigidbody some overhead is created if the entity does not have a component of the type rigidbody. -\subsubsection(Physics with ECS) +\subsubsection{Physics with ECS} With ECS the component (e.g. Rigidbody) would only be used to store data. all functionality would be moved to the Physics system Preview of Rigidbody @@ -669,12 +670,11 @@ The benefit of ECS is that all physics and collsions are handled by one system. What EC can not provide compared to ECS is a physics world. A physics world would be the physics that apply to all dynamic physics components. If you want to create gravity you can add the force to the world. The physics system would read all the Physics forces in the world and apply them to all dynamic entities. This would create an easier to use interface for the user and improve the efficiency of the physics because the total forces can be calcualted ones and then applied to all dynamic entities. - - - -\subsection{Findings} +\subsubsection{Collsions} \subsection{Conclusion} +More components need te be created for both EC and ECS with the diagram provided by the customer. With ECS having the benefit of creating a world where all dynamic object can have a force they interact with. A physics system has the benefit that all physics functionalities are located within one system instead in each component. The flow of Physics updates can be change within the physics system instead of in the gameloop itself. + \section{Audio} -- cgit v1.2.3 From fbbb532b6e85b5a86b0300b2cab4bdfbc8c49959 Mon Sep 17 00:00:00 2001 From: Jaro Date: Tue, 1 Oct 2024 18:34:54 +0200 Subject: added research collision --- notulen/wk5-2.txt | 68 ++++++++++++++++++++++++++++++++++++++++ research.tex | 92 ++++++++++++++++++++++++++++++++++++++++++++++++------- 2 files changed, 149 insertions(+), 11 deletions(-) create mode 100644 notulen/wk5-2.txt diff --git a/notulen/wk5-2.txt b/notulen/wk5-2.txt new file mode 100644 index 0000000..ae0c6a8 --- /dev/null +++ b/notulen/wk5-2.txt @@ -0,0 +1,68 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + design document + Discussing top-down + Game design + - + Git + Code standard -> LOEK update + Show updates + Getter and setter wil get: 'set' and 'get' + namespace/ using namespace + + Environments + - + Research (POC) + research eventmanager -> Wouter POC + resource manager -> Niels POC check datatype for conversion + start research savedata + start research renderer + start research scripting + [closed] start research debugging + [closed] start research gameobject + start research physics Starting POC -> Jaro + [closed] Discussed functional physics requirements + More research about physics + research ecs -> Max POC(showed poc design must change asked customer if design can change) + start research particles Starting research -> Jaro (LOEK is sterk tegen particles in physics system omdat loek geen vloeistof wilt) + Design + discussed class diagram + one instance of rigidbody and collider + Gameobject is not the owner of the component but the manager is + and one component type per gameobject. + Functions within a model can they change? + [closed] Adding design audio + Adding design resource manager -> niels met LOEK overleggen + Adding design gameloop + eventmanager -> Wouter toevoegen + Discuss facade design. + Who is owner of which facade instancies? + How does a game designer make a scene? + resourceManager discuss design. + Product + Creating 3rd party tool facade audio -> LOEK verder werken + Api class diagram to c++ will wait until some design changes + Test + Add unit test for audio (wait on api) + Discuss about what to test (wait on api) + Question Bob + Mail (waiting on mail for KD) + Tell where these documents are located -> jaro + + + + + + diff --git a/research.tex b/research.tex index 9ef4f43..791e9f1 100644 --- a/research.tex +++ b/research.tex @@ -585,9 +585,16 @@ Chipmunk2D: \item[License:] MIT License \end{description} -Simple Physics features: -There are some features that could be beneficial for this project.a list has been created to show these features. More complex features will be worked out furter. +\subsubsection{Physics system (engine specific physics engine)} +A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine. + +features a physics engine should provide is determined by the requirements. +Because the only requirement is that the user should easily add physics a list below is made for simple physics that can be implemented without the use of an 3rd party physics engine. Other features can be made by the user using scripts. + +For simple features as listed below (besides collision and particels) a Physics system is sufficient to provide these features to the game engine. + +Simple Physics features a physics engine could provide: \begin{itemize} \item Gravity @@ -616,13 +623,6 @@ There are some features that could be beneficial for this project.a list has bee \item particels \end{itemize} -Physics system (engine specific physics engine): -A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine. - -For simple features as listed above (besides collision and particels) a Physics system is sufficient to provide these features to the game engine. - -These features can be implented using EC and ECS. Both have each own benefits and downsites. - \subsubsection{Physics with EC} with EC the component (e.g. Rigidbody) would have some functionality to change its own physics. Besides storing data it would hold function as well for applying gravity, forces, or handle other physics-related logic. @@ -670,11 +670,81 @@ The benefit of ECS is that all physics and collsions are handled by one system. What EC can not provide compared to ECS is a physics world. A physics world would be the physics that apply to all dynamic physics components. If you want to create gravity you can add the force to the world. The physics system would read all the Physics forces in the world and apply them to all dynamic entities. This would create an easier to use interface for the user and improve the efficiency of the physics because the total forces can be calcualted ones and then applied to all dynamic entities. -\subsubsection{Collsions} - \subsection{Conclusion} More components need te be created for both EC and ECS with the diagram provided by the customer. With ECS having the benefit of creating a world where all dynamic object can have a force they interact with. A physics system has the benefit that all physics functionalities are located within one system instead in each component. The flow of Physics updates can be change within the physics system instead of in the gameloop itself. +\section{Collisions} + +\subsection{Introduction} + +Collision is mostly made part of an Physics engine, however it is something seperate but some collision handeling is done by the Physics engine that is the reason why they are most of the time one system. + +Collsions exists from two thing. Collsion detection and collsion handeling/ Some handeling is done by the physics engine and by user scripts and will not be explanined in this topic. Collsion detection is the scope of this research. +There is a need of understanding what different type of collision objects are and what algoritm can be used to increase efficiency of the detection. + +\subsection{Findings} + + +Collsion detection is made out of 2 fases. + +%https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection + +%https://medium.com/@bpmw/quadtrees-for-2d-games-with-moving-elements-63360b08329f + +%https://medium.com/my-games-company/optimizing-r-tree-inserts-in-unity-a-bomberman-like-example-81d2576efd75 + +%https://matthias-research.github.io/pages/tenMinutePhysics/11-hashing.pdf + +The first fase want to make a list out of objects that could be colliding. Some algorithm can be used to make these list in an efficient way. +Quad Trees, R-Trees or a Spatial Hashmap. + +\begin{description} + \item[Quadtrees] Quadtrees partition 2D space into quadrants (stored as nodes in a tree), dividing these quadrants into smaller quadrants when they contain more than a certain threshold of elements. + \item[R-Trees] These are data structures commonly used for spatial access. They are more suited for dynamic data and allow efficient querying of rectangles or bounding boxes, making them useful for collision detection. + \item[Spatial hashing] This technique divides space into uniform grids (similar to cells in a 2D array), and each object is assigned to one or more cells based on its position. Objects within the same or adjacent cells are checked for collisions, improving efficiency by limiting the number of checks to nearby objects. +\end{description} + +R-Trees are easy to understand but how the R-tree is build (how objects are inserted) is complex. The benefits of this tree for this project are not needed because Quadtree would be sufficient for this purpose. reading the data would be as fast as the quadtree but implemeting the R-tree and knowing how to implement it takes to much time and is out of scope. + + +\begin{table} + \begin{tabularx}{\linewidth}{lXl} + \toprule + Criteria & Quadtree & R-tree & Spatial Hashing \\ + \midrule + Best for & Static objects, sparse data & Complex shapes, dynamic objects & Fast-moving objects, uniform data \\ + \midrule + Handles moving objects & Poorly (requires restructuring) & Well (efficient updates) & Very well (simple re-hash) \\ + \midrule + Memory usage & Moderate & Moderate to high & Can be high \\ + \midrule + Complexity & Moderate & High & Low \\ + \midrule + Spatial queries & Efficient & Very efficient & Less efficient \\ + \midrule + Grid size sensitivity & Not applicable & Not applicable & High (tuning needed) \\ + \midrule + Handling variable density & Good & Good & Poor \\ + \bottomrule + \end{tabularx} + \caption{Comparison of Quadtree, R-tree, and Spatial Hashing} +\end{table} + + +%https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection + +The second face checks the list from the first face if there are actually colliding. the narrow face detections are descripted in the list below. + +List of collision detection objects/algoritms (narrow) +\begin{description} + \item[Axis-Aligned Bounding Box]One of the simpler forms of collision detection is between two rectangles that are axis aligned — meaning no rotation. The algorithm works by ensuring there is no gap between any of the 4 sides of the rectangles. + \item[Circle Collision] a simple shape for collision detection is between two circles. This algorithm works by taking the center points of the two circles and ensuring the distance between the center points are less than the two radii added together. + \item[Separating Axis Theorem] This is a collision algorithm that can detect a collision between any two convex polygons. It's more complicated to implement than other methods but is more powerful. +\end{description} + + +\subsection{Conclusion} + \section{Audio} -- cgit v1.2.3 From 0aa19d88f9c90c888ec1decdf32a37414b8b300d Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 2 Oct 2024 17:14:19 +0200 Subject: Added tasks --- time.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index 73b2272..ea20769 100644 --- a/time.txt +++ b/time.txt @@ -88,6 +88,8 @@ max: 2024-09-25 1h wrote email to Bob max: 2024-09-25 2h40m make my own ECS (homemade ECS) max: 2024-09-26 2h eight project meeting max: 2024-09-26 1h wrote email to Bob (after project meeting) +max: 2024-09-30 1h30m nineth project meeting +max: 2024-10-02 6h15m improved own ECS (POC) wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting @@ -144,7 +146,7 @@ niels: 2024-09-23 2h researching and POC tiled library tmxlite niels: 2024-09-24 2h project Meeting niels: 2024-09-24 45m meeting with Bob niels: 2024-09-25 6h integrate the resource manager spritesheet, tmxlite, texture. -niels: 2024-09-26 2h project meeting +niels: 2024-09-26 2h project meeting jaro: 2024-09-02 1h project meeting :: project kickoff jaro: 2024-09-02 45m project meeting -- cgit v1.2.3 From cf7889e151c05cf6f7f40a470ec113947c11980a Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 3 Oct 2024 13:43:10 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 73b2272..06f4e63 100644 --- a/time.txt +++ b/time.txt @@ -54,6 +54,7 @@ loek: 2024-09-29 45m docs :: audio facade design loek: 2024-09-30 1h40m project meeting loek: 2024-10-01 2h20m review :: feedback & discussing software design loek: 2024-10-01 30m implementation :: audio facade and API +loek: 2024-10-03 1h30m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From a8031602cd8a78f5b0d4dfddae3d2ff347ac7a3d Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 4 Oct 2024 09:04:36 +0200 Subject: Added tasks --- time.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/time.txt b/time.txt index ea20769..d054786 100644 --- a/time.txt +++ b/time.txt @@ -90,6 +90,8 @@ max: 2024-09-26 2h eight project meeting max: 2024-09-26 1h wrote email to Bob (after project meeting) max: 2024-09-30 1h30m nineth project meeting max: 2024-10-02 6h15m improved own ECS (POC) +max: 2024-10-03 30m tenth project meeting +max: 2024-10-03 1h30m fifth project lesson wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From cc81fa71edf1ab7d6d60222c4c9d0c5733cfaac4 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Fri, 4 Oct 2024 10:39:59 +0200 Subject: updated time --- time.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/time.txt b/time.txt index 06f4e63..91a8e30 100644 --- a/time.txt +++ b/time.txt @@ -111,9 +111,16 @@ wouter: 2024-09-18 3h finishing gameloop poc and starting event manager wouter: 2024-09-19 15m project meeting wouter: 2024-09-19 1h30m project meeting wouter: 2024-09-19 45m project meeting -wouter: 2024-09-19 15m docs :: remove versioning wouter: 2024-09-26 2h eight project meeting wouter: 2024-09-26 3h researching event manager +wouter: 2024-09-28 6h researching and developing event poc +wouter: 2024-09-29 3h researching and developing event poc +wouter: 2024-09-30 1h40m project meeting +wouter: 2024-10-03 1h30m discussing event with seger +wouter: 2024-10-03 4h developing event poc +wouter: 2024-10-03 1h30m creating gameloop design +wouter: 2024-10-04 2h developing event poc +wouter: 2024-10-03 1h30m project meeting niels: 2024-09-02 1h project meeting :: project kickoff @@ -145,7 +152,7 @@ niels: 2024-09-23 2h researching and POC tiled library tmxlite niels: 2024-09-24 2h project Meeting niels: 2024-09-24 45m meeting with Bob niels: 2024-09-25 6h integrate the resource manager spritesheet, tmxlite, texture. -niels: 2024-09-26 2h project meeting +niels: 2024-09-26 2h project meeting jaro: 2024-09-02 1h project meeting :: project kickoff jaro: 2024-09-02 45m project meeting -- cgit v1.2.3 From b86248424047b66e4b005b525ca6019754a01c06 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 4 Oct 2024 12:02:58 +0200 Subject: time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 06f4e63..d229822 100644 --- a/time.txt +++ b/time.txt @@ -55,6 +55,7 @@ loek: 2024-09-30 1h40m project meeting loek: 2024-10-01 2h20m review :: feedback & discussing software design loek: 2024-10-01 30m implementation :: audio facade and API loek: 2024-10-03 1h30m project meeting +loek: 2024-10-04 15m research :: read others' research max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From a600634464e39095870b1a27ed107941d45f034a Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Fri, 4 Oct 2024 13:10:23 +0200 Subject: uren deze week --- time.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/time.txt b/time.txt index 26156d1..69bf0a0 100644 --- a/time.txt +++ b/time.txt @@ -158,6 +158,19 @@ niels: 2024-09-24 2h project Meeting niels: 2024-09-24 45m meeting with Bob niels: 2024-09-25 6h integrate the resource manager spritesheet, tmxlite, texture. niels: 2024-09-26 2h project meeting +niels: 2024-09-30 1h40m project meeting +niels: 2024-10-01 2h design resource manager and making resource manager singleton +niels: 2024-10-01 1h meeting loek refactoring resource manager +niels: 2024-10-01 1h20m meeting jaro & loek about questions regarding design and ownership pointers +niels: 2024-10-01 45m starting refactoring code after feedback +niels: 2024-10-01 1h30m try implementating library in git submodule. And refactoring code further +niels: 2024-10-02 1h finishing adding git submodule and bugs related to compiling external library +niels: 2024-10-02 4h refacting code further so that textures and spritesheet work and fixing bugs. +niels: 2024-10-04 1h10m project meeting + + + + jaro: 2024-09-02 1h project meeting :: project kickoff jaro: 2024-09-02 45m project meeting -- cgit v1.2.3 From f12f8366f83e8c4adb7d3a681a9298511b6c0a85 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 4 Oct 2024 13:14:42 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 26156d1..ba91190 100644 --- a/time.txt +++ b/time.txt @@ -56,6 +56,7 @@ loek: 2024-10-01 2h20m review :: feedback & discussing software design loek: 2024-10-01 30m implementation :: audio facade and API loek: 2024-10-03 1h30m project meeting loek: 2024-10-04 15m research :: read others' research +loek: 2024-10-04 1h15m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From c974d5978017ba4217bad801ed7906e42ec6d0bb Mon Sep 17 00:00:00 2001 From: Jaro Date: Fri, 4 Oct 2024 13:31:55 +0200 Subject: updated research and notes --- notulen/wk5-2.txt | 55 ++++++++++++++++++++++++++++--------------------------- 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/notulen/wk5-2.txt b/notulen/wk5-2.txt index ae0c6a8..3da0849 100644 --- a/notulen/wk5-2.txt +++ b/notulen/wk5-2.txt @@ -10,7 +10,7 @@ eventmanager sub-requirements -> Wouter write document gameloop sub-requirements -> Wouter write document ecs sub-requirements - particles sub-requirement + particles sub-requirement -> Jaro write document resourceManager sub-requirement -> Niels write document rendering sub-requirement design document @@ -20,49 +20,50 @@ Git Code standard -> LOEK update Show updates - Getter and setter wil get: 'set' and 'get' + [closed] Getter and setter wil get: 'set' and 'get' namespace/ using namespace - Environments - Research (POC) - research eventmanager -> Wouter POC - resource manager -> Niels POC check datatype for conversion - start research savedata - start research renderer - start research scripting - [closed] start research debugging - [closed] start research gameobject + research eventmanager -> Wouter POC (goede voortgang) + resource manager -> Niels POC check datatype for conversion (na meeting afgerond) alleen implementatie tiled + start research ui -> wouter + start research ai + start research savedata -> loek + start research renderer -> niels (kleine start) + start research scripting -> loek + start research debugging (los staande profilers, toevoegen timers voor profilers?) start research physics Starting POC -> Jaro - [closed] Discussed functional physics requirements More research about physics - research ecs -> Max POC(showed poc design must change asked customer if design can change) + Question customer about physics requirements + start reasearch collsion detection -> Jaro + research ecs -> Max POC start research particles Starting research -> Jaro (LOEK is sterk tegen particles in physics system omdat loek geen vloeistof wilt) Design - discussed class diagram + [closed] discussed class diagram one instance of rigidbody and collider Gameobject is not the owner of the component but the manager is and one component type per gameobject. - Functions within a model can they change? - [closed] Adding design audio - Adding design resource manager -> niels met LOEK overleggen - Adding design gameloop + eventmanager -> Wouter toevoegen + Functions within a model can they change + Adding design asset class -> niels + Adding design resource holder -> niels + [closed] Adding design gameloop -> Wouter toevoegen Discuss facade design. Who is owner of which facade instancies? + who is owner of what? How does a game designer make a scene? - resourceManager discuss design. + [closed] resourceManager discuss design. + review design document (loeks features) -> Wouter Product - Creating 3rd party tool facade audio -> LOEK verder werken - Api class diagram to c++ will wait until some design changes + [closed] Creating 3rd party tool facade audio -> LOEK verder werken + Api class diagram to c++ Test - Add unit test for audio (wait on api) + Add unit test for audio (do we want unit tests) Discuss about what to test (wait on api) + Change location tests -> loek Question Bob - Mail (waiting on mail for KD) Tell where these documents are located -> jaro - - - - - + Question customer about physics requirements + functions in components (setter) + We ondersteunen toetsenbord en muis. -- cgit v1.2.3 From 52273c078f0341c02f5b3a35896b031728f36dda Mon Sep 17 00:00:00 2001 From: Jaro Date: Fri, 4 Oct 2024 16:48:09 +0200 Subject: updated time --- time.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/time.txt b/time.txt index 4494d0a..ca39cc5 100644 --- a/time.txt +++ b/time.txt @@ -210,4 +210,12 @@ jaro: 2024-09-26 2h30m physics research and poc jaro: 2024-09-26 30m preparing meeting jaro: 2024-09-26 2h team meeting jaro: 2024-09-27 45m converting notes +jaro: 2024-09-27 2h30m weeklyupdate + Physics +jaro: 2024-09-30 1h30m project meeting +jaro: 2024-10-01 3h research physics + collisions +jaro: 2024-10-01 1h meeting facade +jaro: 2024-10-01 3h15m research physics + collisions +jaro: 2024-10-01 1h30m Particels poc +jaro: 2024-10-03 2h project meeting + project lesson +jaro: 2024-10-04 1h15m project meeting # vim:ft=cfg -- cgit v1.2.3 From 5fc8183fa4645421819502adda09c4587290965c Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 4 Oct 2024 17:43:43 +0200 Subject: Added task --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 4d4a934..5798f5b 100644 --- a/time.txt +++ b/time.txt @@ -93,6 +93,7 @@ max: 2024-09-30 1h30m nineth project meeting max: 2024-10-02 6h15m improved own ECS (POC) max: 2024-10-03 30m tenth project meeting max: 2024-10-03 1h30m fifth project lesson +max: 2024-10-04 2h20m creating class diagram of ecs-homemade (and researching other possibilities for the ecs-homemade) wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From 020062f07c370a5e07fcbe3acbebf795da7ba235 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Sat, 5 Oct 2024 12:40:07 +0200 Subject: Added task --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index cb07cff..00a153d 100644 --- a/time.txt +++ b/time.txt @@ -96,6 +96,7 @@ max: 2024-10-02 6h15m improved own ECS (POC) max: 2024-10-03 30m tenth project meeting max: 2024-10-03 1h30m fifth project lesson max: 2024-10-04 2h20m creating class diagram of ecs-homemade (and researching other possibilities for the ecs-homemade) +max: 2024-10-05 2h made memory efficient ecs wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From 523793d0fa64acbb9a04403a5c6054941a5296d0 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 5 Oct 2024 15:00:41 +0200 Subject: cleanup + sync design with crepe `loek/audio` source branch --- img/facade-audio.puml | 23 ++++++++++------------- img/theme.ipuml | 17 +++++++++++++++-- latexmkrc | 2 ++ projdoc.cls | 2 +- time.txt | 1 + 5 files changed, 29 insertions(+), 16 deletions(-) diff --git a/img/facade-audio.puml b/img/facade-audio.puml index 6749915..60af60f 100644 --- a/img/facade-audio.puml +++ b/img/facade-audio.puml @@ -2,14 +2,11 @@ !include theme.ipuml skinparam Linetype ortho - package crepe { - package api { - class Resource <> - } + class Asset <> class Sound { - +Sound(resource) + +Sound(asset) -- +pause() +play() @@ -20,7 +17,7 @@ package crepe { -sample : SoLoud::Wav -handle : SoLoud::handle -- - -load(resource) + -load(asset) } class SoundContext <> { @@ -31,6 +28,11 @@ package crepe { -- -engine : SoLoud::Soloud } + + Sound .> SoundContext + SoundContext .> Sound + + Sound .left> Asset } package SoLoud { @@ -38,15 +40,10 @@ package SoLoud { class Wav <> } -' layout -crepe -[hidden]down- SoLoud - crepe.Sound --> SoLoud.Wav crepe.SoundContext --> SoLoud.Soloud -crepe.Sound .> crepe.SoundContext -crepe.SoundContext .> crepe.Sound - -crepe.Sound .> crepe.api.Resource +' LAYOUT +crepe -[hidden]down- SoLoud @enduml diff --git a/img/theme.ipuml b/img/theme.ipuml index f716ddf..ae3b1c7 100644 --- a/img/theme.ipuml +++ b/img/theme.ipuml @@ -1,13 +1,26 @@ +' vim:ft=plantuml + !theme plain skinparam ClassAttributeIconSize 0 skinparam ClassFontStyle bold skinparam DefaultFontName Inter -skinparam DefaultFontSize 14 +skinparam DefaultFontSize 10 skinparam MaxMessageSize 200 skinparam Nodesep 25 -skinparam Padding 2 +' skinparam Padding 0 skinparam Ranksep 50 skinparam RoundCorner 0 +skinparam PackageStyle rectangle +skinparam PackageFontStyle italic + +hide class circle +' class <> for third-party classes hide <> stereotype hide <> members + +' rectangle <> +hide <> stereotype +skinparam Rectangle<>BorderStyle dashed +skinparam Rectangle<>BorderColor gray + diff --git a/latexmkrc b/latexmkrc index d2c3cdc..cdc2001 100644 --- a/latexmkrc +++ b/latexmkrc @@ -12,6 +12,8 @@ $clean_ext .= ' %R.ist %R.xdy bbl run.xml'; 'plan', 'research', 'timerep', + 'design', + 'requirements', ); push @file_not_found, '^Package .* No file `([^\\\']*)\\\''; diff --git a/projdoc.cls b/projdoc.cls index 8a2c05d..b369b18 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -330,7 +330,7 @@ % adjust scale for puml diagrams \newcommand{\includepumldiag}[1]{% \StrSubstitute{#1}{.puml}{.eps}[\filename]% - \fitimg{\includegraphics[scale=0.6]{\filename}}% + \fitimg{\includegraphics[scale=0.75]{\filename}}% } % prevent page break between two paragraphs diff --git a/time.txt b/time.txt index 4494d0a..bdb122d 100644 --- a/time.txt +++ b/time.txt @@ -57,6 +57,7 @@ loek: 2024-10-01 30m implementation :: audio facade and API loek: 2024-10-03 1h30m project meeting loek: 2024-10-04 15m research :: read others' research loek: 2024-10-04 1h15m project meeting +loek: 2024-10-05 1h10m refacting :: unify unit tests + update code style max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From aa73d0293a1a3e84d6ce18bea967c7d3fa5d0016 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 6 Oct 2024 17:40:22 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 6b33bbc..8d748b7 100644 --- a/time.txt +++ b/time.txt @@ -58,6 +58,7 @@ loek: 2024-10-03 1h30m project meeting loek: 2024-10-04 15m research :: read others' research loek: 2024-10-04 1h15m project meeting loek: 2024-10-05 1h10m refacting :: unify unit tests + update code style +loek: 2024-10-06 3h40m implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 6630baa24bdc8b90e24189aab8fea8aa8f020f43 Mon Sep 17 00:00:00 2001 From: Jaro Date: Mon, 7 Oct 2024 13:43:20 +0200 Subject: notes added 6-1 --- figs.drawio | 102 +++++++++++++++++++++++++++++++----------------------- notulen/wk6-1.txt | 61 ++++++++++++++++++++++++++++++++ 2 files changed, 119 insertions(+), 44 deletions(-) create mode 100644 notulen/wk6-1.txt diff --git a/figs.drawio b/figs.drawio index 7c961d1..f6ed6fc 100644 --- a/figs.drawio +++ b/figs.drawio @@ -401,18 +401,21 @@ - + + + + - + - + @@ -434,7 +437,7 @@ - + @@ -497,7 +500,7 @@ - + @@ -507,12 +510,12 @@ - + - + @@ -522,12 +525,12 @@ - + - + @@ -537,12 +540,12 @@ - + - + @@ -552,12 +555,12 @@ - + - + @@ -567,12 +570,12 @@ - + - + @@ -582,12 +585,12 @@ - + - + @@ -597,12 +600,12 @@ - + - + @@ -611,17 +614,17 @@ - + - + - + @@ -631,35 +634,35 @@ - + - + - + - + - + @@ -669,7 +672,7 @@ - + @@ -678,34 +681,45 @@ - + - + - + - + - + - + - + - + + + + + + + + + + + + @@ -714,42 +728,42 @@ - + - + - + - + - + - + - + - + diff --git a/notulen/wk6-1.txt b/notulen/wk6-1.txt new file mode 100644 index 0000000..142b2e0 --- /dev/null +++ b/notulen/wk6-1.txt @@ -0,0 +1,61 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement -> Jaro write document + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + design document + Discussing top-down + Game design + - + Git + Code standard -> LOEK update + Show updates + [closed] namespace/ using namespace + + Environments + - + Research (POC) + research eventmanager -> Wouter POC (goede voortgang) + resource manager -> Niels POC check datatype for conversion (na meeting afgerond) alleen implementatie tiled + start research ui -> wouter + start research ai + start research savedata -> loek + start research renderer -> niels (kleine start) + start research scripting -> loek + start research debugging (los staande profilers, toevoegen timers voor profilers?) + start research physics Starting POC -> Jaro + More research about physics + [closed] Question customer about physics requirements + start reasearch collsion detection -> Jaro + research ecs -> Max POC (change in design of ecs. moved components after each other in memory to increase efficiency.) loek/scripts branch voor ecs. + start research particles Starting research -> Jaro (start lifetime. spawning area) + Design + Adding design asset class -> niels + Adding design resource holder -> niels + [closed] Adding design gameloop -> Wouter toevoegen + Discuss facade design. + Who is owner of which facade instancies? + who is owner of what? + How does a game designer make a scene? + [closed] resourceManager discuss design. + review design document (loeks features) -> Wouter + Product + [closed] Creating 3rd party tool facade audio -> LOEK verder werken + Api class diagram to c++ + Test + [closed] Add unit test for audio (do we want unit tests) + Discuss about what to test (wait on api) testen uitgebreid als je wilt maar mag niet teveel tijd kosten en moet nuttig zijn. + [closed] Change location tests -> loek + Question Bob + - + -- cgit v1.2.3 From 443b88053e580a790e2e5e5ecaaf506602bd2ae9 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 7 Oct 2024 13:44:30 +0200 Subject: update time.txt --- design.tex | 2 +- time.txt | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/design.tex b/design.tex index 1e42c03..7b232fe 100644 --- a/design.tex +++ b/design.tex @@ -52,7 +52,7 @@ contains the following classes: This class is friends with \codeinline{Sound}, so only \codeinline{Sound} is able to get the \codeinline{SoundContext} instance. \item[Sound] This is a wrapper around the \codeinline{SoLoud::Wav} class, and uses - cr\^epe's \codeinline{api::Resource} class to load an audio sample instead. + cr\^epe's \codeinline{Asset} class to load an audio sample instead. \end{description} \begin{figure} diff --git a/time.txt b/time.txt index 8d748b7..4aca083 100644 --- a/time.txt +++ b/time.txt @@ -59,6 +59,7 @@ loek: 2024-10-04 15m research :: read others' research loek: 2024-10-04 1h15m project meeting loek: 2024-10-05 1h10m refacting :: unify unit tests + update code style loek: 2024-10-06 3h40m implementation :: scripting interface +loek: 2024-10-07 2h45m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 0cd06aa8d1cc6ec7a3140459e9acf503bbc164b3 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Tue, 8 Oct 2024 15:41:54 +0200 Subject: update time.txt --- time.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index 4aca083..c355164 100644 --- a/time.txt +++ b/time.txt @@ -11,7 +11,7 @@ loek: 2024-09-05 15m repository scaffolding :: additional latex contributing gui loek: 2024-09-05 1h40m project meeting loek: 2024-09-05 1h24m time report script loek: 2024-09-06 55m time report script -loek: 2024-09-09 30m feedback :: niels code style guide +loek: 2024-09-09 30m review :: niels code style guide loek: 2024-09-09 45m review :: wouter research PR#5 loek: 2024-09-09 25m documentation style guide loek: 2024-09-10 1h55m project meeting @@ -60,6 +60,8 @@ loek: 2024-10-04 1h15m project meeting loek: 2024-10-05 1h10m refacting :: unify unit tests + update code style loek: 2024-10-06 3h40m implementation :: scripting interface loek: 2024-10-07 2h45m project meeting +loek: 2024-10-08 40m review :: Max' ECS code +loek: 2024-10-08 5m review :: incorporate feedback and merge PR max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From d3f498235d90112a31c55c4625f719ea09f01217 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 9 Oct 2024 14:24:36 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index c355164..28ed423 100644 --- a/time.txt +++ b/time.txt @@ -62,6 +62,7 @@ loek: 2024-10-06 3h40m implementation :: scripting interface loek: 2024-10-07 2h45m project meeting loek: 2024-10-08 40m review :: Max' ECS code loek: 2024-10-08 5m review :: incorporate feedback and merge PR +loek: 2024-10-09 25m review :: feedback discussion + code style update max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 4d2302bcb5559671f2f8bf2cbb82aa2345382eb8 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 9 Oct 2024 16:05:23 +0200 Subject: Expanded diagram --- figs.drawio | 762 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 758 insertions(+), 4 deletions(-) diff --git a/figs.drawio b/figs.drawio index f6ed6fc..1a15831 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + - + @@ -408,7 +408,7 @@ - + @@ -709,7 +709,7 @@ - + @@ -723,6 +723,760 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3 From cc474afb533e1c632e6f4a49e7ac0d1e18fdbc79 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 9 Oct 2024 17:14:43 +0200 Subject: Added tasks --- time.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/time.txt b/time.txt index 00a153d..095f5e9 100644 --- a/time.txt +++ b/time.txt @@ -97,6 +97,10 @@ max: 2024-10-03 30m tenth project meeting max: 2024-10-03 1h30m fifth project lesson max: 2024-10-04 2h20m creating class diagram of ecs-homemade (and researching other possibilities for the ecs-homemade) max: 2024-10-05 2h made memory efficient ecs +max: 2024-10-09 2h trying to get clang-format working (ending up upgrading Linux) +max: 2024-10-09 30m reviewing feedback of ecs-homemade +max: 2024-10-09 30m expanding class diagram +max: 2024-10-09 2h50m investigating compiler error options for game programmer when adding too much or too little Components of a specific type wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From aa2835cbdbfd71f9d2b6ff74f3243862c2c56ca8 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 9 Oct 2024 17:17:55 +0200 Subject: Added tasks --- time.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/time.txt b/time.txt index 095f5e9..bd38743 100644 --- a/time.txt +++ b/time.txt @@ -97,6 +97,8 @@ max: 2024-10-03 30m tenth project meeting max: 2024-10-03 1h30m fifth project lesson max: 2024-10-04 2h20m creating class diagram of ecs-homemade (and researching other possibilities for the ecs-homemade) max: 2024-10-05 2h made memory efficient ecs +max: 2024-10-07 30m sixth project lesson +max: 2024-10-07 2h15m eleventh project meeting max: 2024-10-09 2h trying to get clang-format working (ending up upgrading Linux) max: 2024-10-09 30m reviewing feedback of ecs-homemade max: 2024-10-09 30m expanding class diagram -- cgit v1.2.3 From 2ff0a4d97024723337e8919bbae4b1a8c94004a4 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 10 Oct 2024 08:05:20 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 28ed423..c8da785 100644 --- a/time.txt +++ b/time.txt @@ -63,6 +63,7 @@ loek: 2024-10-07 2h45m project meeting loek: 2024-10-08 40m review :: Max' ECS code loek: 2024-10-08 5m review :: incorporate feedback and merge PR loek: 2024-10-09 25m review :: feedback discussion + code style update +loek: 2024-10-10 1h05m refacting :: fix build system + update readmes max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 27afd9194701d4faec01fe54bc9e8cafe9ee0cbb Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 10 Oct 2024 10:06:45 +0200 Subject: added notulen wk6-2 --- notulen/wk6-2.txt | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 notulen/wk6-2.txt diff --git a/notulen/wk6-2.txt b/notulen/wk6-2.txt new file mode 100644 index 0000000..142b2e0 --- /dev/null +++ b/notulen/wk6-2.txt @@ -0,0 +1,61 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement -> Jaro write document + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + design document + Discussing top-down + Game design + - + Git + Code standard -> LOEK update + Show updates + [closed] namespace/ using namespace + + Environments + - + Research (POC) + research eventmanager -> Wouter POC (goede voortgang) + resource manager -> Niels POC check datatype for conversion (na meeting afgerond) alleen implementatie tiled + start research ui -> wouter + start research ai + start research savedata -> loek + start research renderer -> niels (kleine start) + start research scripting -> loek + start research debugging (los staande profilers, toevoegen timers voor profilers?) + start research physics Starting POC -> Jaro + More research about physics + [closed] Question customer about physics requirements + start reasearch collsion detection -> Jaro + research ecs -> Max POC (change in design of ecs. moved components after each other in memory to increase efficiency.) loek/scripts branch voor ecs. + start research particles Starting research -> Jaro (start lifetime. spawning area) + Design + Adding design asset class -> niels + Adding design resource holder -> niels + [closed] Adding design gameloop -> Wouter toevoegen + Discuss facade design. + Who is owner of which facade instancies? + who is owner of what? + How does a game designer make a scene? + [closed] resourceManager discuss design. + review design document (loeks features) -> Wouter + Product + [closed] Creating 3rd party tool facade audio -> LOEK verder werken + Api class diagram to c++ + Test + [closed] Add unit test for audio (do we want unit tests) + Discuss about what to test (wait on api) testen uitgebreid als je wilt maar mag niet teveel tijd kosten en moet nuttig zijn. + [closed] Change location tests -> loek + Question Bob + - + -- cgit v1.2.3 From bd7230c7dcc01ca8100ba27c7c8bf5af6b7375e5 Mon Sep 17 00:00:00 2001 From: Jaro Date: Thu, 10 Oct 2024 12:27:12 +0200 Subject: added notulen --- figs.drawio | 383 ++++++++++++++++++++++++++++-------------------------- notulen/wk6-2.txt | 31 +++-- 2 files changed, 219 insertions(+), 195 deletions(-) diff --git a/figs.drawio b/figs.drawio index 1a15831..5082752 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + @@ -716,7 +716,19 @@ - + + + + + + + + + + + + + @@ -724,54 +736,54 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -780,152 +792,152 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -935,298 +947,298 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -1235,12 +1247,12 @@ - + - + @@ -1249,23 +1261,23 @@ - + - + - + - + @@ -1275,12 +1287,12 @@ - + - + @@ -1290,12 +1302,12 @@ - + - + @@ -1304,12 +1316,12 @@ - + - + @@ -1318,12 +1330,12 @@ - + - + @@ -1332,17 +1344,17 @@ - + - + - + @@ -1351,7 +1363,7 @@ - + @@ -1360,7 +1372,7 @@ - + @@ -1370,7 +1382,7 @@ - + @@ -1380,7 +1392,7 @@ - + @@ -1390,7 +1402,7 @@ - + @@ -1399,7 +1411,7 @@ - + @@ -1408,72 +1420,81 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + + + + + + + diff --git a/notulen/wk6-2.txt b/notulen/wk6-2.txt index 142b2e0..36751b6 100644 --- a/notulen/wk6-2.txt +++ b/notulen/wk6-2.txt @@ -20,42 +20,45 @@ Git Code standard -> LOEK update Show updates - [closed] namespace/ using namespace + Code standard with examples not in main? + POC can/should be made in Example. + Code that performs POC should be as the code standard so it can be easy to understand and copied if needed. Environments - Research (POC) - research eventmanager -> Wouter POC (goede voortgang) + research eventmanager -> Wouter POC (goede voortgang) knoppen uitlezen resource manager -> Niels POC check datatype for conversion (na meeting afgerond) alleen implementatie tiled start research ui -> wouter start research ai start research savedata -> loek - start research renderer -> niels (kleine start) + start research renderer -> niels (sprite & color & transform) POC simple (SDL_GPU voor efficiency verbetering) start research scripting -> loek start research debugging (los staande profilers, toevoegen timers voor profilers?) start research physics Starting POC -> Jaro More research about physics [closed] Question customer about physics requirements start reasearch collsion detection -> Jaro - research ecs -> Max POC (change in design of ecs. moved components after each other in memory to increase efficiency.) loek/scripts branch voor ecs. + research ecs -> Max POC add detecting if a component exists. start research particles Starting research -> Jaro (start lifetime. spawning area) Design Adding design asset class -> niels Adding design resource holder -> niels [closed] Adding design gameloop -> Wouter toevoegen - Discuss facade design. - Who is owner of which facade instancies? - who is owner of what? + [closed] Discuss facade design. + [closed] Who is owner of which facade instancies? + [closed] who is owner of what? How does a game designer make a scene? [closed] resourceManager discuss design. - review design document (loeks features) -> Wouter + [closed] review design document (loeks features) -> Wouter Product - [closed] Creating 3rd party tool facade audio -> LOEK verder werken - Api class diagram to c++ + [closed] Api class diagram to c++ Test - [closed] Add unit test for audio (do we want unit tests) - Discuss about what to test (wait on api) testen uitgebreid als je wilt maar mag niet teveel tijd kosten en moet nuttig zijn. - [closed] Change location tests -> loek - Question Bob - + Question Bob + animator heeft 1 sprite sheet (1 sprite) animator sprite relatie + sprite sheet staat altijd in leesvolgorde + Overig + Presentatie maken -> Jaro + -- cgit v1.2.3 From 7e7ee01ba8f9accaecf6349a8504d90cf6ef5164 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 10 Oct 2024 12:32:16 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index c8da785..3981aa4 100644 --- a/time.txt +++ b/time.txt @@ -64,6 +64,7 @@ loek: 2024-10-08 40m review :: Max' ECS code loek: 2024-10-08 5m review :: incorporate feedback and merge PR loek: 2024-10-09 25m review :: feedback discussion + code style update loek: 2024-10-10 1h05m refacting :: fix build system + update readmes +loek: 2024-10-10 1h30m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 4ab1b9f7d759649a3622a9e2806562378f9102b7 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Fri, 11 Oct 2024 11:21:16 +0200 Subject: updated time --- time.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index 3981aa4..254bc33 100644 --- a/time.txt +++ b/time.txt @@ -133,8 +133,13 @@ wouter: 2024-09-30 1h40m project meeting wouter: 2024-10-03 1h30m discussing event with seger wouter: 2024-10-03 4h developing event poc wouter: 2024-10-03 1h30m creating gameloop design -wouter: 2024-10-04 2h developing event poc wouter: 2024-10-03 1h30m project meeting +wouter: 2024-10-04 2h developing event poc +wouter: 2024-10-04 1h15m project meeting +wouter: 2024-10-07 2h45m project meeting +wouter: 2024-10-08 4h: finishing keyboard and mouse events +wouter: 2024-10-09 3h: intergrating gameloop with events for testing +wouter: 2024-10-10 1h30m project meeting niels: 2024-09-02 1h project meeting :: project kickoff -- cgit v1.2.3 From fcb284af9426e6957b1111cccb8f1cccd346d751 Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Fri, 11 Oct 2024 13:32:12 +0200 Subject: week 6 time update --- time.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/time.txt b/time.txt index 3981aa4..3b580e6 100644 --- a/time.txt +++ b/time.txt @@ -176,6 +176,11 @@ niels: 2024-10-01 1h30m try implementating library in git submodule. And refacto niels: 2024-10-02 1h finishing adding git submodule and bugs related to compiling external library niels: 2024-10-02 4h refacting code further so that textures and spritesheet work and fixing bugs. niels: 2024-10-04 1h10m project meeting +niels: 2024-10-07 2h45m project meeting +niels: 2024-10-09 2h adding the rendering components to api, and making the rendering system +niels: 2024-10-09 3h researching and programming,debugging the rendersystem +niels: 2024-10-10 3h Test jaro/particels branch to improve sdl functionalities. additionally, researching the necessary components +niels: 2024-10-11 1h30m project meeting -- cgit v1.2.3 From 43067aec84b6c8fd07f8e18754e76ef398363846 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 11 Oct 2024 13:41:25 +0200 Subject: fix time.txt --- time.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/time.txt b/time.txt index 6764fd7..300a193 100644 --- a/time.txt +++ b/time.txt @@ -145,8 +145,8 @@ wouter: 2024-10-03 1h30m project meeting wouter: 2024-10-04 2h developing event poc wouter: 2024-10-04 1h15m project meeting wouter: 2024-10-07 2h45m project meeting -wouter: 2024-10-08 4h: finishing keyboard and mouse events -wouter: 2024-10-09 3h: intergrating gameloop with events for testing +wouter: 2024-10-08 4h finishing keyboard and mouse events +wouter: 2024-10-09 3h intergrating gameloop with events for testing wouter: 2024-10-10 1h30m project meeting -- cgit v1.2.3 From 74d9aab0fb2717a50fdc46e618be5b3e4a36ae2b Mon Sep 17 00:00:00 2001 From: Jaro Date: Fri, 11 Oct 2024 19:46:25 +0200 Subject: updated time --- time.txt | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/time.txt b/time.txt index 300a193..a75465f 100644 --- a/time.txt +++ b/time.txt @@ -244,4 +244,13 @@ jaro: 2024-10-01 3h15m research physics + collisions jaro: 2024-10-01 1h30m Particels poc jaro: 2024-10-03 2h project meeting + project lesson jaro: 2024-10-04 1h15m project meeting +jaro: 2024-10-07 2h particle system +jaro: 2024-10-07 30m project lesson +jaro: 2024-10-07 2hm project meeting +jaro: 2024-10-07 4h30m particle system +jaro: 2024-10-09 30m particle system with ECS +jaro: 2024-10-10 3h30m particle system with ECS +jaro: 2024-10-10 1h30m project meeting +jaro: 2024-10-11 30m weekly update + # vim:ft=cfg -- cgit v1.2.3 From 2cc43cd24c17b0ec56f01a39b2ac53c15a0a4b88 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 11 Oct 2024 21:21:13 +0200 Subject: update time.txt descriptions --- time.txt | 76 ++++++++++++++++++++++++++++++++-------------------------------- 1 file changed, 38 insertions(+), 38 deletions(-) diff --git a/time.txt b/time.txt index 300a193..0b68667 100644 --- a/time.txt +++ b/time.txt @@ -1,69 +1,69 @@ -loek: 2024-09-02 1h project meeting :: project kickoff +loek: 2024-09-02 1h project meeting (project kickoff) loek: 2024-09-02 45m project meeting -loek: 2024-09-02 1h4m repository scaffolding -loek: 2024-09-03 25m repository scaffolding -loek: 2024-09-03 1h30m repository scaffolding :: engine repository, unit testing -loek: 2024-09-04 1h30m repository scaffolding :: latex example code +loek: 2024-09-02 1h4m tooling :: repository (scaffolding) +loek: 2024-09-03 25m tooling :: repository (scaffolding) +loek: 2024-09-03 1h30m tooling :: unit testing +loek: 2024-09-04 1h30m tooling :: documentation (add latex example code) loek: 2024-09-04 50m poc :: dynamic library linking test example -loek: 2024-09-04 45m repository scaffolding :: visual studio code latex configuration -loek: 2024-09-04 20m repository scaffolding :: visual studio code cmake configuration -loek: 2024-09-05 15m repository scaffolding :: additional latex contributing guidelines +loek: 2024-09-04 45m tooling :: repository (visual studio code latex configuration) +loek: 2024-09-04 20m tooling :: repository (visual studio code cmake configuration) +loek: 2024-09-05 15m tooling :: documentation (additional latex contributing guidelines) loek: 2024-09-05 1h40m project meeting -loek: 2024-09-05 1h24m time report script -loek: 2024-09-06 55m time report script -loek: 2024-09-09 30m review :: niels code style guide -loek: 2024-09-09 45m review :: wouter research PR#5 -loek: 2024-09-09 25m documentation style guide +loek: 2024-09-05 1h24m tooling :: time report script +loek: 2024-09-06 55m tooling :: time report script +loek: 2024-09-09 30m review :: style (niels code style guide) +loek: 2024-09-09 45m review :: PR review (#5 wouter research) +loek: 2024-09-09 25m docs :: style guide loek: 2024-09-10 1h55m project meeting -loek: 2024-09-10 25m briefing :: watch bob videos -loek: 2024-09-10 5m docs :: update readme -loek: 2024-09-10 12m docs :: add comparison package and more example latex code +loek: 2024-09-10 25m research :: watch bob's videos +loek: 2024-09-10 5m tooling :: repository (update readme) +loek: 2024-09-10 12m tooling :: documentation (comparison package & more example latex code) loek: 2024-09-10 30m project meeting loek: 2024-09-11 1h40m research :: profiling and debugging -loek: 2024-09-12 15m integration :: PR merge +loek: 2024-09-12 15m review :: PR review loek: 2024-09-12 30m research :: audio loek: 2024-09-13 1h10m project meeting -loek: 2024-09-13 45m integration :: PR merge -loek: 2024-09-14 45m refactoring :: clean up LaTeX build system -loek: 2024-09-14 1h10m docs :: requirements -loek: 2024-09-15 2h55m docs :: requirements -loek: 2024-09-16 2h30m docs :: requirements +loek: 2024-09-13 45m review :: PR review +loek: 2024-09-14 45m tooling :: documentation (clean up LaTeX build system) +loek: 2024-09-14 1h10m tooling :: requirements +loek: 2024-09-15 2h55m tooling :: requirements +loek: 2024-09-16 2h30m tooling :: requirements loek: 2024-09-17 1h20m project meeting -loek: 2024-09-17 55m bugs :: cross-platform latexmk filespec -loek: 2024-09-17 2h25m docs :: requirements +loek: 2024-09-17 55m tooling :: documentation (cross-platform latexmk filespec bug) +loek: 2024-09-17 2h25m tooling :: requirements loek: 2024-09-18 2h20m docs :: requirements loek: 2024-09-18 1h50m research :: audio -loek: 2024-09-18 1h05m integration :: PR merge -loek: 2024-09-19 30m docs :: requirements +loek: 2024-09-18 1h05m review :: PR review +loek: 2024-09-19 30m tooling :: requirements loek: 2024-09-19 15m project meeting loek: 2024-09-19 1h30m project meeting loek: 2024-09-19 45m project meeting -loek: 2024-09-19 15m docs :: remove versioning -loek: 2024-09-19 30m PR merge and style guide update +loek: 2024-09-19 15m tooling :: documentation (move to git commit versioning) +loek: 2024-09-19 30m review :: PR review (+ style guide update) loek: 2024-09-22 2h15m docs :: research loek: 2024-09-24 1h45m project meeting -loek: 2024-09-25 3h implementation :: audio facade and API +loek: 2024-09-25 3h implementation :: audio API loek: 2024-09-26 2h project meeting -loek: 2024-09-25 1h20m implementation :: audio facade and API -loek: 2024-09-27 20m PR merge and style guide update -loek: 2024-09-27 55m implementation :: fix library import structure -loek: 2024-09-28 2h20m implementation :: audio facade and API +loek: 2024-09-25 1h20m implementation :: audio API +loek: 2024-09-27 20m review :: PR review (+ style guide update) +loek: 2024-09-27 55m tooling :: build system (fix library import structure) +loek: 2024-09-28 2h20m implementation :: audio API loek: 2024-09-29 1h55m implementation :: debug logging facilities -loek: 2024-09-29 20m implementation :: audio facade -loek: 2024-09-29 45m docs :: audio facade design +loek: 2024-09-29 20m implementation :: audio API +loek: 2024-09-29 45m docs :: design :: audio API loek: 2024-09-30 1h40m project meeting loek: 2024-10-01 2h20m review :: feedback & discussing software design -loek: 2024-10-01 30m implementation :: audio facade and API +loek: 2024-10-01 30m implementation :: audio API loek: 2024-10-03 1h30m project meeting loek: 2024-10-04 15m research :: read others' research loek: 2024-10-04 1h15m project meeting -loek: 2024-10-05 1h10m refacting :: unify unit tests + update code style +loek: 2024-10-05 1h10m tooling :: unit testing (unify unit tests + update code style) loek: 2024-10-06 3h40m implementation :: scripting interface loek: 2024-10-07 2h45m project meeting loek: 2024-10-08 40m review :: Max' ECS code loek: 2024-10-08 5m review :: incorporate feedback and merge PR loek: 2024-10-09 25m review :: feedback discussion + code style update -loek: 2024-10-10 1h05m refacting :: fix build system + update readmes +loek: 2024-10-10 1h05m tooling :: build system (fix libraries + update readmes) loek: 2024-10-10 1h30m project meeting max: 2024-09-02 1h project kickoff -- cgit v1.2.3 From 7af12557fac836ca00ba9de8703f06f3db96aea8 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 12 Oct 2024 20:55:11 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 0b68667..93d502f 100644 --- a/time.txt +++ b/time.txt @@ -65,6 +65,7 @@ loek: 2024-10-08 5m review :: incorporate feedback and merge PR loek: 2024-10-09 25m review :: feedback discussion + code style update loek: 2024-10-10 1h05m tooling :: build system (fix libraries + update readmes) loek: 2024-10-10 1h30m project meeting +loek: 2024-10-12 1h15m implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 359e5314ed504ed2dc20df0f9fea4e5f6d7f55b4 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 13 Oct 2024 20:57:04 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index b62a38c..5566af0 100644 --- a/time.txt +++ b/time.txt @@ -66,6 +66,7 @@ loek: 2024-10-09 25m review :: feedback discussion + code style update loek: 2024-10-10 1h05m tooling :: build system (fix libraries + update readmes) loek: 2024-10-10 1h30m project meeting loek: 2024-10-12 1h15m implementation :: scripting interface +loek: 2024-10-13 1h implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From b65d3148fa01fe295ad430c8a0804a0aa2b81200 Mon Sep 17 00:00:00 2001 From: Jaro Date: Mon, 14 Oct 2024 13:55:07 +0200 Subject: added notes --- notulen/wk7-1.txt | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 notulen/wk7-1.txt diff --git a/notulen/wk7-1.txt b/notulen/wk7-1.txt new file mode 100644 index 0000000..164e0ea --- /dev/null +++ b/notulen/wk7-1.txt @@ -0,0 +1,55 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement -> Jaro write document + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + design document + Discussing top-down + Game design + - + Git + Code standard -> LOEK update + Show updates + Code standard with examples not in main? -> niels + Environments + - + Research (POC) + research eventmanager -> Wouter POC (goede voortgang) knoppen uitlezen + resource manager -> Niels POC check datatype for conversion (na meeting afgerond) alleen implementatie tiled + start research ui -> wouter + start research ai + start research savedata -> loek + start research renderer -> niels (sprite & color & transform) POC simple (SDL_GPU voor efficiency verbetering) + start research scripting -> loek + [closed] start research debugging (los staande profilers, toevoegen timers voor profilers?) + start research physics Starting POC -> Jaro + More research about physics + start reasearch collision detection -> Jaro + research ecs -> Loek will add fix for derived class for scripts + start research particles Starting research -> Jaro (start lifetime. spawning area) + Design + Adding design asset class -> niels + Adding design resource holder -> niels + How does a game designer make a scene? + Product + - + Test + - + Question Bob + animator heeft 1 sprite sheet (1 sprite) animator sprite relatie (gevraagd) + sprite sheet staat altijd in leesvolgorde (gevraagd) + mag de API gewoon een interface worden voor wat onderliggend een ECS is. + Overig + Timers voor systems + + -- cgit v1.2.3 From d4fbaad4ad83e430b8a28436c63a8e0f34abc762 Mon Sep 17 00:00:00 2001 From: Jaro Date: Mon, 14 Oct 2024 13:56:15 +0200 Subject: updated notes --- notulen/wk7-1.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/notulen/wk7-1.txt b/notulen/wk7-1.txt index 164e0ea..2462a37 100644 --- a/notulen/wk7-1.txt +++ b/notulen/wk7-1.txt @@ -51,5 +51,6 @@ mag de API gewoon een interface worden voor wat onderliggend een ECS is. Overig Timers voor systems + 8 uur per groepsgenoot deze week door drukte. -- cgit v1.2.3 From 2706e419bb4d51b891ee6b97eb460d71151b8cab Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Mon, 14 Oct 2024 14:12:48 +0200 Subject: Added tasks --- time.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/time.txt b/time.txt index fe12cd5..e9e6b2f 100644 --- a/time.txt +++ b/time.txt @@ -111,6 +111,9 @@ max: 2024-10-09 2h trying to get clang-format working (ending up upgrading Linux max: 2024-10-09 30m reviewing feedback of ecs-homemade max: 2024-10-09 30m expanding class diagram max: 2024-10-09 2h50m investigating compiler error options for game programmer when adding too much or too little Components of a specific type +max: 2024-10-13 30m preparing 'kennisdeling' and 'functioneringsgesprek' +max: 2024-10-14 2h kennisdeling +max: 2024-10-14 1h30m twelfth project meeting wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From 5589d3ec3d1fa6fca2ed43d56bfb8d05ed3544d5 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 14 Oct 2024 16:18:20 +0200 Subject: update time.txt --- time.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/time.txt b/time.txt index 5566af0..617f675 100644 --- a/time.txt +++ b/time.txt @@ -67,6 +67,8 @@ loek: 2024-10-10 1h05m tooling :: build system (fix libraries + update readmes) loek: 2024-10-10 1h30m project meeting loek: 2024-10-12 1h15m implementation :: scripting interface loek: 2024-10-13 1h implementation :: scripting interface +loek: 2024-10-14 2h project meeting (class) +loek: 2024-10-14 1h30m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From c3004f72518886d064a208a85cf1268dc5a811b3 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 16 Oct 2024 16:21:26 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 617f675..28a7616 100644 --- a/time.txt +++ b/time.txt @@ -69,6 +69,7 @@ loek: 2024-10-12 1h15m implementation :: scripting interface loek: 2024-10-13 1h implementation :: scripting interface loek: 2024-10-14 2h project meeting (class) loek: 2024-10-14 1h30m project meeting +loek: 2024-10-16 1h40m implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 798935074f3cf6ddbbc8b554609a8cb022a008a1 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Wed, 16 Oct 2024 17:12:53 +0200 Subject: Added tasks --- time.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/time.txt b/time.txt index cce2f9d..4258eca 100644 --- a/time.txt +++ b/time.txt @@ -116,6 +116,9 @@ max: 2024-10-09 2h50m investigating compiler error options for game programmer w max: 2024-10-13 30m preparing 'kennisdeling' and 'functioneringsgesprek' max: 2024-10-14 2h kennisdeling max: 2024-10-14 1h30m twelfth project meeting +max: 2024-10-16 30m investigated whether or not EnTT can handle multiple inheritance +max: 2024-10-16 3h rethinked scripting (to avoid mutliple inheritance) +max: 2024-10-16 20m added new scripting idea to ecs-homemade wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From ae7dd2dd9f268f34b1e49b4ce0dcf2a23aa50984 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 16 Oct 2024 17:24:09 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 28a7616..4de8014 100644 --- a/time.txt +++ b/time.txt @@ -70,6 +70,7 @@ loek: 2024-10-13 1h implementation :: scripting interface loek: 2024-10-14 2h project meeting (class) loek: 2024-10-14 1h30m project meeting loek: 2024-10-16 1h40m implementation :: scripting interface +loek: 2024-10-16 40m implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From e008c6d28cc2ea1beadc9fd9f360dc93d6ce1107 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Wed, 16 Oct 2024 18:33:34 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 4de8014..1318a09 100644 --- a/time.txt +++ b/time.txt @@ -71,6 +71,7 @@ loek: 2024-10-14 2h project meeting (class) loek: 2024-10-14 1h30m project meeting loek: 2024-10-16 1h40m implementation :: scripting interface loek: 2024-10-16 40m implementation :: scripting interface +loek: 2024-10-16 20m implementation :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From ce637a08089287d7aa445e2c4c40fab9199da41a Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 17 Oct 2024 12:47:46 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 1318a09..e870c4b 100644 --- a/time.txt +++ b/time.txt @@ -72,6 +72,7 @@ loek: 2024-10-14 1h30m project meeting loek: 2024-10-16 1h40m implementation :: scripting interface loek: 2024-10-16 40m implementation :: scripting interface loek: 2024-10-16 20m implementation :: scripting interface +loek: 2024-10-17 40m project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 96454358e9cbaa13034e436e5a6f58e24d4f32a6 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Thu, 17 Oct 2024 16:37:50 +0200 Subject: Added task --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 4258eca..589151a 100644 --- a/time.txt +++ b/time.txt @@ -119,6 +119,7 @@ max: 2024-10-14 1h30m twelfth project meeting max: 2024-10-16 30m investigated whether or not EnTT can handle multiple inheritance max: 2024-10-16 3h rethinked scripting (to avoid mutliple inheritance) max: 2024-10-16 20m added new scripting idea to ecs-homemade +max: 2024-10-17 1h thirteenth project meeting wouter: 2024-09-02 1h project meeting :: project kickoff wouter: 2024-09-02 45m project meeting -- cgit v1.2.3 From 7b43750be38ad205ab1e130930261ca84af714dd Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 17 Oct 2024 17:17:31 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index e870c4b..58ead6a 100644 --- a/time.txt +++ b/time.txt @@ -73,6 +73,7 @@ loek: 2024-10-16 1h40m implementation :: scripting interface loek: 2024-10-16 40m implementation :: scripting interface loek: 2024-10-16 20m implementation :: scripting interface loek: 2024-10-17 40m project meeting +loek: 2024-10-17 10m review :: PR review (#5 and #6) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 4a40378f58160212c0c1c42552a1301e3a498037 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 18 Oct 2024 11:30:41 +0200 Subject: update time2tex format --- scripts/time2tex.py | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/scripts/time2tex.py b/scripts/time2tex.py index a5d6802..f3f8de9 100755 --- a/scripts/time2tex.py +++ b/scripts/time2tex.py @@ -11,7 +11,7 @@ def fmt_duration(sec): hour = mins // 60 if hour > 0: - out.append("%02dh" % (hour, )) + out.append("%dh" % (hour, )) mins = mins % 60 out.append("%02dm" % (mins, )) @@ -91,16 +91,13 @@ def fmt_weekly_overview(times): return tex.env('table', tex.join( tex.cmd('centering'), tex.cmd('fitimg', - tex.env('tabular', r'l' + r'r@{~}l' * len(members) + r'@{\qquad}r', tex.join( + tex.env('tabular', r'l' + r'r@{~}l' * len(members) + r'>{\quad}r', tex.join( tex.cmd('toprule'), - tex.tabrule(*[ - tex.cmd('textbf', cell) - for cell in [ - tex.esc("#"), - *tex.explist([ member, "" ] for member in members), - "Subtotal", - ] - ]), + tex.tabrule( + tex.cmd("textbf", tex.esc("#")), + *[tex.cmd("multicolumn", "2", "c", tex.cmd("textbf", member)) for member in members], + tex.cmd("textbf", "Subtotal"), + ), tex.cmd('midrule'), *[ tex.tabrule(*[ -- cgit v1.2.3 From 4760be8c90297857ba5c9cf82e2478039fdc9365 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 18 Oct 2024 14:50:41 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index c55d0c7..301e70f 100644 --- a/time.txt +++ b/time.txt @@ -74,6 +74,7 @@ loek: 2024-10-16 40m implementation :: scripting interface loek: 2024-10-16 20m implementation :: scripting interface loek: 2024-10-17 40m project meeting loek: 2024-10-17 10m review :: PR review (#5 and #6) +loek: 2024-10-18 1h40m docs :: design :: scripting interface max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From dd52051fa7cec81118c85f6a6b4c8471c04e4613 Mon Sep 17 00:00:00 2001 From: Jaro Date: Sat, 19 Oct 2024 14:32:44 +0200 Subject: updated time --- time.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/time.txt b/time.txt index 301e70f..0bb396f 100644 --- a/time.txt +++ b/time.txt @@ -269,5 +269,8 @@ jaro: 2024-10-09 30m particle system with ECS jaro: 2024-10-10 3h30m particle system with ECS jaro: 2024-10-10 1h30m project meeting jaro: 2024-10-11 30m weekly update +jaro: 2024-10-14 2h knowledge sharing +jaro: 2024-10-14 1h30m project meeting +jaro: 2024-10-17 1h project discussion # vim:ft=cfg -- cgit v1.2.3 From f7a68fb685adfa79c66c13968b0b26b425901f59 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 20 Oct 2024 18:25:03 +0200 Subject: fix latex --- research.tex | 501 ++++++++++++++++++++++++++++++++++------------------------- sources.bib | 11 +- 2 files changed, 292 insertions(+), 220 deletions(-) diff --git a/research.tex b/research.tex index 791e9f1..385efbe 100644 --- a/research.tex +++ b/research.tex @@ -6,7 +6,7 @@ \tablestables \newpage -\section{Introduction} +% \section{Introduction} \section{Game engine} @@ -53,7 +53,7 @@ layers are divided into the following categories:\noparbreak The above mentioned layers should be structured, somehow. One of the requirements is that the game engine's API uses a so-called gameObject (with one or more component(s)). The gameObject is described in more detail at -\cref{sec:Gameobjects/components}. +\cref{sec:gameobjects-components}. There are multiple structures that could be used to structure a game engine. It's of course possible to use inheritance. A major disadvantages of inheritance is that it's @@ -81,8 +81,8 @@ harder \autocite{man:DecoratorDesignPattern}. \label{fig:decorator} \end{figure} -The Extension Objects design pattern (as shown in \cref{fig:extension objects}) could -also be used to structure the game engine. The Extension Objects design pattern +The \emph{extension objects} design pattern (as shown in \cref{fig:dp:ext-objs}) +could also be used to structure the game engine. The extension objects design pattern allows to modify an object's propperties/behavior by adding one (or more) Extensions. The object that is modified, could be the gameObject and the components could be the Extensions. This is quite the same as the required API. An advantage is, that the @@ -92,7 +92,7 @@ for the sprite Extension and the method \codeinline{update()} for the script Extension). In other words, the interfaces of the different Extensions should not be the same. This is way more flexible than the Decorator design pattern. A disadvantage is that the data and functionality are in the same class (namely inside the Extion's -methods), so it's not sepperated. Another disadvantage is that the Extension Objects +methods), so it's not sepperated. Another disadvantage is that the extension objects design pattern can be quite slow, because objects are scattered in memory (and it is very hard to quickly get their memory address) \autocite{man:ExtensionObjectDesignPattern, man:extionsionObjectsStackOverflow}. @@ -100,9 +100,9 @@ very hard to quickly get their memory address) \begin{figure} \centering \includegraphics[width=0.5\textwidth]{img/ExtensionObjects.jpg} - \caption{Extension Objects design pattern} + \caption{Extension objects design pattern} Source: \autocite{img:extionsionObjects} - \label{fig:extension objects} + \label{fig:dp:ext-objs} \end{figure} Another (very popular) design pattern to structure the game engine, is the Entity @@ -179,7 +179,7 @@ based on the amount of stars on GitHub. EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT\\ \bottomrule \end{tabular} - \caption{Popular \gls{ecs} libraries} + \caption{Popular \glsfmtname{ecs} libraries} Source: \autocite{github:awesome-ecs} \label{tab:popularECSLibraries} \end{table} @@ -190,10 +190,10 @@ It is, of course, not necessary to use a library to implement an \gls{ecs} architecture. However, it seems very hard to achieve the same performance as a library \autocite{github:ecsfaq}. -\subsection{Conclusion} +% \subsection{Conclusion} \section{Gameobjects/components} -\label{sec:Gameobjects/components} +\label{sec:gameobjects-components} \subsection{Introduction} @@ -234,7 +234,7 @@ can not have more than one parent. \autocite{man:unityTransformClass} \subsection{Conclusion} -\section{Third-party Tools} +\section{Third-party tools} \subsection{Introduction} @@ -248,7 +248,7 @@ described. \subsection{Findings} -\subsubsection{Media Frameworks} +\subsubsection{Media frameworks} A game engine must have the ability to handle user input, render graphics, and process audio. Several large frameworks are available that provide these features and @@ -359,7 +359,7 @@ Unity supports many different image formats:\noparbreak \end{itemize} \end{multicols} -\subsection{Audio Format} +\subsection{Audio format} % TODO: +ref (both urldate 2024-09-12) The choice of audio format for the cr\^epe game engine depends on several factors, @@ -386,46 +386,46 @@ licensing flexibility. \subsection{Conclusion} -\section{Rendering} - -\subsection{Introduction} - -\subsection{Findings} - -\subsection{Conclusion} - -\section{Event manager/game loop} - -\subsection{Introduction} - -\subsection{Findings} - -\subsection{Conclusion} - -% TODO: this entire section -\section{Profiling and debugging} - -% Which profiling and debugging features are wanted? -% How to provide those profiling and debugging features? -% Can most of the profiling/debugging be handled by external tools? - -% Ideas: -% - flame graph -% - watchtable (combine w/ fps/speed control overlay?) -% - debug printing utility functions - -\subsection{Introduction} - -\subsection{Findings} - -\subsubsection{Callgrind} - -\begin{comparison} - \pro{Source code does not need to be modified for profiling} - \con{Execution speed is severely impacted} -\end{comparison} - -\subsection{Conclusion} +% \section{Rendering} +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsection{Conclusion} + +% \section{Event manager/game loop} +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsection{Conclusion} + +% % TODO: this entire section +% \section{Profiling and debugging} +% +% % Which profiling and debugging features are wanted? +% % How to provide those profiling and debugging features? +% % Can most of the profiling/debugging be handled by external tools? +% +% % Ideas: +% % - flame graph +% % - watchtable (combine w/ fps/speed control overlay?) +% % - debug printing utility functions +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsubsection{Callgrind} +% +% \begin{comparison} +% \pro{Source code does not need to be modified for profiling} +% \con{Execution speed is severely impacted} +% \end{comparison} +% +% \subsection{Conclusion} \section{Audio} @@ -472,20 +472,20 @@ is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}. Due to a severe shortage of libraries that fit our requirements, SoLoud appears to be the most suitable (and only) audio library for use in this project. -\section{Scripting} - -\subsection{Introduction} - -\subsection{Findings} - -\subsection{Conclusion} +% \section{Scripting} +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsection{Conclusion} \section{Physics} %links %ragdoll info: https://learn.unity.com/tutorial/creating-ragdolls-2019#649c42abedbc2a04c2145ce7 %softbody info: https://www.greenfoot.org/scenarios/29502 -. + %2d box concepts: https://box2d.org/ %liquidfun (fork of box2d): https://google.github.io/liquidfun/ %Chipmunk2D: https://chipmunk-physics.net/ @@ -493,118 +493,141 @@ the most suitable (and only) audio library for use in this project. %rigid body:https://docs.unity3d.com/ScriptReference/Rigidbody.html \subsection{Introduction} -This part of the research explains Physics concepts and the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation. +This part of the research explains Physics concepts and the use of physics in a game +engine. Furthermore, it examines the ease of using a physics engine compared to +implementing physics from scratch. Ultimately, a recommendation will be provided on +whether using a physics engine is more feasible than a custom implementation. \subsection{Physics concepts} -Some information about certain Physics topics. second partdescibes what physics we will be able to use and what it is. +Some information about certain Physics topics. second partdescibes what physics we +will be able to use and what it is. + %Physics core concepts: https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively %ragdoll https://bluebirdinternational.com/ragdoll-physics/ -Kinematics: -Kinematics in game physics involves calculating the position, velocity, and acceleration of objects to simulate realistic motion. It affects everything from character movement to projectiles and vehicles. Collision detection is key, as it determines when objects collide and how they respond, including any damage or effects. Kinematics also helps create lifelike animations, like jumping or running, enhancing the game's realism and immersion. -\begin{itemize} - \item mass - \item speed - \item direction - \item collision detection -\end{itemize} - - -Dynamics: -Dynamics simulate object interactions and forces, such as gravity and friction, to enhance realism. It includes rigid body, soft body, and fluid dynamics. For example, it affects car movements in racing games and projectiles in shooters. Balancing dynamics is crucial to maintain performance. Ragdoll physics, a related concept, models a character’s body as interconnected rigid bodies for realistic movement. -\begin{itemize} - \item rigid body dynamics - \item soft body dynamics - \item fluid dynamics - \item ragdoll physics -\end{itemize} - - -Collision: -Collision detection is the process of determining when two or more objects in the game world come into contact with each other. There are several techniques used for collision detection. -\begin{itemize} - \item bounding boxes - \item bounding spheres - \item mesh-based collision -\end{itemize} -These techniques involve creating simple shapes around the objects and checking if they intersect with each other. - -Rigidbody: -Rigidbodys deels with the behavior of of non deformable solid objects. it has some physical properties. -\begin{itemize} - \item mass - \item velocity - \item angular velocity - \item orientation -\end{itemize} -To calculate all forces applied to the rigid body the most used algoritm is Newton-Euler equations. The alogritm is about mass an conservation of energy. - -Softbody: -Soft body dynamics simulates deformable objects like cloth, fluids, and flesh, adding complexity beyond rigid body dynamics. Key techniques include: -\begin{itemize} - \item Finite Element Method: Divides the object into small elements that interact based on physical laws. - \item Mass-Spring Systems: Uses masses and springs to model deformation and stretching. -\end{itemize} -These methods enhance game realism by creating lifelike clothing, natural water effects, and realistic collision deformations. However, they are resource intensive an require precise calculations to avoid unrealistic results. - -Particle Systems: -Particle systems simulate numerous small objects to create larger effects like dust, smoke, fire, or explosions. These effects can add an extra layer of realism to a game. - -Fluid Dynamics: -Fluid dynamics shows how fluids move and behave. In game physics, it simulates liquids like water or lava, adding complexity and realism to games with fluid interactions. - -Aerodynamics: -Aerodynamics shows the movement of air and its interaction with solid objects. In video games, it simulates how objects like airplanes or birds move through the air, adding a realistic touch to games involving flight or gliding. - +\begin{description} + \item[Kinematics] Kinematics in game physics involves calculating the position, + velocity, and acceleration of objects to simulate realistic motion. It affects + everything from character movement to projectiles and vehicles. Collision + detection is key, as it determines when objects collide and how they respond, + including any damage or effects. Kinematics also helps create lifelike + animations, like jumping or running, enhancing the game's realism and immersion. + \begin{itemize} + \item mass + \item speed + \item direction + \item collision detection + \end{itemize} + \item[Dynamics] Dynamics simulate object interactions and forces, such as gravity + and friction, to enhance realism. It includes rigid body, soft body, and fluid + dynamics. For example, it affects car movements in racing games and projectiles + in shooters. Balancing dynamics is crucial to maintain performance. Ragdoll + physics, a related concept, models a character's body as interconnected rigid + bodies for realistic movement. + \begin{itemize} + \item rigid body dynamics + \item soft body dynamics + \item fluid dynamics + \item ragdoll physics + \end{itemize} + \item[Collision] Collision detection is the process of determining when two or more + objects in the game world come into contact with each other. There are several + techniques used for collision detection. + \begin{itemize} + \item bounding boxes + \item bounding spheres + \item mesh-based collision + \end{itemize} + These techniques involve creating simple shapes around the objects and checking + if they intersect with each other. + \item[Rigidbody] Rigidbodys deels with the behavior of of non deformable solid + objects. it has some physical properties. + \begin{itemize} + \item mass + \item velocity + \item angular velocity + \item orientation + \end{itemize} + To calculate all forces applied to the rigid body the most used algoritm is + Newton-Euler equations. The alogritm is about mass an conservation of energy. + \item[Softbody] Soft body dynamics simulates deformable objects like cloth, fluids, + and flesh, adding complexity beyond rigid body dynamics. Key techniques + include:\noparbreak + \begin{itemize} + \item Finite Element Method: Divides the object into small elements that + interact based on physical laws. + \item Mass-Spring Systems: Uses masses and springs to model deformation and + stretching. + \end{itemize} + These methods enhance game realism by creating lifelike clothing, natural water + effects, and realistic collision deformations. However, they are resource + intensive an require precise calculations to avoid unrealistic results. + \item[Particle Systems] Particle systems simulate numerous small objects to + create larger effects like dust, smoke, fire, or explosions. These effects can + add an extra layer of realism to a game. + \item[Fluid Dynamics] Fluid dynamics shows how fluids move and behave. In game + physics, it simulates liquids like water or lava, adding complexity and realism + to games with fluid interactions. + \item[Aerodynamics] Aerodynamics shows the movement of air and its interaction + with solid objects. In video games, it simulates how objects like airplanes or + birds move through the air, adding a realistic touch to games involving flight + or gliding. +\end{description} \subsection{Findings} -This part shows some phiscics engines an certain physics features that could be needed within the project. +This part shows some phiscics engines an certain physics features that could be +needed within the project. +\subsubsection{Available physics engines} -\subsubsection{available Physics Engines} -available physics engines for complex Physics -Box2D: +Available physics engines for complex physics:\noparbreak \begin{description} - \item[Description:] One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. - \item[License:] MIT License -\end{description} + \item[Box2D] One of the most popular and widely used open-source 2D physics + engines, Box2D is known for its simplicity, robustness, and efficiency. -LiquidFun: -\begin{description} - \item[Description:] A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It’s ideal for games that require both solid and fluid dynamics. - \item[License:] Apache License 2.0 -\end{description} + MIT licensed. + \item[LiquidFun] A fork of Box2D, LiquidFun adds particle-based fluid simulation to + Box2D's rigid body dynamics. It's ideal for games that require both solid and + fluid dynamics. -Chipmunk2D: -\begin{description} - \item[Description:] A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations. - \item[License:] MIT License -\end{description} + Apache 2.0 licensed. + \item[Chipmunk2D] A lightweight and fast 2D physics engine that emphasizes ease of + use and flexibility. Chipmunk2D is designed to be simple enough to understand and + integrate but powerful enough for complex simulations. + MIT licensed. +\end{description} \subsubsection{Physics system (engine specific physics engine)} -A physics engine that is independent can be used across multiple game engines or applications. But when the physics engine is built directly into the game engine and can not be reused independently, it is often considered a physics system or physics module within that specific engine. It is optimized and designed to work within the constraints and features of that particular engine. -features a physics engine should provide is determined by the requirements. -Because the only requirement is that the user should easily add physics a list below is made for simple physics that can be implemented without the use of an 3rd party physics engine. Other features can be made by the user using scripts. +A physics engine that is independent can be used across multiple game engines or +applications. But when the physics engine is built directly into the game engine and +can not be reused independently, it is often considered a physics system or physics +module within that specific engine. It is optimized and designed to work within the +constraints and features of that particular engine. -For simple features as listed below (besides collision and particels) a Physics system is sufficient to provide these features to the game engine. +features a physics engine should provide is determined by the requirements. Because +the only requirement is that the user should easily add physics a list below is made +for simple physics that can be implemented without the use of an 3rd party physics +engine. Other features can be made by the user using scripts. -Simple Physics features a physics engine could provide: +For simple features as listed below (besides collision and particels) a Physics +system is sufficient to provide these features to the game engine. +Simple Physics features a physics engine could provide:\noparbreak \begin{itemize} - \item Gravity - \item Collision (detection + standard handeling) - \item Rigidbody body - \begin{itemize} + \item Gravity + \item Collision (detection + standard handeling) + \item Rigidbody body\noparbreak + \begin{itemize} \item mass \item gravity scale \item velocity - \item body type + \item body type\noparbreak \begin{itemize} \item Static \item Dynamic @@ -613,8 +636,8 @@ Simple Physics features a physics engine could provide: \end{itemize} \end{itemize} \item collsion detection mode - \item movement - \begin{itemize} + \item movement\noparbreak + \begin{itemize} \item player movement \item bounce \item rotation @@ -624,9 +647,12 @@ Simple Physics features a physics engine could provide: \end{itemize} \subsubsection{Physics with EC} -with EC the component (e.g. Rigidbody) would have some functionality to change its own physics. Besides storing data it would hold function as well for applying gravity, forces, or handle other physics-related logic. -Preview of Rigidbody +with EC the component (e.g.~Rigidbody) would have some functionality to change its +own physics. Besides storing data it would hold function as well for applying +gravity, forces, or handle other physics-related logic. + +Preview of Rigidbody\noparbreak \begin{itemize} \item Mass (data) \item gravityscale (data) @@ -637,15 +663,22 @@ Preview of Rigidbody With this logic inside of each component the gameloop would look like this: -step 1: Have a list of components. -step 2: call for each component the rigidbody with the update function (changing its velocity) -step 3: call for each component the update position function (change x and y of each entity) -step 4: check for collsion handeling (would be the collsion component) +\begin{enumerate}[label={step \arabic*:},leftmargin=5em] + \item Have a list of components. + \item call for each component the rigidbody with the update function (changing its + velocity) + \item call for each component the update position function (change x and y of each + entity) + \item check for collsion handeling (would be the collsion component) +\end{enumerate} -because it is not known with EC if the list contains all object with a rigidbody some overhead is created if the entity does not have a component of the type rigidbody. +Because it is not known with EC if the list contains all object with a rigidbody some +overhead is created if the entity does not have a component of the type rigidbody. \subsubsection{Physics with ECS} -With ECS the component (e.g. Rigidbody) would only be used to store data. all functionality would be moved to the Physics system + +With ECS the component (e.g.~Rigidbody) would only be used to store data. all +functionality would be moved to the Physics system Preview of Rigidbody \begin{itemize} @@ -662,29 +695,52 @@ Preview of physics system A seperate sytem would be made that would do all the calculations for the physics. -With this logic inside of each component the gameloop would look like this: -Step(1): ECS provides a list of rigidbodies (with the enitties) -Step(2): physics system updates all components +With this logic inside of each component the gameloop would look like +this:\noparbreak +\begin{enumerate}[label={Step(\arabic*):},leftmargin=5em] + \item ECS provides a list of rigidbodies (with the enitties) + \item physics system updates all components +\end{enumerate} -The benefit of ECS is that all physics and collsions are handled by one system. The Physics functionalities would be gathered in one place instead of multiple components. The Physics system could seperate the Physics function creating a correct Physics flow with only one loop. For EC to do this each function would need to have its own loop in the gameloop creating more overhead. +The benefit of ECS is that all physics and collsions are handled by one system. The +Physics functionalities would be gathered in one place instead of multiple +components. The Physics system could seperate the Physics function creating a correct +Physics flow with only one loop. For EC to do this each function would need to have +its own loop in the gameloop creating more overhead. -What EC can not provide compared to ECS is a physics world. A physics world would be the physics that apply to all dynamic physics components. If you want to create gravity you can add the force to the world. The physics system would read all the Physics forces in the world and apply them to all dynamic entities. This would create an easier to use interface for the user and improve the efficiency of the physics because the total forces can be calcualted ones and then applied to all dynamic entities. +What EC can not provide compared to ECS is a physics world. A physics world would be +the physics that apply to all dynamic physics components. If you want to create +gravity you can add the force to the world. The physics system would read all the +Physics forces in the world and apply them to all dynamic entities. This would create +an easier to use interface for the user and improve the efficiency of the physics +because the total forces can be calcualted ones and then applied to all dynamic +entities. \subsection{Conclusion} -More components need te be created for both EC and ECS with the diagram provided by the customer. With ECS having the benefit of creating a world where all dynamic object can have a force they interact with. A physics system has the benefit that all physics functionalities are located within one system instead in each component. The flow of Physics updates can be change within the physics system instead of in the gameloop itself. + +More components need te be created for both EC and ECS with the diagram provided by +the customer. With ECS having the benefit of creating a world where all dynamic +object can have a force they interact with. A physics system has the benefit that all +physics functionalities are located within one system instead in each component. The +flow of Physics updates can be change within the physics system instead of in the +gameloop itself. \section{Collisions} \subsection{Introduction} -Collision is mostly made part of an Physics engine, however it is something seperate but some collision handeling is done by the Physics engine that is the reason why they are most of the time one system. +Collision is mostly made part of an Physics engine, however it is something seperate +but some collision handeling is done by the Physics engine that is the reason why +they are most of the time one system. -Collsions exists from two thing. Collsion detection and collsion handeling/ Some handeling is done by the physics engine and by user scripts and will not be explanined in this topic. Collsion detection is the scope of this research. -There is a need of understanding what different type of collision objects are and what algoritm can be used to increase efficiency of the detection. +Collsions exists from two thing. Collsion detection and collsion handeling/ Some +handeling is done by the physics engine and by user scripts and will not be +explanined in this topic. Collsion detection is the scope of this research. There is +a need of understanding what different type of collision objects are and what +algoritm can be used to increase efficiency of the detection. \subsection{Findings} - Collsion detection is made out of 2 fases. %https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection @@ -695,72 +751,89 @@ Collsion detection is made out of 2 fases. %https://matthias-research.github.io/pages/tenMinutePhysics/11-hashing.pdf -The first fase want to make a list out of objects that could be colliding. Some algorithm can be used to make these list in an efficient way. -Quad Trees, R-Trees or a Spatial Hashmap. +The first fase want to make a list out of objects that could be colliding. Some +algorithm can be used to make these list in an efficient way. quadtrees, R-Trees or +a spatial hashmap. \begin{description} - \item[Quadtrees] Quadtrees partition 2D space into quadrants (stored as nodes in a tree), dividing these quadrants into smaller quadrants when they contain more than a certain threshold of elements. - \item[R-Trees] These are data structures commonly used for spatial access. They are more suited for dynamic data and allow efficient querying of rectangles or bounding boxes, making them useful for collision detection. - \item[Spatial hashing] This technique divides space into uniform grids (similar to cells in a 2D array), and each object is assigned to one or more cells based on its position. Objects within the same or adjacent cells are checked for collisions, improving efficiency by limiting the number of checks to nearby objects. + \item[Quadtrees] Quadtrees partition 2D space into quadrants (stored as nodes in a + tree), dividing these quadrants into smaller quadrants when they contain more + than a certain threshold of elements. + \item[R-Trees] These are data structures commonly used for spatial access. They are + more suited for dynamic data and allow efficient querying of rectangles or + bounding boxes, making them useful for collision detection. + \item[Spatial hashing] This technique divides space into uniform grids (similar to + cells in a 2D array), and each object is assigned to one or more cells based on + its position. Objects within the same or adjacent cells are checked for + collisions, improving efficiency by limiting the number of checks to nearby + objects. \end{description} -R-Trees are easy to understand but how the R-tree is build (how objects are inserted) is complex. The benefits of this tree for this project are not needed because Quadtree would be sufficient for this purpose. reading the data would be as fast as the quadtree but implemeting the R-tree and knowing how to implement it takes to much time and is out of scope. - +R-Trees are easy to understand but how the R-tree is build (how objects are inserted) +is complex. The benefits of this tree for this project are not needed because +quadtree would be sufficient for this purpose. reading the data would be as fast as +the quadtree but implemeting the R-tree and knowing how to implement it takes to much +time and is out of scope. \begin{table} - \begin{tabularx}{\linewidth}{lXl} - \toprule - Criteria & Quadtree & R-tree & Spatial Hashing \\ - \midrule - Best for & Static objects, sparse data & Complex shapes, dynamic objects & Fast-moving objects, uniform data \\ - \midrule - Handles moving objects & Poorly (requires restructuring) & Well (efficient updates) & Very well (simple re-hash) \\ - \midrule - Memory usage & Moderate & Moderate to high & Can be high \\ - \midrule - Complexity & Moderate & High & Low \\ - \midrule - Spatial queries & Efficient & Very efficient & Less efficient \\ - \midrule - Grid size sensitivity & Not applicable & Not applicable & High (tuning needed) \\ - \midrule - Handling variable density & Good & Good & Poor \\ - \bottomrule - \end{tabularx} - \caption{Comparison of Quadtree, R-tree, and Spatial Hashing} + \begin{tabularx}{\linewidth}{p{8em}XXX} + \toprule + Criteria & Quadtree & R-tree & Spatial hashing \\ + \midrule + Best for & Static objects, sparse data & Complex shapes, dynamic objects & Fast-moving objects, uniform data \\ + \midrule + Handles moving objects & Poorly (requires restructuring) & Well (efficient updates) & Very well (simple re-hash) \\ + \midrule + Memory usage & Moderate & Moderate to high & Can be high \\ + \midrule + Complexity & Moderate & High & Low \\ + \midrule + Spatial queries & Efficient & Very efficient & Less efficient \\ + \midrule + Grid size sensitivity & N/A & N/A & High (tuning needed) \\ + \midrule + Handling variable density & Good & Good & Poor \\ + \bottomrule + \end{tabularx} + \caption{Comparison of quadtree, R-tree, and spatial hashing} \end{table} - %https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection The second face checks the list from the first face if there are actually colliding. the narrow face detections are descripted in the list below. List of collision detection objects/algoritms (narrow) \begin{description} - \item[Axis-Aligned Bounding Box]One of the simpler forms of collision detection is between two rectangles that are axis aligned — meaning no rotation. The algorithm works by ensuring there is no gap between any of the 4 sides of the rectangles. - \item[Circle Collision] a simple shape for collision detection is between two circles. This algorithm works by taking the center points of the two circles and ensuring the distance between the center points are less than the two radii added together. - \item[Separating Axis Theorem] This is a collision algorithm that can detect a collision between any two convex polygons. It's more complicated to implement than other methods but is more powerful. + \item[Axis-Aligned Bounding Box]One of the simpler forms of collision detection is + between two rectangles that are axis aligned --- meaning no rotation. The + algorithm works by ensuring there is no gap between any of the 4 sides of the + rectangles. + \item[Circle Collision] a simple shape for collision detection is between two + circles. This algorithm works by taking the center points of the two circles and + ensuring the distance between the center points are less than the two radii added + together. + \item[Separating Axis Theorem] This is a collision algorithm that can detect a + collision between any two convex polygons. It's more complicated to implement + than other methods but is more powerful. \end{description} - \subsection{Conclusion} - -\section{Audio} - -\subsection{Introduction} - -\subsection{Findings} - -\subsection{Conclusion} - -\section{AI} - -\subsection{Introduction} - -\subsection{Findings} - -\subsection{Conclusion} +% \section{Audio} +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsection{Conclusion} + +% \section{AI} +% +% \subsection{Introduction} +% +% \subsection{Findings} +% +% \subsection{Conclusion} \end{document} diff --git a/sources.bib b/sources.bib index a34f739..7d7b6f7 100644 --- a/sources.bib +++ b/sources.bib @@ -129,7 +129,7 @@ @misc{img:Decorator, title = {Decorator Pattern Structure Diagram}, - author = {Refactoring Guru}, + author = {{Refactoring Guru}}, url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png}, date = {2024} } @@ -144,8 +144,7 @@ @manual{man:DecoratorDesignPattern, title = {Decorator Design Pattern}, - author = {Refactoring Guru}, - organization = {Refactoring Guru}, + author = {{Refactoring Guru}}, url = {https://refactoring.guru/design-patterns/decorator}, date = {2024} } @@ -167,7 +166,7 @@ @misc{img:ECSBlockDiagram, title = {ECS Diagram}, - author = {Unity}, + author = {{Unity}}, url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/images/ECSBlockDiagram.png}, date = {2024} } @@ -189,8 +188,8 @@ @manual{man:ECSComponentManager, title = {ECS Core API}, - author = {Unity Technologies}, - organization = {Unity}, + author = {{Unity Technologies}}, + organization = {{Unity}}, url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/ecs_core.html}, date = {2024} } -- cgit v1.2.3 From b6008ecc0d7e73df8e02a232a82f5ab0d324d93a Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 20 Oct 2024 18:26:11 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 0bb396f..3d3d79b 100644 --- a/time.txt +++ b/time.txt @@ -75,6 +75,7 @@ loek: 2024-10-16 20m implementation :: scripting interface loek: 2024-10-17 40m project meeting loek: 2024-10-17 10m review :: PR review (#5 and #6) loek: 2024-10-18 1h40m docs :: design :: scripting interface +loek: 2024-10-20 30m review :: PR review (#37) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 92571ea9b11c63d40c2cd3d1d3b7dd064fdddf54 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 21 Oct 2024 11:33:21 +0200 Subject: update time.txt --- time.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/time.txt b/time.txt index 3d3d79b..c814b34 100644 --- a/time.txt +++ b/time.txt @@ -76,6 +76,8 @@ loek: 2024-10-17 40m project meeting loek: 2024-10-17 10m review :: PR review (#5 and #6) loek: 2024-10-18 1h40m docs :: design :: scripting interface loek: 2024-10-20 30m review :: PR review (#37) +loek: 2024-10-21 1h30m implementation :: global config interface +loek: 2024-10-21 10m review :: PR review (#7) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3