#designdoc

デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。

デザインドックの存在意義

Define (明確化)

Align (合意形成)

Record (記録)

人と人とのコミュニケーションは常に不完全

デザインドックの基本構成 10項目

One of the many top tips that I have seen for Indie Devs is to create a design doc. My typical un-matured mind said, why bother. My partner and I already planned out our game. This would just waste time and resources. So for our first game I ignored this step......We both sat down for a post-mortem meeting and the main issue was planning. For game #2 we decided to spend a month or two on planning our game. Wow! What a difference, but I didn't realize until I created a design document, how our game was too boring for words.

Well, since we put our game on hold, I felt that in order to do our game justice. I will work on the design document while we are on hold. I thought it would be easy because we did spend two months planning. I couldn't have been more wrong. As I am piecing together ideas that were previously agreed on, I realized there was a huge chunk missing from our plans. How do we keep the game from being mundane? Is there a way that we can tell our story better? How can we get the player fully immersed? What happens after this part? Do I have or know all the code that I will need ? Is the art style suitable for the story we want to tell? Yay, we created a couple of tracks of music, but what about ambient noises needed?

Unfortunately, my partner has less free time than I do. So I started to fill in the gaps on my own. I noticed that as I am filling in the gaps, I am created a deeper story line and more interesting characters...I feel like now the game is a little less punishing to the player and more interesting. If I hadn't been so stubborn in the beginning our first game would've been a bit more immersive.