Prototyping and Planning

How you choose to manage the development of a project is important. But it is a choice. Even if you’re not the project manager if you are working on a project it’s something you should be able to have a say in if you feel the project can be governed better. It will effect most of your waking life so have a say. It
can influence the way developers work and their work in turn will
influence the end product.

For example, working on a project with very loose management, little
documentation and a lot of developer autonomy can be great if the
developers are experienced and there is a high degree of valuable
communication (as opposed to a large amount of noise and little
signal). It can be a total disaster if you don’t have the right type
of engineers for this sort of project though. Some engineers need
little direction and just need to be left alone. Your job as a product
manager is to somehow harness that into your plans. Some engineers
love operating within very strict, very well defined requirements
parameters and quickly become lost when things get loose calling for a
lot of creativity. It could be argued that there lies the distinction
between engineers and programmers. That’s a debate for someone else.

For me, engineering is about solving a problem with the resources you
have. And it’s as simple as that. I don’t like engineers who complain
that there’s not enough time (there’s never enough bloody time), I
don’t like engineers who give up the minute a solution isn’t dropped
into their laps, I don’t like engineers who sit around all day
bemoaning the lack of a Deus ex machina that would instantly make all
the hard work disappear and I certainly don’t like engineers that find
creative ways to do everything except push the project forward. (This
is starting to sound like the Pet Shop Boys’ Paninaro)

However, I love engineers that like to roll up their sleeves and often
get that crazy, distant look in their eye when a problem is thrown
their way. I especially love pragmatic engineers who actively seek to
use someone else’s hard work and conserve their energy for the later stages of
the project. I love engineers that enjoy solving real problems, not
ones they invent to keep themselves entertained. I like engineers that are
competitive about the elegance and economics of their solutions. These
are people you want on your team. These are people that are smart,
that get things done and importantly they add energy which the project
and whole team benefit from. They are also usually engineers who play
well with others and see other functions like sales and marketing as
part of their team too, and not “them”.

Ironically, at the onset of this project the only engineer will be me,
so I’d better fit into the latter category or else I’ll have to fire
myself!

As the earlier discussions with real life game developers have
concluded, that beyond the kernel of the chosen game’s theme, it
doesn’t seem too sensible to have a long period of writing design
documents, followed by a long period of development only to find that
the game design was an absolute dog in the first place and all that’s
been achieved is just a terrific consumption of Jelly Belly jelly
beans.

Therefore, the project will have to operate on a prototyping basis,
whereby I will produce very tight and quick iterations off a the game
outline. The game outline by the way, is a simple one pager on the
game, its purpose, its main mechanic and what the goal of playing
would be. There is deliberately a lot of space to fill it out and part
of the hypothesis at this stage is that given the boundaries of the
game’s mechanic this is where the “fun” will be. And there is only one
way to prove if it is fun or not and that’s by playing with the
prototype.

The project plan looks roughly like this at the moment:

1. Complete simple one pager on the game design
2. Break the design into three main stages that can be implemented
within a few weeks, somewhat obviously these are a beginning, a middle
and an end. And the goal here is to be able to play through the game
as early as possible. Remember we’re not aiming for World of Warcraft
here. It might be that we start off with an exposition screen, a
simple user choice and an end story (you won/you lost). Remember small
steady steps focused on the achievable win out. Don’t start looking at
the horizon all the time. You’ll trip up.
3. Rapidly iterate around the middle part of point 2 until the
mechanic feels fun, when this happens we introduce a bit of formality
again.
4. With a working, fun mechanic we need to formalise the game’s
content and goals. This stage should be a more familiar and formal
process.
5. Create an agile style weekly release plan for implementing the
central goals and content from 4 and gather a small group of alpha
testers
6. Release the game to the alpha group who are happy to play the game
as it’s constantly updated. Use their feedback to update 4 and fix
bugs.
7. When the alpha group are happy with stability, release to beta group
8. continue feedback and updates back to 4.
9. As both groups continue to feedback, invite public users
10. Evaluation, where did it all go right/wrong

So that’s the rough plan, it might be refined a little but that’s the
core of what I want to achieve.

If you’re reading this drop me an email if you’d like to be an alpha
tester 🙂 I could do with some help

Leave a Reply