Autor Wątek: Jak przedstawić swój pomysł.  (Przeczytany 3798 razy)

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Styczeń 28, 2011, 02:40:03
Dzisiaj chciałbym poruszyć bardzo ważny temat. Mianowicie wiele osób przedstawia swoje wspaniałe pomysły na rozmaitych forach i blogach, co jest zjawiskiem pozytywnym. Jednakże zauważyłem pewne mniej lub bardziej poważne błędy popełniane przez przyszłe rzesze designerów. Postanowiłem więc przedstawić najczęściej spotykane błędy w opracowaniach waszych pomysłów oraz doradzić, jak podobnych sytuacji uniknąć na przyszłość.

1.1 Zbytnia rozwlekłość konceptu.

Dzisiejsi ludzie mają mało czasu, a brakuje go zwłaszcza producentom i wydawcom, czyli osobom na ocenie których zależy nam najbardziej. Im dłuższy i rozwleklejszy wstęp do pomysłu, tym większe prawdopodobieństwo, że wyląduje w kosztu, a na danym forum przeczyta go mniej ludzi. Pamiętajmy, że to nasz tekst jest dla ludzi, nie odwrotnie. Powodem nadmiernej rozwlekłości konceptu jest fakt, że przyszły designer chce od razu, na samym wstępie przedstawić wszystkie najlepsze cechy swojego pomysłu. W rzeczywistości jednak po prostu zasypuje odbiorcę masą tekstu. Ludzie oczekują krótkich i zwięzłych informacji na wstępie. Zadaniem konceptu nie jest przedstawienie każdego detalu mechaniki czy fabuły, lecz zainteresowanie odbiorcy do dalszej lektury. Piszemy więc najkrócej i jak najciekawiej, co najwyżej parę zdań nie wdając się w niepotrzebne szczegóły. To ma być jak dobry trailer, nie streszczenie szkolnego podręcznika. Jeżeli zainteresujemy odbiorcę, to sam chętnie przeczyta dalszą część, nawet gdyby było tego parę stron.

1.2 Brak usystematyzowania formy.

Część pomysłów, które widziałem było jednym, niesystematyzowanym pod względem treści blokiem tekstu. Oczywiście taka forma może być dobra, ale raczej do pomysłu na książkę niż grę. Jeżeli masz zamiar zostać pisarzem, to super, ale zaraz! Ty przecież zajmujesz się czymś innym. Postaram się wytłumaczyć to na znanym nam przykładzie. Gry są jak ogry- składają się z warstw. Teraz jeżeli już wszystko rozumiecie to mogę przejść dalej.

Żartowałem. Mówiąc, że gry składają się z warstw miałem na myśli dosłownie warstwy. Mianowicie jak sami z doświadczenia wiecie każda gra posiada warstwy, np. audiowizualną, fabularną, gameplay. Dlatego także i opis naszego pomysłu powinien być w podobny sposób ułożony. Rozdzielamy więc poszczególne elementy, osobno opisujemy wygląd, osobno mechanikę, fabułę tworząc w ten sposób usystematyzowany dokument.

1.3 Nadmierna szablonowość.

Tym razem jest to skręt w drugą stronę. Na forum warsztatu admini wrzucili szablon, mający na celu przykład jak powinno się spisywać pomysły. Niestety niektórzy wzięli to sobie dosłownie do serca i pisząc swój pomysł na grę wypełniali owy szablon niczym urzędowy formularz. Wprawdzie lepsze jest to niż kompletny nieład, ale wadą takiego podejścia jest sztywność formy. Moim zdaniem przyszły designer powinien używać swojej fantazji od samego początku, także spisując swój pomysł. Przecież forma prezentacji naszej koncepcji gry może być równie oryginalna jak sama gra! Stwórzcie własny „szablon”, elastyczny i wygodny. Jeżeli chcecie wyeksponować jakiś istotny element gry, to wrzućcie go na sam „wierzch”. Jeśli coś wymaga bardziej szczegółowego opisania, to stwórzcie dodatkowe podrzędne jednostki systematyczne. Powtarzające się elementy wyłączajcie „przed nawias”, dodajcie coś zabawnego i ciekawego.

1.4 Brak wiedzy o tworzeniu gier.

Wszyscy mamy niesamowite i oryginalne pomysły na grę każdego dnia, ale jeżeli chcemy się nimi podzielić z innymi, to powinniśmy zasięgnąć nieco wiedzy o tym jak powstają gry. Zwłaszcza kiedy staje się to naszą pasją. Oczywiście spisanie pomysłu w języku całkowicie laickim nie jest błędem, wiedza to rzecz nabyta, zawsze możemy się nauczyć czego trzeba. Jednak dobrze jest zdobyć przynajmniej podstawy, gdyż istotne jest, aby ludzie postrzegali nas jako osobę traktującą swoją pasję na poważnie. Nie musimy oczywiście wiedzieć co oznaczają terminy typu TDD, sprint plan, team status report, submission release. Ale takie podstawy jak target, assets, concept art powinniśmy rozumieć i używać ich w miarę potrzeby. Jeśli jesteś prawdziwym pasjonatem, to wcześniej czy później sam wejdziesz w bardziej szczegółowe zagadnienia dotyczące tworzenia gier. Warto jednak o tym pomyśleć i przeczytać kilka artykułów ludzi z branży, najwięcej znajdziesz na zagranicznych blogach, ale w Polsce przecież rynek gamedev jest też dobrze rozwinięty, więc i tu znajdziesz ciekawe blogi. Polecam poniższe polskie linki ogólnie traktujące o branży:

http://gamedev-pl.blogspot.com

http://andrzejkoloska.wordpress.com

No dobra, skoro już wiemy co robimy źle, to pora się dowiedzieć jak robić dobrze. Przedstawię więc mój „szablon”, który stworzyłem na potrzeby własnych pomysłów. Jest elastyczny i nowoczesny, na forum warsztatu pod jego kierunkiem nigdy nie padały negatywne uwagi, więc uważam go za całkiem udany.

2.1 Concept

Koncept jest najważniejszym elementem naszego pomysłu. On będzie czytany jako pierwszy, a że pierwsze wrażenie jest najważniejsze, to powinien być ciekawy, ale i krótki. Ja dzielę go na dwa elementy. Pierwszym jest High Concept, na który składa się tylko kilka słów, jedno krótkie zdanie. Jest czymś w rodzaju sloganu reklamowego, powinien być więc w miarę możliwości krótki, konkretny, intrygujący odbiorcę. Nie musi opisywać gry, ale niech nawiązuje do jej głównej idei, duszy gameplayu. To musi być coś mocnego, co zwraca uwagę, co intryguje. Przykładowo ja użyłem przy jednym z moich pomysłów „Be quick or be dead”. Odbiorca od razu wie, że chodzi o coś z czasem, że od tego zależy nasze życie. Jednocześnie tekst ten nawiązuje do utworu Iron Maiden, który wykorzystałem w prototypie, więc gracze, którzy są fanami tego zespołu na pewno zechcą sprawdzić co kryje się pod tym szyldem. Stworzenie fajnego high conceptu może być łatwe albo trudne, ale podrzucę dobrą radę. Starajcie się wymyślać coś, co będzie nawiązywało do zainteresowań targetu waszej gry. Może być to jakieś wydarzenie, zwrot, powiedzenie, coś co zwróci uwagę ludzi, którym chcemy sprzedać naszą grę. Jeżeli robisz grę muzyczną, to wrzuć słowa jakiejś piosenki, jeżeli sportową, to krótką wypowiedź znanego sportowca. Istotne, aby przekaz był czytelny, jednocześnie dobrze aby był nieostry, ciężko to wytłumaczyć, popracujecie nad tym sami, to szybo załapiecie o co chodzi.

Drugim elementem tego punktu jest właściwy Concept, czyli kilka zdań o tym, czym właściwie jest nasza gra. Niekoniecznie musi być to lista wszystkiego, co wymyśliłeś. Chodzi o to, żeby zainteresować odbiorcę, przykład:

Cytuj
    W Dark Fear światło będzie naszym jedynym przyjacielem. Wcielamy się w anonimowego bohatera, który budzi się w opustoszałym szpitalu, nagle gasną światła, gdzieś w oddali słychać jęki, a my mamy tylko latarkę i policyjnego Walthera P99. Zapraszam do dalszej lektury.

Jak widać, jest tego niewiele, ale napisane w taki sposób, aby nie wyjaśniać zbyt wiele. Czytelnik jeżeli chce się dowiedzieć jakie niebezpieczeństwo kryje się w tym szpitalu, to zapewne przeczyta dalszą część pomysłu.

2.2 Target

Target dla producentów i wydawców jest synonimem docelowej grupy odbiorców danej gry. Jest to jeden z krytycznych punktów, które należy ując w opisie. Gra musi być skierowana do kogoś, nawet takie masówki jak WoW mają swój target. Im bardziej szczegółowo opiszemy docelową grupę graczy tym lepiej. Ma to znaczenie nie tylko dla wydawcy, ale także jest dla nas podpowiedzią w czasie tworzenia gry. Nie wypada wrzucać makabrycznych scen kaźni w grze dla kobiet, to samo działa w drugą stronę. W strzelane gdzie mordujemy setki ludzi wrzucenie przesłodzonego HUDa poskutkuje odruchem wymiotnym u panów. Zamieszczając każdy element musimy pamiętać o zainteresowaniach i możliwościach naszego targetu. Każdy powie, że to przecież podstawowa wiedza, ale spotykam się czasem z  grami dla młodszych dzieci, gdzie pojawiają się zbyt trudne dla nich zręcznościowe elementy. Przykład opisu targetu:

Cytuj
    Jako, że gra daje poczucie władzy i dominacji nad otoczeniem, to skierowana jest w dużej mierze do mężczyzn. Grupa wiekowa takiej gry waha się w przedziale 16~30, choć nie ma tu sztywnej reguły. W większości będzie to przeciętny przedstawiciel klasy średniej, chcący poczuć odrobinę władzy, której w normalnym życiu raczej nie uświadczy.

2.3 Players

Niekoniecznie jest to istotny punkt naszego opisu, ale powinien się w nim znaleźć jeżeli gra będzie zawierała jakieś elementy multi. Można w skrócie napisać, że dostępny będzie tryb taki a taki (tu odesłanie do opisu gameplayu dla multi znajdującego się gdzieś dalej) dla np. 2 albo 4 graczy. Przykład:

Cytuj
    Jest to gra dla jednego gracza, nie ma opcji multi, choć najciekawsze budowle będzie można eksportować i dzielić się nimi z innymi graczami.

2.4 Rules

Zasady są wszędzie, kierują one naszym postępowaniem, bez nich społeczeństwo nie mogłoby istnieć. Najbardziej znanym zbiorem zasad jest prawo (a właściwie to reguł, w prawoznawstwie zasada ≠ reguła). Podobnie jest w grach, tam też obowiązują pewne zasady bez których granie byłoby niemożliwie. Powinniśmy jasno określić, kiedy gracz przegrywa, kiedy wygrywa, co może zrobić a czego nie. Oczywiście nie musimy się wdawać w kazuistykę, opisujemy tylko najważniejsze i najbardziej istotne zasady. Przykład:

Cytuj
    Naszym celem jest pokonanie złego bossa i uratowanie kobiety. Niestety na drodze znajdziemy wiele przeszkód, które przyjdzie nam pokonać. Zetknięcie się z wrogiem powoduje śmierć. Biorąc jednak pod uwagę poziom trudności, znajdziemy wiele checkpointów, które pozwolą się zregenerować po śmierci. Ilość żyć jest nielimitowana.

2.5 Character development

Umieszczenie tego punktu zależy głównie od rodzaju gry, jeżeli tworzymy grę, gdzie nasz bohater się w jakiś sposób rozwija, to powinniśmy zawrzeć taki punkt w naszym opisie. Character development oznacza w devowym świecie rozwój protagonisty. Powinniśmy napisać więc, w jaki sposób rozwijamy bohatera naszego gracza. Czy będzie sam podnosił pewne umiejętności, czy może gracz będzie miał na to jakiś wpływ. Jeżeli tak, to jaki? Napisz najistotniejsze elementy rozwoju, jeżeli jest oparty o jakąś konkretną mechanikę, to pokrótce opisz ją. Przykład:

Cytuj
    Na samym początku jesteśmy drobnym bożkiem, jednak wykonując questy i/lub pokonując wrogich wyznawców zdobywamy doświadczenie i manę. Doświadczenie pozwoli nam wybrać kolejne moce z drzewka rozwoju skilli, w ten sposób nasz bożek rozwija się w określonym kierunku zyskując na potędze. Do wyboru mamy różnorakie moce, może to być ciskanie piorunami, fireball’ami, zsyłanie plag, itp. Część mocy jednak nie służy do walki, lecz przekształcania terenu, gdyż nie od razu będziemy mogli góry przesuwać.

2.6 Gameplay

To najważniejszy punkt naszego pomysłu, bowiem gry mogą nie posiadać rozwoju postaci, trybu multi, ale każda ma jakiś gameplay. Pod tym obcojęzycznym określeniem kryje się po prostu rozgrywka, czyli to co dzieje się na ekranie. Musimy opisać przecież jak nasza gra będzie działała, jak się będzie w nią grało. Nie ma jednolitego sposobu opisywania gameplayu, gdyż każda gra jest inna. Jeżeli naszym pomysłem jest gra w układanie puzzli, to piszemy jak przesuwa się puzzle, jak pracuje kamera, czy to jest 2D a może 3D. Oczywiście jeżeli chcemy, to kwestie natury technicznej możemy ująć w osobnym punkcie, ale oprawa audiowizualna może być jak najbardziej zawarta tutaj. Pamiętajcie tylko o tym, co mówiłem na początku, każda gra jest inna i każda potrzebuje innego opisu. Czasem może się zdarzyć, że będziemy musieli ująć gameplay w kilku podjednostkach systematycznych aby klarownie przedstawić nasze koncepcje. Natomiast przy innej grze jeden punkt całkowicie wystarczy do wyjaśnienia podstawowych kwestii dotyczących zabawy. Przykład:

Cytuj
    Wprawdzie nasz bohater może się poruszać o własnych siłach, ale większość map będzie nas zmuszała do „płynięcia”, gdyż są ustawione pod kątem, przez co nasz Flowb „zsuwa się” w dół, po prostu płynie. Możemy zmieniać kierunek (prawo, lewo) by uniknąć przeszkód, a nawet obracać całą mapą w obie strony co 90 stopni, gdyż obrócenie mapy w wielu przypadkach będzie wymagane do uniknięcia danej przeszkody. Często (prawie zawsze) rozgrywa będzie dynamiczna, więc obrót o dowolny kąt całkowicie się nie sprawdzi i tylko utrudni zabawę. Grawitacja zawsze działa w dół, więc obrót spowoduje „spłynięcie” Flowba zgodnie z przyciąganiem po obróceniu mapy. Przyda się to na przykład w jednej z map, gdzie będziemy szybko płynąć w popękanej rurce, musimy tam obracać mapę tak, by opadać na ściankę w której aktualnie nie ma dziury.

    Na każdej mapie będą miejsca, w których będziemy mogli zmienić stan skupienia Flowba, o ile posiadamy daną zdolność. Jest to wymagane, gdyż czasem trzeba się rozpędzić do wyskoczni albo użyć katapulty, wtedy przydaje się zmiana w lód. Znajdzie się też przykładowo miejsce, gdzie trzeba będzie zmienić się w parę, by potem wpaść w strumień powietrza, który poniesie nas nad przepaścią.

2.7 Outcome

Nasz pomysł zapewne posiada element nagrody dla gracza, aby utrzymać jego zainteresowanie. Może być to lepszy sprzęt do wyżynania wrogów albo intrygująca fabuła, która z czasem się wyjaśnia. W świecie twórców gier, element nagradzania nazywa się Outcome. Dlatego też powinniśmy w tym punkcie wyszczególnić to, co będzie zachętą do dalszego eksplorowania naszej gry. Czasem może być to coś, z czego nie zdajemy sobie na pierwszy rzut oka sprawy, np. w Diablo nagrodą za przechodzenie poziomów był duży wzrost mocy. Dzięki temu mogliśmy siać jeszcze większą masakrę w szeregach wrogów i widzieliśmy jak nasz bohater przeradza się z wymoczka w prawdziwego kozaka. Przykład:

Cytuj
    Nagrodą za przechodzenie poziomów będą rozsiane po mapach punkty, których użycie sprawi wiele frajdy, na przykład gdy porwie nas strumień powietrza i będziemy bardzo szybko i dynamicznie przemieszczać się przez mapę. Czasem znajdzie się skocznia, gdzie po zmianie w lód będziemy mogli się rozpędzić (mniejsze tarcie == większa prędkość) i wyskoczyć wysoko nad urwiskiem jak Adam Małysz.
    To nie wszystko. Na każdej mapie znajdują się bonusowe miejsca, w których możemy znaleźć dodatkowe żetony, by potem wydać je zmieniając wygląd Flowb’a. Jednak aby się do nich dostać potrzebne będzie odrobinę sprytu i zdolności, gdyż każda mapka wymaga wykorzystania wszystkich zdolności by dostać się do każdego bonusowego miejsca.

2.8 HUD

Jeżeli wygląd HUD (Head-Up Display czyli takie elementy jak pasek życia, ikonki skilli, jakiś radar) ma znaczenie, to możemy go zawrzeć w tym punkcie. Nie jest to coś istotnego, więc nie trzeba się specjalnie przejmować, jeżeli nasz pomysł nie obejmuje takich detali. Informacje o tym najlepiej przedstawić w formie graficznej. Łapiemy więc za GIMP (albo Photoshopa jeżeli nas stać) i rysujemy poszczególne elementy. W ten sposób od razu widać co jak wygląda i gdzie leży, podczas kiedy zwykłe opisywanie zajęłoby pół strony.

Na sam koniec możecie zawrzeć punkt z pytaniami i odpowiedziami. Jeżeli przewidujemy, że czytelnik pewnie zapyta o jakiś element, to w ostatnim punkcie zapisujemy odpowiedź na takie pytanie. To jest coś w rodzaju FAQ, czyli pytania które prawdopodobnie mogą się pojawić i odpowiedzi na nie. Tak więc moi drodzy to wszystko na dzisiaj, mam nadzieję, że moje wypociny chociaż trochę ułatwią wam przedstawianie wspaniałych pomysłów w nie mniej ciekawej formie. Pamiętajcie o tym, że można dodać jakieś zabawne rzeczy do opisu, zwłaszcza kiedy gra ma być śmieszna. Miejcie również na uwadze fakt, iż nie istnieje uniwersalny wzór, który pasowałby do każdego pomysłu. Przedstawiłem tylko luźną propozycję, dlatego nie wrzuciłem gotowca, lecz punkt po punkcie tłumaczyłem co jest najistotniejsze. Do każdego pomysły sami powinniście ułożyć sobie formę prezentacji, która będzie najbardziej odpowiednia. Powodzenia!

Tekst dostępny również na moim nowo powstającym blogu:
http://inwriter.wordpress.com/2011/01/28/jak-przedstawic-swoj-pomysl/
« Ostatnia zmiana: Styczeń 28, 2011, 02:41:41 wysłana przez Lamer »

Offline Mr. Spam

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

Offline siso

  • Użytkownik

# Styczeń 28, 2011, 22:31:58
2011-01-28 21:08:34 [FATAL ERROR] Text too long; Hint: try to shorten your idea description and re-post it.
Caused by: org.live.cognition.SmartIdeaException
    at gd.warsztat.forum.reader.PostReader.read(NicePostReader.nl:67)
    at gd.warsztat.forum.browser.TopicViewer.viewTopic(InterestingTopicViewer.nl:78)
    at org.live.sparetimekiller.BoredomHandler.handle(DefaultBoredomHandler.nl:143)
    at org.live.daytime.StandardLoop.tick(StandardLoop.nl:314).


Error explanation:
Cytuj
Dzisiejsi ludzie mają mało czasu, a brakuje go zwłaszcza producentom i wydawcom, czyli osobom na ocenie których zależy nam najbardziej. Im dłuższy i rozwleklejszy wstęp do pomysłu, tym większe prawdopodobieństwo, że wyląduje w kosztu, a na danym forum przeczyta go mniej ludzi. Pamiętajmy, że to nasz tekst jest dla ludzi, nie odwrotnie. Powodem nadmiernej rozwlekłości konceptu jest fakt, że przyszły designer chce od razu, na samym wstępie przedstawić wszystkie najlepsze cechy swojego pomysłu. W rzeczywistości jednak po prostu zasypuje odbiorcę masą tekstu. Ludzie oczekują krótkich i zwięzłych informacji na wstępie.

//edit: minor refactoring
« Ostatnia zmiana: Styczeń 28, 2011, 22:46:48 wysłana przez siso »

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Styczeń 29, 2011, 02:30:42
Chodzi o jakiś błąd na blogu? Niedawno go założyłem, aczkolwiek na wordpress.com nie powinno być problemu, oni to hostingują. WP nigdy mi nie sprawiał takiego problemu na moim hostingu, nie wiem o co chodzi.

bs.mechanik

  • Gość
# Styczeń 29, 2011, 03:51:39
Chodzi o to, ze tego jest tyle, ze nikomu nie bedzie sie tego chcialo czytac.

Offline Vipa

  • Redaktor

# Styczeń 29, 2011, 11:02:38
Mi się chciało :). Parę uwag mam:

Warsztatowy szablon jest/był dla twórców gier. Owszem, ci także grają, ale nie chodzi o zachętę do grania tylko o przedstawienie pomysłu twórcom. Historyjki o tym, jak trzeba uratować księżniczkę mało ich obchodzą i oczekują realiów gry. Zwróć uwagę, że na tym forum bardziej niż arcyciekawa fabuła interesuje podejście do aspektów technicznych. W końcu to szablon rekrutacyjny a nie zachęta do testów bety.
Brak wiedzy o tworzeniu gier to problem przy ogłoszeniach. Nawet nie chodzi o wiedzę, tylko o pamięć jak gry potrafią ewoluować. Ktoś kto od trzech lat gra w WoW przedtem grając mało, nie opisze dobrze gry Arkanoid, bo stwierdzi (i tutaj test dla wszystkich):
  - ale co ja mam tu napisać? Odbijamy deską kulkę w klocki i tyle.
I właśnie tutaj tkwi problem. Ale o wężu na komórkę można było nawijać 5 lat temu przez godzinę? Można było ;).
Ogólne pojęcie kiedyś, na początku, było takie: każda gra polega na wciśnięciu fire w określonym miejscu na ekranie w określonym momencie. Koniec. Oczywiście teraz nie każdy ma fire :). Ale to się nie zmieniło, chodzi o to by wydobyć to co chcemy przekazać, rozwinąć opisem te cechy, które stanowią o rozgrywce w opisywanej konkretnie naszej grze czy naszym pomyśle. Co odróżnia Worms Armageddon od Worms? To trzeba wydobyć, opisać i potem streścić.

Zasady rozgrywki:
Cytuj
Naszym celem jest pokonanie złego bossa i uratowanie kobiety. Niestety na drodze znajdziemy wiele przeszkód, które przyjdzie nam pokonać. Zetknięcie się z wrogiem powoduje śmierć. Biorąc jednak pod uwagę poziom trudności, znajdziemy wiele checkpointów, które pozwolą się zregenerować po śmierci. Ilość żyć jest nielimitowana.
Tu zrobiłeś miszmasz. Pogubiłem się czy opisujesz to dla wydawcy, graczy czy dla innych twórców. "Niestety na drodze..." jest dla graczy, dla wszystkich innych jest to "stety" :). Aha, życie jest jedno. chyba, że robisz grę o kotach lub grę dla maniaków jakiejkolwiek formy reinkarnacji.

Target... Oczywiście każdy produkt (nie zapominaj, że gra to produkt - nie uciecha, [niestety]) posiada swój główny target. Od niego uzależniony jest gameplay, warstwa audiowizualna ale także np. instrukcja. Jednakże zwróć uwagę ile gier trafia w 100%. Target trzeba teraz "zbudować" przez zachowania marketingowe i social.
Tutaj przedstawiasz koncept, który wyznacza target. Trochę na odwrót. Gry robi się na określone zapotrzebowanie. Chyba, że robisz grę dla idei i sam masz z tego fun.

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Styczeń 29, 2011, 14:33:57
Dzięki za komentarz Vipa. Ogólnie to pisałem to dla początkujących ludzi. Detalami dotyczącymi prawideł tego rynku jakich jest wiele nie chciałem więc już nikomu mącić. Czytałem teksty różnych ludzi z branży, każdy widzi to trochę inaczej, ale generalnie kwestią jak przekuć czyjś pomysł na grywalną grę przygotowaną pod konkretnego targeta zajmuje się producent. Pisałem z punktu widzenia garażowego designu, a nie marketingu czy zarządzania, więc dla większości ludzi powinno wystarczyć.

Offline Mendrek

  • Użytkownik

# Luty 07, 2011, 00:43:14
Trochę mam wrażenie, że to porady dla takiego "game designera od wszystkiego". W zasadzie obowiązki game designerów powinny być podzielone pomiędzy story tellerów, level designerów, lead'ów, ect. Niemniej znając realia, to dzisiaj gd-ek musi po prostu być "człowiekiem orkiestrą", i projektując pomysł na grę uwzględniać wiele aspektów rozgrywki, w tym takich w których niekoniecznie jest dobry (np. niekoniecznie musi mieć rozwiniętą kreatywność przestrzenną, bo jest scenarzystą, ect. ). Jednak porady są dobre, a na dodatek takich tu jak na lekarstwo. Zresztą już sobie z paru rzeczy skorzystałem ;)

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Luty 07, 2011, 01:59:15
Dzisiejszy designer powinien być najlepiej One-Man-Army, zwłaszcza w świecie, gdzie sporo growego rynku trzymane jest przez drobnych developerów indie za sprawą PSS, App Store czy Steam, gdyż taki sposób dystrybucji cieszy się coraz większą popularnością. W małych teamach nie ma podziału na vision designerów, story designerów, mechanic... itd. Jeżeli jest jakiś koleś od projektowania i pomysłów to jest zazwyczaj jedna osoba która ogarnia wszystko od tekstów po fabułę i mechanikę. Ja przykładowo pomimo tego, iż interesuje mnie jedynie kwestia designu, to nauczyłem się programowania, modelowania, animacji, opanowałem też najpopularniejsze edytory misji/poziomów oraz frameworki (Flash, Unity, trochę UDK) w których trzaskam własne projekty. Osobiście uważam, że wiedzy nigdy za wiele zwłaszcza dla kogoś, kto zajmuje się projektowaniem.

Offline Mendrek

  • Użytkownik

# Luty 08, 2011, 21:07:26
No do małych projektów to bardziej nacisk kładziony jest trochę inaczej w pracy, i faktycznie nie trzeba dzielić od razu designerów. Jednak w dużych projektach to raczej ciężko byłoby jednemu gd-kowi wszystko ogarnąć. Chociaż ja brałem udział w pewnym dosyć amatorskim (nieskończonym, niestety) projekcie, i większość swego zaangażowania skupiałem na tworzeniu scenariusza i otoczki, a później w mniejszym stopniu tworzyłem wizję gameplay'u, i nie musiałem posiadać jakiejś niezwykłej wiedzy programistycznej czy graficznej. Od tego byli inni ludzi i cały myk polega na tym, by można było się jakoś porozumiewać na zasadzie "ja mam swój język, Ty masz swój, ale umiemy się dogadać". Ofkoz zgodzę się że im więcej wiedzy tym łatwiej jest gd-kowi i pracować i pracę zdobyć, ale też nie straszyłbym ludzi że muszą nagle pochłonąć wszystkie kategorie żeby w ogóle zacząć tworzyć projekty.
« Ostatnia zmiana: Luty 08, 2011, 21:09:40 wysłana przez Mendrek »

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Luty 09, 2011, 00:15:36
Wiesz, dobrze gadasz. Z designerem jest trochę jak z kierowcą. Nie musi się znać na mechanice, ale jeżeli tą wiedzę posiada, to jest mu znacznie łatwiej. Siedząc za kierownicą wie lepiej jakie są ograniczenia i możliwości silnika, skrzyni biegów czy innych układów i potrafi lepiej wykorzystać swój samochód. W serwisie lepiej sprecyzuje problem specjalistom, a w salonie nie nabiją go tak łatwo w bambuko.

Offline really

  • Użytkownik

# Luty 09, 2011, 01:29:41
Myślę, że to porównanie nie jest do końca trafne. Kierowca ma dojechać do celu wykorzystując gotowy samochód. Designer musi zaprojektować nowy model pojazdu w taki sposób, żeby ładnie wyglądał, był wygodny, jednocześnie mając na uwadze ograniczenia stawiane przez zastosowane wewnątrz "bebechy".;)

Offline setaneiro

  • Użytkownik

# Luty 10, 2011, 20:39:45
Chociaż ja brałem udział w pewnym dosyć amatorskim (nieskończonym, niestety) projekcie, i większość swego zaangażowania skupiałem na tworzeniu scenariusza i otoczki, a później w mniejszym stopniu tworzyłem wizję gameplay'u, i nie musiałem posiadać jakiejś niezwykłej wiedzy programistycznej czy graficznej. Od tego byli inni ludzi i cały myk polega na tym, by można było się jakoś porozumiewać na zasadzie "ja mam swój język, Ty masz swój, ale umiemy się dogadać".
Jakoś mnie nie przekonuje, że fakt tworzenia treści przed formą przyniósł coś dobrego. Jeśli gameplay, czy jego poglądowa wizja, nie powstał przed scenariuszem lub choćby nie był tworzony w trakcie, to jak dla mnie jest to błądzeniem w miejscu. Gra to akurat takie medium, w którym jest ważniejsza jest mechanik niż treść. Jak dla mnie oczywiście. I co ważniejsze nie wyklucza ten pogląd możliwości wsadzenia w tą mechanikę jakiejś über głębokiej fabuły.
Cytuj
Ofkoz zgodzę się że im więcej wiedzy tym łatwiej jest gd-kowi i pracować i pracę zdobyć, ale też nie straszyłbym ludzi że muszą nagle pochłonąć wszystkie kategorie żeby w ogóle zacząć tworzyć projekty.
Prawda, ale jak wyobrażasz sobie takiego projektanta próbującego przekazać swoją wizję np programiście? Mów co chcesz, ale żeby zrobić cokolwiek produktywnego i wartego uwagi trzeba coś umieć. Tak jak z krowy byka nie zrobisz, tak i nie każdy wymyślający własnego MMO jest projektantem.. ;)

Offline Mendrek

  • Użytkownik

# Luty 10, 2011, 21:10:15
Jakoś mnie nie przekonuje, że fakt tworzenia treści przed formą przyniósł coś dobrego. Jeśli gameplay, czy jego poglądowa wizja, nie powstał przed scenariuszem lub choćby nie był tworzony w trakcie, to jak dla mnie jest to błądzeniem w miejscu. Gra to akurat takie medium, w którym jest ważniejsza jest mechanik niż treść. Jak dla mnie oczywiście. I co ważniejsze nie wyklucza ten pogląd możliwości wsadzenia w tą mechanikę jakiejś über głębokiej fabuły.

Tylko częściowo się zgodzę. Pewne koncepty mogą spokojnie powstawać zupełnie obok mechaniki. Jasne, gra musi mieć już jakaś formę, wizję - ale takie rzeczy jak dialogi, bieg fabuły, opisy mogą być tworzone wcześniej. I owszem, to jak miał wyglądać gameplay powstało wcześniej, aczkolwiek gra była na tyle charakterystyczna, że pewne rzeczy mogły być dorabiane później ;) Zgodzę się co do priorytetu mechaniki - w końcu gra z natury rzeczy polega na graniu.

Prawda, ale jak wyobrażasz sobie takiego projektanta próbującego przekazać swoją wizję np programiście? Mów co chcesz, ale żeby zrobić cokolwiek produktywnego i wartego uwagi trzeba coś umieć. Tak jak z krowy byka nie zrobisz, tak i nie każdy wymyślający własnego MMO jest projektantem.. ;)

Taki projektant musi być świadomy (lub uświadamiany ;) ) co jest mniej więcej możliwe do wykonania. Tworząc grę na handheld'y, lub posiadając średnio wykwalifikowaną kadrę, nie można sobie wyobrażać wizji grafiki czy muzyki jak przy Square-Enix czy Capcom, lecz wymaganie od projektanta niesamowitej wiedzy programistycznej to chyba zbyt brutalne. Dajmy artystom pozostać artystami.

Offline Lamer

  • Użytkownik
    • www.inwriter.wordpress.com

# Luty 11, 2011, 00:33:37
Projektant gier nie jest artystą od tego trzeba zacząć. Tym mianem można nazwać scenarzystę filmowego, concept artist, muzyka, ale nie projektanta. Designer musi znać się na kwestiach technicznych, musi to ogarniać bo tę wiedzę będzie wykorzystywał. Nie wyobrażam sobie designera, który nie zna się na sprawach technicznych, jego rozmowa z programistami to byłby istne kalambury. Traciliby czas, czyli najcenniejszy surowiec w napiętych sprintach. Uważam, że projektant także powinien znać się na kwestiach technicznych, mówi wtedy jasno, że tu potrzeba RimLighting z normalką, a tam efekt DOF. Też kiedyś myślałem, że designer to tylko pomysły i teksty pisze, ale jest trochę inaczej. Oczywiście nikt nie będzie wymagał pisania algorytmów neuronowych, ale prostą gierkę powinieneś być w stanie spłodzić przy użyciu jakiegoś API.