Lucrez la un joc in Godot ptr. un client. In viitorul apropiat va trebui sa export versiuni putin diferite ale jocului (pe parte de views dar posibil si pe partea de logica).
O mare parte din codebase va fi comuna tuturor acestor exporturi (partea de comunicatie cu serverul, etc).
La ce m-am gandit pana acum:
One codebase using custom export presets for each build
asta pare cea mai complexa optiune, va trebui sa fac juggling cu fisierele unice ptr. fiecare build (posibilitatea de a le incurca intre ele, mai ales assets grafice care sunt de obicei intr-un loc comun)
Multiple branches branched from an original dev/prod branch.
Lucrez in branch-ul de baza sa modific elemente cheie (eg: conexiune server). Apoi in celelalte branch-uri fac merge cu branch-ul de baza.
pare mai manageable dar poate imi scapa drawbacks de care inca nu stiu
Folosind Git submodules
nu am lucrat cu ele dar am auzit de la devs (tot in gamedev) ca sunt greu de lucrat si au probleme
Dacă doar build-ul diferă, ori folosești feature flags ori folosești un sistem de plugin-uri.
Pentru feature flags ai un fișier, să zicem .env și variații pentru fiecare build. E.g. .env-full, .env-lite etc. În aceste fișiere .env definești constante iar la build time compari acele constante: if ENABLE_FEATURE_X: import module y
Feature flags, un singur repo și tag la fiecare release in git.
Dacă faci mai multe branchuri automat o să ai o problemă cu versiunile. Îți trebuie o bază din care pornești versiunea dar ajungi foarte ușor să rupi baza și distrugi versionarea. (Semver de exemplu nu mai are nici un sens)
Dacă nu ai nici o intenție de a face merge back in main deja poți face direct repo separat că branch-ul nu mai are nimic deaface cu main-ul. Asta poate implica și exportarea tututor dependintelor reutilizabile între proiecte.
Multumes @iamntz , nu stiam de feature tags, desi folosesc Godot de vreo 2-3 ani:)
O sa fac research dar tot nu sunt sigur ca e o solutie ideala. Din cate vad aceste feature tags sunt niste variabile globale if OS.has_feature("my_custom_export")#do stuff
Daca le-as folosi in cod ar face lucrurile greu de administrat. Cu 6-10 diverse exporturi, if-else-urile ar deveni monstruoase.
Poate as putea sa fac inheritance la script-urile shared si sa le folosesc pe alea in functie de feature:
#ServerConnectionMyFeature.gd
#inherited server connection
#Main.gd
if OS.has_feature("MyFeature):
server_connection = ServerConnectionMyFeature.new()
dar din nou e problema cu complexitatea. Daca server_connection e folosit in 30-40 de locuri in cod if else nu e o solutie optima.
Poate niste refactoring masiv folosind ceva gen Factory design pattern…dar o sa ia prea mult timp de implementat cred.
Eu am lucrat la un moment dat cu git submodules. Au trecut vreo 7 ani de atunci insa nu imi aduc aminte cu placere de perioada aia. Simteam ca ma lupt cu repository-ul.
Cred ca e cea mai buna optiune, ideal ar fi sa izolezi resursele comune de cele specifice si alea sa le stochezi separat.
Ca si exemplu la proiectul pe care lucrez am structurat toate aplicatiile mobile intr-un singur codebase, se genereaza aplicatii mobile iOS si Android pentru 5 entitati separate, partea mai interesanta pentru tine ar fi asta:
src/libs - chestii comune intre toate aplicatiile mobile - pagini intregi, componente, librarii, ...
src/mobile/bestauto - tenant separat, contine doar codul specific. Ideal ar fi ca bucata asta sa fie cat mai mica sau autogenerata.
src/mobile/bestauto/src/tenantConfiguration.ts - feature flags specifice per aplicatie
src/mobile/bestauto/src/theme/variables.scss - css vars/tema aplicatiei
src/mobile/keys - configuratia pt CI, keys and profiles