This issue is for tracking the progress of an alternative architecture approach. As this requires some time, dont rush to change things upfront, its of no use yet.
Within the current state of the project, there are some technical scenarios which may/will lead to problems, bugs, inflexible code, raceconditions. Some of the problems are:
The overall use of the static-modifier
Almost anything is static
There are static classes, static functions, static members and vice versa
A lot of knowledge is only implicitly available (like module handling, the current source-code doesn't reflect this behaviour)
There are a lot of methods which alter some data within static-class instances which doesnt return any value (void)
There is no API / layer for managing assets or everything else
Its currently not possible to write unit-tests in order to test overall logic, because there is always some kind of state which needs to be loaded in some 'magic' way
Like Memeory.init() - there shouldnt be a relation between the loading of the assets and some data handling of the graphicsAdapter
Things to improve (Needs some time)
[ ] Introduce an object-oriented architecture (Use abstraction and inheritence, common patterns etc.)
[ ] Get rid of implicit state manipulation of members (void-methods which alter static-instance data - instead use OOP to alter data of instances of objects)
[ ] With OOP - Get rid of duplicate code
[ ] Get rid of the overall static access
[ ] Introduce the ability of testing to the project
[ ] Introduce an asset-handling layer - We need an api which allows the reading of the used assets in the game. Currently, this is done per module in relation with the ArchiveWorker. There should be a dedicated class which just returns texts/textures/world-information, etc. without initializing or setting anything.
[ ] Enable the code to be tested with unit-tests / or document what is needed to get the core-functionalities of the engine initialized
Smaller things to improve (Could be done fairly quickly)
[ ] Match the filenames with the classnames
[ ] Document the code - there is a lot of interesting stuff happening in this project - make it accessible to the world :)!
Summary
This issue is for tracking the progress of an alternative architecture approach. As this requires some time, dont rush to change things upfront, its of no use yet.
Within the current state of the project, there are some technical scenarios which may/will lead to problems, bugs, inflexible code, raceconditions. Some of the problems are:
static-modifierThings to improve (Needs some time)
Smaller things to improve (Could be done fairly quickly)