Plan prac nad ścigałką endless runner z systemem dróg typu modular

[Felipesku]

Potrzebuję planu/projektu/harmonogramu prac lub też informacji jak posiąść tą wiedzę nie czytając kilku książek, co trzeba zrobić aby stworzyć grę wyścigową typu endless runner w której omija się inne pojazdy. Chcę aby gra była oparta na modułach które będę mógł potem dalej rozbudowywać. Wiem, że takich gier jest na rynku pełno, ale taki właśnie mam plan i to chcę wykonać.

(Kupiłem na Udemy lekcję z endless runerem, ale chciałbym to przyszykować od strony papierkowej aby mieć wszystko zapisane.)

Najlepiej Harmonogram typu:

I. Trzeba stworzyć/zrobić/napisać(kupić w sklepie Assetstore):

1. To (np: stworzyć/kupić modele pojazdów)
2. To (kupić na Assetstore system zarządzania ruchem)
3. To (kupić system sterowania autem na Assetstore)
4. …
   …
5. I to (stworzyć Hall of Fame)

II. Tworzymy gre

1. No właśnie co i w jakiej kolejności?

itd.

Co do tej pory zrobiłem:

Mam tytuł.
Mam Filary projektu
Mam wstępną mechanikę
Mam zarys intra
Wiem, że chcę zaimplementować mikropłatności
Wiem, że będę potrzebował systemu testów/testerów
Wiem, że chcę aby drogi były tworzone z modułów w locie.
Wiem, że chcę zaimplementować dodatkowy filtr końcowy na grafice typu dithering.
Mam pomysł na typ grafiki
Mam część grafiki
Wiem, że będę potrzebował dobrą muzykę.

Co jeszcze?

Ewentualnie szukam osoby która już ukończyła podobne projekty, zechce podzielić się wiedzą i ustrzec mnie przed typowymi błędami. Może być za pieniądze, proszę wtedy o podanie orientacyjnego kosztu, proszę wziąć pod uwagę, iż chcę kompletny harmonogram, nie kilkanaście linijek które sam mogę napisać. Więcej szczegółów mogę podać w wiadomości prywatnej.

[niciel]

Z tego co wyczytałem nie masz nic. Nie obraz się ale ‘nazwa gry’ w wyliczance tego co masz to tak jak byś napisał “szlahta nie…” w CV. Gdzie jest info o tym co potrafisz, co jesteś w stanie sam wykonać? Plany planami ale czasami tak bywa że trafiasz na ścianę przy z założenia prostej sprawie. I jej nie przeskoczysz, przynajmniej nie od razu.

Nie napisałeś jaka technologia cie interesuje…
Ale przeszukując udeny zakładam że unity… Pytanie jaka wersja? Jak bardzo chcesz to skomplikować. Samo dodanie modułów jako addonow aktualizacji (a nie cała podmiana klienta) może być prosta, (podmiany assetow unity,) bądź trudna (a raczej trudniejsza) jak dodanie nowych mechanik (pliki wykonalne), ja bym Ci po prostu radził zacząć a potem modyfikować projekt według tego jak ci będzie szło, bez twardych planów że coś musi być.

[Felipesku]

Niby chcesz pomóc i mówisz żebym się nie obrażał a potem wylatujesz że szlachtą… a pewnie że czuję się urażony twoja wypowiedzią bo nic ona nie wnosi oprócz twojego widzimisię.

Mam wiele, zapał, głowę pełną pomysłów i chęci do nauki a to 90% sukcesu. Ale Hej! Mam cały brulion z zapiskami a ty mi mówisz, że nic nie mam. To jest dopiero tupet. I nie jest tu ważne ile mam a to czego szukam a szukam osoby która stworzy mi harmonogram prac tak abym wszystko po kolei zrobil. Pewnie że chodzi o Unity bo nic innego nie tknę z marna dwuletnią wiedzą programowania w C++.

Awiec podsumujmy twoja pomoc:

Wstęp do miecha, miecho, udawana pomoc zupełnie nie w temacie.

Kolego ja doskonale wiem co i jak chce zrobić, wystarczy zapytać.

[Felipesku]

Może dla uściślenia, interesuje mnie Konspekt prac w oparciu o kryteria które podam (czyli robię za Game Designera), Gamification, szerokopojety Game Development i wszelka wiedza na ten temat od osoby która jest chętna dzielić się nią za free lub nie, lub też samo przygotowanie konspektu dla dalszych prac już przy Game Developingu.

Jak tu tylko taka pomoc to prędzej to wszystko sam ogarnę… zobaczymy. Zalożylem że tu ludzie dzieła się wiedzą…

[appG]

Tutaj zauważyłem, że pozostali tylko i wyłącznie zgorzkniali ludzie i młodzi wchodzący w branże. Polecam przenieść się na angielski gamedev.

Jezeli chodzi o Twoje pytanie to :

• moduł obsługi pojazdu - mam na mysli tutaj ulepszenia tego pojazdu, nowe funkcjonalnosci itp. Gra w ktorej jedzie sie bez celu albo by osiagnac tylko lepszy wynik szybko sie znudzi
• fizyka pojazdu - potrzebujesz przygotowac fizyke jazdy tego pojazdu ktory bedzie sterowany. W takich grach jest to calkiem inny model ruchu niz dla pojazdow wyprzedzanych
• fizyka pojazdow wyprzedzanych
• modul zniszczen - ten moze wiazac sie z wizualnym aspektem typu podmiana grafik lub tez wplywac rowniez na osiagi
• modul generowania ruchu - to chyba najwazniejsze, zwykla losowosc nie wystarczy musi byc mozliwe ominiecie pojazdow bez uderzenia - nic nie wkurza bardziej gdy gra generuje pojazdy tak ze pasa ruchu nie mozna zmienic i jedzie sie 2-3 minuty by zderzyc sie z pojazdem bo nie da sie inaczej
• modul generowania otoczenia - jakies drzewka, domy co by lataly obok
• modul generowania drogi - zwezenia drog, rozszerzenia, rozdzielenia itp
• modul oswietlenia
• modul graficzny
• modul sterowania

Czesc z tych modulow dostaniesz w ramach silnika gry jaki wybierzesz o ile wybierzesz.

Prawda jest tez taka ze pomysl na gre to niewiele i pomysl jest warty zlotowke plus vat. Wybrales sobie spory projekt, nie masz doswiadczenia to moze sie skonczyc zle. Moze na poczatek warto pomyslec o czyms co sie nie sprzeda a da Ci wiedze typu mario, tetris, arkanoid.

[Radomiej]

Generalnie jak chcesz zrobić grę w Unity i masz już pomysł, to:

1. Ustalasz sobie budżet i czas: to będą główne zasoby na podstawie których będziesz wyznaczał featursy i możliwości projektowe.
2. Przeglądasz rynek twojego gatunku, patrzysz co było na początku, co jest teraz, jakie są trendy: na podstawie tego możesz sobie zmodyfikować swój pomysł.
3. Patrzysz czy na Assetstory są jakieś assety które ci pomogą, idealnie jest je przetestować zanim zaczniesz dodawać je do projektu. Dodatkowo polecam używać assetów które mają 4 lub 5 gwiazdek, i które są aktualizowane na bieżąco(nadal żywe). Problem z Assetami też jest taki że często brakuje im niektórych rzeczy które będą dla ciebie istotne, albo co często się zdarza nie są takie proste do użycia jak się wydaje, np. jeśli będziesz próbował skleić różne assety to z tym jest różnie, potrzebujesz też czasu aby nauczyć się jak one działają więc jest to obusieczny miecz i jeśli zaczniesz brać za dużo assetów to może się okazać że stracisz na ich integracji więcej czasu niż na ręcznym napisaniu funkcjonalności. Więc bierzesz albo main asseta którego się uczysz i na nim robisz gameplay albo korzystasz z takich które będziesz wykorzystywał w 60/80%; tutaj także podczas testowania i poznawania dostosowujesz pomysł do tego jak wyglądają możliwości techniczne i narzędzia z których będziesz korzystał.
4. Projekt gry(Prototyp): tworzysz projekt i starasz się w nim trzymać tylko to co potrzebujesz, wszystkie testy i zabawy najlepiej robić w osobnych projektach. Robisz prototyp, patrzysz jak się zachowuje i aktualizujesz pomysł. Po wczesnym gameplay decydujesz czy iść z tym dalej, czy uda ci się wykonać projekt z ustalonym budżetem i czasem, albo czy chcesz go negocjować. Generalnie polecam ciąć tylko w dół, nie w górę, chyba że zmieniają się fundamenty projektowe(wygrana w lotto, znalazł się wydawca etc.) wtedy wracamy do punktu 1.
5. PR, social media: trzeba przygotować grę do zaistnienia w świadomości graczy, dobrze jest to zrobić w tym momencie, co także oznacza że gdzieś tutaj także trzeba pomyśleć nad designem i wyglądem gry.
6. Dopracowywanie gry właściwej: Tutaj generalnie przekuwamy prototyp w coś bardziej dopracowanego, Game Design powinien mieć już jakieś konkretne wartości, np. rodzaje przeszkód, moment ich występowania etc., wrzucamy grafiki, levele(stage). Prawdopodobnie będziesz chciał mieć borda np. w Trello gdzie będziesz wrzucał rzeczy do zrobienia. Ogólnie w tym momencie nadal będzie potrzeba żeby pewne rzeczy przetestować(prototypować) więc dobrze rozróżniać między rzeczami które muszą być domknięte a które mają działać tylko koncepcyjnie(np. jakiś ruchomy blok co do którego nie jesteś pewny czy będzie pasował do gameplayu) bo mogą za chwilę zniknąć. I tutaj kolejna istotna zasada żeby zawsze po wprowadzonych zmianach dało się projekt odpalić i zagrać.
7. Dystrybucja i dodatkowe usługi: tutaj zakres jest różny, np. na Google Play, musisz przygotować projekt, dodać odpowiednie biblioteki(reklamy, płatności), stworzyć ranking, osiągnięcia etc.
8. Maintenance: reagowanie na uwagi graczy, fixowanie bugów, zmiany w rozgrywce

W dużym skrócie od strony zarządzani projektem to tyle, najważniejsze w tym jest umiejętne reagowanie na zmienne i wytrwałość

[Felipesku]

Mam już za sobą kilka ukończonych projektów pisanych w C++ w tym podróbka GaduGadu z komunikacją klient-serwer, Snake, Sokoban i jakaś tekstowa gra sieciowa typu MUD pisana w Pythonie (najlepsza zabawa przy tym była

Także nie zaczynam od samego zera, niemniej jednak faktycznie dopiero wszystko jest w planach w kajeciku, troche grafiki trochę mechaniki, sporo rzeczy które podpowiedzieli mi znajomi (jeden kolo zażądał ode mnie torbę pełną pieniędzy jak mi się uda )

Wybrałem silnik Unity gdyż już trochę prototypowałem na biegu grę w której się biegało ludzikiem po planszy i idzie to bardzo sprawnie.

Hej! Dzięki za info, odzyskałem wiarę w ludzi

Właśnie tak się zastanawiałem, czy nie lepiej od razu na TIG’a ale pomyślałem, że tak po sąsiedzku może jednak będzie lepiej. Może poznam kogoś z okolic Mazowsza kto zainteresuje się projektem jak już będzie widać, że nie odpuszczę

A czy kojarzysz może jak się opisuje ‘jaki jest klimat gry’, bo nie wiem czy dobrze tą kwestię rozumiem. Napisałem, że -pośpiech, wciągający, nakręcający do zobaczenia zakończenia, ale obawiam się, że nie rozumiem do końca o co tu chodzi bo gdzieśprzeczytałem, że jest pięć punktów:

1.Elevator Pitch - czyli w pięciu słowach o swojej grze tak aby zachęcić potencjalną osobę do zadawania dalszych pytań
2. Jaki typ odbiory wybierasz
3.Co zyskasz na stworzeniu gry
4.Co gracz będzie z tego miał
5. Jaki jest klimat gry - no i włąśnie tego nie czaje.

[Felipesku]

rzysz czy na Assetstory są jakieś assety które ci pomogą, idealnie jest je przetestować zanim zaczniesz dodawać je do projektu. Dodatkowo polecam używać assetów które mają 4 lub 5 gwiazdek, i które są aktualizowane na bieżąco(nadal żywe). Problem z Assetami też jest taki że

Dzięki za cenne wskazówki, zapiszę sobie w kajeciku jeśli pozwolisz

Z wytrwałością nie powinno być problemu, od dwóch lat pracuję nad tym tytułem na papierze więc raczej teraz już się nie poddam (bo nie lubię pisać, a jakoś to przetrwałem).

A czy znasz może jakąś regułę bądź też metodę opisującą proces, typu:

I.

• Platforms
• Number Of Players
• Target Audience
• Duration

II.

• • Genre
• Mechanics
• Story And Theme
• Aesthetics

III.

• Goals
• Interaction
• Obstacles
• Rules

Tylko taki bardziej rozbudowany opis, lub może książka. Chciałbym sobie teraz z kajeciku wszystko przenieść w jakiś taki spis co i jak po kolei mam robić i głowie się jak mam to zrobić. Chodzi mi o takie rozwiniecie punktu 4. i 6. z Twojej wypowiedzi.

[appG]

Jeżeli chodzi o sam opis by gra sie sprzedala lub by dolaczyli do nich inni to polecam skorzystac z pomocy marketingowca. W tej branzy rzadko tworzy sie cos samemu. Jezeli nie masz znajomego co zajmuje sie spezedaza to mysle ze taki opis bedzie Cie kosztowal 100-200 zl. Choc to bardziej juz po zakonczeniu gry. Gra nie wydaje sie przynajmniej z opisu duza, wiec wczesny dostep odpada

[Radomiej]

Jak dobrze zrozumiałem pytanie to chodzi tobie o roadmape i założenia projektowe, możesz sobie popatrzeć na GDD(Jak napisać Game Design Document)
oraz na praktyczny sposób implementowania tego co sobie założyłeś.
Generalnie ciężko dać tu jedną uniwersalną zasadę. Ogólnie punkt 4 ma tobie powiedzieć czy faktycznie da radę zrealizować projekt według twoich założeń i bardziej empirycznie pokazać jak gra będzie wyglądać. Czasem jest tak że w głowie plan jest świetny ale po pierwszych próbach implementacji widzisz że czegoś brakuje, albo że niektóre założenia są zbędne albo będą trudne do zrealizowania z technicznego punktu widzenia(brak bibliotek, skomplikowany algorytm). Generalnie po wyjściu z tego etapu dobrze jakbyś już wiedział czy najtrudniejsze elementy gry będą możliwe do zrealizowania, głównie dotyczy to mechaniki, ale jeśli chcesz polegać na jakiś zaawansowanych efektach graficznych czy jakimś stylu, to musisz zobaczyć czy masz możliwości jego zastosowania. Np. jeśli założyłeś że na twojej mapie ma być 100000 obiektów widocznych na raz to powinieneś wiedzieć że klasyczne podejście w Unity się nie sprawdzi, trzeba używać spritów/bilbordów/GPU Instancingu programowania w stylu ECS a to nakłada z kolei kolejne limity np. do możliwości stosowania shaderów itp. Generalnie prototyp to Core twojej gry, który potem będziesz dopracowywał w punkcie 6. Ma tutaj zastosowanie klasyczna zasada 80-20(niektórzy mówią 70-30), czyli 80% funkcjonalności jesteś w stanie zrobić w 20% założonego czasu, ale pozostałe 20% które determinuje jakość produktu końcowego będziesz robił przez resztę czasu, bo dopracowanie assetów czy mechanik żeby dobrze to z sobą współpracowało wymaga znacznie więcej czasu niż po prostu sklejenie tego do siebie i dodanie paru menusów; tzw. crapy to właśnie przykład takiej gry która została ukończona bez dopracowania Dlatego polecam ciąć w dół, bo w procesie prototypowania często można odnieść wrażenie że to jest easy to do, ale należy brać pod uwagę że jak robisz sam jakiś skrypt to jego dopracowanie do reszty w punkcie 6 zajmie 4x więcej czasu, a jak korzystasz z gotowego Assetu to może to być >10x więcej czasu, bo nie widzisz czasu jakie autor spędził na jego przygotowanie i czasem będzie wymagane zmodyfikowanie jego zawartości tak by wkomponowała się do twojej gry i robiła to czego od niej oczekujesz.
Odnośnie punktu III to możesz sobie spojrzeć na:
Inżynieria gier. Level design dla początkujących (http://inzynieria-gier.wonderland-engineering.eu/?page_id=9)

[NamespaceV]

Generalnie tworzenie gry jest procesem iteracyjnym i nawet bardzo doświadczone teamy mają problem z konkretnym harmonogramem. Zwłaszcza że każdy projekt jest inny.

Moe kiedyś będzie lista punktów do zrobienia, na teraz to takiej listy nigdy nie widziałem.
A wszystkie branże około programistyczne odchodzą od dużych planów na rzecz podejścia zwinnego (agile), bo planowanie działa kiepsko i lepiej się nie oszukiwać i rezygnować na sytuację na bieżąco.

Zostaje tylko ramowy plan, i iteracja. Bez mocnego teamu nawet ramowy plan będzie dziurawy jak sito.
A mocny team dorzuci sobie ciekawsze featurey tak że też będzie mało zgodnie z planem.
I zawsze cos pójdzie nie tak.

To co polecam się skupić:

• jakie jest USP (unique selling point)
  czyli co takiego ma ta gra że ktoś zagra w nią a nie jedną z miliona innych
  wiadomo że nie przelicytujesz gigantów na feature,
  ale np bo mam kota jako postać a ludzie lubią koty
  bo mam unikalny styl graficzny który przyciąga uwagę
  bo chodzi na starych telefonach na których nowe gry nie chodzą
  itd

• jak najszybciej grywalny gamepley i rozwijanie go
  w 200 stron dokumentacji projektowej nie da się zagrać
  jak masz cokolwiek co działa to można to rozwijać w zupełnie nieprzewidzianych kierunkach

• budowa sensownego teamu
  najważniejszym “zasobem” są ludzie
  bez sensownych ludzi plan nie pomoże,
  sensowni ludzie pomogą ułożyć plan, który i tak 4 razy kompletnie się zmieni po drodze

• dostosować projekt do skilli teamu
  co z tego że masz super pomysł, jak nikt w teamie nie umie go zrobić
  a ktoś w teamie zrobił małą pierdółkę… i akurat super działa tylko zmienia wizję gry
  to trzeba na wyczucie ale warto takie okazje łapać

[NamespaceV]

Mogę trochę opisać jak ja bym to organizował ale jak pisałem wyżej każdy projekt i każdy team działa inaczej.

Na początek ramowe GDD na google docsie opisujące

• główne USP
• elevator pitch
• docelowe platformy
• różne pomysły na featurey
• posortowane po kryterium fajność / trudność

GDD określa ogólny kierunek projektu.

Potem równolegle.

Graficy pracują nad stylem dla gry - enviro, postacie. Jak to ma wyglądać?
Oszacować jak dużo będzie potrzeba assetów do docelowej produkcji. I co jest must have a co można ściąć jak nie będzie czasu.

Programiści robią na boxach + tempy od grafików jakiś gameplay w który można zagrać żeby zweryfikować czy pomysły się trzymają kupy i team może je dostarczyć.
Jeśli jest znana platforma docelowa i wiadomo że to np free to play z monetyzacją równolegle idą prace nad integracją z płatnościami bo tego nie można zrąbać.

W międzyczasie GDD żyje i się ciągle zmienia. A całość gry też nieustannie się zmienia bo każdy eksperyment czy nowy pomysł pcha grę w innym kierunku. Jak projekt idzie dobrze to gra staje się coraz lepsza do grania. Bo iteracja prototypów znajduje fajne pomysły, a potem team je rozwija. W praktyce idzie jak zawsze - na około i się nie klei, ale dobry team ląduje projekt.