Let's talk about the proposed spec. For those new to this concept please review our discussion on Concepts.
Let's move on now.
Our first step is to review our sketch. Can you pickout some views? In this sample we pick out 3 - let's isolate them.
sample sketch
Lets look at one of the three views more closely and isolate all of its interface parts. To do this I decided use Adobe illustrator to clean up one of our sketches.
That looks better.
Our next step is to define the areas of the interface. This is when you start to become creative. What I mean by this is that this is your job to define what areas of the interface are called. If there is no know name for the area like SCORE then make up a word - but think carefully about it, make sure it makes sense.
Let's label as much as we can in this example.
There even more parts we can define in this sample but we'll keep it simple for now. The point is to keep naming areas that mean something to you that is of importance. In the sample above I even named the area where action is taking place (Singularity Cosmic expansion area). I do this because if I am describing where the action will take place, which is important, then the programmer will understand what I am taking about. Remember, only YOU understand this interface so we need to outline the interface to someone else so they can read it.
This outline of the views is the first step in a proposed spec. At this point many artists can get involved in making a more graphic pleasing reprentation of your idea. Doing so will really make your idea stand out and easy to read.
The next step is to create the document. We need to outline a few things in the proposed spec that is necessary for someone to understand your idea. Let's take a look at a simple outline.
1. Overview
Describe the idea of your application in one sentence. This is difficult but you need to focus on the main purpose of the application. For example we could say - The BigBang is a math solving game.
2. Audience
What audience is your application targeting? For example we could say - This application is for children 6+ and adults.
3. Platform
Where will the development take place for the release? PC - Windows XP or Max OSX or will it be an iPhone application. For example we could say - The application will primarily be designed and ported for the iPhone/iPod touch devices. Other versions for android and Blackberry will follow.
4. Application Overview
Now its time to talk about the application. Imagine yourself stepping through the application for the first time. Ask yourself:
What do you see first. What do you select.
What happens or what does the user see.
What does the user do.
What does the user accomplish to complete the level.
What levels are there thats of interest to the player.
A good idea is to step through parts that are less interesting and are details, you want to discuss the gist of the application that makes it appealing to users. This is the message you need to convey in a proposed spec. This is what sells the concept.
Here's how I would start off in the sample we are discussing - The game begins with a Big Bang and where objects are released from the center at random positions, timing and angles... and so on.
Now your almost done. After you go through it a few times it should paint a nice picture of your concept. Presenting it is now much easier. Give it to someone else to review and see if your idea is clear and add parts of importance that should be mentioned or remove parts that are less important. The idea here is too present a clean concept. This is NOT the document you provide a programmer with, there's much more work involved for a detailed specifications document.
Next we will discuss a detailed spec and what's involved and a client spec. Both of these documents are important for they outline the details for a client (content to approve) and details the programmers (how it works) to effectively cost the job and get a time line.
