Game Dev - dobre praktyki

Ciekaw jestem opinii doświadczonych Kolegów i Koleżanek w temacie dobrych praktyk Game Dev ogólnie oraz Indie.

Z przerwami ale ciągle rozwijam swój projekt strategii turowej. W miarę rozwoju i dokładania nowych elementów zaczynam się gubić w swoim projekcie. Z tego właśnie powodu zdecydowałem się popracować trochę nad dokumentacją projektu i poczytać o dobrych praktykach.

Na tę chwilę co chcę zaimplementować to:

• Listę TODO zamienić na Game Design Document - czyli opisać wszystkie dotychczas zaimplemenbtowane mechaniki i opis tego co jeszcze chcę dołożyć
• Opisać osobno: Architekturę, Mechaniki, Modelowanie
• Jeszcze nie wiem jak sobie opisać przypadki testowe
• Dokumentacja przepływu stanów

AI to będzie pewnie oddzielna przygoda dla mnie, boję się nawet myśleć jak to ugryźć XD Ale gdybyście mieli sugestie o czym myśleć na posiomie architektury pod kątem AI żeby później uniknąć wielkiej przebudowy, to piszcie

Czy myślicie że Architecture Decision Records ma sens w małym projekcie indie?

Czy byście dorzucili jakieś nieoczywiste rzeczy? Lub dla Was oczywiste ale niekoniecznie dla juniora / stażysty?

bakunet napisał(a):

Na tę chwilę co chcę zaimplementować to:

• Listę TODO zamienić na Game Design Document - czyli opisać wszystkie dotychczas zaimplemenbtowane mechaniki i opis tego co jeszcze chcę dołożyć

Do takich swoich mniejszych projektów, typowy GDD to niekoniecznie jedyny słuszny kierunek.
Niedawno trafiłem na taki filmik:

Może u Ciebie też podpasuje taki jednostronicowy dokument ;)

bakunet napisał(a):

• Opisać osobno: Architekturę, Mechaniki, Modelowanie

Ja takie ważniejsze, nietypowe rzeczy opisuję w wiki swojego projektu.

bakunet napisał(a):

AI to będzie pewnie oddzielna przygoda dla mnie, boję się nawet myśleć jak to ugryźć XD Ale gdybyście mieli sugestie o czym myśleć na posiomie architektury pod kątem AI żeby później uniknąć wielkiej przebudowy, to piszcie

AI powinno mieć dostęp do tych samych akcji co gracz.
Gracz akcje ma podpięte do swojego interfejsu/input.
AI ma te same akcje podpięte do swojego skryptu.

@Spine

Dobre video dla usystematyzowania i zdefiniowania bloków GDD. Zgadzam się w 100%, spróbuję utrzymać GDD proste jak się da. Choć 1 strona raczej odpada, gdzie będę miał kilka dość złożonych systemów (tury, eventy, pogoda, ruch, bitwy, dźwięki, lokalizacja, języki, generowanie mapy, karty, więcej grzechów nie pamiętam).

Co do akcji, gdzieś czytałem by wszystkie akcje definiować jako komendy i traktować system komend jako interfejs dla gracza / AI. Chyba tak właśnie zrobię.

Jak ostatnio robiłem prototyp gierki w godocie to design projektu mialem mniej więcej taki jak w Reacie na frontendzie. Componenty np. player, enemy, health bar. Sceny - poziomy jak podstrony w web developmencie. Wszystko okraszone ObjectOrientedProgrammingiem i komunikacją na eventach po sygnałach/eventbusach. Jedyne co wyszło poza "enterprajsowy" stack to implementacja state machine'ów.
W sumie to używałem standardowych wzorców projektowych i gra tworzyła się sama (https://gameprogrammingpatterns.com/contents.html)

Tutaj rezultat: https://matadini.itch.io/tech-demo-2026

ADR w małym indie ma sens przy decyzjach, których powodu nie widać w kodzie po kilku miesiącach. «Gracz i AI wołają te same komendy» to taki wpis: dwie linijki i data. Osobny szablon na pogodę, tury i dźwięk powtórzy GDD, a ten i tak lepiej zostawić krótki, jak pisał Spine. Powód wyboru komend warto zapisać. Listy mechanik nie.