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?
Śledzenie tego bloga to jedna z lepszych decyzji w moim życiu xD Dobre tipy, zastosuje się do nich w swoim projekcie.
Bardzo dziękuję za pozytywny komentarz. Cieszę się, że mogłem pomóc dzieląc się swoimi doświadczeniami i zainspirować 😉