Czy mogę użyć funkcji pełzania na swoją korzyść? [Zamknięte]

Czy mogę użyć funkcji pełzania na swoją korzyść?

Za każdym razem, gdy prototypuję grę, funkcje są dodawane przypadkowo. Dzieje się tak albo przez przypadek, albo łatwo jest je dodać na podstawie istniejących treści.

Jeśli znam gatunek gry, czy mogę zacząć tworzyć podstawową mechanikę i dodawać funkcje, gdy staną się widoczne?

Na przykład, jeśli chcę stworzyć platformówkę 2D w ciągu 6 miesięcy, czy mogę po prostu zacząć bieganie, skakanie, strzelanie itp. I dodawać podstawową mechanikę, gdy nieumyślnie je znajdę? Czy jest to zbyt ryzykowne w przypadku inwestycji czasowej bez wcześniej ustalonego planu?

Moja logika polega na tym, że projekt będzie bardziej huczny. Wybory projektowe będą łatwiejsze do zbudowania wokół tego, co jest łatwe do wykonania (pod względem czasowym).

Podsumowując, czy jest coś złego w budowaniu gry, zanim ją zaprojektuję?

To interesujące pytanie. Głównie dlatego, że odpowiedź na to pytanie podnosi odcienie szarości w porównaniu do dylematu czarno-biały.

czy coś jest nie tak z budowaniem gry, zanim ją zaprojektuję?

Jeśli uważasz, że to pytanie jest typu tak lub nie, odpowiedź może być tylko: tak, jest. Jeśli odpowiedź może być bardziej szczegółowa, to się zmienia. Powód: nigdy nie należy zbudować grę przed jakimś projektowania. Ale na pewno możesz zapisać części projektu na później.

Oznacza to, że nie sądzę, że powinieneś postrzegać ten problem jako działanie, czy nie. Jest to raczej coś, o czym powinieneś myśleć w kategoriach stopni. Funkcja pełzania może być drugim korzeniem wszelkiego zła w odniesieniu do rozwoju gier (pierwszym, jak nas myśli Donald Knuth, jest to, że „przedwczesna optymalizacja jest źródłem wszelkiego zła” ). Z mojego doświadczenia wynika jednak, że nie myślenie o żadnej z głównych funkcji, tj. Brak przynajmniej podstawowego projektu miejsca, w którym chcesz iść z podstawową mechaniką, również nie jest dobrym pomysłem.

Pierwszym głównym powodem jest to, że pod względem zasobów (w tym czasu jako zasobu) pomocne jest pewne planowanie, aby poprowadzić cię przez korytarz - ponieważ ciągłe dochodzenie do ślepych zaułków z powodu nadmiernej próby i błędu może być tak samo marnowaniem zasoby, które muszą zawierać nieprzewidziane funkcje.

Drugim głównym powodem, jeśli chodzi o projektowanie gier, jest spójność. Dobry projekt gry ma spójność koncepcyjną lub konsekwencję, jeśli chcesz. Oznacza to, że ogólna rozgrywka, historia, implementacja, a nawet grafika powinny do siebie pasować tak płynnie, jak to możliwe. Jest bardzo mało prawdopodobne, że projekt gry osiągnie coś takiego, jeśli główne funkcje zostaną odkryte w drodze. Jeśli nie, to dlatego, że w ruchu jest dużo przypadkowości: rzeczy, na które natkniesz się, mogą mieć bardzo różny wpływ, w zależności od tego, kiedy je znalazłeś .

Nie mam na myśli powiedzenia, że ​​w ogóle nie powinieneś robić tego, co powiedziałeś. Twierdzę tylko, że musisz znaleźć równowagę.

Na przykład, jeśli chcę stworzyć platformówkę 2D w ciągu 6 miesięcy, czy mogę po prostu zacząć bieganie, skakanie, strzelanie itp. I dodawać podstawową mechanikę, gdy nieumyślnie je znajdę? Czy jest to zbyt ryzykowne w przypadku inwestycji czasowej bez wcześniej ustalonego planu?

Zacznę od wprowadzenia niewielkiej modyfikacji w zdaniu. Wykonując bieganie, skakanie, strzelanie itp., Już wdrażasz podstawową mechanikę. To, co chciałbyś dodać w swoim przykładzie, to specyficzne funkcje gry.

Nie dlatego, że wiesz, że gra będzie platformą 2D, bieganie, skakanie lub strzelanie nie mogą się różnić w zależności od projektu gry. Czy twój gracz może biegać po ścianach? Czy twój gracz może unosić się w powietrzu podczas skoku? Nawet, czy Twój gracz może strzelać podczas biegu? Czy Twój gracz strzela tylko w kierunku liniowym lub przez parabolę? Decyzje te mogą w dużym stopniu zależeć od funkcji gry.

Ale rozumiem twój punkt widzenia: te mechaniki często mają niektóre części, które różnią się bardzo niewiele. Tak więc, jeśli zrobić jakąś grę zaprojektowaniu i decyduje o podstawowych funkcji jak się nieco pewności, jak bieganie, skakanie, strzelanie, etc będzie działać, to początek. Następnie możesz wybrać te mechaniki i dalej na nich budować.

Oczywiście nadal możesz później znaleźć nową funkcję, która wymaga zmiany tych mechanizmów - bez względu na to, jak podstawowe były. Ale kluczem tutaj jest prawdopodobieństwo. Prawdopodobieństwo, że zdarzy się to zbyt często, będzie mniejsze, jeśli przynajmniej pomyślisz o konsekwencjach biegania, strzelania, skakania itp. Dla podstawowych pomysłów na grę.

Na koniec, jeśli chcesz pojechać tą trasą, proponuję następujące. Pomyśl o tym jak o procesie iteracyjnym. Robisz początkowe, ogólne myślenie projektowe. Wcielasz w grę to, co wydaje się podstawowe i bardziej „uniwersalne”, aby odniosło sukces. Następnie wykonujesz więcej myślenia projektowego, ponownie oceniasz to, co zaimplementowałeś i idziesz do dalszej implementacji.

Podczas wykonywania skomplikowanych projektów, takich jak gry, często nie możesz wykonać wszystkich potrzebnych funkcji, ponieważ brakuje Ci czasu / pieniędzy lub nie okazały się tak dobre, jak się spodziewałeś. Jest to znane jako pełzanie funkcji. Ale ma to drugą stronę; znajdziesz także funkcje, których nie uważałeś za potrzebne, ale w miarę kształtowania projektu ich potrzeba staje się widoczna.

Dlatego ludzie budują prototypy - aby mogli dowiedzieć się, co działa, a co nie, aby wyciąć funkcje, które nie działają , ale także znaleźć nowe funkcje, które byłyby niesamowite . Jeśli nie robisz żadnej z tych rzeczy, których się nie uczysz , robisz to źle.

Jest to w zasadzie sentyment wyrażony w przemówieniu Advanced Prototyping , przeprowadzonym przez Chrisa Heckera i Chaima Gingolda, który zawiera wiele przykładów z ich pracy na Spore, gdzie często byli zaskoczeni tym, co działało, a co nie, idąc nawet do przeprojektowania całości systemy oparte na sprzężeniu zwrotnym prototypu.

Innym przykładem jest proces projektowania Left 4 Dead ; początkowo w grze były tylko podstawowe zombie, ale na podstawie testów z doświadczonymi graczami projektanci odkryli, że gracze trzymali się razem skutecznie, a gra była zbyt łatwa, dlatego dodali specjalne zombie, aby rozdzielić zespół i zapewnić ekscytującą grę.

Oczywiście nie oznacza to, że powinieneś budować swoją grę bez żadnego wcześniejszego projektu . Zanim przejdziesz dalej, upewnij się, że rdzeń gry jest zabawny, ponieważ często jest to najtrudniejsza część tworzenia gry.

Powiedziałbym „tak”. Ale wcześniej zaplanuj niektóre wspólne cechy / klasy, aby uzyskać spójność między każdym nowym komponentem.

Unity jest znane ze swojego komponentowego podejścia do tworzenia gier i umożliwiłoby tę formę rozwoju z łatwością. Jeśli nie korzystasz z Unity, możesz powielić podejście półskładnikowe. Nie znam innych silników gier.

Wszystkie obiekty gry Unity mają element transformacji. Określa pozycję, obrót i skalę obiektu. Stwórz więc ogólną klasę „transformuj”, aby przechowywać te wartości, a także odniesienie do rzeczywistego obiektu gry.

Weźmy na przykład komponent „Jump”. Niech cała logika działa z klasą transformacji obiektu gry w celu manipulowania pozycją. (Lub twój silnik będzie już miał podobną wbudowaną klasę.) Możesz dołączyć tę klasę „Jump” do dowolnego obiektu, a klasa będzie animować pozycję przekształcenia po uruchomieniu akcji (Jump.PerformJump () lub cokolwiek innego). Klasa Jump nie musi nic wiedzieć o swoim właścicielu (lub przynajmniej minimalnych informacjach).

Teraz możesz się dobrze bawić, tworząc mnóstwo komponentów, a następnie dołączając je do obiektów gry, łącząc je w jednym obiekcie itp. Na przykład: Uruchom, Skacz, Kucnij, MovingTile, FireWeapon (określ sprite „pocisk” i zachowanie, które należy wykonać składnik ogólny) itp.

Ustaw każdy komponent tak ogólny, jak to możliwe, aby umożliwić wiele zastosowań / odmian. W przypadku FireWeapon możesz określić duszka pocisku, prędkość, obrażenia itp. Możesz spróbować znormalizować te atrybuty, tak aby prędkość i obrażenia były określone od 0 do 1. Następnie skaluj je do maksymalnych wartości w grze. W ten sposób martwisz się tylko względnymi różnicami między broniami. Ponadto dostosowuje się do globalnych ustawień, takich jak trudność, na której wyższy poziom trudności ma większe maksymalne obrażenia itp.

Zanim się zorientujesz, masz do dyspozycji arsenał komponentów i możesz teraz szybko opracowywać dla każdego rodzaju gry.

Krótko: przez większość czasu nie można wykonać pojedynczego kroku projektowego, ani pojedynczego kroku kodowania. Będziesz musiał je naprzemiennie. Zasadniczo staraj się szanować to, co już zostało zaprojektowane (a nie to, co jest już zakodowane).

O braku wstępnego projektu (tylko szkic lub obraz mentalny): jeśli nie masz projektu, nie masz projektu. Musisz coś zrobić z tym. Ale dopóki zaczniesz go budować, staraj się go szanować, nie przychodź za każdym razem z nowym.

Wykonuj eksperymenty i uzyskaj losowe funkcje, które mogą być szkodliwe. Może to być nawet korzystne lub nieuniknione. Na przykład: wiesz, że chcesz wspierać skakanie (wiele RPG 3D / 2D nie pozwala na skakanie). Skąd to wiedziałeś? Ponieważ wyobrażałeś sobie mapę gry wymagającą przeskakiwania w celu usunięcia przeszkody? Tak więc implementacja skoku jest wystarczająco dobra, o ile pozwala graczowi posortować tę przeszkodę lub musi spełniać określone cechy, takie jak maksymalna osiągalna wysokość, może być wzmocniona przez przedmioty lub obiekty gry na mapie, fizyka musi obejmować przyspieszenie lub odbicie ( kiedy Mario wskakuje na wroga, zyskuje impuls do ponownego podniesienia, co jest bardzo ważne w grze)?

Jeśli potrafisz już odpowiedzieć na te pytania, to dokumenty projektowe (urojone lub prawdziwe) są bardzo kompletne. Jeśli nie możesz na nie odpowiedzieć, twój projekt jest niekompletny. W takim przypadku musisz ponownie przejść do pracy nad projektem lub przeprowadzić eksperymenty, aby wypełnić luki. Możliwości mogą być bardzo otwarte lub bardzo ograniczające. Jeśli niektóre poziomy gry będą miały przeszkody, a po prostu potrzebujesz dla nich skoków, wtedy masz dużą swobodę w określeniu maksymalnej osiągalnej wysokości lub prędkości, być może zdecydujesz się udawać, że istnieje silnik fizyki, zacznij wszystko, aby poprawić grafikę animacji skoku, ale nie potrzebujesz jej do niczego innego. (W wielu grach 2D RPG nie można skakać, kiedy chcesz, ale tak długo, jak na mapie znajduje się pojedynczy otwór na płytkę, próba wejścia w niego automatycznie powoduje skok do płytki podłogowej obok płytki otworu)

Rozumiem, że można kodować bez kompletnego projektu, o ile szanujesz to, co już postanowiono. W niektórych sytuacjach może to być nieuniknione, ponieważ wszechświaty gier mogą być budowane z różnych procesów myślenia. Na przykład gra karciana: Wiem, że chcę, aby karty miały Atak i Obrona, pewną liczbę kart na stole w danym momencie i że gracz podczas swojej tury może wybrać, którą kartą zaatakować, którą inną kartę. Może się wydawać, że jest to już kompletny projekt, ale potem przychodzi balansowanie gry, możliwe tylko dzięki wielu symulacjom. Po wielu symulacjach zdecydowałem, że karta z Attack 10 jest obezwładniona, mogę po prostu usunąć ją z gry, ale bardzo mi się podoba, więc zrobię coś innego, Stworzę nową regułę, która mówi, że jeśli gracz zaatakuje taką kartą, nie może zaatakować inną kartą podczas tej tury. Teraz mam nową zasadę, która wzbogaca mechanikę gry, ale zastosowanie jej do pojedynczej karty wygląda dziwnie (jak brudny hack), zdaję sobie sprawę, że wygląda dziwnie, a następnie postanawiam utworzyć nowy zestaw kart, które mają dużą liczbę, ale stosuje się do nich nową zasadę ograniczenia. Teraz mam bardziej złożoną mechanikę gry, zbudowaną ponad prostszą, oryginalną, moim zdaniem, wykorzystałem ją do stworzenia lepszej gry.

Jedną rzeczą dotyczącą tego ostatniego przykładu, w proponowanym przykładzie gry karcianej, nowe karty mogą skutkować nowymi zasobami (wzrost kosztów, wzrost czasu). Myślę jednak, że jest to dobry przykład tego, że możliwości, które widzisz tylko podczas kodowania, mają dobry wpływ na twoje decyzje projektowe.

Nie sądzę, że większość gier, w które gramy, została w pełni zaprojektowana przed kodowaniem, jestem pewien, że musieli podejmować trudne decyzje, aby przestrzegać terminów i tak dalej.

Kiedy ktoś za to wszystko płaci: wyjaśnij, negocjuj.