Jak w prototypowaniu mogę łatwiej badać zachowanie gry?

Sama buduję gry niezależne, ale zwykle brakuje mi energii, gdy wznoszę nowo opracowaną grę na poziom, na którym można grać z zachowaniem, więc zamiast eksploracji decyduję się na udoskonalenie. Z okropnymi wynikami.

^{(zdjęcie z blogu interkomu )}

Na przykład uważam, że cykle iteracji dla zachowań dostosowujących (tj. Łączenia i restartowania aplikacji C ++) są tak długie, że zabijają całą kreatywność. Buduję narzędzie, aby sobie z tym poradzić.

Jakie są inne sposoby szybkiego zbadania zachowania gry? Interesują mnie metodologie stosowane zarówno przez niezależnych programistów, jak i większe firmy.

Jak zauważyłeś, gdy pracujesz nad mechaniką gry, szybkość iteracji ma kluczowe znaczenie. Im dłuższy czas między myśleniem o modyfikacji a możliwością testowania z tą modyfikacją, tym mniej produktywny będziesz i tym bardziej będziesz rozproszony. W rezultacie zdecydowanie chcesz zarządzać czasem iteracji.

Dla mnie stwierdzam, że moja produktywność naprawdę zaczyna spadać, gdy czas na przetestowanie prostej zmiany przekracza około pięciu sekund. Więc kiedy eksperymentujesz, aby udoskonalić sposób, w jaki gra się czuje, jednym z twoich celów musi być wymyślenie „w jaki sposób mogę dokonać zmiany, a następnie grać przy użyciu tej zmiany w mniej niż pięć sekund”. Tak naprawdę nie ma znaczenia, jak to robisz, pod warunkiem, że czas iteracji będzie mniej więcej na tym poziomie.

Wiele dużych nowoczesnych silników (Unity, Unreal itp.) Zwykle robi to, umieszczając ich edytor w silniku gry, dzięki czemu można wprowadzać większość modyfikacji na żywo, bez konieczności ponownego uruchamiania gry. Mniejsze silniki / gry zazwyczaj koncentrują się na pracy w innym kierunku; spraw, aby gra się kompilowała i uruchamiała tak szybko, że nie ma znaczenia, czy musisz ponownie uruchomić grę dla każdej zmiany; nadal będziesz w testach, zanim upłynie ten pięć sekund.

W moim obecnym projekcie zajmuje mi około dziesięć sekund, aby wykonać małą rekompilację, połączyć, uruchomić grę, a następnie przejść do rozgrywki (większość z nich generuje renderowalną geometrię świata podczas ładowania zapisanej gry). A to o wiele za długo. Dlatego stworzyłem osobne tryby gry, które pozwalają mi testować różne części gry bez ładowania wszystkich prawdziwych zasobów gry, dzięki czemu mogę wchodzić i wychodzić znacznie, znacznie szybciej; zwykle w ciągu około dwóch do trzech sekund. Jeśli chcę przetestować interfejs użytkownika, mogę to zrobić bez ładowania do prawdziwej gry. Jeśli chcę przetestować renderowanie, mam inny tryb, w którym mogę to przetestować, ponownie bez ładowania całego systemu gry.

Widziałem innych ludzi, którzy podeszli do problemu, umieszczając logikę gry w bibliotece DLL i pozwalając, aby plik wykonywalny gry znajdujący się już w pamięci ponownie załadował bibliotekę DLL podczas gry, dzięki czemu można odbudować bibliotekę DLL i ponownie załadować ją do jest już załadowany plik wykonywalny, więc nie trzeba ponownie ładować / odbudowywać zasobów graficznych gry. Wydaje mi się to szaleństwem, ale widziałem, jak to zrobiono.

Znacznie prostsze byłoby określenie zachowania gry i / lub konfiguracji w skryptach lub plikach danych oraz zapewnienie sposobu na ponowne załadowanie tych plików na żądanie, lub po prostu obserwowanie ich modyfikacji, bez konieczności zamykania grę w dół, połącz ją ponownie, a następnie uruchom ponownie.

Istnieje wiele podejść. Wybierz to, co działa najlepiej dla Ciebie. Ale jednym z kluczy do udoskonalenia mechaniki gry jest niezwykle szybka iteracja. Jeśli tego nie masz, prawie nie ma znaczenia, co jeszcze robisz.

Aby dobrze prototypować, zmniejsz koszty testowania pomysłów.

Mój przepływ pracy jest dostosowany do małych gier, ale uważam, że te rzeczy są pomocne:

• Technologia przyjazna dla prototypów  Uważam, że pomocne jest używanie dynamicznego języka programowania i frameworka, takiego jak Lua ( LÖVE jest fajny dla 2D), JavaScript lub Lisp / Scheme, gdzie nakłonienie programu do zrobienia czegoś wymaga minimalnego naciśnięcia klawiszy, nawet kosztem wszystkiego innego. Gdy wiesz, czego chcesz i chcesz go udoskonalić, zoptymalizuj lub przenieś do innego silnika.
• Kontrola wersji  Przechowuj prototypy w repozytorium kontrolowanym pod kątem wersji. Oddział wcześnie, gałąź często. Dzięki temu możesz wygodnie próbować rzeczy bez obawy, że coś zgubisz lub zapomnisz. ( Git ma najtańszy model rozgałęziania.)
• Zbuduj automatyzację  Upewnij się, że musisz zrobić tak mało, jak to możliwe, aby faktycznie uruchomić program. Moim zdaniem, nawet konieczności naciskania przycisku jest zbyt wiele, zazwyczaj mają Makefileo make watchcel, który działa inotifywaitw pętli, w reakcji na zmiany pliku automatycznie kompilacji / uruchamiania gry. W języku interpretowanym lub skompilowanym w JIT jest to natychmiastowe.

Jako programista skupiający się głównie na prototypowaniu, oto kilka porad z mojego doświadczenia.

1. Użyj silnika, który pozwala SZYBKO wprowadzać zmiany. Obejmuje to między innymi „Nie czekanie na kompilację”, ale także „zmianę rzeczy w czasie wykonywania”, „łatwość debugowania”, „dostępność zasobów testowych” itp. Osobiście uwielbiam Unity3D, ale nie jest to najlepsze narzędzie. Najlepsze narzędzie zależy od gry: na przykład Unreal Engine kompiluje kod znacznie wolniej niż Unity3D, ale może szybko uruchomić wielu połączonych klientów. W przypadku gry sieciowej często kompensuje to koszty kompilacji. Weź również pod uwagę znajomość. Jeśli jesteś fanem C ++, nawet najlepszy silnik JavaScript nie przyniesie wiele dobrego i na odwrót. Nie marnuj czasu na walkę z nieznaną technologią (to znaczy ucz się innych języków / frameworków, ale nie w tym samym czasie, gdy tworzysz ważne prototypy).
2. Dowiedz się, jak bezlitośnie usuwać istniejące funkcje. Trzymanie się rzeczy, które już zaimplementowałeś, jest przekleństwem udanego prototypowania, ale puszczenie pracy jest ciężkie.
3. Jeśli nie współpracujesz z projektantem gier, postaw wyraźną granicę między „noszeniem czapki programisty” a „noszeniem czapki projektanta”. Dodanie nowej fajnej funkcji gry wydaje się bardzo kuszące, ale nie rób tego, gdy jesteś na pozycji projektanta. Staraj się raczej tworzyć zabawną rozgrywkę (najlepiej wiele wariantów) z tym, co masz; sporządzić listę funkcji, które mogłyby pomóc, a następnie wdrożyć (niektóre) je.
4. Szybkie prototypowanie polega na równoważeniu dwóch przeciwieństw. Chcesz tworzyć rzeczy tak szybko, jak to możliwe, więc piszesz zły kod. Ale chcesz jak najwięcej zmieniać rzeczy, więc musisz napisać dobry kod! Naucz się równoważyć te dwa. Niestety nie mogę wymyślić żadnej konkretnej porady, jak to zrobić, ale przynajmniej zdaj sobie sprawę z tego problemu (-8

Sprawdź, ile czasu wymaga prototypowanie. Z mojego doświadczenia wynika, że ​​chcesz mieć grywalną wersję czegokolwiek w ciągu maksymalnie dwóch dni - od zera; i chcesz codziennie testować jedną lub dwie nowe funkcje. Jeśli nie osiągasz tych celów, poszukaj sposobów, aby być szybszym.

Rozwój gry można podzielić na cztery następujące fazy:

• prototypowanie
• dopracowanie rozgrywki
• rozwój
• udoskonalenie wydajności

Wydaje mi się, że eksploracja rozgrywki odbywa się głównie na etapie prototypowania. Oto kilka porad, które staram się stosować:

• Rozpocznij projektowanie od papierowego prototypu. Po zrozumieniu, czym może być ta gra, zacznij ją kodować, aby naprawdę poczuć interakcje. Być może jest to bezużyteczne w przypadku gier 3D, ale osobiście bardzo mi pomogło w przeszłości.

• Kod wiedząc, że po zakończeniu wyrzucisz swój kod. Pozwoli ci to być liberalnym, jeśli chodzi o wybór silnika gry.

• Ważne są szybkie cykle iteracji (jak zauważyli wcześniej inni). Wybierz silnik gry na podstawie jego zdolności do szybkiego pokazania, co napisałeś. Na tym etapie nie musisz również przejmować się wydajnością ani wiernością graficzną.

• Ogranicz swój zakres. Jeśli rzeczywista rozgrywka to 2D (zwykła gra strategiczna, JRPG), prototyp w 2D. W tej fazie zależy tylko na opiniach na temat rozgrywki .

• Nie trać czasu na polerowanie lub wyszukiwanie zasobów. Wypisz coś na papierze, zrób zdjęcie, wytnij w Photoshopie, może pokoloruj i użyj jako duszka. Włącz mikrofon i powiedz „pew pew”. Połącz dwie kostki i kulę, a otrzymasz robota. Zawsze miej na uwadze, odkrywanie możliwości gry jest Twoim pierwszym i jedynym priorytetem.

Po podjęciu decyzji o zabawnym prototypie zacznij go udoskonalać. Nie sądzę, aby istniał powód do zmiany technologii, chyba że istnieje element rozgrywki, który tego potrzebuje.

Później w fazie rozwoju będziesz mieć pod ręką wyrafinowany prototyp, opracowując nową, znacznie lepiej wyglądającą, o wiele lepiej brzmiącą, o wiele lepiej czującą grę. Tutaj musisz wybrać rzeczywisty silnik gry, którego chcesz użyć.

Na koniec weź to, co masz i dostrój, aby zużywać mniej zasobów.

Większość tego, co opisuję powyżej, to powszechna wiedza, ale umieszczenie jej na liście, dzieląc cały proces rozwoju, pomaga mi spojrzeć na każdy krok z innej perspektywy. Mam nadzieję, że ci to pomoże.

Zgadzam się z odpowiedzią Trevora Powella, że szybkość iteracji ma kluczowe znaczenie dla pozostania w twórczym nastroju, a nie tylko polerowania. Dużym źródłem inspiracji jest dla mnie przemówienie Bret Victor „Inventing on Principle” . Niestety na tym poziomie trudno znaleźć prawdziwe narzędzia. Sam próbowałem zbudować taki do programowania w języku Python, który pozwala mi uruchamiać kod Python podczas pisania. Nazywa się to Live Coding w Pythonie .

Zbudowałem narzędzie do prototypowania o nazwie Trabant, które:

• jest TYLKO 3D i mechaniką gry (bez interfejsu użytkownika, bez tekstu, bez niczego);
• wymaga bardzo małego kodu i żadnych zasobów do zbudowania prototypu;
• Modele 3D są tworzone w kodzie przy użyciu grafiki ASCII ;
• umożliwia iteracje podsekundowe;
• ma wsparcie symulacji sztywnego ciała;
• działa na systemach Windows, Mac, Linux i iOS;
• używa dobrze znanego języka ogólnego przeznaczenia, Python;
• ma IDE dla Windows i iOS.

Zbudowałem w nim 30 prototypów testowych, aby zweryfikować powyższe.

Jak podkreślał Trevor Powell, iteracje muszą wynosić <5 sekund, a iteracje <1s uważam za prawie pięć razy lepsze.:)

Anko wspomniała, że używanie dynamicznego języka jest dobrym pomysłem, wybrałem Python, ponieważ jest jednym z najczęściej używanych . Jeśli chodzi o automatyzację kompilacji, testowanie w Trabant jest tak szybkie, jak naciśnięcie klawisza F5 w IDE (lub F6, aby przetestować go na iPadzie), a ponieważ nie jest wymagany żaden etap kompilacji, nie robi się to natychmiast.

Kod wyrzucenie był jednym z Nevermind na wynos . Całkowicie się zgadzam i Trabant to egzekwuje.

Oprócz naprawdę ważnej prędkości iteracji Trevora Powella, oto kilka innych przydatnych uwag:

To jak dobry kod ...

Jest tam wiele IF.

Im bardziej solidna koncepcja, tym mniej trzeba się bawić. Jeśli wiesz, czym jest twoje mięso, prototypowanie staje się - co umieścić i jak ustawić rzeczy w stosunku do centralnego filaru (twoje najważniejsze).

Jeśli zaczynasz jak wiele innych - nie do końca pewny, co chcesz zrobić, idziesz w jednym kierunku i eksplorujesz wiele na drodze pokazanego obrazu.

Tak czy inaczej zaangażowanie w technologię nie ma znaczenia, jeśli to, czego szukasz, może być symulowane bez dużej głębi - prototypuj to, co chcesz / możesz.

Nie marnuj ani sekundy dodatkowej ilości zasobów. Pobierz wszystko z Internetu. Własne czy nie. Chcesz poczuć swoją koncepcję w pracy - chyba że grafika jest Twoją główną cechą, nikt nie pozwie Cię za eksperymentowanie z dźwiękami, teksturami i innymi rzeczami innych ludzi, nie umieścisz go jeszcze na półce w sklepie. Chyba że masz już fundusze - przekonanie ludzi, że koncepcja jest warta, to rzecz, która przyniesie ci pieniądze na zdobycie potrzebnych zasobów. Widziałem, jak ludzie studia gier prezentują koncepcje gier ze zmodyfikowanymi wersjami zastrzeżonych gier, do których nie mają żadnych praw.

To tak, jakbyś budował model w skali. Chociaż niesamowite jest mieć miniaturową replikę życia tego, czego chcesz. Czasami wystarcza, aby wyciąć go z czasopism, wykonać ręcznie i skleić elementy razem. Wszyscy z odrobiną wyobraźni nie będą zakładać, że zbudujesz wieżowiec z tego samego kartonu, z którym pokazałeś model w skali. A w branżach kreatywnych - lepiej jest pracować z ludźmi z wyobraźnią. Jeśli nie będą w stanie spojrzeć w przeszłość na pewne problemy, aby dostrzec potencjał całej koncepcji, rzadko, jeśli w ogóle, docenią produkt. Brak uznania oznacza, że ​​są mniej skłonni do popełniania zobowiązań i jest to spirala spadkowa. To różnica między ustaleniem postawy twojego dziecka, by podbić świat, a powiedzeniem „Nie możesz nawet odpowiednio zawiązać butów, mały głupku,

Cokolwiek robisz, zawsze pamiętaj, że sama postawa jest więcej niż wystarczająca do zrujnowania czegokolwiek absolutnie niezależnie od jego potencjału technologicznego lub gospodarczego.

Kiedyś prototypowałem grę, używając wyłącznie obrazów gif i dając im coś wspólnego z javascript. Nie jest olśniewający, ale służył pokazaniu tego, co chciałem pokazać. Nie ma znaczenia, czy później opracujesz go wyłącznie na konsolę Xbox.

Jeśli Twój pomysł jest bardziej złożony niż prosty prototyp, będziesz musiał zbadać technologię, z której będziesz korzystać - ponieważ prototyp będzie rusztowaniem dla ostatecznej rzeczy (po prostu dlatego, że dużo zainwestowano w i nie można go lekko wyrzucić) - jeśli oczywiście zostanie zatwierdzony.