search

PanosK92 / SpartanEngine

A game engine with an emphasis on real-time cutting-edge solutions
https://panoskarabelas.com
MIT License
2.24k stars 189 forks source link

Eliminating the need for namespace internal linkage in World class. #117

Closed ApostolosBouz closed 12 months ago

ApostolosBouz commented 1 year ago

This is a stepping stone edit.

To my understanding, in order to develop features like stored and reusable Entities, Undo/Redo, and easier World editing from UI, we first need to make World class able to be inherited in a meaningful way.

If this PR passes, next step is to derive separate Worlds for Car, Cube, Forest, etc. from a single World class.

PanosK92 commented 1 year ago

Thanks for the PR.

What's the benefit of moving things from the anonymous namespace into the class itself?

ApostolosBouz commented 1 year ago

Thanks for the reply. I have some reasons in mind, based on Spartan's roadmap, and overall design clarity:

  1. Bringing functions and variables into the scope of the class, so that they are part of the class implementation, so that the World can be subclassed effectively.
  2. Better design clarity and intend.
  3. Better emphasis of class role.
  4. Potential performance improvement by inlining the previous anonymous namespace members.
  5. Better team collaboration by editing specialized Worlds instead of one big class.

To sum up, and having mentioned that this is a "stepping stone" edit:

  1. As far as functionality in concerned, nothing has changed yet (maybe a barely noticeable performance on world initialization).
  2. My intend is to move forward specializing World class, to separate derived Worlds based on their content to make adding and editing content easier.
ApostolosBouz commented 1 year ago

To elaborate further on "Better team collaboration by editing specialized Worlds instead of one big class." While trying out new types of systems, Entities or Components, several developers could work on separate Worlds. Some might need the ability to create a cube, a cube with Physics, or no cube at all. Others might work on purely rendering features. So I thought editing a single World file to have all those things available might not be the way to go, especially if we are aiming towards saving those worlds on a proper format to reopen later, though UI actions.

ApostolosBouz commented 12 months ago

Closing - no actual meassurable value.