Ce este un GDD?

De ce am avea nevoie de asa ceva?

De ce am avea nevoie de asa ceva?

Claritate pentru intreaga echipa

Eliminarea feature-creepingului

Perspectiva obiectiva (eliminare hype)

Structura unui GDD

Structura (Clasica) Phase-uri

Concept Phase

Design Phase

Production/Implementation Phase

Structura (Clasica) Concept Phase

Scop: Introducere in proiect. Este o carte de vizita pentru toti.

Este definita prin:

-Game Concept
-Game Proposal

1. Game Concept
1.Intro- O fraza bomba!

2.Description- Fraza bomba de mai sus dar detaliata. Experienta narativa, walkthrough.

3.Key Feats- Simplu, scurt, cu liniuta (punctele de atractie a jocului vostru)

4.Genre/Platform- Kind of obvious ce-i aici.

2.Game Proposal
Pentru cine scriem?

2.Game Proposal

Game Proposal
Ce ne trebuie?

1.Market analysis (public tinta, titluri de succes concurente)

2.Technical analysis (feature-uri nemaintalnite,risk-uri, estimari resurse/timp)
3.Cost & revenue (costuri,pret de vanzare, estimare profit)

Structura (Clasica) - Design Phase

Scop: Descrierea clara si detaliata a viziunii pentru joc.
Design phase-ul este format din:

-Functional Specification

-Technical Specification

1.Functional Specification
Cine citeste = intreaga echipa de productie. Contine:
-Game Mechanics (Mecanici prezente,Core Gameplay, Multiplayer)
-UI (Flowchart pentru ecrane, Functional Break-down, Mockups)
-Story (Rezumatul povestii, Personajele, Back-story)
-Art & Video (Stil,Mood,Caracteristici,Paleta de culori, 2D/3D Art &
Animation,Cinematici)
-Sound & Music (Stil,Teme,Mood,Lista sunete,Lista muzica

1.Functional Specification
Probleme frecvente:
- Lipsa de detalii a elementelor prezentate/descrise
- Lipsa de consistenta a materialului
- PREA MULTA INFORMATIE!!!! ( !@$*(&(*SAF(*A(*&@!#(*!& = PREA MULT)
- Material Contradictoriu ( A=B [3 pagini mai incolo] A != B Fuuuuuuuuuu)

2.Technical Specification
Cine Citeste: Lead Programmer, Technical Director, programatori basically.
Contine:
-Game Physics ( Colin McRae sau woobly-doobly physics)
-Control Scheme (Actiuni legate de butoane, Control cu gamepad/mouse/VR)
-Camera Control (Static sau Dynamic, viteze de rotatie/apropiere, reguli speciale)
-AI (Schema de AI ce include comportament,path finding,selectie,reactivitate,etc.)
-Multiplayer (Client-server/peer-to-peer,compensare latency,etc.)

2.Technical Specification
Probleme frecvente:
-Generalizarea informatiei
-Omiterea informatiei
-Prea putin research si/sau timp dedicat pentru o problema

Production/Implementation Phase
Ce ne trebuie?
-Level Design respectand specificatiile din Design Phase

-Revizuirea continua a documentelor din Design Phase o data ce productia

avanseaza

-ATAT!

Tips pentru un GDD bun!

1.Usor lizibil ( mult spatiu, headers cu bold, spatiu intre paragrafe, linii cat mai
scurte).
2. Explica clar echipei planul tau maret inainte sa le ceri ceva.
3.Secretul sta in detalii.
4.Formatul text nu mai este suficient uneori.
5.Pregateste alternative in zone sensibile/neclare.

Exemple de fail 1
You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both

groups nod to everything you say.

That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and
begins to think, "What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, I can design a
game just as well as anybody else!" And the hands keep typing code.
Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a
complex 3D rendering to finish. Unsure and not really caring whether he's dreaming or is actually getting paid for all this,
immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways
previously unimagined - certainly not by you.
By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You
need to inspire.
For example, say you're designing a shooter. You want to train your players to deal with certain challenges before they actually
meet them, so you place less lethal mini-challenges a few steps in advance. You're going to have to explain that to everybody on
the development team, so they'll understand why certain things are where they are and why they work the way they do.

Exemple de Fail 2
A document without details is useless. Generalities can be
interpreted by anybody in any way that they like.

"Thou Shalt Not Kill" meant one thing to Moses and another to a
Spanish conquistador. Detailing whom you shouldn't kill and
under which circumstances would have been more helpful.

Intrebari?