Jak rozpocząć tworzenie gry? [Zamknięte]

Kiedy zaczynasz nowy projekt gry, co robisz najpierw? Jak zaczynasz Co daje Ci najlepszy start do ukończenia projektu, a nie wypalenie się, zanim się gdziekolwiek dostanie?

_{Mody proszę o pomoc w tagach ... Nie mam pojęcia, jak to skategoryzować ... :)}

Prototyp. Spróbuj wdrożyć koncepcję gry za pomocą narzędzia do szybkiej iteracji. Wypróbuj Python lub po prostu łatwy w obsłudze interfejs API typu open source, aby uruchomić swój „pomysł na grę”. Staraj się maksymalnie uprościć, używaj piłek zamiast postaci, zmniejsz wizję jakiejś reprezentacji wizualnej. W ten sposób zawsze możesz na to patrzeć, dyskutować, dyskutować i udzielać informacji zwrotnych. Ustaw ustaloną oś czasu dla każdego prototypu (może 2 dni? Może tygodniowe szczyty?). W ten sposób w prototypie możesz zrobić tyle, ile chcesz.

Czasami możesz nakreślić swój pomysł na kawałku papieru, jeśli jest to wystarczająco proste. Po przygotowaniu pomysłu zacznij planować, jakiego rodzaju systemów i mechaniki potrzebujesz. Spróbuj uporządkować linie czasu dla rzeczy i sprawdź, czy można się do nich zobowiązać. Jeśli jesteś grupą ludzi, którzy chcą stworzyć grę razem, musisz to zrobić razem. Zrób to przy piwie, osobiście lub za pomocą programu do czatu głosowego. Gdy już wiesz, co robić - każdy może zacząć od tego, co robi. Upewnij się, że masz komunikację. Staraj się organizować spotkania zespołowe z częstymi przerwami w zależności od tego, ile czasu chcielibyście odłożyć.

Jeśli tworzysz własną grę, pamiętaj, że czas jest ograniczony i nie możesz zrobić wszystkiego ładnie. Być może kule i kostki wystarczą, aby uruchomić grafikę, jeśli jesteś programistą. Uświadom sobie swoje ograniczenia i pracuj z nimi, a nie przeciwko nim.

Mam nadzieję, że te kilka wskazówek pomoże :)

Jako nauczyciel widzę wiele projektów hobby dla uczniów, które zawodzą. Niezmiennie najważniejszym powodem niepowodzenia jest przekroczenie zasięgu: projekt rozpoczyna się od tej wielkiej wizji wielkiej rzeczy, która jest zbyt duża, aby ją zrealizować, coraz więcej ludzi zostaje zaangażowanych, dopóki nie upada pod ciężarem własnego projektu, a wszyscy pozostawia sfrustrowanego i zdemoralizowanego.

Najlepszym lekarstwem na to jest bezwzględne ograniczenie zakresu. Zamiast mówić „jak mam wystarczająco dużo energii, aby dokończyć długi projekt?” powinieneś zamiast tego powiedzieć „jak zaprojektować projekt, który jest na tyle krótki, że mogę go ukończyć, zanim się nim znudzę?”

Wydarzenia związane z „jamem gry” (rodzaj gry w weekend) są świetnym sposobem na rozpoczęcie i są świetne do budowania dobrych nawyków podczas robienia szybkich prototypów. W WORST spędzasz weekend tworząc kiepską grę ... prawdopodobnie nauczyłeś się czegoś w tym procesie ... I zaoszczędziłeś miesięcy pracy nad pomysłem, który nie był tak fajny, jak początkowo sądziłeś. W najlepszym razie okazuje się, że masz coś naprawdę wyjątkowego i możesz zacząć dodawać małe funkcje pojedynczo, aż do uzyskania w pełni funkcjonalnego projektu.

W moich małych projektach związanych z hobby, inną rzeczą, którą znalazłem, która pomaga, jest rozpoczęcie od pełnej listy wszystkich znanych zadań programistycznych, które należy wykonać, zamówić i skalować w dół, aby każde zadanie było wykonalne i możliwe do przetestowania, być może 30 do 60 minut, szczyty. Bardzo energetyzujące jest wykonywanie małego zadania, obserwowanie, jak działa w grze i wykreślanie go z listy ... co sprawia, że ​​jest o wiele bardziej prawdopodobne, że zrobię następną rzecz na liście od czasu ostatniego tak łatwo, a potem następny ... rodzaj jedzenia chipsów ziemniaczanych.

Kolejna wskazówka: za każdym razem, gdy pomyślnie wdrożysz nową funkcję, wykonaj kopię zapasową (lub użyj kontroli kodu źródłowego, co jest w zasadzie to samo, ale nie wszyscy używają kontroli źródła, jeśli tylko oni pracują nad własnym projektem osobistym). W ten sposób, jeśli całkowicie spieprzysz kod o 2 nad ranem i nie będziesz w stanie dowiedzieć się, jak go przywrócić do stanu roboczego, projekt nie jest martwy i nie trzeba go uruchamiać od nowa; zamiast tego po prostu cofnij się do ostatniego ukończonego i działającego kamienia milowego i spróbuj ponownie.

Powiedziałbym, że naprawdę ważną rzeczą jest zawsze mieć coś do pokazania.

Mam na myśli, że możesz spędzać wieki w systemie encji opartym na danych, z odroczonym renderowaniem i naprawdę wysokim FPS, i tym podobne. Ale są szanse, że będziesz się nudzić, nie mając nic do pokazania i się poddasz. Natomiast jeśli najpierw spróbujesz wyświetlić kilka modeli na ekranie, przesuń je i idź stamtąd, będziesz miał znacznie większą szansę.

Myślę, że pierwszy to rozwój oddolny; praca od frameworku do samej treści, a druga jest odgórna; pracując od zdobywania treści i stamtąd budując.

Mała uwaga, ale coś, co naprawdę pomaga.

Jako samotny programista uważam, że pomaga wcześnie wdrożyć dźwięk. Uważam, że motywuje mnie to do cięższej pracy nad innymi funkcjami, ponieważ nawet w pierwszych tygodniach (z grafiką ograniczoną do kolorowych wielokątów, wykrywaniem kolizji, brakujących elementów sterujących itp.) Dźwięk nadal sprawia wrażenie, jakby był „prawie na miejscu” . ”

Kiedyś pracowałem nad projektem, który wydawał się robić wszystko dobrze. Założyli stronę internetową / tablicę ogłoszeń dla wszystkich osób pracujących nad projektem w celu współpracy. Przedstawili wszystkim określone harmonogramy i cele, a sama gra była dobrym pomysłem. Mimo to ludzie zaczęli opuszczać mapę dopiero po około 2 miesiącach. Po 3 miesiącach rozwój został zakończony, a gra nigdy nie została ukończona.

Więc jeśli pracujesz w zespole, myślę, że potrzebujesz zachęty. Potrzebujesz kogoś, kto będzie w ciągłym kontakcie ze wszystkimi, upewniając się, że wykonuje pracę i przypomina im, dlaczego chce to robić dalej.

Jeśli pracujesz sam; Nie jestem zbyt pewny. Jestem okropny z grafiką itp., Więc głównie koncentruję się na silnikach. To zawsze wystarcza, aby mnie zainteresować :)

Deweloperzy zawsze podpowiadają, aby nie przenosić się na nowe obszary, dopóki nie skończysz tego, nad którym teraz pracujesz. Jeśli próbujesz zbudować grę samodzielnie, nie uważam, że jest to zbyt haniebne, jeśli zdecydujesz się złamać tę zasadę. Praca nad czymś świeżym jest dobrym sposobem na podniesienie poziomu ekscytacji!

Jest wiele dobrych odpowiedzi, ale dodam też moje:

• Zawsze miej uruchomiony projekt, na który możesz spojrzeć. Nie wchodź w tryb tankowania, w którym kodujesz przez 2 tygodnie bez czegoś do pokazania.
• Utrzymuj krótką pętlę sprzężenia zwrotnego (jest to rozwinięcie w poprzednim punkcie): kod trochę nowej funkcji, pokaż ją, uzyskaj opinię.
• Nigdy nie wdrażaj czegoś, czego nie potrzebujesz teraz, co jest następstwem: nigdy nie buduj frameworka w projekcie.

Chciałbym trochę rozwinąć ostatni punkt, ponieważ widziałem to wiele razy: nigdy nie buduj najpierw frameworka. Jest wiele powodów, ale w zasadzie nie będziesz mieć niezbędnej wizji, aby robić rzeczy dobrze, zmarnujesz dużo czasu na myślenie o tym, co będzie, a stracisz morale, gdy po X dniach / tygodniach pracy będzie nic do pokazania.

Problem polega na tym, że ramy są często niezbędne do produktu końcowego, więc co zrobić koder? Zacznij budować konkretnie, z zakodowanymi wartościami. Kiedy będziesz musiał zmienić wartość, zmień ją w opcjach. Kiedy musisz zrobić dwie podobne rzeczy, wyodrębnij podobne części razem, ale resztę określ. Jeśli będziesz to robić dalej, w rzeczywistości stworzysz strukturę, która powstaje z konieczności, zamiast marnować czas na co-jeśli.

Po zbudowaniu X gry, możesz rozważyć rozpoczęcie od frameworka, będziesz mieć wystarczająco dużo doświadczenia, aby go uruchomić.

Zanim zacząłem rozwijać swoją pierwszą grę, miałem pomysły na dwa lub trzy zeszyty. Spędziłem kilka miesięcy, grając w podobne gry w celach badawczych - określając, które funkcje mi się podobają, a które nie. Generalnie staram się najpierw skupić na mechanice, a później zająć się wyglądem i stylem (ale uważam, aby nie zignorować użyteczności). Przed zanurzeniem się w programowanie zaleciłbym szorstki, ale dokładny projekt. Nie staraj się dopracowywać każdego szczegółu zbyt wcześnie, ponieważ Twój projekt będzie musiał ewoluować, aby uwzględnić problemy z odtwarzaniem, ograniczenia technologiczne itp.

Upewnij się, że Twój pomysł jest pełny, przeprowadzając burzę mózgów i zapisując kilka kluczowych celów projektowych. Przechodzę przez proces, który nazywam odnajdywaniem gry „soul”. IE, co jest głównym powodem, dla którego tworzę tę grę. Stąd opracowuję więcej koncepcji i pomysłów, które będą wspierać ten główny cel. Cały proces może potrwać godziny, dni, tygodnie lub dłużej, w zależności od tego, jak wpadnie na ten pomysł.

Stąd zdobądź coś widocznego i kinetycznego. Uważam, że umiejętność grania w grę i uzyskiwanie od niej informacji zwrotnych jest niezbędna do utrzymania motywacji. Zwykle wdrażam efekty wizualne i dźwiękowe, a także prostą obsługę i przetwarzanie danych wejściowych, tak aby coś się „działo” i wydawało się raczej rzeczywistością niż snem.

Bez względu na to, jak przebiega twoja strategia rozwoju, nie mogę wystarczająco podkreślić, abyś nie był zajęty próbą zaprojektowania i zakodowania „silnika” gry. Każda funkcja, która nie ma widocznego ani dotykowego efektu w grze, oferuje bardzo niewielką nagrodę. Aby to zrównoważyć za pomocą podstawowych systemów podstawowych, wyświetl informacje programistyczne na ekranie. IE FPS, zmienne AI i każdy inny tekst, który pomoże ujawnić, że istnieje coś, co nie było wcześniej. Nie ma nic bardziej wyczerpującego niż spędzanie 10 godzin na kodowaniu systemu, kompilowaniu i posiadaniu dokładnie takich samych doświadczeń jak poprzednio.

Kilka lat temu napisałem artykuł o znalezieniu duszy do gier, którą możesz zainteresować tutaj: http://deleter.phatcode.net/index.php?page=articles&a=8

edytuj: I jeszcze jedna rzecz, o której widzę wspomniana w innym poście, nad którym chcę się rozwinąć. Graj w gry nie tylko podczas projektowania gry, ale za każdym razem, gdy nie czujesz się bardzo zmotywowany do pracy nad własną grą. Uważam, że granie w podobne gry pomaga mi zapamiętać, dlaczego chcę stworzyć swoją grę, i pomaga mi w dalszym zwiększaniu wydajności.

Ponadto możesz zbudować „bank inspiracji” ze zdjęciami, filmami, muzyką i klipami dźwiękowymi, które zawierają elementy tego, co chcesz umieścić w swojej grze. Za każdym razem, gdy potrzebujesz wskazówek, wróć do tych źródeł, aby pomóc w podejmowaniu decyzji. Pomoże to utrzymać motywację i pozostać na dobrej drodze.

Zwykle najpierw skupiam się na interfejsie użytkownika. Pomaga mi wyobrazić sobie, jak będzie grała. Poza tym najpierw pracuję nad łatwymi myślami, więc nie daję się w coś wciągnąć.

Zacznij od koncepcji gry, ustaw przyczynę gry, rozgrywkę, wygląd i styl gry, którą chcesz stworzyć.

Stamtąd możesz zacząć tworzyć funkcje i listy zasobów, aby programista i artysta mogli przynajmniej zacząć nad czymś pracować, podczas gdy projektant zastanawia się lub ulepsza mechanikę gry.

W ten sposób masz przynajmniej trochę kodu i zasobów w ciągu kilku dni lub tygodni, aby zwiększyć morale i rozpocząć projekt.

Dla mnie pomaga mentalnie „zmapować” pomysł gry przed jej uruchomieniem. Spróbuję wymyślić główną mechanikę, podstawową strukturę wewnętrznej gry, może trochę drobiazgów na temat tego, jak chcę, żeby działała. Następnie nakładam gumę na drogę i rozpoczynam pracę, gięcie lub łamanie części mojej mapy mentalnej, gdzie kod wymaga innej konfiguracji. Mogę zapisać pewne rzeczy (historia, być może kluczowe funkcje), ale w tym momencie projekt zwykle przesuwa się zbyt mocno, aby dokument był przydatny.

W przeciwnym razie zwlekam z tym, że na początku jest to fałszywy projekt: /