Post-mortem, czyli spowiedź gamedeva #2

Ciąg dalszy rozrachunku z ostatnio skończonym projektem

Wnioski

  • od samego początku koncentrować się na maksymalizowaniu wprowadzanej wartości do gry, przy jak najmniejszym koszcie korzystając z każdego możliwego rozwiązania – np. dorysowując jakiś mały szczególik, zamiast kodząc coś po nocach = design jest tani

  • bardziej ciąć zakres, szybciej wywalać czasochłonne pomysły
  • poświęcać maksymalnie 1 pomodoro na research, prototyp powie więcej o tym, ile zajmie wprowadzenie jakiejś nowej mechaniki – jeśli krótko i łatwo to próbujemy to zrobić, jeśli długo – wywalamy
  • wykorzystać podejście Scrum
  • planując projekt trzeba dodać ryzyko – brak obecności członków zespołu i siebie w niektóre dni z różnych powodu
  • głębsze planowanie – ustalenie sobie milestone’ów, własnych deadline’ów (sprintów) i staranie się ich dotrzymać – nie żeby deadlinem był ostatni dzień oddania projektu
  • zautomatyzować codzienne raportowanie progresu swoich prac – bycie widocznym dla członków zespołu – daily self-DSM
  • zautomatyzować proces budowania i notyfikowania członków zespołu o nowym releasie, dodając przy tym release notesy (żeby wiedzieli jakie poprawki się pojawiły, co mogą testować)
  • maksymalnie skrócić feedback loop – testowanie każdej nawet atomowej zmiany skraca drogę do znalezienia błędu
  • prototyp powinien być jak najczęściej testowany na platformie docelowej
  • zbierać content do marketingu od samego początku: nagrywać każdą nowo wprowadzoną mechanikę (przez filmik lub gif); warto też swoją drogą streamować proces pracy w celu odkrywania procesów, które można potem automatyzować, content do marketingu gry
  • śledzić swoją pracę i na bieżaco dzielić się spostrzeżeniami, tipami z innymi
  • polishowanie = animacje, particle i muzyka
  • animacje są tym, co dodaje życia grze, sprawia, że staje się dynamiczna
  • jak najwcześniej pokazać innym jak posługiwać się silnikiem do prostych zmian np. wartości zmiennych – żeby mogli sami tweakować grę
  • todosy związane z refaktoringiem zapisywać w kodzie – im bliżej kodu, tym prędzej będą zrobione i o nich nie zapomnimy – nie warto ich przenosić do Trello – za dużo niepotrzebnej przy tym roboty
  • refaktoryzować zawsze i tylko wtedy gdy pojawia się duplikacja – ale najpierw coś zduplikować, sprawić aby działało, a potem dopiero refaktoryzować – w ten sposób otrzymamy łatwy do kopiowania i zmieniania kawałek funkcjonalności
  • debugger pozwala prześledzić dokładnie właściwy flow działania, a nie taki jak nam się wydaje – dlatego stosować go zawsze wtedy gdy nie rozumiemy dokładnie jak coś działa
  • większość błędów wynika z zwykłych pomyłek, które jakoś nam nie jest łatwo od razu dostrzec, albo z braku wiedzy (że np. jeśli on_input zwraca true to event nie jest dalej propagowany)
  • najbardziej rażące błędy poprawiać przed wprowadzaniem nowych funkcjonalności. Ale małe błędy na początku olewać i zajmować się przed nimi wprowadzaniem nowych feature’ów
  • nie poddawać się – dopiero po korzystaniu z narzędzia około przez jeden miesiąc nabieramy w nim wystarczającej wprawy – tak, że praca staje się łatwiejsza i przyjemniejsza
  • nie zostawiać publikacji gry na ostatni dzień, bo na pewno coś się wywali i nie będzie działać jak powinno – zrobić to wcześniej, żeby poznać problemy i je rozwiazać na spokojnie – spina nie jest najlepszym pomocnikiem
  • na końcu jest zawsze za dużo zadań xd

A Wy jakie wnioski ostatnio wyciągnęliście z pracy nad swoimi projektami?

2 odpowiedzi do “Post-mortem, czyli spowiedź gamedeva #2”

    1. Bardzo dziękuję za pozytywny komentarz. Cieszę się, że mogłem pomóc dzieląc się swoimi doświadczeniami i zainspirować 😉

Dodaj komentarz