Developer Guidelines and Tips

Developers should follow these guidelines for contributing to the project.

Coding conventions

Naming conventions


The whole codebase is under the Antura namespace. The main systems can be accessed through the Antura namespace and thus fall under it.

All minigames are under the Antura.MiniGames namespace. Each minigame needs its own namespace in the form of Antura.MiniGames.GAME_ID with GAME_ID being the name of the minigame.

Most core code will be in a subsystem. Specific subsystem code is inside a Antura.SUBSYSTEM namespace, where SUBSYSTEM is the subsystem’s name. What follows is a list of subsystems with their namespaces:

Never commit anything without a namespace, nor anything under the root Antura namespace

Git Ignore

there are several fiels and directories put under Git Ignore.. the useful from Dev POV are:


if you create a Assets/Local directory, you can put inside whatever personal you want, and won’t be versioned.

Coding Guidelines We can use any external plugin, obviously the fewer the better All code and app architecture must be self speaking (in English) to be easily read by new/external contributors Flexibility: no hardcoded vars. Anything should be parameterized (for app variations in other languages or modular evolution) Git commit rule: One feature is One commit rule Commit a feature with all its dependencies when it’s working and tested at least once The commit message should be a simple description of what has been done (the Git log will be used to generate the app changelog so pay attention), with a prefix like: [plugin] lorem ipsum v 1.x.x [bug] fixed xxx [feature] added this in that [changed] behaviour x now does y [cgl] cleaned minigame x code
C# only + Unix line endings Use EA4S namespace for the app, and EA4S.minigame for specific minigames classes. No compilation errors (red) allowed in the dev branch. Always buildable. No compilation warnings (yellow) allowed in master branch (if possible) All the code must be released under the MIT License Everyone should commit just to dev branch (eventually their own) when a feature / debug is done and tested. Do no push to origin without some local testing. Team leads will merge into master to trigger testing builds.