Exploring Interaction and Evaluationthrough Game DesignJulian FietkauBauhaus-Universität WeimarOctober 13th, 2015
Because students have many different project courses to choose from, I was able to assume at least some intrinsic motivation for my specific topic. Nonetheless, the course had to be designed in such a way that students with little to no experience with video games would be able to complete it. In addition, I considered it important to revisit the evaluation methods that the participants already knew from the perspective of a game designer, and to refer to relevant literature from the field of game studies and from the game development industry to help the team apply their knowledge.
Semester Plan
Before the start of the project course, I developed a week-by-week plan to set topical goals throughout the semester. This would serve as a guidepost for myself as well as for the students.
Analytical
Constructive
W1 (Oct 12)
n/a (Because the project fair happened later this week, the course would start in week 2.)
W2 (Oct 19)
Initial meeting + thematic appetizer, discuss goals and expectations and preexisting knowledge
W3 (Oct 26)
Methods overview
Let’s talk about game input and technology
W4 (Nov 2)
Focus groups
Brainstorming and collecting ideas
W5 (Nov 9)
Heuristic evaluation
Prototyping
W6 (Nov 16)
Questionnaires and surveys
Game loops and core systems
W7 (Nov 23)
Interviews
Programming challenges in games + working on your game
W8 (Nov 30)
Observational studies
Working on your game
W9 (Dec 7)
Gameplay metrics
Working on your game
W10 (Dec 14)
Methods summary
Working on your game
Christmas break
W11 (Jan 4)
Working on your game + planning the evaluation
W12 (Jan 11)
Working on your game + preparing the evaluation
W13 (Jan 18)
Conducting the evaluation
W14 (Jan 25)
Discussing evaluation results, lessons learned
On the analytical track, each week until christmas there would be a literature review and a discussion on a particular empirical method and how it could be applied to games research. On the constructive track, the project would start with some general input on game creation and then smoothly move into the phase where the project team would create their own game by taking it from ideation through physical prototyping into a software implementation.
For the discussions on evaluation methods, one person from the team would be designated as the “expert” and would be given two or three relevant academic articles by me, whereas everyone else would read just one article for that week. The expert would then be tasked with guiding the discussion and making sure that all important aspects would get covered. There are a number of teaching methods that call for something like designated experts, but I decided to come up with my own set of guidelines and called the concept semi-structured discussion.
Semi-structured discussion is a method for getting the most out of group discussions. It could be described as somewhere in the middle between regular plenary discussion and interactive presentation. It works like this:
For each discussion, one group member is designated as the expert. They prepare the discussion topic more in-depth than the other members. During the discussion, they take care that important points get covered by steering the direction of the discourse. However, it is important to note that the expert is not a presenter, it is not their job to provide all of the content. Their role is closer to that of a moderator or facilitator.
Here are some loose guidelines for semi-structured discussions.
If you are the expert:
DO: Prepare the discussion topic in-depth using additional literature.
DO: Create a list of points you’d like to see discussed and questions you want to get covered.
DO: Guide the group to the next point if the discussion gets stuck on one aspect for too long.
DO: Try to get a feeling for the level of knowledge of the group members, allow time for areas where they have a lot to say.
DO: Point out similarities and differences between group members’ opinions that you notice during the discussion.
DON’T: Prepare any slides – you are not a presenter this time.
DON’T: Be talking the majority of the time – you can add your perspective, but again, you are not a presenter.
DON’T: Sit back and relax – you will need to concentrate not just on the content, but also on the timeframe.
DON’T: Get hung up on micro-moderation – it’s nice if you make sure everyone gets equal speaking time, but your primary goal is to get the material covered.
DON’T: Write a protocol of the discussion – unless you are the supreme emperor of multitasking, your full attention will be needed for the discussion as it happens.
If you are a regular participant:
DO: Prepare the discussion topic – you don’t have to research as deeply as the expert, but you should have a general idea of the topic.
DO: Be respectful towards the expert’s guidance – if they say you have to go to the next topic, there is probably a good reason for it.
DO: Be constructive and work with the other group members towards a better understanding of the subject.
DON’T: Sit back and relax – your discussion input is needed, you are not a consumer today.
On the constructive track, the sessions would start with getting the participants into a creative mindset. To let them experience that ideas for games can be plentiful with the right prompting once you get into it, I created the Game Idea Game, which is now available for download on a separate area of my website.
In the typical game design process, lots and lots of ideas are created, iterated, improved, sometimes fleshed out and developed, sometimes discarded. When searching for that next brilliant game concept, it can be very useful to get a few people together for a brainstorming session and just start pumping out ideas and talking about them. Coming up with a wide variety of game ideas is a skill that does not come naturally to everyone, but it is something that can be practiced and trained.
This set of cards was developed to give aspiring game designers those initial sparks. Staring at a blank page can be daunting, so the cards give keywords from various categories that can foster and steer creativity, to be used in any way that gets the ideas flowing.
Print the card collection on A4 paper (or larger if you want bigger cards) and cut along the lines. Glue to colored cardboard for extra sturdiness.
Suggested gameplay: Shuffle objective cards seperately, shuffle all white cards in a big pile. Each player draws six white cards and keeps them on hand. Starting with the most experienced player and then going clockwise, each turn the current player flips over an objective card and adds three cards from their hand to it. They then have 30 seconds to explain a game concept that incorporates all those elements. They may add as many cards from their hand as they can incorporate into the idea. Afterwards they draw two new white cards from the pile. If they cannot come up with an idea at all, they have to take the three cards plus one from the pile back on their hand. The first player to completely clear out all cards on hand during their turn wins the game.
Reminder: Above all, this is a creativity tool. If something about this doesn’t work or isn’t fun, change it! Add or remove any cards you want, change the rules to be less competitive (or more competitive), just do whatever works for you and have fun!
For the physical prototyping stage, I prepared a collection of classic board games and a few mixed sets of Lego bricks. This would allow the team to visualize and “tangible-ize” their ideas. Getting computer scientists to warm up to the idea of physical prototyping can be a challenge, but I also knew from previous experience how worthwhile it could be.