Autor Wątek: Jak zacząć grę?  (Przeczytany 5870 razy)

swiru

  • Gość
# Październik 12, 2008, 08:23:26
Jeśli za każdym nowym projektem zaczynać od innej strony. to w końcu większość będziemy w stanie z tych wypocin coś poskładać.
Myślę że elastyczność kodu to podstawa. Jeżeli będziemy w stanie wykorzystać to co wcześniej już skodziliśmy to kiedyś ten giga(w dzisiejszych czasach chyba powinno się mówić "terantyczny" ;P) projekt zostanie skończony.
To taka prosta rada... może wyduszę później jeszcze jakieś - idę spać ;).

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline k_b

  • Użytkownik
    • Blog

# Październik 12, 2008, 11:43:39
mianowicie w jaki sposób zaczynacie swoje projekty, dlaczego tak i jakie są z tego korzyści (tzn. z takiego podejścia a nie innego)?

Generalnie, praktycznie zawsze piszę najpierw plik .doc lub .txt, a nie .cpp czy .hpp. I tu są dwa warianty: w pierwszym piszę dosłownie wszystko co mi aktualnie przychodzi do głowy, taka projektowa sieczka, z której nikt oprócz mnie wiele nie zrozumie; w drugim piszę design document, przy czym bez żadnych list (a więc bez listy poziomów, rodzajów statków, typów graczy - to jest IMO bardzo ważne, takie pisanie list powoli zabija motywację, a każdy element zabijający chęci bezwzględnie eliminuję w pierwszym tygodniu prac), parametrów, itp., sam ogólny opis rozgrywki z możliwymi zagraniami gracza, zależnościami i interakcjami.

Po tych bazgrołach następuje uroczyste skopiowanie frameworka do nowego folderu i zaczynam od razu kodzić gameplay (oczywiście nie menu - menu robię na samym końcu gry, taka przyjemna wisienka na torcie) mając od razu bazę narzędzi do wyświetlania grafiki, odtwarzania dźwięków, przyjmowania wydarzeń i innych. Oczywiście kodzenie zaczyna się od pięknego pliku o nazwie "gameplay.hpp".

Dlaczego tak lepiej? Bo mam okropnie słomiany zapał i 50 folderów niezaczętych projektów.

swiru

  • Gość
# Październik 12, 2008, 12:03:32
Ja rozpoczynam od dużej kartki i ołówka, na której to tymże ołówkiem, rozrysowuję wszystkie elementy programu. Daje mi to pojęcie z czym się chcę zmierzyć i co będzie w miarę osiągalne. Potem Excell i rozpisuję to samo jako schemat, który mogę sobie pokolorować uzależniając to od terminów i prostoty wykonania. Potem tabelka z rozpisem prac i kosztorysu.
Tak przygotowany projekt akceptują wszyscy jego uczestnicy z niewielką pomocą pistoletu przyłożonego do tyłu głowy i dwoma głodnymi psami za drzwiami :D.

I teraz zaczyna się najnudniejsza rzecz a więc samo pisanie (w m.in. moim przypadku) lub rysowanie i udźwiękowienie, w innych.

Mając tak przygotowany projekt prace posuwają się zaskakująco szybko, gdyż każdy wie co go czeka, co trzeba jeszcze zrobić, gdzie można sobie pozwolić na inicjatywę, a gdzie trzeba po prostu naklepać "aby było".

Zalety:
- szybkość realizacji (no chyba nikt nie przyzna, że gry robimy wolno :D, a robimy tylko w weekendy),
- schematyka zadań (nikt na nikogo nie zwali swojej pracy),
- robiąc któryś tam z kolei projekt połowa kodu jest już naklepana,
- ta kartka, o której pisałem na początku, jest już tak wygnieciona, że świetnie się sprawdza w toalecie co pozwala zaoszczędzić na papierze toaletowym.

Wady:
- często na jednym kompie Excell a na drugim projekt,
- hektolitry kawy, napojów energetycznych i wyskokowych.

To co nam pomaga:
- nie szukać przykładowej grafiki w necie. Stosować jebitnie różowy kolor dla tekstur których jeszcze nie ma. Daje to pogląd dla grafika co ma jeszcze zrobić (baaardzo rzuca się to w oczy),
- to co ma jeszcze zrobić programista (lub programiści) wywala na ekran np. napis: "tu powinna być eksplozja".
- jako przykładowe dźwięki stosujemy np. szyderczy śmiech przełożonego (głośność tego dźwięku powinna być odpowiednio zwiększona :D).

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Październik 12, 2008, 14:54:36
Ja zaczynam od zaprojektowania. Nie rysuję diagramów UML, niekoniecznie nawet obmyślam jakie będą klasy, ale spisuję do pliku TXT ogólny projekt, czyli:
- Krótko jednym zdaniem co to będzie
- Środowisko, czyli w jakim języku, na jaką platformę zostanie napisane
- Założenia, czyli np. grupa docelowa, czy projekt ma być mały czy duży, szybko skończony czy jak najlepszy itp.
- Z czego będzie się składał

To "z czego będzie się składał" jest skomplikowane. Najpierw można wypisać jakie cechy ma posiadać gra z punktu widzenia gracza (np. że będzie się dało zbierać punkty, skakać, strzelać do wrogów, chodzić, wybierać mapę), a potem przemyśleć jakie rozwiązania techniczne będą do tego potrzebne (przy zbieraniu punktów pewnie jakieś efekty cząsteczkowe, przy chodzeniu postacią pewnie animacja, do wybierania mapy potrzebne będzie proste GUI).

Wtedy wiem, jaka funkcjonalność jest potrzebna i mogę wypisać, z jakich modułów będzie się składała gra. Wtedy biorę się za ich pisanie po kolei, od tych najniższego poziomu - czyli piszę (albo już mam :)) framework, logger, manager zasobów, manager konfiguracji, z ich użyciem moduł do rysowania grafiki 2D, z jego użyciem moduł do GUI, z użyciem tego z kolei menu itd. Każdy taki moduł najpierw projektuje (jakie możliwości, jakie założenia, na tej podstawie operacowuję interfejs i wymyślam jak to zaimplementować).

Aha, żeby nie było: Oczywiście nie każda mała gra musi mieć wypasiony logger, profiler, manager zasobów, GUI i co tam jeszcze. Wszystko jest kwestią założeń. Jedne części projektu biorą się z innych. Na przykład mam koncepcję "prosty tetris", z niej mam założenia "mała i prosta gra", "do napisania szybko", to stwierdzam że logger nie będzie potrzebny i go nie piszę. Ważne, żeby to była świadomie podjęta decyzja.

Offline Markopolok

  • Użytkownik
    • Mój blog

# Październik 12, 2008, 15:15:12
Ja mam specjalny zeszyt, w którym zapisuje różne rzeczy dotyczące gry czy programu.
Najpierw pisze ogólnie co to ma być, później przechodze do coraz szczegółowszych rzeczy.
Pisze z czego ma być zbudowana gra, jakie klasy mam zrobić, jak mają ze sobą współpracować.
Gdy zaprojektuje wystarczająco dużo rzucam się do programowania.

Offline radsun

  • Użytkownik
    • CaRpg

# Październik 12, 2008, 19:51:15
Projekt można zacząć na dwa sposoby:
  • od ogółu
  • od szczegółu
Ja zawsze zaczynam od drugiego :D
Co do projektowania na kartce to w moim przypadku nie ma to sensu, jak siadam przed kompem zawsze wiem co robić :D
Projekt zaczynam zawsze postaci gracza i sterowania nim a menu zostawiam na koniec

Offline blackhawk

  • Użytkownik

# Październik 12, 2008, 20:01:07
Czas projektowania, którego się niejako wymaga przy rozpoczynaniu projektu jest rzeczywiście okropnie żmudny i już od samego początku nieco zniechęca. Można jednak w pewien sposób ograniczyć projektowanie kosztem czystego pisania. Ja mam w zwyczaju odpowiednio dzielić projekt na składowe takie by w dalszym etapie kodzenia nie byłyby one zależne od późniejszego kodu ale wprost na odwrót. Na sam początek przypada "podstawka", czyli wyświetlanie grafiki obsługa dźwięku, klawiatury... Juz od tego momentu musimy jasno stwierdzić czego tak naprawdę będziemy potrzebowali, jakich efektów. Później zabieramy się za kolejną część np. obsługę okienek która bedzie korzystała z poprzedniego modułu (wszystko robimy tak by było łatwo demontowane i przenośne do innych projektów na tak niskim poziomie). W 3 w kolejności zająłbym się od razu edytorem. Także dzieląc go na elementy od siebie niezależne. Np. samo rysowanie mapki nie musi mieć nic wspólnego z samą rozgrywką (dopiero odpowiednie box'y kolizyjne i inne temu podobne elementy będą).

Więc nasza praca wygląda przemiennie -> projektowanie ->kodzenie -> projektowanie etc. Oczywiście nie mówię że uda nam się w taki sposób dotrwać do samego końca ;D Bo prędzej czy później jakieś zależności krzyżowe się znajdą.

Offline Lobsang Rampa

  • Użytkownik
    • Global Epidemic

# Październik 12, 2008, 20:26:06
Ja z kolei większe projekty (zarówno gry jak i projekty nie związane a grami) zaczynam zawsze "od ogółu", najpierw ogólny szkielet, a później dodawania kolejnych funkcjonalności, stosuję przy tym tzw "metodologię pocisku smugowego", czyli projekt od razu funkcjonuje jako spójna całość, choć większość klas i metod jest na początku pusta. Z czasem kod jest uzupełniany i powoli nabiera życia.

Zanim jednak siądę do kodowanie, długie miesiące poświęcam na projektowanie. Kupuję gruby zeszyt A4 (dla każdego projektu osobny), biorę ołówek, gumkę, linijkę i zaczynam projektować, najpierw ogólne założenia, to co chcę w projekcie osiągnąć, mechanikę, interfejs użytkownika, sprawdzam czy to co wymyśliłem jest spójne i grywalne (jeśli to gra). Robię to tak długo aż jestem przekonany że zastosowane rozwiązania się sprawdzą, często to trwa bardzo długo, obecna grę projektuje już ponad pół roku. Następnym etapem jest projektowanie samego kodu, czyli stworzenie schematu przepływu danych i diagramu klas, wtedy też siadam do kompilatora i testuję to co wymyśliłem, wprowadzam poprawki. Gdy już funkcjonuje szkielet gry, zabieram się za właściwe kodowanie.
« Ostatnia zmiana: Październik 12, 2008, 20:28:02 wysłana przez Lobsang Rampa »

Offline k_b

  • Użytkownik
    • Blog

# Październik 12, 2008, 20:29:04
Zanim jednak siądę do kodowanie, długie miesiące poświęcam na projektowanie. Kupuję gruby zeszyt A4 (dla każdego projektu osobny), biorę ołówek, gumkę, linijkę i zaczynam projektować, najpierw ogólne założenia, to co chcę w projekcie osiągnąć, mechanikę, interfejs użytkownika, sprawdzam czy to co wymyśliłem jest spójne i grywalne. Robie to tak długo aż jestem przekonany że zastosowane rozwiązania się sprawdzą, często to trwa bardzo długo, obecna grę projektuje już ponad pół roku. Następnym etapem jest projektowanie samego kodu, czyli stworzenie schematu przepływu danych i diagramu klas, wtedy też siadam do kompilatora i testuję to co wymyśliłem, wprowadzam poprawki. Gdy już funkcjonuje szkielet gry, zabieram się za właściwe kodowanie.

A to ciekawe. Spróbuję taką metodę wykorzystać w moim najbliższym projekcie :).

swiru

  • Gość
# Październik 12, 2008, 20:43:40
Także dzieląc go na elementy od siebie niezależne.
A potem się dziwić ze, programista wali łbem o ścianę  :)

Moja metoda?
Kiedyś :  projektowanie => pisanie.
Teraz*  :  mięso na SVN'a => poprawianie

*Pomijam uC :)
« Ostatnia zmiana: Październik 12, 2008, 20:50:59 wysłana przez swiru »

Offline Zene

  • Użytkownik
    • Zenedith’s dev blog

# Październik 12, 2008, 20:48:38
Jak zacząć grę? To zależy czy dysponujesz gotowym silnikiem, czy zaczynasz wszystko "od zera" lub prawie "od zera".
Jeśli dysponujesz silnikiem to wiele problemów odpada (ale dochodzi zapoznanie z silnikiem jeśli to nie Twój).

Jeśli chodzi o tworzenie "od zera" to podchodzę podobnie jak Krzysiek K. i Lobsang Rampa - od ogółu do szczegółu, starając się stworzyć na początku pewien trzon aplikacji.

Piszę grę i jeśli brakuje mi pewnych funkcjonalności to ją dodaję na bieżąco do silnika. Z tym że nie jest to dodawanie gdzie popadnie i żeby było "jak najszybciej".
Na pewno nie staram się tworzyć za dużo nad wyrost (w silniku).

I jak najbardziej jestem za robieniem możliwie niezależnych części silnika, używając interfejsów abstrakcyjnych do opisywania zasad interakcji.

Offline Riddlemaster

  • Użytkownik
    • Moja strona domowa

# Październik 13, 2008, 11:31:49
Ja stosuję podejście iteracyjne. Najpierw określam minimalną funkcjonalność, która pozwoli grać/korzystać z aplikacji. Powiedzmy, że w przypadku FPSa byłoby to na początku sterowanie postacią po pustym poziomie, później strzelanie, walka itd. Później w kolejnych iteracjach rozszerzam możliwości projektu aż do osiągnięcia założonego celu (lub powiedzenia sobie - stop już jest fajnie - jeśli na początku go nie wyznaczyłem lub osiągnięcie założonego celu jest zbyt kosztowne).
Kiedyś stosowałem różne metody projektowania (UML i tego typu rzeczy), ale teraz praktycznie tego nie robię (chyba że na bieżąco pewną konkretną funkcjonalność), bo wychodzi na to, że projekt ewoluując przez czas swego trwania ostatecznie tak odbiega od swych pierwotnych założeń, że etap projektu byłby tylko stratą czasu.

Offline yarpen

  • Użytkownik

# Październik 13, 2008, 12:39:51
Podstawa jest prototyp. Tu liczy sie glownie predkosc jego tworzenia. Moze powstac w game makerze, na cudzym silniku, w innym jezyku programowania niz docelowy -- liczy sie, zeby poszlo szybko. Nie zaprzatac sobie glowy elegancja czy rozszerzalnoscia. Jezeli tutaj core gameplaya bedzie fajny, to po przepisaniu tego (bo "urok" prototypu jest taki, ze idzie do kosza) bedzie tylko lepiej. Jezeli bedzie slabo, to pomysl jest do dupy i mozna sie zabrac za cos innego :)

Offline dynax

  • Użytkownik

# Październik 13, 2008, 18:07:53
Zanim jednak siądę do kodowanie, długie miesiące poświęcam na projektowanie. Kupuję gruby zeszyt A4 (dla każdego projektu osobny), biorę ołówek, gumkę, linijkę i zaczynam projektować, najpierw ogólne założenia, to co chcę w projekcie osiągnąć, mechanikę, interfejs użytkownika, sprawdzam czy to co wymyśliłem jest spójne i grywalne (jeśli to gra). Robię to tak długo aż jestem przekonany że zastosowane rozwiązania się sprawdzą, często to trwa bardzo długo, obecna grę projektuje już ponad pół roku. Następnym etapem jest projektowanie samego kodu, czyli stworzenie schematu przepływu danych i diagramu klas, wtedy też siadam do kompilatora i testuję to co wymyśliłem, wprowadzam poprawki. Gdy już funkcjonuje szkielet gry, zabieram się za właściwe kodowanie.

Taaa... jeśli będę siedział pół roku nad projektowaniem to w ogóle nie nauczę się programować. Ja już wolę w ogóle nie projektować niż siedzieć pół roku. Projektowanie to rzecz której najbardziej nie lubię przy programowaniu gier.

Moje motto - Im mniej projektowania tym lepiej :)
« Ostatnia zmiana: Październik 13, 2008, 18:09:24 wysłana przez Dynax »

Offline Wyszo

  • Użytkownik

# Październik 13, 2008, 18:39:48
Zanim jednak siądę do kodowanie, długie miesiące poświęcam na projektowanie. Kupuję gruby zeszyt A4 (dla każdego projektu osobny), biorę ołówek, gumkę, linijkę i zaczynam projektować, najpierw ogólne założenia, to co chcę w projekcie osiągnąć, mechanikę, interfejs użytkownika, sprawdzam czy to co wymyśliłem jest spójne i grywalne (jeśli to gra). Robię to tak długo aż jestem przekonany że zastosowane rozwiązania się sprawdzą, często to trwa bardzo długo, obecna grę projektuje już ponad pół roku. Następnym etapem jest projektowanie samego kodu, czyli stworzenie schematu przepływu danych i diagramu klas, wtedy też siadam do kompilatora i testuję to co wymyśliłem, wprowadzam poprawki. Gdy już funkcjonuje szkielet gry, zabieram się za właściwe kodowanie.

Taaa... jeśli będę siedział pół roku nad projektowaniem to w ogóle nie nauczę się programować. Ja już wolę w ogóle nie projektować niż siedzieć pół roku. Projektowanie to rzecz której najbardziej nie lubię przy programowaniu gier.

Moje motto - Im mniej projektowania tym lepiej :)

Też tak myślałem, ale to jest niestety bardzo słabe podejście. Jak dłubiesz przy czymś małym dla siebie, to ok, ale jeśli projekt jest większy - zwłaszcza jeśli nie jesteś jedyną osobą w projekcie, to takie podejście się nie sprawdza. Niestety trzeba poświęcić dość sporo czasu na projekt, przy czym nie musi być on wcale pełen wielkich diagramów UML, tylko po prostu ma jasno określać nad czym pracujecie, podział ról, harmonogram - co dana osoba ma na kiedy zrobić, itp. W przeciwnym wypadku niby będziecie razem pracować, ale nagle się okaże że ktoś nie zrobił nic przez miesiąc bo w sumie nie bardzo wiedział co, a ktoś inny harował przez ten czas jak wół. Projekt pomaga zarządzać, jego pisanie motywuje do 'burzy mózgów'. Generalnie choć wydaje się on czasem straconym, w praktyce chyba jest wręcz odwrotnie. No niestety. Do tego częste iteracje, refaktoryzacja kodu od razu jak nam coś nie pasuje i łóżko zawalone stosem zapisanych kartek A4, w których nigdy nie można znaleźć akurat tej, która jest w danej chwili potrzebna ;) Co na karteczkach? rozpisany bardzo uproszczony diagram kodu, którym mamy się zająć w danym dniu oraz bardziej złożone algorytmy (które o dziwo bardzo ciężko się poprawia w kodzie, a na kartce bardzo szybko widać błąd... przynajmniej ja tak mam).

W przypadku początkujących polecam inną metodę: nie projektować, siedzieć jak najwięcej nad kodem - na początku produkcje są na tyle proste że możemy sobie swobodnie eksperymentować w trakcie tworzenia.