1

I'm currently designing a 3D game engine in C#. I'm not sure why, but I feel like it's appropriate to mention that the engine will soon support multiple rendering backends (OpenGL 4.6, Direct3D 12, etc).

I'm a point where i have 5 different projects within a solution in VS, and one more project that I use as a place to test all my code.

Currently this is how my solution looks:

Solution project hierarchy

The organisation is as follows:

  • Core: Contains interfaces, enumerations and a few classes that the other projects to reference, for example it contains interfaces that are used for the rendering backend of engine. The project references Math.
  • Launcher: Contains classes used to launch a game with the engine, it also reference the other 4 projects.
  • Math: Contains vectors, matrices and a math helper class.
  • Platform: Contains the rendering abstraction layers for OpenGL and soon Direct3D (This project reference Core amd Math because it contains interfaces for the rendering backend. It also does window and input handling.
  • Rendering: This project references Core and Platform and contains higher level classes (such as mesh, material and a transform class)

All 4 projects are compiled to DLLs.

The TestGame project references all 4 projects to use all of the engines features.

Is the architecture of the engine going to hold up when I get further into development? Or should all these projects be mashed into one project?

Improve this question
3
  • Maybe ask on gamedev.stackexchange.com ? They are more knowlegeable about game engines.
    – Euphoric
    Mar 25, 2018 at 5:17
  • 1
    looks neat, but dont restrict yourself to a set number of projects. more is better, use solution folders to organise them
    – Ewan
    Mar 25, 2018 at 9:50
  • You dont deal with other things than graphics, where would input, physics, sounds, animators or navigation be (when/if there will be)?
    – wondra
    Mar 27, 2018 at 5:33

1 Answer 1

Reset to default
2

The main benefit of separating a large solution into separate projects is independence of deployment; for example, you might want to be able to provide an updated version of the DLL that contains more spells or abilities, while keeping your rendering logic in place. This is especially true if your launcher is capable of downloading and installing updates.

Therefore

  • Code that is likely to stay the forever would be better off all in the same project. It sounds like, for example, GameEngine.Math might not change very much, since the theorems of mathematics and the laws of physics are pretty much constant.

  • Code that is likely to receive frequent updates would be better off all in the same project.

Based on that, I think you've done an OK job.

In addition, you might consider a separate DLL just to define your interfaces (if you use any), which ensures that all of your DLLs "talk the same language" without messy binding redirects and without introducing circular assembly references.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.