Projektowanie gry - od czego zacząć? [Zamknięte]

Mój przyjaciel i ja planujemy wspólną grę, nad którą będziemy pracować w wolnym czasie. To nie jest rozbudowana gra, ale też nie jest prosta.

Pracuje nad fabułą gry, a ja nad grafiką i kodem.

Naprawdę nie wiem od czego zacząć. Wiemy, jaki to będzie podstawowy rodzaj gry i jak się w nią zagra, ale trudno mi naprawdę wiedzieć, od czego zacząć.

Mam Xcode otwarty, ale tak naprawdę nie wiem nawet, co powinienem projektować jako pierwszy.

Jaka jest rada na temat tego bloku pisarza? Gdzie jest dobre miejsce na rozpoczęcie gry? Czy powinienem zaprojektować całą grafikę i układ, zanim dotknę Xcode? Czy powinienem zaprogramować rzeczy, o których wiem, że będę miał z nimi trudności, zanim przejdę do prostych rzeczy?

Zacznij od przygotowania się do gry. Nie spędzaj więcej niż godzinę na grafice, po prostu renderuj grę z symbolami zastępczymi śmieci. Gry nie mają obiektywnych wymagań, które należy spełnić: kluczowym wymogiem jest to, aby były fajne, a ocena, czy gra jest fajna, czy nie, wymaga grania; w związku z tym projektowanie gier powinno odbywać się iteracyjnie . (Polecam Tomowi Wujecowi wyzwanie z pianki jako orientację na iteracyjny projekt.

Stwórz coś na papierze, a przez to mam na myśli makietę i wycięte kawałki. Ustanawiaj zasady i graj w grę na papierowej makiecie. Użyj tego, aby podzielić swój projekt kodu na zestawy funkcji i moduły, nad którymi możesz pracować. Ten proces pomoże twojemu przyjacielowi zaprojektować historię i sposób działania gry.

Możesz mieć ochotę napisać dodatkowe funkcje do swojego kodu, unikaj tego. Prototypujesz, aby zobaczyć, co zadziała.

Po uruchomieniu małego elementu powinieneś pracować iteracyjnie, a przy każdej iteracji dostań jeszcze jedną funkcję. Kiedy coś nie gra dobrze, cofnij się i zmień funkcje. Powtarzaj i zmieniaj.

Podstawową ideą jest posiadanie długoterminowej wizji opartej na makiecie papierowej, a następnie seria krótkoterminowych celów do pracy, które doprowadzą Cię do miejsca, w którym chcesz iść kawałek na raz i bez stresu „ omg, co mam teraz zrobić? ”

Najpierw oceń swoje wymagania. Kodowanie bez planu powoduje później dużo marnotrawstwa.

Co funkcjonalnie musi zrobić gra? Jakie ramy potrzebujesz, aby to zadziałało? Jakie elementy można wypożyczyć z istniejących ram i co musisz napisać sam?

Przed otwarciem Xcode pomocne może być po prostu wycięcie papieru i najpierw przejrzenie wszystkich interfejsów gry i okien dialogowych. To da ci pojęcie o tym, co musisz stworzyć w Konstruktorze interfejsów.

Następnie, w jaki sposób rzeczy współdziałają? Jakie są wymagane różne style interakcji? To powinno dać ci pojęcie, w jaki sposób kontrolery muszą zostać podzielone, uruchomione i zatrzymane.

Nie planuj tego na śmierć, ale jasno określ swoje wymagania, a gdy tylko będziesz mógł rozbić projekt na kawałki o wielkości kęsa (30min-1hog), możesz rozpocząć kodowanie.

Patrząc na 2 dni, 2 tygodnie lub co gorsze, zadania trwające 2 miesiące wiążą się z reakcją walki lub ucieczki. Rozbij go na wystarczająco małe kawałki, abyś mógł je sekwencyjnie odgryźć bez zadławienia, a przypuszczam, że będziesz wiedział dokładnie, od którego ugryzienia zacząć, a który następny.

Jeśli gra ma pasować do istniejącego gatunku lub jest w jakiś sposób podobna do innej gry, po prostu spróbuj wykonać surową, prostą imitację tej gry lub „typowy” przykład gatunku. Jeśli nie jesteś dobrym programistą, postępuj zgodnie z samouczkiem, który przeprowadzi cię przez proces tworzenia gry podobnej do twojej.

Po pewnym czasie powinieneś naturalnie poczuć potrzebę „odejścia” od swojego modelu i rozpocząć grę we własnym kierunku. Stamtąd jest zjazdowa droga dodawania funkcji, naprawiania błędu i ogólnie poprawy w małych krokach.

Jeśli istnieje pewna koncepcja, która jest w jakiś sposób unikalna dla Twojej gry, możesz również zacząć od zbudowania najprostszej demonstracji tej koncepcji. Istnieje również opcja zbudowania gry w oparciu o tę koncepcję.

Rób rzeczy, które dają prototyp grywalny tak szybko, jak to możliwe.

Przez pierwsze 1-2 tygodnie prawdopodobnie nie możesz dokonać dobrych szacunków, ponieważ jesteś nowy w silniku. Tak więc w pierwszych tygodniach szacunki są prawdopodobnie stratą czasu. Zwróć jednak uwagę na czas poświęcony na różne rzeczy, abyś miał doświadczenie, na którym możesz oprzeć swoje pierwsze szacunki. Po tym czasie zacznij planować, szacować i ustalać priorytety!

Trzy rzeczy, których nauczyłem się w ciągu ostatnich 6 miesięcy, kiedy brałem udział w nieudanym projekcie gry (zapłacono mi, że jestem programistą wdrażającym logikę gry):

1. Nie zmieniaj swojego planu codziennie! Oczywiście dobrze jest podążać zwinną ścieżką, ale jeśli codziennie zmieniasz swoje cele, najwyraźniej coś jest nie tak.
2. Śledź czas spędzony na pracy. Porównaj szacunkowe i skuteczne czasy. Na początku prawdopodobnie zauważysz dużą różnicę, ale z czasem powinieneś być w stanie dokonywać lepszych szacunków.
3. Przy ustalaniu priorytetów należy brać pod uwagę szacunki.

Ważne: od czasu do czasu spójrz na projekt i zobacz, co poszło dobrze, a co poszło nie tak. Myślę, że możesz zidentyfikować części, w których spędziłeś zbyt dużo czasu na czymś niepotrzebnym. Spróbuj zostawić takie rzeczy następnym razem. (Na przykład: jeśli pracujesz nad gadżetem, którego Twój gracz może użyć 1 lub 2 razy w grze przez 2 sekundy, nie wydawaj całego miesiąca na wdrożenie).

Jeśli nie wiesz, jak właściwie zaprojektować projekt, sugeruję przeczytanie pierwszego rozdziału Myślenia Bruce'a Eckela w C ++ (książka jest bezpłatna), jest sekcja o nazwie „Analiza i projektowanie”. To dobre wprowadzenie.

Pamiętaj, aby sprawdzić Bruce Eckel's Thinking in C ++ Volume 2 .