Week 1.03: Reflection — Rapid Ideation

Confession time: ‘Ideation’ is a word I’d never come across until I joined this course. I even had to look it’s meaning up in the dictionary after reading the course brief and its one of those nuggets that piqued my interest and encouraged me to enrol.

Ironically it’s not an unfamiliar concept: I’ve been designing and creating things all my working life. The biggest differentiator is everything I’ve worked on has been to fulfil a need or objective set by someone or something else. There have always been quite specific constrains within which I’ve had to operate. With the IGD course those constraints are no longer present, the only true boundary being my own imagination.

The Rapid Ideation techniques I’ve been researching during the course of this week build on the creativity techniques and work together with them to present a (physical) manifestation of a concept or idea in the form of a prototype. Including the term ‘Rapid’ adds an interesting dynamic: by deliberately limiting the time available, the jam team need to be super-focused on the objective.

The Game Jam…

“A game jam is a gathering of people — youth, adults, professional game developers, or really anyone — to design and prototype one or more games in a short timespan” . It is a form of rapid prototyping where the emphasis is on collaborating, experimenting and doing to foster ideas and encourage creativity. The idea is very similar to a musician’s jam session from which it derives its name.

For me, the game jam is going to require a slightly different mindset. Whereas I traditionally strive to always deliver against the objective, it is entirely possibly (in fact extremely probable) that I won’t meet the objective within the timescale. Is that a failure? For a more traditional approach I would say yes. The game jam is somewhat different though and if as a result a concept or prototype fails that’s not necessarily a bad thing. It’s a minor setback and a learning point. Agile development encourages us to ‘fail fast, fail frequently‘ — although I much prefer John C. Maxwell’s slightly modified version: ‘fail early, fail often, but always fail forwards‘ — and the game jam supports this edict perfectly.

Game Jams are very different from my normal modus operandi: I prefer to be in control, to know the next step before I commit to take it. It’s new (to me at least) and therefore outside my own comfort zone so I initially approached the whole game jam idea with fear and trepidation…

• What if I couldn’t deliver within the timescale?
• What if I didn’t have the knowledge, skills or expertise needed?
• What if family and work pressure meant I couldn’t commit the time?

But, F.E.A.R. is just an acronym: False Expectations Appearing Real. Following my research and reading, the first two points have evaporated and the third is just time management and prioritisation.

I found the Game Jam Tutorial and the advice from my peers, particularly Matt, very useful. I would now say I’m looking forwards to the Week 4 Game Jam with nervous excitement for what is to come and I’m especially intrigued by the big reveal planned for Wednesday.

Prototyping…

…was the other big topic for this week and one I feel perhaps more comfortable with. For the day job I use a mishmash of tools and techniques ranging from the informal such as the quick whiteboard sketch to more formal proof of concept and technology demonstrators. It is very important to know there isn’t a ‘one size fits all’ approach to prototyping and whichever process, medium or technique selected will largely depend on what the desired output is. For example, the output of a game jam will probably be a vertical slice prototype built with a game engine to give a taste of gameplay. In contrast, the prototype for the project I’m running at work is a chunk of hardware and software that’s taken a team of engineers across three continents 16 months to develop.

My biggest takeaways from this segment were…

• Wizard of Oz Prototype which uses a human operator to give representative responses to User’s interactions with a prototype UI in lieu of the implementation
• Paper Prototype that uses pieces of paper cut out and stuck together to quickly build UI elements into a mock-up of the product. I really like this technique and plan to use it at work in conjunction with the Wizard of Oz method above.
• Narrative Prototyping with Twine and/or Fungus for non-linear, in-game dialogue is also something I plan to make use of within my own game development. I suspect that capturing the player and NPC dialogue in this way will also lend itself to localisation and I18N further downstream in the development cycle.

List of Images

Figure 1. THORN, 2020 Rapid Ideation Mindmap

References

Photo by Faye Cornish on Unsplash