General Architecture Discussion

[royfalk]

The game currently does not separate concerns properly. This creates several problems:

1. Code is hard to refactor.
2. Code is hard to test and debug. Bugs go unfounded and unfixed.
3. Code is hard to read and refactor.

I suggest we start separating the game engine into the following libraries:

Infra -basic stuff shared by modules. File utilities. Config. Vectors.
3d - everything to do with with 3d. Most notably collider.
3d-gfx - 3d drawing code. Opengl, meshes, etc.
Gfx - game gui in bases, menu, etc.
Game (bad name. Find another) - everything else. Load, save, missions, campaigns, npcs, stores. Also potentially split further.
main_game - ties everything together.

[stephengtuggy]

Infra sounds good. Probably also add string utilities and vega_cast_utils.

To me, the collider falls more under the Physics category. Maybe rename 3d to Physics?

I think Game should be split up further. One component for dealing with savegame files (loading them, saving them, etc.). One component for NPCs / "AI". One for news / large-scale event simulation (i.e. so-and-so's fleet got wiped out in such-and-such system). Additional components for campaigns and for stores.

main_game to tie everything together probably makes sense.

[BenjamenMeyer]

I'd also like to suggest we add an include directory for the cross-module headers and interfaces. Internally, the modules can still have their headers in-line for details; but we should have the formal interfaces external to the modules so we can swap modules out in the future.

[BenjamenMeyer]

suggested source layout:

include/
libraries/
src/

The include contains the headers per #727 (comment)
The libraries are the suggested split out of the libraries, each has its own folder with its source and a CMakefile to build it as a static library.
src is the main engine source that ties everything together, provides the command-line interface, etc.

[stephengtuggy]

That sounds pretty good. How would these directories relate to other Vega Strike programs, such as vegasettings?

[royfalk]

We really shouldn't need a separate vegasettings. The original devs only did that because they needed to set the resolution. We can probably get away with an intro window of 1920x1080 or some such and add a settings menu like every other game.

As for other suggestions, I'm fine with it, but it will take some time to align the game. There will be multiple passes before we're ready for this.

[BenjamenMeyer]

@stephengtuggy the programs can have their own main source directory and then they just link in the libraries they need.
That said, it'd be neat to rebuild vegasettings as a screen within the game so it's a more in-game experience. For things like resolution changes we'd have to set a timeout like Desktop Environments do for testing the changes so that the user can confirm after it's applied that everything is working or automatically revert - but that'd be another issue/discussion/design.

For the moment, I'd just simplify the builds as described above. So to answer the question:

include/
libraries/
libraries/<static library>
src/
src-<tool>/

Where <tool> are the settings, object mapper, and other tools we build - there's about 3 or 4 different binaries that get built. We could do:

include/
libraries/
libraries/<static library>
src/
src/engine/
src/<tool>/

then src is kind of like libraries but for programs.

[BenjamenMeyer]

@royfalk adding the settings menu will certainly require the game assets (VS:UtCS, PWCU) to add some support - at minimum we'd probably want to allow them to skin it; possibly even add some more values if there's something specific to that game. I do like the idea...let's start another sub-topic (in here, or may be discussion) for that so we can flesh it out.