Skip to content

Refactoring Guidelines

These notes represent guidelines for refactoring the Antura code.

Code annotations

The code is annotated to highlight pieces of code that should be refactored. The following tags may be found throughout the code:

  • (refactor): the code should be logically refactored
  • (obsolete): the code should be removed
  • (convention): the code should be refactored to match our conventions

Documentation notes

The specific systems documentation files contain more general notes on refactoring partaining to that subsystem. See the other .md files for more information.

Refactoring notes: Important

These notes are for current development.

  • Database and PlayerProfile use should be linked (no ease of access to either)
  • Managers are scattered among many different folders and use widely different conventions. They should be refactored to show a common intention.
  • Many managers are static makeshift singleton-like classes. Better access should be provided.
  • Helper / utility methods and classes use must be standardized throught the codebase.
  • Helpers should probably belong to the DB, and not to the Teacher.

Refactoring notes

  • Move the contents of _app/Elements to the correct Models/Images folders.
  • Move the contents of Resources to _app/Resources
  • Parts of _manage should be moved to _testing and be removed from the main public repository (as used only for test purposes)

Refactoring notes: New Language

These refactoring notes should be followed to prepare for supporting a new language.

  • Game and Core scripts should be correctly separated. For example, the Intro scene is using code from the _games/_common folders (IGameState for example). The contents of (_games/_common) could be placed in (_app/GamesCommonCode), so that the (_games) folder could be removed completely with no consequence.
  • A lot of the code is tied to the Arabic language. See Localization, the QuestionBuilders, and many minigames.

Refactoring notes: Wishlist

These notes are for future reference.

  • We need to standardize some nomenclature: "core" vs "minigames" / "minigame names" vs "minigame IDs" / "vote" vs "outcome" vs "grade" vs "score"

Codebase

  • The core code and the Teacher work only with QuestionProviders, so it would be better to just assume that all games will use them (and no other provider)
  • The word 'Data' is used interchangeably for 'LivingLetterData' and the database 'Data' (see LL_WordData versus Db.WordData). This creates confusion especially when handling learning data. This can be solved by making sure that LivingLetters data is converted into Views, and that the database's learning data is instead defined as LearningData (example: WordLearningData). Note also that the core should use DAta, not LL_Data. The view choice should be made by the MiniGame.

MiniGame Data

  • MiniGame variations are not actually enforced by the codebase, but it would be a good idea to make all games use them, as currently the core app reasons in terms of 'MiniGameCode', but a MiniGame is actually identified by the 'game scene' and the 'variation'
  • We could make the MiniGame register to the Core, and make sure that the MiniGameData is generated by the core