Ard Bonewald from GameHouse held a great talk about designing games for casual players and gave us a top 5 with tips for doing that. Although the talk was very generalizing, he could prove his approach was working because he had his game company running based on it!

1. Girls think games are bad for you.
   Make her feel less guilty! Make the game play quick (<3 min.) and make it safe to stop at any point. What helps is when the game offers meaningful entertainment, like brain training.
2. Girls are powered by emotion.
   Make it a interesting game, emotion is in the details. Make it personal!
3. Girls play games at the hardcore difficulty.
   Girls don’t read tutorials. Let them play the game, not the controls. Players can remember 5 things at max.
4. Girls don’t like losing or are afraid of failing.
   Failing makes it too personal, as if they have failed instead of just failed at the game. The game should be emotionally safe and encourage rather than punish them.
5. Girls can not be captured on a list.
   Don’t try to generalize them, they are all unique. Make them feel this!

Prototyping, rapid iterating and design goodness

Kellee Santiago from thatgamecompany gave a fantastic talk about the company and their approach on creating games. thatgamecompany is trying to push the boundairies of games, trying to show emotions in games that have yet been successful in the medium. It surprised me that they used about the same vision and goal approach I talked about earlier. With their games, they wanted to create an emotional shelter. Sometimes, hard fun is your enemy. They often lie close to emotions that are already explored in games, such as frustration and high tension.

Flower, their 2nd PSN title, had a huge amount of prototypes, as game development at thatgamecompany is based on rapid iteration and play testing. Most prototypes of Flower did not ‘feel’ the way they wanted the game to feel. Most of the times, the prototypes were completely abandoned, but the eventual game ended up using all the things they learned by creating those prototypes.

“Find the magic, execute the magic.”

“You don’t want to bet anything you don’t want to lose.”

Kellee notes that the iterative game development process does not really fit in the game industry, while it is the ideal process; it has difficulties with deadlines. This makes the planning and coordination a challenging task, in which estimates of wandering game designers and expensive iterations prove themselves difficult to plan.

Her presentation contained some very good advise for starting studios:

• Find your project scope upfront.
• Define the quality of each prototype.
• Define the quality of each iteration on the game.
• Wandering is OKAY.

The thing that ‘surprised’ and relieved me the most was the fact that everyone at thatgamecompany was able to create his own prototypes and was able to program or script themselves.

The New Gamemaker

Alan Yu, vise president of ngmoco, gave a very insightful presentation about creating games for the iPhone throughout the years, and gave hints and tips on how the next generation of game makers is going to survive.

He and his company realized that the only way to become and stay successful was to connect or merge business with game design. Basically, there are 3 ways of making money with free iPhone apps:

• Direct subsidy, e.g. buy 1, get 1 free.
• 3rd party ads.
• Premium content.

When the core compulsion loop of the game is limited or regulated, you create an environment in which people want to continue. This is where the money comes in.

Creating games for the iPhone takes less longer that traditional games and the market is moving too fast to hire specialists. For game developers, this means that they have to be fast and flexible. Shipping games is very important; creating a lot of small games means you have had a lot of opportunities to fail & proceed successfully.

And the rest…

The starting presentation of Toru Iwatani was fun to watch, but did not bring us any new insights on game development. Masaya Matsuura was creating a cool music rhythm game which he talked about. And David Perry talked about his history of games and how he thinks his company Gaikai will change the way people play games.

Till next year!

Please comment on missing pitfalls!

Entering production without something fun.
It appears that in practice, games that are not already fun before they go into production have a really hard time to find the fun at all during production. Beside the fact that working on a not -yet- fun game is bad for the morale of the team, visions of the game are almost never the same for each team member, resulting in unclear goals and uncertain artist and programming work. Having a fun vertical slice of the game that captures the core of the game early in the process greatly enhances the production because everybody knows where the project is going and can work on fine-tuning that feeling, instead of continuously trying to find that fun factor.

Start big, end up small.
3 core mechanics, 25 levels, 20 skins, 4 environments and a 6-player co-op campaign to start with, end up with 1 mechanic, 3 levels and no multiplayer. Unfortunately, this happens a lot in practice and is a very demotivating, economical and time consuming issue. Starting with something small and ‘finishing’ it long before the final deadline will not only be very motivating, it will also increase the chance on ‘happy accidents’ and remove a lot of stress from you and your team.

Peer reviews not taken seriously.
Designers can often have the habit of not playing each others work, being too focussed on their own work and neglecting to play the work of others. A peer review is something that should be structurally integrated in the process, as it will lead to sharing ideas and a healthy environment for constructive critique, after which the designer responsible for the work can iterate on his work.

Starting too late with play testing.
Doing play tests early in the game development process means a more stable version at the end of the process. It helps to set your focus on what is important and what has to be changed and will eventually lead to better end results.

Not enough games played.
Teams, but mostly the game designers, are expected to already have a strong knowledge of games, what works and what does not with the genre you are currently working on. Unfortunately, this is not often the case. Devoting time to play games with your team can greatly enhance the ability to express ideas or come up with new ones.

Too much importance on design documentation.
A designer can try to imagine how the game would play, but more often there are too many interactive elements that can have a huge impact on the eventual game play and the overall ‘fun’. The only way to prove your theory is to actually see it in action. A lot of great ideas are discovered through experiments and ‘happy accidents,’ but unfortunately, these are discovered quite late in the process and often treated as correcting previous errors, as designers are expected to get it right the first time. Try to test more than to write!

Not taking advantage of placeholders.
Team members, particularly artists and animators, generally prefer working on final assets than low-quality ones that will have to be replaced later. Unfortunately, this often means that the designer has to wait to test his features, resulting in a slow-down of the design process. By extensively using placeholders, the design process doesn’t just speed up, the designer can focus more on the game play than the decoration.

Not keeping design documentation up-to-date.
When documentation is not kept up-to-date, people lose faith in it and at some point they will stop using it as reference. When the main goal of design documentation is cross-department communication, this is a disaster and the design documents are seen as ‘worthless’ by the rest of the team. Although time consuming, design documentation is important because of its ability to keep all the information together and to leave few room left for wrong interpretations.
Also, design documents do not have to be bibles. Don’t try to make them as such – try including as much as visuals as possible, as images can really say a thousand words.

No external play testing.
Unless the game designer is able to erase all experience with games from his memory and think like a casual gamer, you will need external playtesting in order to test your ideas. You would be suprised how intuitive your ‘most-intuitive-interface-ever’ would be according to a 45 year old mother. But also for the hardcore audience, original features that work perfectly might not be that straightforward for your hardcore audience. And what about difficulty and feedback? If you know the drill and the underlying system, you play the game very differently from a new player.

Vogels! is a rehabilitation game that helps patients with a hemiplegia recover. The game, or rather the red bird in it, is controlled by a gravity-compensating supportive arm of which its position is tracked and ‘copied’ in-game.

For each new game, the patient calibrates the game to fit the level of impairment of the patient. In-game, the patient flies, following a path, through various parts of the world and grabbing birds.

Vogels! was created for Focal Meditech as a proof of concept by Team KOMODO, five Utrecht School of the Arts students and two Utrecht University students. My role in the team was Game Design and Project Coordination.

Post Mortem: What went right!

• Translating real life mechanics into game mechanics. In essence, we took what the arm offered us, combined it with how the patients would use it and then created the mechanics for our game. The process of taking all the elements and concluding them to what would now be our core game went very smooth, as all decisions seemed very logical thanks to the great base of research we had done.
• The additive process and checkpoints. Every two weeks we had a milestone in which we would have a next version of the game ready. Because we were more or less finishing added features to the game every two weeks too, it was possible to remove 60% of our game just 4 weeks before deadline without any trouble, giving us the opportunity to focus on what was truly important for the game and to prove the concept we had been working on in the past months. Fortunately there was enough room for this hacking and slashing – killing your darlings is painful, but we have to stay realistic!
• Implementing research into game design. Having one designer (read: one guy who takes the final design decisions) on the team that is also the man on the research appeared to work great. Because we did research specifically for game-related information and issues, a lot of data could directly be distilled into our game, e.g. the length of the game, how instructions work, calibrating, role of the therapist, etc.
• External help. There are always people who can do something better than you do. Asking for help is never wrong. I think we were very lucky to have Lies van Roessel as our supervisor as she got us help from all around.
• From exchange student to sound designer. I think none of us even though of Eri, our exchange student from Japan, becoming this good at audio design. She literally started with zero knowledge of audio and music in games and managed to fully equip our game with immersive game sounds and effect which most of them, she recorded herself. She created sound moodboards and already knew in the early phase of the game how it was supposed to sound like. Again, she couldn’t have done it without the external help of audio designer Richard van Tol, who gave her lessons and critique on her audio design.

Post Mortem: What went wrong!

• Scattered group. During the whole project, we had 2 part time programmers. If you have ever made a video game, you know where most of the work and effort goes into; code. We met the programmers two days a week which was the bare minimum, and emailed most of the remaining days. Eventually, I had to help the programmers with lots of game code to make sure we would make it, which was not the ideal setup since I was slacking on design tasks in the meanwhile.
  Beside this unlucky fact, a major mistake that we made was ‘finalizing’ the concepts of the game without the programmers involved. They missed most of the concept phase because of their busy schedule and thereby did not feel as much connected as all the full-time members. I wonder if there was anything we could have done to prevent this – the project had to continue and we couldn’t wait for the programmers.
• Unspoken expectations about each other. The tension was incredibly high sometimes because we did not talk about ‘what was normal’ at the beginning of the project. As the team coordinator, I tried to keep everyone motivated and effective at work, and though I had a good idea about what ‘hard work’ included. I mistakenly asked team members to stop having fun during our project days and found out that there are many different work styles one can have. If we had just gone through this quickly at the beginning, none of this would have been an issue.
• Few world iteration. We had a round world which made it particularly difficult for the world artist to iterate on it. And lets be honest, lack of motivation did not make it any better. It also came to my mind that, when you go into crunch time not fully motivated, you are going to have a problem finishing your work.
• Documentation. Nobody was checking the design wiki, I had a lonely time in there… All communication was done outside the wiki, which is not a problem at all, but it did make the documentation redundant. Art used their wiki to put together their images, which did seemed to work fine.
• Vision-less weeks during production. At some point in our process we stopped using our vision as the main argument of our choices. I think we were lucky that we eventually had the game vision that we wanted all implemented. Next time, I’d rather not leave it to luck and keep the vision of the game I’m working on in the back of my mind all the time…
• Mid-project Media Management students. I don’t know who at our school thought it would be a good idea to involve first-year media management students with the project while there was already good coordination and a steady planning. It was a stupid idea, they did not even show up most of the times.

Team KOMODO!

Supervisors:

Vogels! Exhibiting!

Many were interested in our game at the Cross Care Cafe, organised by Izovator.

Team KOMODO together. Francis his birthday was a lot of fun

At the Festival of Games 2010, our game was a huge success!

Toru Iwatani, creator of Pac Man, observes our hardware while playing the game

Totally unexpected, we win the Diamond trophy, 'Best-of-show' award of the Festival of Games, together with an iPad! Picture by Zuraida Buter...

High five with [Space], post your score below.

> Play Celebrity Fives <

By Adriaan de Jongh & Juliette Janssen.

What if a demographic group, for which we have so many trouble creating awesome games, would make games just for themselves? A female group of  game designers, artist and programmers that would create a game for just them – what would come out? As far as I know, this has never been tried before, I guess the game industry still remains a men’s world. But beside the female games discussion, what if a group of people that all love kite surfing would make a game to do just that? Or people with a dog fetish? Oh, I don’t want to think about that…

Anyway, if such group would make a game they love, a game in which they can share their love for the subject with others, where the fun of that group is transfered to any player, wouldn’t that be the ultimate hit? Hell yes!!!

I have a close to home example, one that shows that this theory can indeed apply. This years Global Game Jam, I participated with a team of which most members work or have worked at W!games, a game studio in Amsterdam. We all knew what it took to make a game and went into the project with the mindset to create a super awesome game. We threw in all the elements that the game we wanted to create would have and came to a concept really fast… All in all, it was the best process I had ever participated in, it went excellent. In the end, we had a game that was not far from the exact thing we had in mind and we all loved it. Because it was only created in 48 hours, we did not have the time to make it very accessible for other players, but after a few games, every player would get it and like it. Those players are the audience alike.

At the end of the day, it’s about getting your game on the table. It must be well thought through, look good and must play good. I think development phases can mean a great deal if you wish to achieve that and phases can help you and your team to focus on what the phase is for. But then again, than it is not about your game anymore, it is about completing the phases and completing the process.

I believe that if you focus on the steps that must be taken in order to create the game, there is no confusion and you will never be ‘stuck’ in a previous phase. I have never done a project in which the design document was completely written and final the moment the production phase started – another problem of development phases is that there is always an overlap. And that is not going to clear things out.

This is what generally goes wrong with student games – school requires the game to be created by clear phases that must all be completed before the other. The problem is that for most students, this suggests that when you are in the production phase, you don’t have to work on your concept anymore. And beside that, writing complete design documents based on assumptions is never a good idea – the same goes for planning. This is the reason why most student games are either crappy or not finished.

You must be thinking about SCRUM now, but that is on a whole different level – SCRUM does not let you look into the the coming months, only into a week or so. Thats why I like the word ‘milestone’ – milestones don’t need names, they only exist when a certain level of production is (or is going to be) achieved and they are great motivational boosts when you are near or at one. Now, take it from here.

Games are very strong if it comes to binding costumers (or players) to their experience and maybe even better at creating memorable experiences. Almost nobody reads through policies and terms of use – a game with these simple lines of text at its core would surely make these important aspects much more present.

Why can’t brands be more game-like? Why can’t, for instance, people ‘fight’ for their products? Why are brand products often not related to each other in terms of the relation between the product and the costumer? Why don’t brands have achievements and why are costumers not rewarded with titles when they achieve them? Why is there no interaction between the costumers who bought certain products from a brand? I could instantly think of a dozen examples of how to turn a brand into a MMRPG!

I can not imagine the examples I called have not been tried, but I haven’t found any game or brand yet that has become successful in it.

Please comment, this is presumably a very interesting topic.

http://2dboy.com/2009/10/19/birthday-sale-results/

The first thing I realized when I read through the results was that people are currently paying money for games they have not played before. And that is somehow strange, because how can we know its value when we have no idea of how much it will entertain us? I find it a dangerous thought that the amount of money that you have to pay resembles the amount of joy you will have from the game. And even worse is the way we think about a game that we have already bought, see http://goo.gl/eBqX for the reasoning. So not only are we probably paying way to much for games, we think about them much better when we pay a high price.

The second thing that crossed my mind was Runescape. They have a pretty good pay-model which would let people play the game, let them see what their fun is worth – and if they like it, they can pay for it and receive even more fun!

What is interesting about the World of Goo experiment is that they ask the player how much they think the game is worth BEFORE they have played it. So this experiment is all about expectations. And this simple thing is what all games have to cope with. It seems very interesting to do some more research into expectations and how to raise them. Ain’t that what marketing is all about?

An interesting next step would be to ask a player how much a game is worth after he has played it. How should that work? Interesting thought.

I have a confession to make – and it is a confession because I am ashamed of it. When I started playing World of Warcraft when I was 14, I immediately became an addict. My life became World of Warcraft 24/7, when I wasn’t playing it I was thinking it, when the servers were offline I was watching movies of it, I spend a minimum amount of time with my friends and worst of all – and the reason I quit – I felt bad that I was socially underdeveloped compared to other kids of my age. In other words, I had no girlfriend. And the moment I quit, I knew that I threw away the two years of my life that I played the game.

But now that I have grown up (a little), I have started to see things from a different perspective. These years might have not been as useless as I thought, I think I even have learned a great deal from this game! And lets start with just one of these: world economy. I will need to explain the economy in order to let you understand my point, so here comes the intense reading:

In a way, the world economy in World of Warcraft (WoW) is exactly same as the economy in our world. In WoW, money is rewarded after a player has killed a unit in the game world. A player can not only use this money to buy items that are necessary in order to advance through the game, he can also buy items that make the player more powerful. This can be done through an ‘auction house’, a marketplace in which players can purchase items by bidding on it or buy them out of the auction house for a higher price. Items are also dropped by units in the game, and because of their scarcity, these items could have a great value in the auction house. Players often hunt loads of units down in order to find valuable items that they can sell in the auction house, it is exactly like demand and supply.

Players also have the ability to choose between ‘professions’ that enable the player to craft different kinds of items, but because a player is never able to craft all the different kinds of items, another economy arises: players offering services to each other for small fees.

And then there is the underground market, which goes far beyond the game itself: buying in-game currency with real-world currency. Beside the Japanese companies ‘grinding’ (repeatedly killing the same enemies) for money and selling it in real world to real people and trading the money in-game, people even bought 3rd party software that would play the game for them and make sure the player would have a constant flow of income. Even today, years after the release of the first copies of WoW, Blizzard is still trying to ban all of these companies and programs.

If a player wants to become a strong and powerful player, he must know this complex system from the in- and outside to use it in a efficient way and to take an advantage out of it. And from my experience, almost all player in WoW know the drill.

Now that you know how the world economy of WoW works, I don’t think I have to tell you in what way it looks like our economy. Almost every part of the economy in WoW can apply to a part of the economy in our world. From the constant flow of money that players receive from their actions to the scarcity of items, from analyzing market behavior to selling your services, all these things can be translated directly to real-life examples.

But economy is not all. World of Warcraft contains one of the strongest forms of communities I have ever experienced. These so called ‘guilds’ are organized groups of people with hierarchies that have a shared goal, which can vary from ‘having fun’ to ‘raiding dungeons’ in order to become stronger as a whole. These communities demand things from players that no other game has ever achieved, including time, money for website hosting, taking effort to recruit other players, creating fair hierarchies and rewarding players for loyalty. Joining a guild is very much like a job interview, extremely difficult when you don’t have the experience, very easy if you have the right friends.

And another thing is the Player vs. Player (PvP) combat system. Players can team up with 1, 2 or 4 other players and be part of an ongoing competition between each other. In order reach the top in these competitions, you need a really strong team with an insane amount of experience. How to create and organize such a strong team is a tremendous effort.

There is so much to learn from World of Warcraft, dare I say more than any other serious game has ever learned anyone. And I believe World of Warcraft is not the only game that is teaching so many people. Games have the great ability to show players how certain systems work. If only the serious games market would focus on this fact instead of creating ‘educative’ games.

First of all, is there a difference between a vision and a goal? I think there is, and it can be found in the fact that a vision is much more general and can be interpreted in many, many ways. This is what sets the direction to your designs. The goal, on the other hand, is what narrows your vision, adds constraints to them. For example, if the vision of your next game would be ‘to create a multiplayer game with high dependency on each other’ it would be very broad. The concept could be used in a whole lot of of totally different games. To narrow it down, your goals could be ‘to create a story-intense game’, ‘to give the player interesting destructive choices’, ‘to let the player fully customize the characters’, etc.

Bear in mind that a game does not need a vision and a goal, but it does make it a lot easier for the team and the designers to have such for your game. Why, you ask? Let’s start with a direction for your game:

Imagine yourself working in a big team: everyone has his responsibilities for the parts that have to be done. Most of these parts require you to temporarily ‘narrow’ your vision, and a dangerous pitfall is forget what the product that you are working on has to achieve – and maybe you come up with things that do not fit that idea. A general vision or goal can bring you back to the level which tells you what you want to achieve. And this doesn’t just count for individuals, but for smaller parts of a team too. The different departments in a game studio, for example, are often specialized and focused on one aspect of the game, and what brings all these different focus points together is the direction and the vision of the complete game.

What this last thing means for a game studio is that everybody has his expectations of the final game, and this can be positive or negative for your final product. Positive if the vision of the game inspires the studio and is a little ambitious but achievable, negative if your vision is not challenging your studio in any way.

So having a direction for your game can help a lot, but how can constraints help you or your team to create better games?

A good example would be the indie games industry. Independent game studios have a sh*tload of constraints: time, money, resources, no business relations, marketing skills, you name it. But still every month, indie game developers manage to create games that reach the mainstream audience and sell thousands of them, some of them comparable to AAA titles. So how do they do it? How do they manage to create wonderful games with so much constraints?

I think the answer lies in the solutions of these problems: studios must come up with creative solutions to do ‘more with less’, to use everything they have got in the most optimal way. And that optimal way does not have to be the most straight forward way. Although constraints might sound like an inability at first, if you think again, it can also be used the other way around too: constraints can be used to help you focus on what is really, really, really important for your game. If you have no time and no money, but still want to make a great game, it has to be cheap and easy – and now that you know that you can use this inability to create a better game, you could even see it as an enormous challenge!

Once you realize that constraints can also help you instead of just blocking you, it’s like a new dimension opening to you. Now that you know where to focus on, you can see the bigger picture much easier and directly know what you can and can not do. If something doesn’t fully support your vision, leave it out! If something blurs the vision of your game, leave it out! If an adorable extra feature takes too much time for your programmers to make, leave – it – out!

The goals and vision of your game can simply be tools that you can use in your team. These tools give your team a direction and constraints. And if used well, these two small things might make the difference between being successful or not. So think about it: do you want to be successful?