Autor Wątek: Opis mechaniki gry - by programista miał lżej  (Przeczytany 1199 razy)

Offline setaneiro

  • Użytkownik

# Październik 23, 2010, 19:10:01
Dłubiąc ostatnio przy swoim projekcie zdałem sobie sprawę z pewnego problemu. Przeszukując dokument opisujący mechanikę gry, doszedłem do wniosku... że nie do końca wiem jak ją opisać. Kwestią, która mnie męczy, jest "głębia" opisu działania danego mechanizmu dla programisty, który na podstawie tego zakoduje go. Bo chyba sztuką jest tak opisać działanie gry tak, by projektant i programista byli zadowoleni.

Jaki ten opis, teoretycznie, powinien być?
Niepodważalnym i zrozumiałym faktem jest, że projektant powinien mieć choćby podstawową i ogólną wiedzę nt. programowania. I teraz opisując kolejne mechanizmy gry zastanawiam się ile w tym opisie ma być "suchego", niezależnego od opinii programisty tekstu, mówiącego wprost jak ów mechanizm ma działać (i proponując jakieś rozwiązanie), a ile ma być samego pomysłu.
Lepiej wprost opisać koderowi co i jak ma robić, czy opisując zawrzeć tylko najważniejszą ideę i pozostawić programującej to osobie wolne pole do działania?
Jak bardzo dokument z mechaniką gry ma być tekstem "technicznym", a jak bardzo raczej typową "opisówką" mechanizmów?

Offline Mr. Spam

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

Offline Xirdus

  • Moderator

# Październik 23, 2010, 21:27:17
Ja bym zrobił opis tego, jak dany mechanizm przetwarza dane, czyli jaki jest efekt końcowy (co funkcja zmienia), jakie przyjmuje dane i jak one wpływają na wynik, jakich innych mechanizmów będzie używać itp. Ale mnie się nie słuchaj, nigdy czegoś takiego nie robiłem.

Offline intoxicate

  • Użytkownik
    • Jak zrobic gre FPP

# Październik 25, 2010, 18:07:27
Cytuj
Jak bardzo dokument z mechaniką gry ma być tekstem "technicznym", a jak bardzo raczej typową "opisówką" mechanizmów?
UML, tabelki, opisu minimum.

Offline MadBonsai

  • Użytkownik
    • Ifrit

# Październik 25, 2010, 20:46:56
Dokumentacja powstaje razem z projektem albo... okazuję się, że wcale tej dokumentacji za wiele nie trzeba. Nie sil się na zbyt szczegółowy opis, jeśli sam kiepsko ogarniesz te szczegóły ;) Poza tym detale ciągle się zmieniają.
Programista ma rozumieć, o co ci chodzi. Co jest ważne, a coś mało istotnym pomysłem spod prysznica. Ma mieć materiał do roboty. W zasadzie to cała filozofia.
Reszta zależy od projektu, zespołu i sposobu komunikacji :)

Offline yarpen

  • Użytkownik

# Październik 26, 2010, 21:13:25
Moje doswiadczenie jest takie, ze nie ma znaczenia jak dobry jest opis -- i tak nie da sie tego zrobic bazujac jedynie na tym. Dlatego wole 3 zdania opisujace z grubsza system i rozmowe z dezajnerem (wyjasnienie poczatkowych watpliwosci), szybki prototyp + pozniejsze zmiany robione wspolnie. Na pewno nie ma sensu plodzic zbyt skomplikowanych dokumentow, bo to tylko zmarnowana praca. Dodatkowa zaleta podejscia bardziej praktycznego jest taka, ze ogranicza troche swawole dezajnerow i sklania ich do wybierania sensowniejszych rozwiazan (pierwszy system ekonomii w Wiedzminie, tworzony na zasadzie -- najpierw teoria na 10 stron, pozniej kodowanie nie nadawal sie do niczego).