Autor Wątek: Ma ktoś przepis na dokończenie gry?  (Przeczytany 4996 razy)

Offline gothicgirl

  • Użytkownik

# Kwiecień 21, 2010, 15:31:31
Witam.
Chciałabym was się zapytać
czy macie jakiś przepis na dokończenie gry.

Nie mówię tutaj od strony technicznej jakie API, tylko od raczej strony psychicznej człowieka :D.

Sobie przypuśćmy ustalam już:

Ze ta gra będzie jakimś np. dress-up girl.
Wybieram już odpowiednie api typu: OpenGL, SFML i takie tam.
Piszę już tą gre, tworzę te frameworki, które tam mają swoją liste objektów które wyswietla i takie tam.
Gra już jest w 50% skończona.

A potem następuje taki czas ze zwalniasz prace nad tym, i sobie myślisz:
- Grafika jakaś słaba, staram się ją poprawiać.
- Trochę więcej roboty z różnymi objektami niż myślałam.
- Patrzy się na konkurencyjne gry, i chce się dołożyć więcej możliwości, i się to robi, kolejne wydłużenie czasu produkcji.
- Jakiś błąd, poprawiam. Następny tez poprawiam itp.
- Praca coraz wolniej idzie, zniechęcenie coraz bardziej bierze górę.
- Postanawia się odpocząć od tego na jakieś kilka dni, by zebrać myśli, i pomyśleć jak wszystko dokończyć.
- Mija jakiś czas, z moją krótką pamięcią, coraz bardziej zaczynam się tracić we własnym kodzie.
- Zapomina się do czego jaką zmienną napisałam i jak się ona nazywała.
- Kod zaczyna być coraz bardziej zagmatwany, coraz więcej procedur, i sama się w tym trace, wiecznie szukanie jednej rzeczy...
- ... tak jakby słomiany zapał.

... w końcu sobie myślę, echhh .... i na tym się kończy!
Potem postanawiam od nowa to napisać, tym razem
próbuje kod zaprojektować tak by się w nim nie pogubić, widocznie robię coś nie tak czy coś?
A potem znowu zaczyna ten kod się paskudzić, i gmatwać.

Jak do tego mam podejść?
Zaprojektować sobie jakiś schemat najpierw?
jak ma ten kod wyglądać, jakie klasy? może zaprojektować najpierw w UML, a potem przelać na kod?

Jeśli wiecie o czym pisze, to ma ktoś jakiś przepis na to?
« Ostatnia zmiana: Kwiecień 21, 2010, 15:33:31 wysłana przez gothicgirl »

Offline Mr. Spam

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

Offline Troll

  • Użytkownik
    • Oficjalna strona gry Gizarma

# Kwiecień 21, 2010, 15:33:29
przepisu na ukończenie projektu nie ma, są tylko metody które zwiększają prawdopodobieństwo jego ukończenia

Offline Vx-x.

  • Użytkownik
    • Vx-x. Page

# Kwiecień 21, 2010, 15:36:37
Nazywaj zmienne tak, żeby po ich nazwie było wiadomo co robią (nie jakieś "zmntmpd2"), do każdej klasy trzymaj pliki NazwaKlasy.hpp i NazwaKlasy.cpp, nie wpychaj jakieś funkcji na siłę do innego pliku (bo akurat muszę jej szybko użyć), używaj wcięć i komentarzy. Oddziel logikę od grafiki. I nie rób listy TODO na 3 kartki, bo już na połowie pierwszej braknie Ci zapału. Napisz jedną rzecz - jak działa - bierz się za następną. Ja przynajmniej tak robię.

A co do błędów w kodzie -> nie martw się, wszystkich wkurzają tak samo jak Ciebie.
« Ostatnia zmiana: Kwiecień 21, 2010, 15:40:15 wysłana przez Vx-x. »

# Kwiecień 21, 2010, 16:18:49
Kiedyś na interview pytali mnie czy przed rozpoczęciem pisania rozrysowuje sobie schemat architektury na kartce, i jestem pewien, że sporo straciłem odpowiadając, że nie. Ale projektowanie na kartce/UML nie jest dla każdego. Gdybym musiał sobie rozpisywać coś co powinienem mieć w wyobraźni to ... chyba bym musiał przestać programować. Co mi to da że zobaczę coś na kartce jeśli nie mogę ogarnąć całości w głowie? Ponadto to jakiś mit, albo po prostu złe podejście żeby traktować architekturę/interfejsy jako coś prawie niezmiennego, co można z góry przewidzieć. Dlatego nie tylko lekceważę UML, ale też nie stosuje plików nagłówkowych w C++.
Co mi pomaga?:
1.  Bardzo długie rozważania nad dodaniem choćby linijki kodu. Zwykle kombinuje jak mogę żeby jak najmniej napisać, stosuje szablony, biblioteki zewnętrzne.
2. Pisanie top-down i back-to-start. Nie traci się z pola widzenia celu, który się chce osiągnąć.
3. Tworzenie klas, których obiekty nie podlegają zmianom po utworzeniu czyli nie zawierają publicznych pól i metod, które nie są const. Klasa jest tu snapshotem jakiegoś stanu - jak potrzeba zmodyfikowanego stanu to się robi nowy obiekt. Łatwiej się utrzymuje porządek, debuguje i przy okazji można poczynić pewne sztuczki optymalizacyjne korzystając z faktu, że obiekty są niezmienne. Oczywiście przez utworzenie obiektu rozumiem wywołanie konstruktora - wszelkie metody "inititalize()" odpadają.
4. Inspirowanie się STLem czy "Modern C++ Design: Generic Programming and Design Patterns Applied".

Offline Lipek Samo Zło

  • Użytkownik

# Kwiecień 21, 2010, 16:26:05
Z tym UML'em jest tak, że nawet jak zaprojektujesz sobie grę doskonale (w Twoim przekonaniu) to i tak na ogół coś trzeba zmienić, dlatego ja staram się projektować tylko dosyć ogólny prototyp, po czym wraz z kodem projektuję On The Fly. Projektowanie daje mi to, że po spojrzeniu na diagram od razu widzę które elementy mojego kodu są do poprawy (np gdzie muszę uniknąć "sterowania przepływem").
Mnie ostatnio motywuje również prowadzenie dev-loga (takiego dla mnie w który piszę co dziś zrobiłem i co robić będę jutro).

# Kwiecień 21, 2010, 16:49:49
Jako że nic odkrywczego (poza namiętnym korzystaniem z kartki i długopisu) do powiedzenia nie mam, polecę tylko pewien artykuł Reg'a.

Offline zxc

  • Użytkownik

# Kwiecień 21, 2010, 18:25:42
Moim zdaniem patrzysz od złej strony.

Pokazuj grę ludziom, do których jest adresowana. Pisanie gier wymaga pasji, ale nie robisz tego tylko dla siebie, a również dla graczy.  To gracza czas masz zagospodarować swoją grą. Pokaż grę komuś i zobacz jak reaguje. Będziesz naturalnie zawiedziona, ale również zobaczysz co działa, a co nie działa. To jest kontakt z rzeczywistością, którego potrzebuje każdy projekt. Z takiej sesji testowania będziesz miała serię wniosków, które będziesz chciała przenieść do gry i zobaczyć jak gra radzi sobie po zmianach. Tak wygląda prawdziwa praca nad grą, kod jest tylko środkiem do celu. Nie przejmuj się nim zanadto. Prawdziwy problem to zrobić grę, która będzie interesującym sposobem na spędzenie czasu.

Od technicznej strony, myślę, że przy prostej przebierance powinien wystarczyć system stanów gry: stanem gry jest każda plansza menu i ekran gameplay'a itp., a zarządza nimi menedżer stanów. Wykonuje krok symulacji aktywnego stanu i przekazuje do niego input, natomiast rysowane są wszystkie stany, oznaczone jako widoczne. W ten sposób możesz łatwo robić przejścia między poszczególnymi planszami, a kod ich zawartości jest ładnie oddzielony. Obok menedżera stanów jest menedżer zasobów, który zajmuje się wczytywaniem grafik, obiektów i dźwięków, do których odwołać się może każdy stan.

Zapewne miałabyś planszę menu i wyboru/stworzenia profilu, planszę opcji, planszę odznak, planszę wyboru laleczki, planszę customizowania laleczki z różnymi wariantami wyglądu części ciała, planszę z zakładaniem i zdejmowaniem ubrań, planszę z nakładaniem makijażu, planszę z wybiegiem czy krytyką koleżanek w szkole. Wszystkie te plansze dziedziczyłyby po stanie gry i jeśli jesteś w możesz połapać się w kodzie odpowiadającym za jedną z tych rzeczy, to dzięki podziałowi na stany gry jesteś w stanie połapać się we wszystkich, bo kod jest ładnie oddzielony. Do tego potrzebujesz napisać porządną klasę lalki, która będzie zawierała aktualne ubrania i aktualny makijaż i do obiektu aktywnej lalki u aktywnego użytkownika odwoływać się będą wszystkie te stany gry. To byłby moim zdaniem dobry grunt, na którym relatywnie łatwo będzie zapanować nad bałaganem. Szybkie hacki wciąż będziesz mogła stosować, ale nie będą się tak dramatycznie odbijały na całości kodu.

Mam nadzieję, że nie piszę zbytnich oczywistości i jakoś to będzie pomocne. Było to pomocne dla mnie, kiedy byłem w - patrząc z opisu - podobnej sytuacji. Przede wszystkim pokazuj swoją pracę ludziom, do których ją adresujesz - sadzaj ich przed komputerem, nic nie tłumacz i zobacz co robią. Jeśli czegoś nie rozumieją, to musisz to zmienić, żeby było zrozumiałe. Jeśli nie bawią się dobrze, to musisz zrozumieć dlaczego. Obserwacja ludzi bawiących się (lub - częściej - nie bawiących się wcale...) przy twojej grze to jest pouczające doświadczenie, którego nie można przecenić i również umiejętność znacznie ważniejsza niż tworzenie "ładnego" kodu.

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Kwiecień 21, 2010, 18:52:10
a zarządza nimi menedżer stanów. Wykonuje krok symulacji aktywnego stanu i przekazuje do niego input, natomiast rysowane są wszystkie stany, oznaczone jako widoczne. W ten sposób możesz łatwo robić przejścia między poszczególnymi planszami, a kod ich zawartości jest ładnie oddzielony. Obok menedżera stanów jest menedżer zasobów,
Zapomniałeś o menadżerach menadżerów i nadrzędnego menadżera menadżerów. :)

Offline siso

  • Użytkownik

# Kwiecień 21, 2010, 18:58:12
Zapomniałeś o menadżerach menadżerów i nadrzędnego menadżera menadżerów. :)
Overdesign nigdy nie był tym, co tygrysy lubią najbardziej, ale sama idea zarządzania czymś centralnie nie jest wcale taka zła ;)

Offline Oijadt

  • Użytkownik

# Kwiecień 21, 2010, 19:10:34
1. trzymasz sie timeline'u i tworzysz to co zaplanowalas.
2. dodatkowe rzeczy , ktore wymyslasz w trakcie, zapisujesz i robisz na koncu.
3. jesli feature wymaga duzej zmiany nie robisz go.
4. grafike poprawiasz na koncu.
5. zapierasz sie aby nie poddac sie przy najblizszej okazji ;)

edit: no i nie wolno zaczynac od poczatku!

« Ostatnia zmiana: Kwiecień 21, 2010, 19:29:51 wysłana przez Oijadt »

Offline zxc

  • Użytkownik

# Kwiecień 21, 2010, 19:14:52
a zarządza nimi menedżer stanów. Wykonuje krok symulacji aktywnego stanu i przekazuje do niego input, natomiast rysowane są wszystkie stany, oznaczone jako widoczne. W ten sposób możesz łatwo robić przejścia między poszczególnymi planszami, a kod ich zawartości jest ładnie oddzielony. Obok menedżera stanów jest menedżer zasobów,
Zapomniałeś o menadżerach menadżerów i nadrzędnego menadżera menadżerów. :)
Nie mówię jak to zrobić, żeby nie wyglądało śmiesznie dla kogoś kto chce się pośmiać, tylko jak to zrobić, żeby działało i było wygodne. Nie znam lepszego sposobu. Ciebie chyba aktywowało samo słowo "menedżer" i w takiej sytuacji nie wiem jak ci pomóc. Spróbuj może zrobić coś takiego samemu? Najlepiej bez użycia słów, które zaburzają twoją koncentrację.

Offline głos

  • Użytkownik

# Kwiecień 21, 2010, 19:43:22
gothicgirl, tekst z życia wzięty :)

Z powyższych wypowiedzi podpisałbym się tylko pod tym cyt. "Pokazuj grę ludziom"

Po prostu nie piszesz gry tylko silnik dla tej gry i stąd zniechęcenie.
Żeby pisać silnik trzeba wiedzieć jak go pisać, wykazać dużo samozaparcia, jeszcze więcej determianacji oraz mieć dużo, dużo, ... i jeszcze więcej :) wolnego czasu bo nauka metodą prób i błędów zajmuje lata.

Stąd rada jest prosta weź gotowe narzędzie, jedno, drugie, trzecie .... Spróbuj wykonać prototyp gry,
zobacz które z tych narzędzi (silników) najbardziej Tobie odpowiada.
Wtedy zobaczysz jak wygląda gra a nie jej pisanie :), postępy będą motywowały i przy odrobinie dyscypliny i wiedzy ukończysz grę.

Offline Złośliwiec

  • Użytkownik
    • Dark Cult

# Kwiecień 21, 2010, 21:08:34
- Mija jakiś czas, z moją krótką pamięcią, coraz bardziej zaczynam się tracić we własnym kodzie.
- Zapomina się do czego jaką zmienną napisałam i jak się ona nazywała.
- Kod zaczyna być coraz bardziej zagmatwany, coraz więcej procedur, i sama się w tym trace, wiecznie szukanie jednej rzeczy...

Potrzebujesz po prostu refaktoringu. Wybierz jakiś kawałek kodu, który najbardziej cię wkurza - może to być plik, klasa, pojedyncza funkcja albo cały aspekt, np. obsługa klawiatury. I napraw ten fragment, tak aby stał się czytelniejszy, prostszy, bardziej elastyczny. Jeśli nic innego nie da się zrobić, napisz od nowa. Jeśli poświęcisz temu zajęciu odpowiednio dużo czasu w stosunku do "normalnego" programowania, problemy z zagmatwanym kodem zaczną powoli znikać.

Offline menajev

  • Użytkownik
    • Karate Inowrocław

# Kwiecień 21, 2010, 21:29:15
Z doświadczenia mniej odległogo niż bym chciał - jeśli chcesz skończyć grę, nie pozwól nikomu (nawet członkom swojego zespołu, sobie zresztą też nie) dodawać niczego do TODO.
Ustal sobie plan minimum funkcjonalności gry (czyli to, co MUSI być, żeby gra była grywalna) i dopiero po ich wykonaniu dodawaj mniej ważne rzeczy pokroju zmnieniających się pór dnia czy np. dziewczynę tańczącą na 16 różnych sposobów w zależności od tego, co się na nią założy (plan minimum - po prostu stoi). W przeciwnym wypadku spędzisz sporo czasu na dodawanie dupereli, a grywalne to wciąż nie będzie.

# Kwiecień 21, 2010, 22:19:42
Żeby ukończyć grę , trzeba:
1.Opanować język programowanie w 90%-95% , w którym się grę pisze
2.Dobrze zaprojektować i napisać co ma być w grze i jak ma wyglądać
3.Pisać częściami np. Render , fizykę  , a nie wszystko jednocześnie.
4.Wiedzieć co się umie , a co nie.
5.Zrobić dobry szkielet aplikacji (pliki nagłówkowe , oddzielne źródła)
Opisywać w komentarzach każdą ważniejszą lub globalną funkcję/klasę

I przede wszystkim stosować metodę małych kroczków.
Oraz testować funkcje na spreparowane dane , a nie od razu włączać w kod. To jest dość względne , i zależy od poziomu skomplikowania funkcji.
(jak opanujesz specyfikę języka , i nabierzesz doświadczenia , to można niekiedy od razu włączać nowe funkcje do projektu )

Takie zbiorowisko zrobiłem ,moich własnych przemyśleń , do których sam doszedłem w trakcie nauki c (c++ trochę też znam)