Jak zrobić grę? [Zamknięte]

Mój problem polega na tym, że za każdym razem, gdy zaczynam programować klon gry (do ćwiczeń), własną grę lub jakiś inny problem, zatrzymuję się gdzieś w połowie rozwoju, ponieważ straciłem zainteresowanie.

Jak nadal interesujesz się tworzeniem gry lub rozwojem w ogóle?

Jako projektant staram się myśleć o ludziach jako o zbiorach statystyk i zmiennych. Kiedy zadajesz pytanie, mogę łatwo wyobrazić sobie, że [Pong_Dev_Interest] maleje, a [Spa_Inv_Dev_Interest] rośnie. Gdy różnica między nimi jest większa niż [Dev_Project_Inertia] (nieco związana z [Dev_Completion_Desire]), aktywność na [Pong_Dev] zatrzymuje się i rozpoczyna się [Spa_Inv_Dev].

W języku angielskim: nie udało Ci się ukończyć projektu, ponieważ twoje surowe pragnienie zobaczenia gotowego produktu jest zastąpione brakiem zainteresowania obecnym projektem. Jeśli naprawdę chcesz go ukończyć, jedynym rozwiązaniem jest wybranie jednego (wybrałbym twój klon do ponga) i dokończenie go . Powiedz sobie: „Ja wiem, że może mógłbym jeszcze trochę udoskonalić tego klonowania, ale do cholery, dobrze jest wykopać projekt za drzwi”. Więc pracuj dalej.

Kiedy się nudzisz, pracuj dalej. Kiedy wszystko idzie świetnie, pracuj dalej. Kiedy popada w bzdury, kontynuuj pracę! Wytrwać! Bądź małym twórcą, który mógłby! Wierzę w Ciebie!

Ahem. Mam tam trochę przesady. Ale dostajesz znoszenie.

Codziennie stosuję się do własnych rad. Stworzyłem środowisko i aktorów, zbudowałem je w warunkach wygranych i przegranych oraz stworzyłem obiekty, z których będzie korzystać Gracz. Zasadniczo jestem gotowy, aby rozpocząć projektowanie poziomów i moje zainteresowanie wzrosło. Ale robię trochę każdego dnia. Każdego dnia. Pewnego dnia skończę.

I będzie tak dobrze.

Zawsze zadaję sobie to samo pytanie i jest kilka rzeczy, które możesz zrobić, aby zmotywować się (wiele z nich już tutaj zamieszczono). To, co działa dobrze dla mnie, to coś, co słyszałem na jednym z Indiach podczas tegorocznego GDC, myślę, że to on stworzył grę w Monako :-)

Najpierw znajdź projekt, który dobrze pasuje do twojego doświadczenia. Nie zaczynam tworzyć FPS, jeśli nawet nie znasz podstaw OpenGL / DirectX. (chyba że używasz silnika gry, ale nie o to tutaj chodzi ;-))

Następnie zrób sobie listę rzeczy do zrobienia i kamieni milowych, które chcesz osiągnąć, aby zawsze wiedzieć, gdzie się udać. TODO jest ważną częścią. Zdefiniuj swoje zadania, aby każde zadanie można było łatwo wykonać w ciągu dnia lub za kilka godzin . Kiedy zaczynasz kodować, projektować, modelować itp., Już widzisz światło na końcu tunelu. Nic nie jest bardziej przygnębiające niż projektowanie i kodowanie dużego Game Engine przez miesiąc bez zbliżania się do linii mety. Podziel duże zadania na mniejsze. Szybkie ukończenie zadania jest naprawdę satysfakcjonujące i pozwala kontynuować. Na przykład, to była moja lista zadań dla małej strzelanki kosmicznej w tym samym czasie:

• Efekty dźwiękowe
• Muzyka
• Przebuduj statek
• Przemodeluj rakiety
• Wykrywanie kolizji między strzałami a graczem / wrogiem
• Spraw, by wrogowie strzelali
• Ekran tytułowy
• Wynik / Życie / Energia Niezależnie od nakładki

Wszystkie te zadania były łatwe do wykonania, a gdy zaczną działać w grze, możesz iterować te obszary i je szlifować.

I hej, skończyłem małą grę. To nie jest ładne, ale w zasadzie zrobione, co w końcu było naprawdę satysfakcjonujące :-)

Musisz zidentyfikować problem, aby go rozwiązać. Dlaczego tracisz zainteresowanie?

Dla mnie zwykle dzieje się tak, ponieważ spędzam tyle czasu na frameworku, a po tygodniach nie mogłem nawet zdobyć jednego elementu rozgrywki.

Jednym ze sposobów na zwiększenie mojej motywacji jest iteracyjne prototypowanie lub jakaś forma rozwoju opartego na testach. Zwykle wiąże się to z automatyzacją przypadków testowych, ale ponieważ gry wymagają intensywnej grafiki, nie można zautomatyzować ekranów i animacji jako testów, ale logikę gry można zautomatyzować.

W przypadku części, których nie można zautomatyzować, zasadniczo zaplanuję kilka kamieni milowych w grze. Kamień milowy 1 prawdopodobnie wyrenderowałby duszka na ekranie i na przykład zmusiłby WASD do pracy. Stopniowo dodam więcej funkcji i poprawię.

To forma podziału i podboju. Podziel się na małe fragmenty, pracuj nad tym, z którym czujesz się komfortowo, a następnie zintegruj. Wypłukać i powtórzyć. W końcu możesz zobaczyć lepszy sposób zmiany układu rzeczy i możesz zmienić kod. Niełatwo jest nie mieć architektury z góry, ale zwykle, gdy zaczynasz programować, trudno jest ją wyobrazić, dopóki nie zdobędziesz kilku lat doświadczenia.

Staram się znaleźć łatwiejszą część do wykonania. Na przykład, jeśli nie mogę wymyślić, jak coś zrobić, albo nie chcę, zmieniam biegi i modeluję, lub piszę shader itp.

Zobacz ten i ten inny post.

Jeśli nie wiesz, jak poprawnie ustrukturyzować grę, powinieneś zacząć uczyć się, jak wyodrębniać ich elementy w bloki niezależne od gry. To może ci pomóc na wiele sposobów (oprócz tego, że jest interesujący), takich jak: doświadczenie dzielenia abstrakcji od implementacji, lepsze wykorzystanie dziedzictwa i projektowania interfejsu lub po prostu jak umieścić grę w wielu plikach, aby wyglądała pro (lub zapewniała elastyczność implementacji za pomocą bibliotek linków dynamicznych lub innych zastosowań interfejsu). Wcześniej czy później zdasz sobie sprawę, że wszystko można zrobić, a wtedy znajdziesz się bez problemu z motywacją (po prostu to robisz).

Miałem ten sam problem, kiedy utknąłem na początku, ale najlepszym rozwiązaniem jest ciągłe poruszanie się, lub możesz utknąć na zawsze, dopóki coś jakoś nie zresetuje (i może to potrwać zbyt długo). Nie ma znaczenia, czy w niektórych dniach po prostu kodujesz 2 linie, ale każdego dnia musisz przynajmniej otworzyć projekt i spróbować coś ulepszyć (jest to niekończące się zadanie, ale to nie jest problem).

Jeśli w pewnym momencie program nie działa, powinieneś cofnąć to, co zrobiłeś ostatnio (zachowaj kopię zapasową, użyj svn lub przynajmniej .rar z nazwą daty) do punktu, w którym działało, i spróbuj to zrobić ponownie lub pracuj nad innymi zmianami, które musisz wprowadzić, dopóki nie spróbujesz ponownie.

Najpierw powinieneś spróbować naprawić błąd za pomocą debugera, ale nie wiem, czy twój język obsługuje debugger ... ale jeśli przypadkiem użyjesz C ++ lub czegoś takiego (co poleciłbym, jeśli chcesz tworzyć gry), powinieneś lepiej wykorzystać swój debugger, ponieważ pomoże ci to szybko znaleźć błąd w jednym uruchomieniu.

Czytanie o programowaniu gier jest również dobrą rzeczą do kontynuowania na ten temat, jeśli nie chcesz pracować nad czymś konkretnym. Istnieje kilka dobrych książek i artykułów o silnikach gier i projektowaniu, które można znaleźć w Internecie.

Nie będziesz w stanie nic zrobić, jeśli nie będziesz ćwiczyć. Próba znalezienia błędu może być początkowo bardzo frustrująca, ale potem dowiadujesz się, że to naprawdę łatwe, jeśli wiesz, jak to zrobić. Tego nauczysz się unikać z czasem, kodując w taki sposób, aby zmiany nie wpływały na cały program, zmniejszając liczbę miejsc, w których szukać błędu. Jeśli za każdym razem staje się to trudne, poddajesz się, to za każdym razem, gdy myślisz o stworzeniu gry, poddajesz się przed rozpoczęciem gry. Naucz się, jak przezwyciężyć zły moment, pokonując go: P Jeśli nie przejdziesz przez ten moment, w którym stracisz motywację, twoje lenistwo zwycięży, a ty stracisz, tak to działa, dopóki nie nauczysz się, jak odzyskać motywację bez większego wysiłku.

PS Zastanawiałem się ... czego używasz do stworzenia gry?

[miał pozostać komentarzem do odpowiedzi anona, która została usunięta, gdy ją opublikowałem. Wspomniał, że miał całą tę funkcjonalność, a następnie podzielił kod jednego pliku na wiele plików, tylko po to, żeby wszystko się rozpadło]

Re: refaktoryzacja, rzeczy mogą się zdarzyć, nawet profesjonalistom. Czasami nawet przy dobrych narzędziach, takich jak Git, scalanie może się nie powieść, więc zamiast funkcji A i B oba działają, nie działają! Jedynym wyborem jest wrócić do A i spróbować ponownie. Na szczęście kontrola wersji zapisze dla ciebie ten kod; jeśli nie używasz kontroli wersji rzeczywistej, przynajmniej zrób to ręcznie, regularnie kompresując folder deweloperów - miejsce na HD jest tanie! Podsumowując, wróć do tego, co działa, i dokonaj korekty w mniejszych krokach, upewniając się, że gra nadal działa na każdym kroku. Naprawdę przygnębiające jest czyszczenie kodu, aby zobaczyć, jak wszystko się rozpada. Po prostu przywróć stary kod.

Aby pozostać zmotywowanym, powtarzaj sobie, że tworzysz grę, a nie silnik gry - cóż, chyba że to twoja sprawa. To fajne, silniki gier są świetne, ale zbyt często przeszkadzają w tworzeniu gier.

Aby zilustrować mój punkt widzenia, mogę powiedzieć, jak często się to dzieje: najpierw tworzysz kilka duszków, przenosisz je na ekranie za pomocą proto-frameworka i jesteś zachwycony! Możesz zobaczyć swoje postępy i wszystko idzie dobrze; możesz pokazać swoim znajomym.

Potem, kiedy już trochę zagrasz z koncepcją, zdajesz sobie sprawę, że musisz uelastycznić swój framework (lub silnik gry). Lub że powinieneś ponownie uwzględnić niektóre klasy, które nie są zgodne z najnowszymi wzorcami. I stamtąd wyruszasz w spiralę śmierci: przestajesz pracować nad grą i zaczynasz pracować nad silnikiem gry. Silniki do gier nie są tak zabawne. Możesz spędzać godziny na refaktoryzacji i nie masz nic do pokazania - w grze. A potem tracisz zainteresowanie.

Pamiętaj więc: twórz gry, a nie silniki gier. Refaktoryzuj tylko wtedy, gdy potrzebujesz. Nie bądź zbyt elastyczny - tylko minimum. *

*: oczywiście refaktoryzacja i elastyczność są ważne. Ale nie tak ważne, jak faktyczne ukończenie gry.

Postaraj się stworzyć wersję do gry w ciągu jednego dnia, bez względu na to, jak proste. Następnie iteruj.

1. Nie próbuj komplikować swojej gry!

2. Podziel swoje zadanie na małe, konkretne, mierzalne podzadania. Jeśli jakieś podzadanie wydaje się zbyt duże, podziel je dalej.

3. Upewnij się, że po zakończeniu zadania zapisałeś „GOTOWE” dużymi literami na liście zadań (używam pliku .txt). Nie usuwaj zadania, ponieważ wtedy nie będzie wyglądało na to, że robisz postępy.

Tym się właśnie zajmuję. To działało w przeszłości.