Learning Game Design - Introduction

Yesterday we had our first game design learning project meeting. The project goal is to learn the basics of game design and put them into practice. It's a project I started for members of STAGE. For me, it's also an important project to get more familiar with game design. I mean sure, I've read some books on game design, and done some designing and even prototyping myself, but getting more practice is key. I don't think I can credibly bring game design concepts into usability design if I haven't designed a lot of games myself.

The plan is to use Ian Schreiber's online course material from last year. The course is called Game Design Concepts, and should take us twenty to thirty weeks. Our study group is something like five people - a suitable size to keep meetings sane. Each of us will do reading and exercises on our own time, and then we will meet weekly to discuss the week's topics and exercises. Once the exercises start to be about actually designing something, we will include play testing into our meeting agendas. The course is about non-digital games, as these are much easier to do solo.

So, I will probably write more about the course, especially about the things I have learned, in the future.

Features in Need of More Use

Another interlude, I know. A lot is going on but there isn't much to write home about at the moment. So I'll take this chance to discuss some great features I'd seen in some applications. This post was mostly inspired by Dia which I've been using to draw diagrams today.

The first feature is snap to grid which is present in Dia. The idea of this feature is not very radical. The editing area has a grid on it. If snap to grid is turned on, whenever objects are moved, their corners and sizes will snap to the grid. So my box for example will be exactly 6 times 4 grid squares, and is strictly lined up with the grid. This makes two things easy: creating boxes with the same size is easy, and lining up multiple boxes is super easy. Oh and drawing straight lines is almost too easy. This feature's relative is snap to object but I don't find it nearly as useful. What it does? If objects are moved close to each other, they are snapped together. Snap to grid on the other hand should be available in every program where objects can be positioned. Every. Program.

Dia also reminded me of another feature I really like: customizable keyboard shortcuts. Dia doesn't have those, but all KDE applications do. I don't think there's any limit as to how far this should go. I would consider it optimal if every single action in the application could be given a shortcut. KDE apps don't manage this, but their customization is easy. Pick an action from a list, assign a shortcut. My only gripe with them is that some actions I'd really like to assign a shortcut to are not on that list. The biggest "why?" of all: only 12 tab shortcuts available for browsers. Not quite enough. A lot of heavier programs have macros (but they can't fix everything). But: customizable shortcuts - not that hard to program. So where are they?

While on the topic of customization, how about customizable menus. Much like shortcuts, except instead of assigning actions to keys, they are assigned to user-defined menus. This is actually a feature I haven't seen much in applications and can't really name one. I have seen it in some operating systems. Most notably, my current Nokia phone. The phone itself is horrible. Can't remember the model number, but it's their current low end. It has the worst keypad I've ever used. What it has, is a "go to" menu behind one button on the main screen. It's a menu for collecting shortcuts. I don't need to navigate the stupid menu system to get to the most important things.

Sure enough, these features are mostly what could be called "power user features", especially the customizations. Actually, both of these features are very often available in games. Especially PC games. Which is yet another reason for UI designers to go and play some games. The power of these features is largely understood, so nothing revolutionary here. What I just wanted to say is: use them more! Use them everywhere. They're some of the extra features you actually can't go wrong with.

Introducing STAGE

It's been a while since the last entry. There are things going on, and interesting stuff is about to happen. Results will follow. In the meanwhile, I'd like to talk about STAGE (backronym under discussion). In short, it's a game development club primarily for students in the Oulu region. The ball was set rolling by me and Ari Kangasniemi (Games Research Center, University of Oulu) earlier this Autumn.

The point of STAGE is to offer students interested in any aspect of game development a local community. We don't have that much gamedev studying options in Oulu (next to none at the uni, some at other schools) but apparently we do have lots of students interested in it. Bringing them together is a logical step, one that should have been taken some time ago. Now it's under way. We will provide information about work and study possibilities, self-study resources and a channel of communication for starting projects and getting people to work on them.

For my own research, the club is an important channel to gamedev. It is also a limited possibility to work on some game projects that might support my research, assuming I can make them interesting enough to get people participate in them. But that is definitely in the future. For now, I think the most important aspect is being able to contact other people interested in gamedev. Throw around ideas and, of course, make some games. Stuff I'm really looking forward to are game jams. First our local practice jam, then Global Game Jam next January. I think I'll focus on programming there, unless I come up with some really impressive design and decide to pitch it.

I think that's it for this interlude. Expect updates on STAGE after said jams, and possibly other stuff as well. In the meanwhile, if you are interested, go take a look at our forums (they are in Finnish though).

Cooperation in Games (and Elsewhere)

Last week on Friday I and a few fellow researchers were taking part in a cooperative game session. The purpose of that particular game is to improve communication inside teams. We tried it out for more research-oriented reasons. There is a lot we already know about playing together and cooperation but this doesn't prevent me from thinking it a bit. So here we go: another game-related blog topic. Just some general thoughts about cooperation.

Lately I have mostly cooperated with other players in board games. Recently cooperative board games have been on the rise. They are a good concept for a couple of reasons. First of all, in cooperative games it is less important for the players to be evenly matched. They are competing against the game after all, not each other (although some of them have one or two players as traitors trying to undermine the others!) This makes them more accessible to less than hardcore players. The other reason is just that thinking together is Fun (yes with a capital F). I also do believe these kinds of games are good for improving communication skills (there is most likely research done on this subject, something I'll have to dig up later).

Board games also integrate the benefit of bringing people together into the same physical space. However, cooperation in digital games over the internet is no less fun. One quite important difference worth notice is what skills each player brings to the game. In board games, players mostly bring just their brain. Manual dexterity, hand-eye coordination and so on are not really important because the games are not played in real time*. In digital games played on consoles or computers, players typically need to be familiar with appropriate input devices. Real-time games typically also require reflexes. First-person shooters require good hand-eye coordination. Put simply, they are somewhat less accessible for non-experienced players.

Digital games do have a benefit over most cooperative board games. In board games, where thinking time is theoretically infinite one player can, in theory, play the game by himself. This causes a situation where less experienced players find themselves being told exactly what they should do on their turns. This is seen as a problem among the board gaming community, largely because in board games carrying out actions is trivial. Fun is in the thinking. In digital games it is much easier for game developers to make games where one experienced player cannot play for the whole team. Experienced players can still be leaders, giving out directions or even orders (in more organized play) but overall success is much more dependent on everyone's skills.

Assuming the aim is to improve everyone's communication skills, some tricks can be employed. Many board games employ rules that somehow limit communication. For instance, in many cooperative board games players are not allowed to show their cards to others. Often it is even forbidden to talk about one's cards in detail. Another thing that can be done in board games is enforcing time limits. If time is limited, one experienced player simply doesn't have enough time to mind everyone else's playing. Basically any kind of knowledge distribution scheme works wonders.

In digital games critical resources can be distributed among the players. When everyone can do something others can not, everyone needs to be involved. In most games, location can be considered a resource. Information visible from one particular place can be valuable and therefore require one player to stay there and report said information to others. Generally speaking, dividing the game to multiple terminals (computers or consoles) allows more player specific information which is also harder to convey to others. In the spirit of time limits, the game could even enforce microphone time limits. Speak too much, and your mic goes silent leaving leading for someone else to do.

Ahem. Looks like I sidetracked quite a bit. But hey, at least now you might know more about the specifics of cooperative games. Cooperative play is motivating. Winning or losing is no longer just about yourself but the whole team. It also makes many seemingly less interesting games much more interesting (try and play some coop board games solo, they are quite boring). Cooperation is also generally important at work. Most people these days don't work solo. As usual, there are two angles when looking at games and real life cooperation. The first angle is improving communication skills via suitable cooperative games or game-like activities. The second angle is making tasks more motivating by increasing game-like cooperation.

The second angle is a matter of tools. Cooperation generally leads to better results and is therefore already desirable. Many applications on the other do not support cooperation. Means of remote communicating need more improvement. Voice and text are often insufficient. It is much more powerful to show things. Solutions have been developed and will be developed in the future. One important requirement for communication and cooperation is that it needs to be effortless. Cooperating with people on the other side of the globe should be as effective as with people in the same office. At the moment this clearly is not so. Perhaps games can help us here. That is one more question for me to think about.

* There is at least one really good exception. Space Alert is a game where players together as a team have exactly ten minutes to plan all of their actions for the game. These are then carried out afterwards to see how the plan holds together. The time limit demands quick thinking and really good coordination from players.

Goal Forming

The last aspect I'll explore in the flow series of posts is goals. This writing has a companion article I have written for Tiny Universes, which explores how rewarding certain kinds of behavior can change how a game is played entirely, using two games as examples. In general, goal forming is an important aspect of user experience, and on lower level also pure usability. The usability aspect is explained well enough on The Design of Everyday Things (Don Norman) - in short, the user needs to be able to understand what goals can be set when using a given interface, and how to use that interface to achieve those goals.

When discussing achievements a couple of posts back, I mentioned they have more to do with goal forming than anything else. When a player plays a game, her first goals are typically to learn the game, proceed through its levels (or whatever) and finish it. There are of course various sub-goals while playing. Achievements or trophies often come into play afterwards and collecting them is another goal. It can also be argued that good trophies are ones that give the player some clear additional goals, which will increase the longevity of the game and therefore improve its value for money ratio. Case in point, before we had these modern consoles with their trophy or achievement systems, Star Ocean 3 had built-in battle trophies. It took me about 50 hours to finish the game, and then I spent another 250 or more hours collecting trophies (I'm still missing 7 out of 300).

In general, a good trophy challenges the player to play the game differently, introducing more difficulty. In Mirror's Edge there is a trophy that requires you to not shoot a single shot during the game. BioShock rewards the player for playing without resurrection chambers turned on. And of course Star Ocean 3 rewarded so many different and interesting things that it kept me hooked for a long time. Typically the only reward is a reminder in your account that you've gotten the trophy, although some games (like Final Fantasy XIII) hand out some minor gifts like operating system themes for getting trophies. Bad trophies are the kind that just require the player to do some repetitive thing a lot of times. More of the same is not very interesting, but doing the same thing differently can be.

Now, let's exit games for a while. With interfaces, especially in interactive spaces where interfaces can be abundant, it is important to get the users to form the right goals. By this I of course mean we need to assist them in forming goals that are relevant to them, assuming they are using our interfaces at leisure. In a work situation on the other hand we might want to introduce reward schemes that support effective work. Regardless of situation though, it's useful to keep the requirements of flow in mind: the user cannot achieve flow if he cannot set goals. So even before thinking what kinds of goals our interface should support, it needs to support goal forming in general. It can then be useful to do some research on what kinds of goals a prototype inspires in people, and then think how they could be adjusted, if necessary.

When the overall goal of an activity is fixed, the system should aid users in forming sub-goals that help them move towards the overall goal and stay motivated. If the activity can be split into a plethora of short-term goals, progress is easy to measure, and if there is flexibility in task order, users can also select short-term goals that are a good match for their current skills. In general, people split activities into short-term goals all the time when working but it definitely cannot hurt to make systems that support keeping track of these goals, and that can also suggest goals.

Before achievements and trophies entered the life of gamers, people used to make up their own challenges. These were definitely no less interesting, but of course no one was certain whether a challenge would be possible at all until someone completed it. With formal trophies, game developers can design the challenges and ensure that they are indeed possible to reach (although, some of the craziest ones are almost unreachable). So for example, in order to improve my writing, I could use a text editor that has various trophies for using language in special ways, like "use 5 different synonyms for a common word in one article". Of course I can make up all these challenges myself, or search the internet, but if it is in fact built into my interface, they are constantly present and easily available for viewing.

Overall, goal forming is a highly relevant topic for user experience. I have once again just scratched the surface, but already discovered at least two important aspects of it. The first one is to gain an understanding of what goals users can form when using your interface. The second one is guiding users to form goals that are constructive towards the overall goal of a larger activity. If every phase of an activity can has its own short-term goal, the user experience is likely to improve. This is too often not the case when viewing the learning curves of more complex applications.

Teaching Experiences - Game Programming Course

As I mentioned briefly, this Autumn I was teaching a course called Introduction to Programming Through Game Development. It was a short short course consisting of roughly 30 hours of combined lectures and guided practice. The idea of the course was to try out a new method for teaching basic programming. Unsurprisingly it was targeted to students interested in game development. Today I had the last guided session. Final results of the course will be evaluated once the students have turned in their assignments. For now, I will share some thoughts I had about the actual teaching.

Cramming basics of programming and basics of programming into one course is a lot of things to teach. If compared to our department's normal elementary programming course, the amount of topics is most likely doubled. The saving grace is motivation. However, in retrospect I should have probably reserved more time for the basics of basics. This time I got away with it, if only because everyone actually attending the course knew at least something about programming. Although this also means we didn't exactly reach our intended target audience. The first note to self: the course needs to be longer or some topics, no matter how useful they would be, need to be dropped.

The idea that motivation is higher when the topic is truly interesting is not surprising. From some comments, and some impressions I had while teaching, the course did seem to embody this idea. Our topics were more advanced and they were introduced on a quicker pace. Most people were still able to keep up. The course implementation suggests that those who didn't should have come up to speed on their own time (around 10 hours per week were scheduled for independent learning). It is safe to say however that motivation is clearly not enough to make this really really work as an introductory course.

My teaching paradigm can be summarized into a few words: "Provide impressive results early and often". Students on a programming should get their hands dirty within the first hour. This is not unlike games - the player needs to achieve something within the first five minutes or so. Drawing objects on the screen is in fact very easy when using XNA, so this requirement was definitely met. This I found to be in general a good thing when teaching game programming. Results are highly visible. Especially in the beginning. Once they know how to make a sprite move, the students are hooked. Then it is possible to move into the nitty-gritty of programming for a while. When they start to get bored again, it's time for more impressive stuff.

I still need to work a bit on this almost game-like course structure but I do think it definitely works. Starting with the easy stuff might sound like the way to go, but I think it's better to go for the impressive first even if it is a bit harder. Another really good thing about game programming is teaching object oriented programming. It becomes a lot easier if the objects are actual sprites on the screen. You can almost touch them, that's how concrete they become. OOP in general is one of the harder programming concepts to grasp but also one of the most important. Therefore it's really good if we can make it more accessible. In game programming it's also quite impossible to get very far and stay sane without using OOP.

To summarize, I think my teaching ideas are sound in principle but I need more experience. This course was just an experiment, but we're hoping to make it into a real course in the future. This will be my chance to improve it further, and of course improve my teaching at the same time. In the meanwhile, I'm teaching normal elementary programming for the next ten weeks, which will be another chance to improve my teaching abilities.

Next month I can follow up on this after seeing the assignments and feedback from students.

Audio Mostly in Piteå

Before continuing the Flow-series of posts, I'm presenting you a conference report. Audio Mostly is a conference for interacting with sound, so what was I doing there? Well, coincidentally, the organizing party is collaborating with us in the II City project, and my work just happened to be in demonstrable condition. Of course, now that it's been demoed I guess I can also write a post describing it a bit. Later though.

While I'm no audio expert (in fact, I just know how to listen to music - but I do think I'm fairly good at it!), the conference had much to offer, mostly in the department of game audio. It was also a good glimpse into the field of audio design, something I previously had little or no idea about. So now I know a little bit, and I can put my knowledge to use in game design or elsewhere. Although I will still have to rely on someone else to actually produce the audio - I have vowed to stay off the arts. That is of course a time issue - if I had the time, sure, I'd like to be my own graphics artist and audio producer.

The more interesting papers were about researching how people perceive audio. What kind of audio is suitable for different situations, how well audio expresses something, is it possible to tell stories using non-speech audio only and so on. From game design point of view, this kind of information is highly valuable (there even was one paper about horror game sounds). From the interface point of view, I'm kind of skeptic. As I am writing this, I'm listening to music and I have turned off every single audio signal from my operating system. There is only so much audio that can fit into one environment. Audio feedback is good, but relying on it too heavily can backfire. But that is just my opinion, and I should probably check some papers on the topic.

Since it was a small conference (they're keeping it that way intentionally) the atmosphere was really relaxed and enjoyable. I met a lot of people who were doing interesting things, and many audio-related conversations were had. Overall, Audio Mostly was more fun than Foundations of Digital Games, but not as useful for my research. Also, the chances of me going there again are kind of slim, especially now that I'm slowly transferring my work to a new project from II City (which also ends before Audio Mostly is next held in Piteå, which would be 2012 - they're having it in some more remote location every other year).