Jako klient, próbujący przekonać programistę / programistę do rozwinięcia moich pomysłów w działający program, co powinienem przekazać moim programistom?


45

Jestem dyrektorem grupy zajmującej się tworzeniem gier dla początkujących (mówię „grupa”, ponieważ nie jest to jeszcze oficjalna firma). Niedawno zyskałem chęć kilku programistów, którzy są gotowi pomóc mi w projekcie, ale proszą o dokumentację.

Rozumiem potrzebę dokumentacji i mam wiele naszych pomysłów w kilku różnych dokumentach, ale wyobrażam sobie, że będę chciał zorganizować ją w taki sposób, aby programiści mogli zrozumieć zarówno indywidualnie, jak i zbiorowo.

Czy jest coś, co powinienem pominąć w takim dokumencie; jeśli tak, jakie rzeczy? Czy istnieje odpowiedni szablon dla tego rodzaju dokumentów; jeśli tak, gdzie mogę to znaleźć? Czy jest coś jeszcze, co powinienem wiedzieć, aby zaoferować programistom, zanim zaczną pracę?

Wiem, że zadawano mi tutaj wiele pytań. Mam nadzieję, że to nie problem. Z góry dziękuję za wszelkie wskazówki!


5
Liz England wygłosiła dobry mikrotalk na GDC 2016 na temat dokumentacji, którą można wykonać , dostosowując dokumentację projektu gry do różnych odbiorców , z odniesieniami do innych przydatnych źródeł.
DMGregory

Jako programista (który w rzeczywistości tworzy grę) mogę powiedzieć, że chciałbym mieć cały zeszyt ze szczegółowymi statystykami. Ale równie łatwo byłoby mi użyć zdania wyjaśniającego cel, dane demograficzne do celu i platformę do stworzenia dokładnie tej samej gry wideo.
Programy Redwolf,

Odpowiedzi:


47

Tworzenie gier zwykle działa nieco inaczej niż tworzenie aplikacji. Powodem jest to, że gry mają zwykle o wiele mniej rygorystyczne wymagania. Nie masz dobrze zdefiniowanego problemu biznesowego, który oprogramowanie ma rozwiązać. Jedynymi prawdziwymi wymaganiami gry są: „działa poprawnie na docelowej platformie”, „odwołuje się do docelowej grupy demograficznej” i „jest fajnie się gra” (a być może „sprzedaje dużo mikrotransakcji”, jeśli jesteś w tej sekcji branży ). Wszystko inne może ulec zmianie podczas rozwoju.

Aby jednak upewnić się, że wszyscy twórcy gry pracują w tym samym kierunku i nie kończą na śmierć z powodu różnic twórczych, powinieneś mieć jakąś skodyfikowaną „wizję” tego, jak chcesz, aby gra wyglądała i grała w nią . Ta wizja jest zwykle skodyfikowana w dokumencie dotyczącym projektu gry . Taki dokument zwykle opisuje:

  • Podstawowa zasada gry:
    • Wabik : Głównym gra pomysł, opisany jako krótko, jak to możliwe.
    • Jaki jest gatunek tej gry?
    • Kto jest twoim docelowym demograficznym?
    • Na które platformy kierujesz reklamy?
  • Mechanika gry:
    • Jakie działania może wykonać gracz w tej grze i jak wpływają na grę?
    • Jakie byty niezwiązane z grą są w grze, jak się zachowują i jak współdziałają ze sobą i z graczem?
  • Zakres:
    • Jaką zawartość chcesz mieć w grze?
    • Jaki poziom jakości ma mieć ta zawartość?
  • Kierunek estetyczny gry:
    • Jaką ogólną atmosferę chcesz mieć w grze?
    • Jak chcesz, aby gra wyglądała?
    • Jak chcesz, aby gra brzmiała?
  • Jeśli chodzi o historię, wiele zależy od gatunku. Niektóre gry nie wymagają żadnej historii. Wiele gier wymaga tylko kilku zdań. Ale jeśli tworzysz grę fabularną, taką jak RPG lub przygoda, może to być najdłuższa część dokumentu projektowego i może obejmować:
    • Opis świata, w którym rozgrywa się gra, i jej kluczowych lokalizacji
    • Opis ważnych postaci, ich wyglądu, osobowości i historii
    • Podstawowy zarys fabuły opowiadany podczas gry

Jeśli rozglądasz się po Internecie, możesz znaleźć wiele szablonów dokumentów projektowych gier. Branża gier zajmuje się znacznie mniej formalnościami i znormalizowanymi procesami niż reszta branży, więc nie znajdziesz jednego standardu ISO, który rządziłby nimi wszystkimi. Po prostu spróbuj znaleźć jeden styl, który pasuje do Twojego projektu, Twojego zespołu i metodologii pracy.

Bądź jednak otwarty na zmiany podczas rozwoju. Gdy dokumenty dotyczące projektowania popularnych gier wyciekają do społeczeństwa, umyślnie lub nieumyślnie, zwykle można zauważyć coś interesującego. Jeśli porównasz te wczesne uwagi projektowe do ukończonej gry, zwykle będzie wiele znaczących różnic. Zwykle jest to wynik procesu projektowania, który twórcy gier nazywają Fail Faster :

  1. Wymyśl szorstki design
  2. Utwórz prosty prototyp
  3. Przeprowadź test z krytycznym nastawieniem i dowiedz się, co nie działa
  4. Popraw swój projekt
  5. Wróć do etapu 2

Nie obawiaj się więc zmieniać lub wycinać funkcji, gdy podczas testowania gry zdasz sobie sprawę, że tak naprawdę nie są tak zabawne, jak w twojej głowie. Bądź także otwarty na sugestie zespołu. Większość ludzi z branży tworzenia gier postanowiła dołączyć do branży, ponieważ chcą realizować własne pomysły na gry. Danie zespołowi kreatywnego wpływu może być dla nich świetną motywacją. Ale jako dobry producent Twoim obowiązkiem jest również powiedzieć „Nie!” jeśli uważasz, że pomysł nie zadziała lub przekroczy budżet.

Z niecierpliwością czekam na twoją grę.


Dziękuję Ci bardzo! Twój szczegół bardzo dobrze odpowiada na moje pytanie i naprawdę doceniam wskazówki. Zrobię co w mojej mocy, aby wprowadzić to w życie w moich projektach. FYI (również dla każdego innego), moją „grupę” można znaleźć na ataxiagames.com . Jeszcze raz dziękuję!
Graham Lewis,

Proponuję również zajrzeć na to forum.unity.com/threads/game-design-document-template.240038 Ponieważ użyłem go z przyjacielem i bardzo pomogło nam to wyostrzyć pomysł i uzyskać dobrą definicję tego, co należy realizować w ten sposób.
Nico,

Nie mogę uwierzyć, że nikt nigdy wcześniej nie zadał tego pytania, i to też jest niesamowita odpowiedź! Jestem pewien, że to pomoże wielu ludziom.
Brian H.,

3
Jeden standard ISO, by rządzić nimi wszystkimi / Jeden standard ISO, aby je znaleźć / Jeden standard ISO, aby je wszystkie / I w dokumentacji je wiążą / W krainie rozwoju wodospadu, gdzie znajdują się specyfikacje.
OnoSendai
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.