The first week here is spent in prototyping and brainstorming, creating a process of rapid idea generation and learning individual roles.
Teams are sorted out through an application process, coders, artists, QA, Designer, producer, and generally number about ten. During the initial prototyping / game jam sessions the focus is on learning process, getting use to churning out a playable idea inside of two hours, keeping the scope small and turning around to do brainstorming as a group to develop ideas.
All team members contribute to design at this point, in fact generally the teams are broken into sub-teams to create even more games, so a team of 10 may end up creating 2 or 3 games in a two hour game jam.
The first prototyping came after the briefest of explanations of the product owner’s research question, and the application of certain constraints. I thought this was quite smart in that it allowed the teams to explore their understanding of the issue, and to begin iterating ideas. This was followed up with a detailed discussion of the research. These game jams were much more about process than product, and helped to create the team.
This then leads to more prototyping and developing an understanding of the tools, workflow, shedding ideas, focusing the prototype on specific mechanics.
Realizing I have collapsed this down quite a lot, some time is spent on brainstorming, and organized ideation.
the 5 principles of brainstorming:
Rule 1: Withholding judgment
Rule 2: Encourage wild and exaggerated ideas
Rule 3: Quantity counts at this stage, not quality
Rule 4: Build on the ideas put forward by others
Rule 5: Every person and every idea has equal worth
(here I have to throw out that there is an alternate methodology which says keep the criticality because the ideas get better: http://www.newyorker.com/reporting/2012/01/30/120130fa_fact_lehrer?currentPage=all )
Hints/Tips: designate a leader/caretaker and a secretary, hear everyone and try not to interrupt, time box (beginning and end), explain the process, write everything down.
Problems suitable to brainstorming: those with clear definition, a creative solution (not a judgement call), simple problem (complex problems can be divided), clearly articulated
keep doing it…
This whole process becomes a cycle of development leading up to the first friday focus testing session. Multiple iterations need to be created and trashed, little effective bits moved forward to the next version etc. Everyone participates equally in these design jams. So what cannot be iterated on paper? Certain mechanics are difficult, but frequently this can be solved with a “computer” player who is essentially acting on a script, other specifically mechanically based games may require digital prototypes, but there is nothing wrong with this, it just cannot interrupt the quick iteration of ideas, the flow of the project and the contribution of the entire team.
Before the first focus test, all of the individual role based teams have also had a chance to meet. QA is going to administer the focus test, but the entire team needs to be aware of the procedure, and what it is that the team is testing for. The game will eventually be played in a vacuum, to this end the product owner may have specific needs related to the focus test.
1) what is the question (why are you testing)
2) what are the setup conditions (Observer Sheet)
3) Player sheet (rules)
4) cues to observer, things to look for that the player can’t or won’t tell you
5) after survey (use google forms, on separate computer)
was it fun, what meaning did you get from this, can you summarize your experience in 3 sentences
player is always right (don’t argue, don’t defend, don’t explain)
decompress, with product owner, designer, who else? compile information and share it with group
single page observer sheet
This focus testing is scheduled for every Friday of the summer program, with open focus testing (with 60 outsiders) scheduled to happen twice during the period.