Jak ustrukturyzować dokument projektowy? [Zamknięte]


30

Czy dokument projektowy powinien być ciągłą linią tekstu z prawdziwymi zdaniami, bardziej jak opis całej gry, czy powinienem układać go w proste punkty? Jakie są korzyści i czy istnieje więcej sposobów jego strukturyzacji?


5
Nie dlatego, że wcale nie zgadzam się z odpowiedzią Josha, ale 35 minut przy tylko 1 odpowiedzi to trochę za wcześnie, aby oznaczyć pytanie jako odpowiedź, na pewno?
Kylotan

4
Tak! Zgadzam się. Zawsze możesz to zmienić później, ale zawsze jest to bardzo rozczarowujące dla osoby, której odpowiedzi odmawiasz. Co więcej, czasami wybór odpowiedzi zniechęca innych do samodzielnego udzielania odpowiedzi, a to może sprawić, że przegapisz znacznie lepszą odpowiedź niż moja.
Josh

OK, welp, odznaczono odpowiedź. Ale prawdopodobnie oznaczę to ponownie jutro, uważam, że to naprawdę przydatne! Chyba, że ​​oczywiście ktoś da mi coś jeszcze bardziej przydatnego;). Dzięki za tę wskazówkę, nie myślałem o tym!
jcora

Możesz również sprawdzić ten artykuł, aby uzyskać więcej informacji na temat struktury Twojego GDD. To naprawdę świetne źródło: active.tutsplus.com/articles/game-design/…
Daniel Sidhion

@Josh, twój wynik to zastraszanie - kto spróbuje cię pokonać odpowiedzią;)
Tim Holt

Odpowiedzi:


30

Nie ma zasad ani standardów branżowych; ustrukturyzuj dokument w sposób, który będzie najbardziej użyteczny dla osób, które będą go spożywać , pamiętając o celu twojego dokumentu.

Osobiście oczekiwałbym, że będą fragmenty dokumentu, które lepiej pasują do użycia „prawdziwych zdań” do przekazania twojego pomysłu, a także fragmenty, które lepiej nadają się do napisania jako punktowana lista funkcji.

Kto jest twoją publicznością? Jeśli to tylko ty, jeśli ma to pomóc ci skoncentrować myśli, rób wszystko, co dla ciebie działa. Jeśli współpracujesz z innymi, zapytaj ich, w jaki sposób wolą zobaczyć dokument w podziale i jak chcieliby go używać.

Spodziewałbym się zobaczyć prozetyczny opis najważniejszych elementów gry: jest to główna koncepcja, styl i uczucie. Spodziewałbym się wtedy zobaczyć sekcję dla każdej ważnej funkcji gry.

Nie przesadzaj ze szczegółami i statystykami, pamiętaj, że dokument projektowy jest zwykle czymś, co będzie ewoluować przez cały okres gry w miarę tworzenia i iteracji. Jest to niepraktyczne, aby myśleć, że będziesz go napisać raz, aż przodu, i to będzie idealny, więc skupić się na to, czego potrzebujesz, aby przekazać dokument teraz i jak można najlepiej przekazać, że dla konsumentów określonych w tym dokumencie.

Nie ma znaczenia, co robią inni, chcesz robić to, co najlepiej pasuje do Twojego zespołu.


dokument projektowy stanowi rdzeń gry. w ten sam sposób, w jaki piszesz zarys książki, jedyne, co naprawdę się liczy, to „to, czego potrzebujesz”, aby zrozumieć swój pomysł i go zrealizować. chociaż chciałbym wzmocnić punkt docelowej publiczności i że nawet w każdej podsekcji może być inna publiczność, plan projektu jest dla zespołu / kierownika, przypadki użycia / ERD są dla programistów, a opisy jednostek są dla artystów. to jeden z niewielu przypadków, w których możesz napisać coś, co wydaje się nie pasować do siebie oprócz tego, że dotyczy tego samego ogólnego tematu.
gardian06

24

Oprócz tego, co powiedział Josh w swojej odpowiedzi, kilka osób podzieliło się swoim pomysłem na temat tego, co powinno znaleźć się w dokumencie dotyczącym projektowania gry, co może pomóc ci zdecydować, jakie aspekty będą przydatne w twoich własnych dokumentach. Pamiętaj, że są to profesjonalni projektanci, a to, co działało dla nich w kontekście tradycyjnej branży gier, niekoniecznie jest dla Ciebie odpowiednie, więc warto spróbować dowiedzieć się, dlaczego stosują określone podejścia i wybrać te, które pomogą Ci najbardziej .


Rozejrzałem się za dokumentacją projektu gry i jak to zrobić. Twój pierwszy link był świetny. Działa naprawdę dobrze z „określaniem zakresu”. Ustalenie podstawowego zakresu projektu i szorstkimi słowami wyjaśnij, co jest w grze i poza nią.
Wertilq

5

Jest jedna informacja, którą chciałbym dodać: dokumentując rzeczywisty projekt gry (tj. Zasady), podaj jasne wyjaśnienie, dlaczego wybierasz konkretny projekt reguły.

Jedną z rzeczy, o których prawdopodobnie zapomnisz, gdy będziesz wdrażać coś, jest dokładny powód dodania określonej reguły. Ponadto jedną z rzeczy, które najprawdopodobniej zrobisz, jest dodanie reguł i elementów gry tylko dlatego, że mają je inne gry, a nie dlatego, że gra ich potrzebuje .

Dodanie sekcji dokładnie wyjaśniającej, dlaczego istnieje element gry, zmusza do uzasadnienia użycia tego elementu pod względem ogólnego projektu gry. Później pozwala skutecznie ocenić, czy dany element rzeczywiście spełnia potrzeby, do których został przeznaczony. Jeśli nie, możesz go usunąć i zastąpić czymś innym, co spełnia te potrzeby.

Co więcej, jeśli okaże się, że gra się nie udaje i chcesz wymienić wiele elementów, aby gra była przyjemniejsza, możesz spojrzeć wstecz na dokument projektowy i zrozumieć, dlaczego wybierasz te elementy i jakie nowe elementy trzeba osiągnąć . Jeśli zmieni się potrzeba projektowania gry, możesz zaktualizować listę tego, co powinny robić elementy gry.


1

Podoba mi się sposób, w jaki autor Level Up pisze swoje dokumenty dotyczące projektowania gier, rysując wiele uroczych kształtów, postaci itp.

Bardzo polecam zajrzeć do tej książki Level Up !: Przewodnik po świetnym projektowaniu gier wideo

Dodając małe rysunki do twoich dokumentów, inni zwrócą na ciebie większą uwagę i możesz być pewien, że przeczytają twoje dokumenty projektowe


0

Struktura twojego dokumentu projektu gry zależy wyłącznie od ciebie, ale taki, który tworzę, zwykle zawiera (pamiętaj, że działa to lepiej w grach RPG lub innych grach fabularnych):

Spis treści - Bardzo ważne, ponieważ gdy masz bardziej złożone gry, musisz podać metodę organizacji

Opis gry - Krótki opis gry, zawierający opisy rozgrywki, platformę i inne ważne szczegóły

Przegląd historii - opisz swoją fabułę

Kontrolki - Wymień kontrolki, których będziesz używać w swojej grze

Wymagania techniczne - więcej informacji na temat platformy można znaleźć tutaj

Schemat blokowy gry - pokazuje, jak łączą się ekrany gry

Prezentacja - podaj szczegółowe informacje na temat typu kamery, interfejsu i innych informacji, które zobaczy gracz

Postać gracza - Podaj informacje o swoim graczu, takie jak jego wygląd, historia i narzędzia / bronie, których mogą użyć

Walka - Opisz, jak działa walka (jeśli dotyczy)

Poziomy gry - Podaj przykłady poziomów

Wrogowie - Podaj szczegółowe informacje o twoich wrogach (ataki, spojrzenia)

Bossowie - informacje o konkretnych bossach

NPC - opisz AI, które nie atakują twojej postaci

Muzyka / SFX - jaka muzyka i SFX muszą zostać wyprodukowane

Załączniki - umieść tutaj długie listy wraz ze skryptami i wszelkimi innymi informacjami

Możesz także utworzyć bardziej zwięzłą wersję dokumentu projektu gry, która zawiera około jednej strony, zawierającą następujące elementy:

Omówienie tytułu i koncepcji - krótko opisz, jaka jest gra i co zrobią gracze

Platforma - wymień platformę, na której zostanie opublikowana gra

Główne punkty - Podaj podstawowe informacje o swojej grze, takie jak FPS, MMO i tryb dla jednego gracza

Podsumowanie - Podsumuj swoją fabułę, jeśli istnieje

Postacie - Podaj informacje o swoich postaciach

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.