Hello!

I’m back! Last post we talked about how to organize our game ideas so you can find the gameplay blocks to then define what to prototype and whats the role of designers and programmers on it.

Now we will go through the iteration process.

 

post02question01

Before we go for the iteration steps, establish a goal for the prototype. That’s where you are going for. Try setting a solid goal that leave space for changes and remember, the goal should always result in FUN. That’s the main purpose of the prototype.

Example: Let’s say I want to make the combat system. I’ve broke it down into several parts and I got to the point where I want to prototype the character movement. My goals is to make a smooth and responsive character movement control that allows the user to understand his surroundings while battling.

You can see that my goal is not a “I want the control this way” but rather the feeling I want to convey in the prototype. That’s because the prototype should tell me how the control will work best, not me J.

To explain how to iterate, I split the process according to the team role:

 

post02image01

Think each iteration as a small implementation towards the goal that you established. It`s as if you were putting Lego blocks together. Each block is an iteration, therefore, you need to specify to the programmer the block color, size and shape, so that he can create the block for you and put it together with others.

You may want to test the same block type with different sizes, so it’s important to give the specification with the variables you want the programmer to expose so that you can tweak them by yourself.

At the end of each iteration, you can have 3 outcomes:

  • I like what I see!: It means that it’s going towards the goal and FUN factor. Good, keep iterating on it!
  • This sucks!: It`s not matching the goal. That’s ok! Each iteration that fails, is less time wasted in actual development time. You saved some time and resources of your project! Try something different. If you can`t think about something else, cut the feature.
  • I discovered something new!: The iteration was ok/or not, but you had a completely different vision that goes towards the goal and is MORE FUN than what you envisioned previously. In this case if the vision follow the goal, iterate towards it.

If you end up having 2 different ideas for the same iteration, test both. Start by the one that you can see the result faster. Remember to always focus the iterations on the SYSTEM, not context. If you tie it to the context you are producing results that might not be consistent if the context changes.

Another important aspect you have to care about is the signs and feedbacks of your feature. At each iteration remember to watch out for the accessibility of it. The player needs to understand what you are asking for him to input in the system (Sign) and how he sees the result of his input (Feedback). Use placeholder effects and/or UI for that.

For last, but not least: Don’t forget to document every iteration you do. You need to know where you started and where you are going.

 

post02image02

As I mentioned before, prototyping can be very hard for programmers because it goes against the rules they learn on how to do great code.

If you are coding the prototype, you need to be very aware that the specifications can change every single iteration and your code will get only worse. Don’t worry about that! The iterative prototyping process is there to assure you are making the BEST GAMEPLAY POSSIBLE.

For that, a couple of good rules here:

  • Your code won’t be used to anything more than prove a concept. Don’t waste your time thinking what is best to achieve the results.
  • Thinking in the architecture before the feature is defined usually produces ineffective code and goes against the fast prototyping process.
  • Don’t anticipate problems!
    • Never implement something that may be useful at the next iteration. Wait until that really happens.
    • If the feature has many variations, always start with the easiest one.
  • Be proud even when you lost a day trying to prove a feature that shows it won’t be cool. You have saved production time and avoided that the feature became part of the final game.
  • Remember: You will have time at the production stage to create an awesome architecture to accomplish every aspect needed in the feature.

 

For Prototyping 101 – PART 3 (last one) I will be talking about when and how to show prototypes

If you have any questions, post it and I will be glad to answer 🙂

Leave a Comment

Your email address will not be published. Required fields are marked *