My Process

 

Know the overall vision and goals of the project

I consume every bit of information that I can get about the project. This includes all of the projects lore and the systems. Even the systems that are not necessarily part of my job. I need to know everything there is to know about the project. I need to know how all of the parts of the project work with each other.

 

Just as importantly I need to know what the project is not trying to do. If we are making a FPS I know that I probably don't need to worry about item drops or trade skills. But then again maybe I do. This all comes down to the vision and the goals. Do I completely disregard concepts? No, but I do prioritize my focus and time. Maybe down the road these are things that would be added to the project. But knowing as much as possible helps to set the tone for my work.

 

Brainstorming

When I am given a task I usually work with pen and paper in the beginning. I start a flow of consciousness documenting all the possible ways to create a system or asset. At this time I put everything that comes to mind to paper.

 

Once I feel that I have exhausted my imagination of ideas I begin to refine the list. Using the vision and goals to guide me I begin to play out my designs to what I feel would be a final product. I play out how I think these designs would work with existing systems and assets. In a sense I'm trying to break my designs. I start to ask myself the questions that I think I would get from other team members. I am looking for reasons that these designs wont work or don't fit in the vision and goals.

 

As I eliminate ideas I make sure to fully document why. The reason for this is to reinforce the reasoning behind the design I eventually choose. This is part of the process that I have developed based purely on experience. It comes about because once you do propose a design there is always that stage where others want to contribute. People hate when you say no to them. They hate it even more when you can't give them a reason why. Experience has shown me it's best to just be ready for these conversations. They always happen.

 

Refine the design

Once I have the best design I being to create the design documentation. At this stage I create a two page overview. The document needs to clearly detail some core ideas that the design is meant to achieve:

• How does the design address the assigned task

• How does the design work with other existing assets

• How does the design meet the project vision and goals

• What are the basic steps to implementation

 

The point at this stage is still to keep things simple as it leads into the next step

 

Approval

With this design overview in hand I submit it for approval from the people above me. During the approval phase there may be a period of refinement and feedback. Once I have received the necessary approval I create a more detailed design document. This is the document that has all the gritty details. Included in this document is a time line of the phases of implementation that I think would be necessary for a smooth production of the design. These phases include such things as requirements for prototyping and the minimum amount of functionality necessary to being iteration.

 

With the full design document in hand I would submit for final approval.

 

Implementation

With an approved design document and a rough outline of necessary functionality I wait for the scheduled time for the design to begin production. Once the design enters into production my time is spend incorporating feedback and iteration of the idea.

 

For me this means constantly working with the artists and coders that are implementing my design. This works differently depending on the processes of the studio but in the end it's all about communication. Sometimes this is daily meetings. Other times this means weekly ones. My process at this point is dictated by the production processes of the studio.

 

It's all about iteration; as much of it as I'm allowed to get.