A lead game designer that I'm working with claims that game designers simply write GDD and submit it to the programmers who read it and program based on the document. Is that true? Isn't the game designer suppose to understand the technical limitations and sit with the programmers and see how its executed?
A lead game designer that I'm working with claims that game designers simply write GDD and submit it to the programmers who read it and program based on the document. Is that true?
Hahah, no. That is a massive oversimplification at best, and if this person serious believes that's an ideal way to get anything done I would consider that a huge red flag.
Game development is ideally an iterative process; while designers might come up with initial plans and designs, there should be a constant feedback loop between the designers and the programmers (and the artists, QA, and everybody involved). This enables refinement and shared understanding that's critical to have, especially in such a creative industry.
Every studio I've worked at that was not totally dysfunctional worked this way; how exactly this communication happens may vary (email/Slack/Flowdock/turning around at your desk and talking/etc), but it should always exist and continue up until (and maybe after) each feature ships.
Generally the lead designer is not going to completely understand the technical aspects of the project, because that isn't their area of expertise. That's the technical director's job, or if there isn't a technical director then the lead programmer. This is exactly why it is necessary for the technical director to read the design document, then talk to both the lead designer and the staff programmers to revise any serious problems, assign development tasks to individuals who have the right skills for them, recruit new people if no one with the appropriate skill is available, and create a schedule prioritizing what should be done first, as well as milestones and deadlines. This all assumes an AA or AAA game - indie production methods are rather different and more flexibly adapted to the particular people involved.
Game designers comunicate in a multitude of ways and it differs from company to company.
Most games companies nowadays try to (or pretend to) follow some kind of Agile development process. One of the key principles of Agile production is that the most effective means of communication is a face to face conversation. In SCRUMM there are plenty of chances for the designer to communicate with the rest of the team in a face to face or virtual manner (story planning, story pointing, daily standup, end of sprint demo, retrospective).
Its worth pointing out that in Agile there should never be a separation of concerns. Unfortunately this is one of the areas that most teams screw up on. There should not be an "I'm done chuck it over the fence to the next team" mentality. i.e..
Design team -> Dev Team -> QA = wrong way of working
It is supposed to be the whole team communicating together and working together so designers, devs and QA may frequently be sat around the same machine (or screen sharing on virtual teams) tweaking stuff and working things out. Ideally there should be no such thing as a design team,, programming team etc.. There should just be a team of people with different skills working on a task together.
Other methods of communication will include software tools such as Flowdock, Slack or Trello which basically are fancy chat rooms that plug into all the other tools that are used in a development studio.
One thing designers love to use to communicate things is post it notes. A lot of designers I have worked with are obsessed with writing down every single idea they have and leaving them stuck everywhere.
I'd say your designer is lazy :D The GDD is there to align the vision of the project and (sometimes) to keep it from going off the rails.
So there's an idea. We write the GDD. Everyone (who's relevant to this stage) gets the GDD, reads it, digests it. Then there's a meeting. We discuss what we read. Clarify the question points, identify problems. Once the entire design is clearly understood by everyone it is transformed into a set of milestone goals, design/code tasks, etc.
As the game develops it will drift from the original GDD. Sometimes this means going back and revising the GDD, sometimes it means stopping people from drifting and conforming to the intended design. That's kind of the collaborative effort between production and design to decide which.
In many cases after that first step though the GDD is forgotten about and the game just kind of develops organically from its original idea (this is a terrible method, but it is what ends up happening in the real world more often than I like to admit).
The thing is, this guy had six years of experience and the fact that he says that you barely won't have time to even communicate your concept to the programmers makes me wonder whether big companies like EA, SEGA and Nintendo follow this procedure.
throughout his six years, he has just made endless runners......I don't know whether that's something to accept or something to question one's experience of a game designer.
