1
\$\begingroup\$

Currently I have an architecture (not 100% accurate): enter image description here The RenderData contains primitives, which will be processed by the GraphicsEngine.

  • Upon creation I have to send the pointer of the renderData from the Renderer to the GraphicsEngine.

  • This is done by passing it to the GameObject, which passes it to the Scene, which passes it the Core, which will call the corresponding method at GraphicsEngine.

The problem with this is that the Scene has access to the Core. How can I register these RenderData's at the GraphicsEngine correctly?

And this is the same with Behaviour components signaling the AudioEngine to play a sound.

And this is also the same with the Rigidbody component's RigidbodyData and the PhysicsEngine.

  • But there is another problem: How do I signal the objects which have collided from the PhysicsEngine?

    • I have thought of registering the object ID at the RigidbodyData's of teh collided objects, which Renderer will sense this, and will handle the custom behaviours. (like what happens when a bullet is collided with a player)

    • And if this is good then how do I signal the custom scripts that there is a collosion with another game object? Upon creation of Behaviour's I add their OnCollide method to an array at Rigidbody? Or just instead of storing the Behaviours in the general Component container, have a separated container for them and just iterate through them and call OnCollosion?

Another problem: The Window handles the input, and have to signal these Behaviour components in the Scene.

  • So it has access the Scene, and on receiving input, it calls the Scene corresponding method which will spread the event somehow?
\$\endgroup\$
1
\$\begingroup\$

Your RenderSystem could hold a reference to the GraphicsEngine. The active components could then be registered with the render system which would then simply use the primitives upon rendering.

To init a render system your core could initialise one when you open a window:

  • The window provides a new viewport to Core
  • Core then creates a new RenderSystem
  • The RenderSystem is setup
  • The render system awaits for new RenderComponent to process
  • On each GameObject creation Core receives the object and dispatches all the components to the right systems (Intent, Camera, Render, AI, Script...)
  • all the RenderComponent objects are registered in the RenderSystem
  • On each render your RenderSystem does its thing with the Render components that are registered and active.

Note that nothing should stop the Render Component from accessing the dependencies like TransformComponent to properly do its job.

The fact that your GameObject actively passes render data looks like you have created an overcomplicated architecture.

Try to avoid having specialized functions (based on component specialization) in your GameObject. The game Object should be able to only manage Component objects without ever knowing what they contain.

If you have more than one render system you will have to add a way to filter the components that get registered in the different systems.


Concerning the input, same thing. The InputSystem is created by your Core when the window registers itself:

  • Window tells core it will provide input.
  • Core creates or uses the existing InputSystem
  • InputSystem will then listen to the inputs.
  • InputSystem awaits for new InputComponent objects notify them about the inputs that have changed.

I don't know what you mean by behavior but if you mean they are custom scripts then these scripts can retrieve the InputComponent your game object holds and they can then read the inputs.

This way when a scene starts it will pass all its GameObject to Core. Core will simply register each component of each game object with the corresponding System.

Upon scene deletion the scene will pass all GameObject to Core and all Core has to do is to unregister all the Component objects from the systems.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.