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

Offline Shelim

  • Użytkownik
    • Homepage

# Październik 11, 2008, 22:53:07
Mam dość ciekawy problem organizacyjny z którym każdy z forumowiczów zetknął się przynajmniej raz (jestem o to dziwnie spokojny): 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)?

Wiele osób nie docenia pierwszego tysiąca linii programu. Wszystko co napiszemy (niezbędny rdzeń) będzie podwaliną pod resztę gry - jeżeli popełnimy drobny błąd projektowy, konsekwencje będą się za nami ciągnęły przez resztę przedsięwzięcia. A że refactoring jest często trudny, żmudny i nieprzyjemny, mało osób z tego korzysta. Konsekwencją jest produkt, który posiada klasy odpowiadające tylko za łatanie jakiegoś pozornie nieistotnego drobiazgu, który umknął w pierwszej fazie. Oczywiście, można zacząć 100 projektów, dojść do błędów i się nauczyć, ale nie o to chodzi - jak to ktoś na forum napisał: Najszybciej jest się uczyć na cudzych błędach. Pytanie pierwsze - jakie książki, metodologie, itp. poruszają temat projektowania aplikacji w jej początkowym stadium rozwoju?

Drugie pytanie jest czysto techniczne - co implementujecie jako pierwsze (rozważmy to - może niezbyt szczęśliwie - na przykładzie amatorskiego RPGa 2D)? Wiele osób popełnia klasyczny błąd i jako pierwsze implementuje menu. Po kilku(nastu) dniach kodzenia jedyne co mają, to kontrolki które w zasadzie nic nie robią. Zazwyczaj wtedy przychodzi zniechęcenie, bo w końcu "tyle kodzę, a efektów nie ma żadnych i nawet nie wiadomo że to będzie gra RPG. Równie dobrze mogą być wyścigi."
Drugim podejściem do zaczynania jest podejście techniczne. Zaczynamy od loggera, parsera, rdzenia, klas operujących na zasobach. Dużo nudnego pisania szkieletu, nie ma widocznych efektów. Tak samo jak wyżej, po pewnym czasie może przyjść zniechęcenie. Co jest jednak zaletą, to to, że doświadczony koder bez trudu uzyska środowisko do dalszej pracy. I będzie mu później łatwiej.
Trzecim podejściem jest złota zasada MCR. Ma Coś Robić. Zaczynamy od implementacji uproszczonego gameplayu, typu walka jeden na jeden z jakimś potworem. Potem dodajemy coś dalej. I jeszcze dalej. Rozwijamy to na zasadzie drzewa. Przewagą nad poprzednimi metodologiami jest fakt, że od razu widzimy efekty i nie zniechęcamy się tak łatwo. Wadą jest fakt, że powstaje w kodzie sieczka, którą po prostu ciężko jest później zarządzać.

Ze swojej strony dodam, że za jakiś czas postaram się zebrać i podsumować wyniki tej dyskusji w formie artykułu, który mógłby pomóc początkującym tak zaczynać, żeby skończyć :)

Offline Mr. Spam

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

Offline Mertruve

  • Użytkownik

# Październik 11, 2008, 22:58:35
1. Pomysł
2. ?
3. PROFIT!

Offline Oti

  • Użytkownik

# Październik 11, 2008, 23:10:24
Cytuj
Ze swojej strony dodam, że za jakiś czas postaram się zebrać i podsumować wyniki tej dyskusji w formie artykułu, który mógłby pomóc początkującym tak zaczynać, żeby skończyć
Hmm, IMHO do tego trzeba dojść samemu, na własnym doświadczeniu uczyć się jak zaczynać i jak kończyć(ja tak robię), wątpie, żeby jakiś artykuł miał jakoś specjalnie pomóc.

@topic
Ja kodzę wg. opcji nr 3. Właśnie o te efekty chodzi, ostatnio grę zacząłem od interfejsu. Rezultat? Po kilku dniach mi się znudziło i zabrałem się za projekt(opcja 3), który robię teraz i nic nie wskazuje na to, bym miał go rzucić(jedynie boje się, czy uda mi się rozwiązać parę problemów). Sieczki w kodzie nie zauważyłem, dla mnie jest przejrzysty, wszystko spakowanie w structy.

P.S. Jak zobaczyłem tytuł wątku, to myślałem, że znowu jakiś michu chce w punktach mieć wszystko podane  8)
« Ostatnia zmiana: Październik 11, 2008, 23:11:57 wysłana przez Oti »

Offline civis

  • Użytkownik

# Październik 11, 2008, 23:13:26
ja na ten przykład poświęcam tą godzinkę na podstawy/rdzeń/zmienne, by potem metodą trzecią iść do przodu. co jakiś czas należy robić "rewizję" kodu, i sprawdzać co można ułatwić, czy np już nie używane zmienne wywalić etc.

Offline menajev

  • Użytkownik
    • Karate Inowrocław

# Październik 11, 2008, 23:19:52
Ja zaczynam od skopiowania wszystkiego co zostaje po staremu z jakieś wcześniejszego projektu [czyli w sumie te wszystkie głupoty ustawiające OGL'a, klasa odpowiedzialna za wypisywanie tekstu, etc.], choć ostatnio zaczynam od tego, że - w szkole - rozpisuje sobie headery - a w domku, już na kompie, tylko przepisuje i biorę się za definicje.

niuteQ

  • Gość
# Październik 11, 2008, 23:28:04
Cytuj
Pytanie pierwsze - jakie książki, metodologie, itp. poruszają temat projektowania aplikacji w jej początkowym stadium rozwoju?
Książki nt. inżynierii oprogramowania, wzorców projektowych, języków programowania, takie jak Code Complete, Modern C++ Design i ogólnie -- http://wiki.warsztat.gd/Z_czego_si%C4%99_uczy%C4%87#Projektowanie. Strzelam, że niewiele tego znajdziesz w książkach traktujących stricte o tworzeniu gier.

Do takiego projektowania trzeba odpowiednio podejść według mnie. Gry, fakt, to są specyficzne programy, ale jednak nadal ogromne systemy informatyczne, a nie tylko kod+grafika+dźwięki.

Myślę, że to od czego zaczniesz nie ma znaczenia, i zależy tylko od Ciebie. Nie mniej pewne rzeczy i tak napisane być powinny, dlatego zawsze lepiej działać na gotowych frameworkach/engine'ach.

Offline Wyszo

  • Użytkownik

# Październik 11, 2008, 23:29:49
Mam dość ciekawy problem organizacyjny z którym każdy z forumowiczów zetknął się przynajmniej raz (jestem o to dziwnie spokojny): 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)?

Wiele osób nie docenia pierwszego tysiąca linii programu. Wszystko co napiszemy (niezbędny rdzeń) będzie podwaliną pod resztę gry - jeżeli popełnimy drobny błąd projektowy, konsekwencje będą się za nami ciągnęły przez resztę przedsięwzięcia. A że refactoring jest często trudny, żmudny i nieprzyjemny, mało osób z tego korzysta. Konsekwencją jest produkt, który posiada klasy odpowiadające tylko za łatanie jakiegoś pozornie nieistotnego drobiazgu, który umknął w pierwszej fazie.

No i słusznie nie docenia pierwszego tysiąca linii bo ile to zajmuje czasu? Tydzień roboty po kilka godzin dziennie. Pierwsze tysiąc linii to nigdy nie będzie jakiś wielki kod czy mega-skomplikowany algorytm, więc nie ma się co nim zbytnio przejmować :) Co do refactoringu - to prawda, że jest trudny, żmudny i nieprzyjemny, ale o wiele mniej przyjemnie jest korzystać z mało elastycznego kodu i pluć sobie w brodę, że nie zrobiliśmy tego wygodniej. Kiedy zauważymy, że coś jest źle, należy po prostu jak najszybciej to poprawić, bo inaczej zaobserwujemy efekt kaskadowy, kiedy poprawka w jednym elemencie interfejsu będzie wymagała poprawienia kodu w 20 miejscach, które z tego interfejsu korzystają. Zaznaczam tutaj, że im dokładniej zaplanujemy nasz kod - choćby w formie nabazgrolenia na kartce czegoś na wzór uproszczonego diagramu klas - tym mniej czasu zajmie refactoring.

Odpowiadając na dalszą część wiadomości - według mnie jeśli mówimy o małych projektach to zupełnie nie ma znaczenia od której strony zaczniemy (przy czym mały nie oznacza mikroskopijny - czyli do skończenia w tydzień czy dwa). Nawet jeśli zaczniemy robić grę od menu (czyli od d*** strony) to zrobienie tego menu nikomu nie zajmie więcej niż miesiąc (znów analogiczny szacunek tych kilku godzin dziennie). A jeśli zniechęcimy się i rzucimy w międzyczasie projekt? Jaka strata! Na potrzeby tego menu mamy jakiś prosty (lub wcale nie prosty) system GUI, a więc kod którego możemy użyć ponownie. W każdym razie najważniejsze jest to, żeby nie rzucać się od razu w wir kompilowania, tylko najpierw zawsze przemyśleć co chcemy zrobić i czy nie dałoby się tego przypadkiem zrobić lepiej (na przykład: zamiast usiąść i oprzeć grę na 'frame based movement' pomyśleć, że to podejście może mieć nieciekawe konsekwencje i zrobić ją na 'time based movement', potem zastanowic sie jaka klasa ma byc za to odpowiedzialna, jakie maja byc jej relacje z innymi klasami, rozrysowac sobie schemacik i dopiero usiasc do kompilatora).

Jak to się ma w dużych projektach? A skąd ja mam takie rzeczy wiedzieć :D

(co do poświęconego czasu: podałem jakiś przykładowy przelicznik, jeśli ktoś na przykład ma żonę, długo pracuje, ma mniej lub więcej wolnego czasu, nie programuje regularnie, etc. musi przemnożyć sobie podane wartości czasu przez odpowiedni współczynnik ;))

Offline yomyn

  • Użytkownik
    • yomyn::dev

# Październik 11, 2008, 23:35:14
Drugim podejściem do zaczynania jest podejście techniczne. Zaczynamy od loggera, parsera, rdzenia, klas operujących na zasobach. Dużo nudnego pisania szkieletu, nie ma widocznych efektów.
Ja wlasnie tak zaczynam. Mam wtedy pewnosc, ze jezeli to co chce zrobic nie wypali, moge to wykorzystac do innego projektu. A poza tym, jestem w tej sprawie troche inny, bo mnie kreci widok 2000 linii kodu ktore uruchamiaja konsole i wypisuja

Logger zainicjowany.
Wczytano plik config.dat
SDL i powierzchnia ekranu zainicjowane poprawnie.
Logger zamkniety.
.

Ostatnio nawet koledzy mieli ze mnie troche smiechu, jak zapytali sie co tam kodze, a ja opowiedzialem "po naszemu" co to jest (framework, parser, logger), a jak chceli dowiedziec sie co to robi takiego ciekawego to troszke sie zdziwili :P
Takze, lepiej, w moim mniemaniu, napisac sie raz a dobrze (a to czy ktos sie przy tym nudzi to jego sprawa) i potem korzystac z tego kodu przez bardzo dlugo, niz za kazdym razem pisac to samo.

btw. Przez Ciebie odpalilem projekt w ktorym mialem dosc zlosliwy blad z ktorym nie dawalem sobie rady i odziwo teraz zadzialal.
Karma ++ :)

-yomyn


« Ostatnia zmiana: Październik 11, 2008, 23:36:46 wysłana przez yomyn »

Offline Estelhof

  • Użytkownik

# Październik 11, 2008, 23:36:06
Jak zacząć grę?
- Jak najszybciej :P

A co do drugiego pytania
Drugie pytanie jest czysto techniczne - co implementujecie jako pierwsze
Sam zazwyczaj stosuję metodę pośrednią między 2. a 3. niestety ze wskazaniem na 3. Dlaczego niestety? Czasami brak solidnej podstawy(rdzenia) powoduje, że większość kodu to prowizorka, która w bliżej nieokreślonej przyszłości ma być przebudowana. Po jakimś czasie gdy wszystko się nawarstwi, a dodatkowo wyskoczy jakiś niespodziewany błąd można stracić naprawdę dużo czasu na znalezienie przyczyny w takim kodzie, potem często okazuje się, że połowa kodu wymaga przepisania (jak mój framework 2D :)). Jednak nie wszystko wychodzi tak źle :). Po zakończeniu pisania każdego wydzielonego modułu staram się porządkować kod, przede wszystkim pod względem przejrzystości, tak aby krótkie(jak najkrótsze) spojrzenie wystarczyło by odnaleźć interesujący fragment kodu. Nie skupianie się tylko na szkielecie, ale także na stopniowej implementacji podstawowego gameplaya podwyższa morale OFC. IMO takie połączenie tych sposobów 2. i 3. odpowiednio wyważone i poparte dobrym etapem projektowym to chyba jeden z lepszych pomysłow na tworzenie oprogramowania.
A że refactoring jest często trudny, żmudny i nieprzyjemny, mało osób z tego korzysta.
Dobrze powiedziane często, ale nie zawsze, bo czasami (zwłaszcza robiony na małą skalę na jakimś kluczowym kawałku kodu) potrafi być bardzo przyjemną częścią kodzenia. Przynajmniej dla mnie :)

Offline civis

  • Użytkownik

# Październik 11, 2008, 23:45:35
Cytat: Estelhof
Jak zacząć grę?
- Jak najszybciej :P
a słomiany zapał? rzucasz sie do IDE, piszesz pierwsze komendy, a potem nie wiesz co dalej, i trzeba sie cofać, i myśleć co i jak.

Estelhof: chodziło mi o zbyt pochopne rzucanie się do pisania, bo jak powszechnie wiadomo, od tego niestety wiele amatorów zaczyna. z projektowaniem jest już lepiej, bo zawsze z design doca można zrobić opowiadanie  :D
« Ostatnia zmiana: Październik 12, 2008, 00:01:44 wysłana przez ciVis »

Offline Estelhof

  • Użytkownik

# Październik 11, 2008, 23:52:04
Cytat: Estelhof
Jak zacząć grę?
- Jak najszybciej :P
a słomiany zapał? rzucasz sie do IDE, piszesz pierwsze komendy, a potem nie wiesz co dalej, i trzeba sie cofać, i myśleć co i jak.
Zależy co Ty rozumiesz przez zaczynanie gry :D Najpierw jest faza określania wymagań potem na tej podstawie projektowanie (gdzie dajemy się ponieść emocjom ;D) To chyba też zaczynanie gry :) I wtedy nie ma potrzeby cofać się i myśleć co i jak (przynajmniej nie powinno być :))

Offline Dab

  • Redaktor
    • blog

# Październik 12, 2008, 00:09:21
Mam dość ciekawy problem organizacyjny z którym każdy z forumowiczów zetknął się przynajmniej raz (jestem o to dziwnie spokojny): 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)?

Jak to w jaki? Kupić wypasiony silnik, zatrudnić artystów i zagonić ich do pracy, hehehe. ;)

A podejście "na żywioł" nie jest złe, jeżeli stawiamy na rozwój a nie na napisanie gry. Napiszemy fajne GUI -- spoko, ważne, żeby można było użyć go w innym projekcie. Następnym razem napiszemy coś co fajnie wykorzystuje silnik fizyczny (a gry znowu nie będzie)? Nie ma problemu, niech któryś z następnych projektów będzie integracją wszystkich poprzednich projektów -- i wtedy będziemy mieli podwaliny by wrócić do punktu 1 (wypasiony silniczek) i możemy zacząć szukać grafików. :)

Oczywiście można miesiącami ciągnąć fazę projektowania ale jeżeli i tak efektem końcowym będzie coś w rodzaju "Polish Farmer Snake W Konsoli" to szybciej da radę to klepnąć "z palca" niż dziergać DD, mazać setki diagramów UML, robić badania rynku, prototypować, etc etc
« Ostatnia zmiana: Październik 12, 2008, 00:11:25 wysłana przez Dab »

Offline artpoz

  • Użytkownik
    • blog o tworzeniu gier

# Październik 12, 2008, 00:09:51
Ze swojej strony dodam, że za jakiś czas postaram się zebrać i podsumować wyniki tej dyskusji w formie artykułu, który mógłby pomóc początkującym tak zaczynać, żeby skończyć :)

Polecam cykl artykułów pt: "Jak kończyć projekty?" autorstwa Rega. (WARP 2.0 Digital nr 09, 10, 11)

Pozdrawiam
artpoz

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Październik 12, 2008, 00:13:19
Cytuj
Wiele osób nie docenia pierwszego tysiąca linii programu. Wszystko co napiszemy (niezbędny rdzeń) będzie podwaliną pod resztę gry - jeżeli popełnimy drobny błąd projektowy, konsekwencje będą się za nami ciągnęły przez resztę przedsięwzięcia. A że refactoring jest często trudny, żmudny i nieprzyjemny, mało osób z tego korzysta.
Trudne, żmudne i nieprzyjemne to jest projektowanie, a potem dalej korzystanie z kodu, dla którego okazało się, że o czymś jednak w projekcie zapomnieliśmy. Jako że człowiek jest istotą omylną, nie ma co się bać przerzucać i większych partii kodu na bieżąco, bo najczęściej wtedy to są jeszcze drobne poprawki. :)

Cytuj
Pytanie pierwsze - jakie książki, metodologie, itp. poruszają temat projektowania aplikacji w jej początkowym stadium rozwoju?
Extreme Programming porusza właściwie cały proces. :)

Cytuj
Drugie pytanie jest czysto techniczne - co implementujecie jako pierwsze
Część odpowiedzialną za grafikę, a później gameplay, a więc według zasady MCR. Właściwie sposób implementacji wskazywałby raczej na to, że to jest prototyp, ale biorąc pod uwagę późniejszy refactoring w razie potrzeby i to, że w amatorskich projektach daleko poza prototyp wychodzić nie trzeba, to jest to zupełnie wystarczające. :)

Cytuj
Zaczynamy od loggera, parsera, rdzenia, klas operujących na zasobach.
Że co? Wszystko powyższe można olać i skupić się na pisaniu gry, a nie różnych dziwacznych rzeczy, których istnienia gracz nawet nie zauważy. Logować wiele nie musimy, więc można się oprzeć na dobrych starych message boxach i assertach w razie błędów, do parsowania też wiele nie mamy (w razie czego jest sscanf i istream), za rdzeń wystarczy klasyczna pętla komunikatów, a zasoby można wczytać na starcie wszystkie. Może to jest robienie na odwal, ale ile roboty odpada, a gracz i tak nic nie zauważy. :)

Cytuj
Wadą jest fakt, że powstaje w kodzie sieczka, którą po prostu ciężko jest później zarządzać.
I wtedy odpalamy procedurę refactoringu:
1. Zastanawiamy się, co nas najbardziej wkurza w obecnej architekturze kodu.
2. Zmieniamy to tak, żeby już nas nie wkurzało (albo żeby wkurzało mniej, zależnie ile mamy czasu).
3. Jeżeli coś nas jeszcze wkurza, wróć do punktu 1.

No i po chwili kod jest piękny, czysty i pachnący. W praktyce zauważyłem, że znacznie łatwiej i szybciej jest poprawić tak sobie zaprojektowany kod, niż go dobrze zaprojektować. :)


Co do samego projektowania, to nie zauważyłem, żeby występowało ono u mnie w jakimś nadmiernym stopniu. Co najwyżej przemyślę, jak ma wyglądać interfejs jakiegoś modułu, czy poukładam sobie w głowie trochę kodu, ale większość decyzji projektowych jest wynikiem potrzeby, a nie przewidywania. W razie czego zawsze jest refactoring i nie boję się przerzucić połowy renderera, jeżeli czuję, że to mi się opłaci. :)


Cytuj
Napiszemy fajne GUI -- spoko, ważne, żeby można było użyć go w innym projekcie.
Użyć można zawsze. Pytanie tylko jak wielki refactoring będzie potrzebny. ;)

Offline Haxy.M

  • Użytkownik

# Październik 12, 2008, 01:48:03
Osobiście coś pomiędzy 2-3. Zaczyna, od rzeczy najprostrzych, najbardziej oczywistych. Przykładowo, jeśli bym pisał wspomnianego rpga zacząłbym od klasy postaci i przedmiotu, od jakiś wstępnych założeń jak powinna wyglądać rozgrywka i co chcę tak naprawdę napisać. Do tego staram się pisać od samego początku "solidnie". Jeśli są potrzebne poprawki, to na ogół robię drobnymi krokami, tak by naraz poprawiać w 3-4 miejscach, bo wymiana połowy kodu, to już lepiej napisac od początku wogóle (co też się czasami trafia :-\ )