Czy zastanawiałeś się może, czy metodyki lekkie takie jak Scrum mają sens w tworzeniu gier? Być może nie wiesz czym w ogóle jest Scrum i metodyki lekkie? Jeżeli chcesz pracować w większej, niż jednoosobowa ekipa i chcesz to robić sprytnie i efektywnie, musisz zapoznać się z tymi pojęciami.
Na spotkaniach z Ganymede rozmawialiśmy już o kilku sprawach. Ekipa z Krakowa, odpowiadała między innymi o tym, jak zostać testerem gier, oraz jak zostać programistą gier, a nawet jak zostać projektantem gier. Dziś, poruszyli temat nieco bardziej skomplikowany, z dziedziny inżynierii oprogramowania.
Metodyki lekkie
Zanim opowiem o samym spotkaniu, muszę was wtajemniczyć w to, czy jest Scrum i co to są metodyki zwinne (Agile). Oczywiście nie będzie trudnych definicji.
Kiedyś tam, kilku panów zasiadło sobie i stwierdziło, że metody prowadzenia projektu powszechnie stosowane, są mało sprytne. Dlatego, stworzyli manifest Agile. Definiuje on, jak powinno się tworzyć oprogramowanie. Przy czym! Metody te, stosowane są przy pracy w grupie. Wprowadzanie Scruma czy czegokolwiek innego gdy pracujesz w pojedynkę, albo z jednym znajomym, może być bez sensu. Jak wygląda manifest:
- Ludzi i interakcje ponad procesy i narzędzia.
- Działające oprogramowanie ponad obszerną dokumentację.
- Współpracę z klientem ponad formalne ustalenia.
- Reagowanie na zmiany ponad podążanie za planem.
Co to oznacza? Że proces tworzenia oprogramowania (w tym gier) nie powinien być sztywny. Jak to wyglądało kiedyś? Piszemy dokumentację -> Nie patrząc na nic, klepiemy kod -> Testujemy -> Pokazujemy klientowi.
Więc co mówi nam tak naprawdę Agile? Że nie powinniśmy trzymać się dokumentacji jak ksiądz pisma świętego, a ważniejsza jest stała interakcja z klientem. Tutaj dochodzimy do Scruma. Agile jako takie, to pojęcie. Scrum, to próba wprowadzenia go w życie. Analogia: Jak mamy programowanie, to np. C# jest językiem programowania, ale nie jest jedynym słusznym rozwiązaniem.
Scrum
To teraz w skrócie, na czym polega Scrum? Zbieramy sobie ekipę, Która działa w sprintach. Ogólnie jest pewna rzecz do zrobienia – nazywa się to backlog, czyli w sumie lista wszystkich funkcjonalności, które trzeba zrobić. W każdym sprincie, ekipa wybiera sobie, co w danym sprincie zrobi. Sprint trwa o 1 do 4 tyg. Przy czym, produkt wychodzący po sprincie, musi działać. Musi być przetestowany. Przykładowo, dodajesz do gry skakanie, to po pełnym sprincie, skakanie ma być, ma działać, a do tego nie psuć reszty modułów, które były napisane wcześniej.
Cała prezentacja
Do tego w trakcie są spotkania, które na bieżąco sprawdzają na czym ekipa stoi, co zrobili, co mają zrobić, jakie mają problemy. Po za samą ekipą, mamy też Scrum Mastera i Product ownera. Ostatni symuluje ostatecznego klienta. Czyli wymyśla co ma być w grze, jak to ma działać i jak wyglądać. Scrum Master dba o to, by spotkania się odbywały, by były dobrze przeprowadzone etc.
Czy GameDev jest Agile?
Na to pytanie, starał się odpowiedzieć Artur Staszczyk. Najśmieszniejsze jest to, że odpowiedź na to pytanie, zawiera się w prostym tak. Jest tyle aspektów tworzenia gier, że praca w np. Scrumie, jest dużo bardziej efektywna. Z jakimi problemami, producenci często się spotykają?
Po pierwsze, proces produkcji gry trwa jakiś tam czas. W tym okresie, mogą się pojawić np. nowe rozwiązania, w nowych grach, które znacznie przewyższają to co my wymyśliliśmy. Dlatego, dzięki pracy w krótkich cyklach, możemy na te zmiany zareagować i wprowadzić poprawki w grze.
W grach, często pojawiają się niespodziewane ograniczenia. Na prezentacji padł ciekawy przykład, gdzie pewny zespół tworzył grę o Jamesie Bondzie. Wymyślili super fajny system skradania się i zabijania przeciwnika od tyłu. Gdy pokazali tą funkcję wydawcy, okazało się, że muszą to wyrzucić. Dlaczego? Bo: “James Bond nie zabija od tyłu”. W czasie pracy w cyklach, taki błąd wypadłby zanim ekipa straciłaby czas na jego napisanie.
Po trzecie, nasza gra ma być fajna. Wymyślamy sobie jakieś nowe funkcję w grze, to na przestrzeni sprintu, zostanie sprawdzone, czy ta mechnika gry jest zwyczajnie fajna. Gdybyśmy zrobili to ze wszystkimi mechanikami, na samym końcu, okazałoby się, że nasza gra jest nudna i nieciekawa, a my, nie możemy nic z tym zrobić.
Cała prezentacja
Ostatecznie, warto poświęcić trochę czasu, na wprowadzenie do firmy Scruma, lub innej metodyki zwinnej tworzenia oprogramowania, bo dzięki temu stajemy się bardziej elastyczni, szybciej reagujemy na błędy i nowe wyzwania, a nasza praca jest ciągle testowana.
Na koniec, ważna informacja: Artyści, nie są Scrumowalni! Aby wziąć na siebie napisanie kilku funkcjonalności, musisz przewidzieć, ile zajmie pisanie każdej z nich. Jako programista, możesz to jakoś pi razy drzwi określić. Jednak artysta, nie jest.
– Na kiedy będzie ten model?
– No jak będzie ładny.
– To znaczy, że?
– No jak będzie mi się podobał.
Nie da się. Trzeba się z tym pogodzić. Ocena pracy artysty jest zbyt subiektywna. Nie da się jednoznacznie określić czy to co widzimy jest ładne i czy każdy zareaguje na to takim samym entuzjazmem.