Projektowanie gier

[Liosan]

@głos: a mógłbyś podać jakieś namiary na ten przedmiot? Najlepiej miejsce gdzie są slajdy w sieci, ale nazwa też byłaby fajna

Z tego co w tym semestrze robiłem na uczelni, wydaje mi się, że lekkie metodologie dużo bardziej nadają się do tworzenia gier. Miałem okazję współpracować przy projektowaniu gry w uproszczonym RUP i to był koszmar (masa dokumentów, do których i tak pewnie bym nie zaglądał).

Też miałem okazję i też był koszmar. I co gorsza, zostawiło to ślad na psychice - mam alergię na pisanie rzeczy ograniczających i/lub niedoprecyzowanych w dokumentacji, wykraczającą daleko poza granice zdrowego rozsądku... przynajmniej w dziedzinie tworzenia gier. Taka "fobia" przy wysyłaniu oferty do klienta to może być przydatna rzecz, ale co ma piernik do wiatraka.

Liosan

[głos]

Jak każda (no może z wyjątkiem kierunków poświęconych grom) wykładana metodyka nie mówi ona o grach komputerowych. W mojej ocenie (z tego co pamiętam nie padła nazwa, ale może umknęło mi to) jest to zmodyfikowany (uproszczony i co ważne dostosowany do praktyki -> wykładowca ma własną firmę realizującą projekty informatyczne i wielotetnie doświadczenie) RUP. Na uczelni wykładana była w odniesieniu do baz danych.
Metodyka ta generowała masę dokumentów ale tworzyły one spójną całość (nie mając danych z wcześniejszego kroku nie mogliśmy przejść do kroku nastepnego) i w razie wątpliwości dokumenty te były jedyną podstawą do której się sięgało.
Z tego co wiem to w sieci nie były publikowane materiały.

W przypadku gier należałoby nie bezmyślnie ją stosować tylko adaptować na potrzeby gier.
Czyli twórczo rozwinąć Ale analogie projekt gry <-> projekt aplikacji powiedzmy biznesowej są widoczne  jak na dłoni ( przynajmniej dla mnie). To że każdy krok przetwarza w przypadku gier trochę inne dane to szczegół.

mały OT: Widzę że na IGK 2009 jest ciekawy obszar tematyczny "Nowoczesne metody i technologie projektowania gier" coś w sam raz jak znalazł.

[Esidar]

wykładowca ma własną firmę realizującą projekty informatyczne i wielotetnie doświadczenie

Czyli jak rozumiem ten wykładowca siedzi non-stop na uczelni a nie w firmie ? I jego teoria polega na tym aby "raz zaprojektować na 2 lata do przodu a potem mieć nadzieje że się uda bo muszę siedzieć na uczelni" ?

O róznych metodach można sobie poczytać chociażby na gamasutrze:
http://www.gamasutra.com/view/feature/2742/paper_burns_game_design_with_.php
http://www.gamasutra.com/view/feature/3677/introducing_scrum_at_large_animal_.php

[Angru]

Ja znam jeden  wykładany na Politechnice Wrocławskiej i co ważne sprawdzony w praktyce.

Przykro mi stary ale nie ma jednego słusznego podejścia do projektowania oprogramowania. Pewnie wystarczy jedno by zdać konkretny przedmiot u konkretnego wykładowcy, ale w rzeczywistych projektach które mają zdefiniowane deadline'y, budżet i są obciążone polityką firmy nie ma jednego idealnego procesu. Dlaczego niby jest tyle kontrowersji wokół RUPu, Agile'a, EUPu i innych metodologii?

Tymczasem zgadzam się z Riddlemasterem, RUP w przypadku małego zespołu piszącego grę jest stanowczo zbyt ciężki (około połowa czasu spędzona na dokumentowaniu) i oparty na przewidywaniu. Jeżli upieramy się przy wyborze procesu, skłaniałbym do czegoś w stronę Agile czy programowania ekstremalnego. Z jednej strony ze względu na dynamikę zmian w pomysłach dotyczących funkcjonalności gry, a z drugiej z uwagi na fakt, że wczesne efekty podnoszą morale zespołu.

[bananu7]

A z moich doświadczeń wynika, że dobrze jest mieć spisany projekt przed faktycznym rozpoczęciem prac. Metoda szybkich prototypów sprawdza się przy małych projektach, ale jeśli chcemy napisać coś na poważnie, program powinien być zbudowany z klocków, które możemy przestawiać, dodawać i zabierać. To samo dotyczy projektu, pozwalając mu dynamicznie zmieniać się w zależności od sytuacji.
W amatorskim tworzeniu gier, gdy ludzie pracują za darmo, brak projektu jest katastrofą, gdyż każdy zgłasza swoje uwagi i wydaje mu się, że skoro pracuje przy projekcie, ma pełne prawo decydowania o tym, co w nim będzie. Poza tym napisanie projektu oszczędza czas potrzebny na tłumaczenie każdej nowej osobie założeń gry ...

[Madlok]

Mógłby ktoś wypisać najogólniej te wszystkie obiekty w przykładowej grze? Czy jest sens tworzyć obiekt "gracz" albo "AI"? Czy cały świat/mapa jako obiekt to dobry pomysł? Czy jest coś takiego jak obiekt "gra" albo "rysowanie po ekranie"?
Dla najprostszej gry typu łażenie chłopkiem po jakimś terenie.

[sobol]

Ja znam jeden  wykładany na Politechnice Wrocławskiej i co ważne sprawdzony w praktyce.

Skoro znasz jeden, a wypowiadasz się jak alfa i omega w temacie, to się po prostu ośmieszasz.

wykładowca ma własną firmę realizującą projekty informatyczne i wielotetnie doświadczenie

Taaa, wszechwiedzący wykładowca wymyślił jedyne słuszne rozwiązanie

Z Twoich wszystkich wypowiedzi razem wziętych wynikają dwie rzeczy - po pierwsze masz blade pojęcie o inżynierii oprogramowania jako takiej, w dodatku cała Twoja wiedza opiera się na teorii, zero praktyki. Po drugie nie masz żadnego pojęcia o procesie powstawania gier. Bez urazy, takie wnioski wysnuwam bo przeczytaniu tego, co napisałeś.

Co do samego tematu - najlepiej to opisał Esidar IMO, gry powstają iteracyjnie, iteracje powinny być krótkie, a cały projekt na tyle elastyczny, żeby w każdym momencie można było wprowadzić (często bardzo duże) zmiany. Gra powinna też powstawać tak, żeby jak najszybciej można było rozpocząć proces testowania, a o tym chyba nikt z was nie wspomniał
Ogólnie uważam, że wiedza z zakresu inżynierii oprogramowania może się przydać w gamedevie, ale raczej trudno jest zaprzęgnąć jakąś "sprawdzoną" metodologię ze względu na specyfikę dziedziny.

<edit>

Mógłby ktoś wypisać najogólniej te wszystkie obiekty w przykładowej grze? Czy jest sens tworzyć obiekt "gracz" albo "AI"? Czy cały świat/mapa jako obiekt to dobry pomysł? Czy jest coś takiego jak obiekt "gra" albo "rysowanie po ekranie"?
Dla najprostszej gry typu łażenie chłopkiem po jakimś terenie.

Nie ma jedynego słusznego sposobu Jest sens tworzyć obiekt gracz, jeśli jest Ci on potrzebny, tak samo każdy inny obiekt, który sobie wymyślisz. Każda gra jest zbudowana inaczej. Na dobrą sprawę, nawet nie musisz pisać obiektowo - popatrz na kody Q2/3.

[Vipa]

Ale dyskusja co najmniej bez sensu. Zaprojektować i zrealizować projekt można bazując na konkretnych stałych danych. Jeżeli program ma przedstawiać zjawisko fizyczne, które jest potwierdzone i wprowadzone, równocześnie brak wymagań dotyczących wizualizacji, to może się udać jakimś utartym schematem, aczkolwiek i tak założę się iż będą zmiany odnośnie sposobu przedstawienia wyniku .

Projekt gry owszem jest ważny, ale tak samo ważna jest łatwość jego dostosowania do aktualnych wymagań. Inaczej gry powstające parę lat w ogóle by nie istniały, a nawet jeśli to były by to gnioty kompletnie nie wpasowujące się w wymagania graczy.
Tak jak pisał Esidar: niekiedy trzeba zmienić podejście o 180 stopni i to bardzo szybko. Dlatego nie ma sensu spędzać tygodni i miesięcy nad projektowaniem. Trzeba to zrobić szybko i bezboleśnie.

[gits]

A mnie one nie śmieszą. Tym bardziej, że zawodowo zajmuję się wytwarzaniem oprogramowanie (...) trudno jest udokumentować życzenia klienta.

To czego się nauczyłeś w biznesowym pisaniu, możesz zapomnieć bo gry to zupełnie co inna dziedzina Tutaj nie ma klienta. Tutaj nikt ci nie powie czego chce. Klientów są potencjalne setki, tysiące, i każdy chce czegoś innego.

Jak projektuje się gry komputerowe? Zarówno w fazie planowanie, zbierania wymagań jak i innych etapach prac.

Masz pomysł i go realizujesz. Koniec. Nikt ci nie powie że dobrze robisz albo "kto jakie ma wymaania". Gry projektujesz tak jak TY tego chcesz i sam musisz dokonywać wyborów co jest lepsze. Co więcej sam musisz być odbiorcą i sam musisz wiedzieć czy coś ci wyszło.

Nie zaprzątaj sobie też głowy UML, projektowaniem itd. Statystycznie 20% oryginalnego pomysłu pozostaje w finalnym produkcie. Coś co jest fajne na papierze okazuje się totalną klapą w grze. Najważniejsze to umieć szybko wykonywac prototypy i nie bać się zmian o 180 stopni.

Podoba mi się to co napisałeś. Tak to wygląda. Kiedyś jeszcze widziałem statystyki mówiące, że 75% gier nie zostaje ukończonych i wydanych. Nie wiem ile w tym prawdy.

[Asmodeusz]

A nie lepiej działać zgodnie z zasadą hierarchizacji projekt-wykonanie? W jednej dużej firmie (nazwy nie chcę podawać) zajmującej się tworzeniem dużej aplikacji multimedialnej (prawie jak gra) podejście było następujące: zespół składający się z projektantów-testerów przygotowywał dokładny (włącznie z "co dana metoda ma robić") projekt z timeline, podziałem obowiązków itd. Programiści siadali i przepisywali go na język zrozumiały dla komputera. Po wykonaniu pierwszego (oznaczonego w projekcie) prototypu projektanci dostawali go w łapy, przeglądali, modyfikowali projekt i zestaw modyfikacji + timeline dla nich trafiał do programistów. Sądzę, że przy dobrej organizacji, w dużej firmie, przy silnym oddzieleniu projektantów od programistów i połączeniu funkcji projektowania z testami takie rozwiązanie ma prawo działać. W prywatnym pisaniu wprowadza odrobinę systematyczności i masę roboty

[JCoder]

A mnie one nie śmieszą. Tym bardziej, że zawodowo zajmuję się wytwarzaniem oprogramowanie (...) trudno jest udokumentować życzenia klienta.

To czego się nauczyłeś w biznesowym pisaniu, możesz zapomnieć bo gry to zupełnie co inna dziedzina Tutaj nie ma klienta. Tutaj nikt ci nie powie czego chce. Klientów są potencjalne setki, tysiące, i każdy chce czegoś innego.

Jak projektuje się gry komputerowe? Zarówno w fazie planowanie, zbierania wymagań jak i innych etapach prac.

Masz pomysł i go realizujesz. Koniec. Nikt ci nie powie że dobrze robisz albo "kto jakie ma wymaania". Gry projektujesz tak jak TY tego chcesz i sam musisz dokonywać wyborów co jest lepsze. Co więcej sam musisz być odbiorcą i sam musisz wiedzieć czy coś ci wyszło.

Nie zaprzątaj sobie też głowy UML, projektowaniem itd. Statystycznie 20% oryginalnego pomysłu pozostaje w finalnym produkcie. Coś co jest fajne na papierze okazuje się totalną klapą w grze. Najważniejsze to umieć szybko wykonywac prototypy i nie bać się zmian o 180 stopni.

Podoba mi się to co napisałeś. Tak to wygląda. Kiedyś jeszcze widziałem statystyki mówiące, że 75% gier nie zostaje ukończonych i wydanych. Nie wiem ile w tym prawdy.

Bo to dotyczy widać wszystkich projektów. Tych biznesowych projektowanych zgodnie z RUP i PRINCE2 też.
Przykładem takiego projektu zdaje się jest komputeryzacja ZUSu, system zarządzania studiami na Politechnice Wrocławskiej no i parę innych by się pewnie znalazło. Metodyki lekkie mają przynajmniej tę zaletę, że nawet jak się projekt wykopyrtnie to straty są mniejsze. Oszczędza się np. prąd, bo nie trzeba niszczyć 10 ton dokumentacji

Zmiany w projekcie są nieuniknione. Jeżeli nie ma zmian, to znaczy, że projekt nie jest nikomu potrzebny.
Co nie oznacza, że projektowanie nie jest potrzebne. Ale raczej robi się to w trakcie pisania kodu, a nie przed. Jak masz dobrego architekta / projektanta, to zmiany nie są tak bolesne. W przypadku wymagających gier jest nieco trudniej, bo optymalizacja często psuje strukturę kodu i uniemożliwia stosowanie wysokopoziomowych języków.