DenkanStoos Website

DenkanStoos is growing further and it is time to spread the word. Some guys volunteered to find the right channels to do so, namely Björn Lindner (Xing) and Nikolaus Schlemm a.ka. Nikl (coder nostra). Status is that some tools were evaluated but there is no final decision yet. The plan is to have some kind of landing page an a collaborative tool (CMS or wiki) in place till the next meeting.

Employee Exchange Program

Knud Kegel (CoreMedia) and Yves Stalgies (etracker) presented the result of the employee exchange program they initiated. They both sent one employee each to work for the other organization for three weeks. The initial intention was to use this as a “retention program” to provide people new experiences without having to quit their current job. In the end it turned out that the knowledge transfer and networking effects felt to be the most valuable outcome. Anyway, everybody seems to have enjoyed this experiment. CoreMedia and etracker are going to do this again – maybe/hopefully more companies will be interested to take part.

Management is dead: Impulse by Niels Pfläging

The second part of the evening was moderated by Markus Wittwer (oose). We started with a talk by Niels Pfläging (BetaCodex Network). Niels authored some awesome books on e.g. budgeting and leadership. He is a pioneer within the field of new ways of leadership. At least my personal interpretation is, that Niels focused explicitly on the gap between agile methodologies and scientific management  long before Stoos Gathering.

Niels explained why command-and-control and the separation of thinking and acting / administration and workers. In his opinion, management in the tayloristic way is dead: although most companies still have pyramid-shaped org charts and hierarchical structures, many of the most successful companies only use hierarchies for compliance and focus on their social network and their value chain. Actually Niels described the latter as a third dimension next to formal and informal structure of a company. One that is not understood by most companies and the toughest to handle of the three. I never thought about it this way and will definitely investigate further

After this intro, we discussed about this impulse in small groups and presented the results. We finished this part of the evening with a fishbowl where we talked e.g. about the relation between the agile movement and management and what it means to change organizations in a healthy direction.

After the fishbowl the “official” part was done and people chatted for another 30 minutes or so. The event was over at about 22:30 which I think is a proof that people enjoyed it. I did for sure – looking forward to the next meeting, probably end of June.

In the first part of my blog article, I gave a little introduction on the concept of Flow and its dimensions by the Hungarian psychologist Mihalyi Csikszentmihalyi. Even though this theory is not linked to video games or User Experience, flow is a much discussed state people strive for, which leads to the question, how flow can help us in the game development and especially in User Experience Design.

Read the whole article

Abstract Part II: Flow in Games

In the second part I introduced different approaches that transferred the original flow theory to the games industry. Different concepts like the Game Flow Framework (Järvinen et al. 2002), the Game Flow Questionaire (Sweetser and Wyeth, 2005) or another game flow model by Kiili and Lainema (2008) were described to find a connection between Flow and UX.

Read the whole article

Part III: Flow and User Experience

And here we go for some final thoughts about Flow in Games. I already indicated, that Flow and User Experience are closer than we might initially expect. When conducting research for my thesis, I discovered a very small, but (at least for me) quite helpful article written by Marc Hassenzahl (2008), in which he described this special link between Flow and User Experience I was actually searching for in numerous articles.

User Experience, compared to Usability, includes emotions, perceptions and other psychological aspects, while interacting with a product or service. For Hassenzahl, these emotions are a result of an (inter-)action, thus he asks for the causes, how these emotions occur – in other words, how UX is “made”.

Hassenzahl assumes that people perceive interactive products along with two different dimensions.
The first one – the pragmatic quality – calls for a focus on the product and refers to the product’s perceived ability to support the achievement of do-goals, such as finding a book in an online bookstore.
The second dimension – the hedonic quality – calls for a focus on the Self and refers to the product’s perceived ability to support the achievement of be-goals, such as emotions based on basic human needs like success, personal growth or self-expression.
Hassenzahl argues that the goal of interacting with a product is to achieve those be-goals. To make it a bit clearer: If the UX of a product is good, people feel autonomous, competent or anyhow stimulated. Pragmatic qualities, such as Usability can facilitate the achievement of these feelings.

A potential critique of this model is that people usually don’t play games because they want to feel competent or autonomous, but rather to relax or to feel good. So the goal of the activity is the (good) experience itself – not any deeper psychological construct. But as Hassenzahl explains (and I actually agree with him on this), this positive experience is still derived from something and it may not matter if we want to feel good or if we want to fulfill our need for relatedness – in the end our experience still stems from fulfilling a basic psychological need.

Therefore, understanding basic human needs and taking care of a good Usability might help us to create a good UX – nothing really new, right? But what I found interesting is, that Hassenzahl uses this very basic description to link Flow to User Experience. He describes Flow as “a positive experience caused by an optimal balance of challenges and skills in a goal-oriented environment. In other words, flow is the positive UX derived from fulfilling the need for competence (i.e., mastery); it is a particular experience stemming from the fulfillment of a particular be-goal” (Hassenzahl 2008, p. 2).

Reading Hassenzahls article does not only help me in getting a better understanding of experiences per se, it also shows me, that Flow is not that far-off from User Experience as I initially thought. It is not this vague and blurry concept with different dimensions that again are hard to define. Actually, it is something I am confronted with every single day – especially in the games industry, where Flow might receive more attention than in other industries. Yet, don’t get me wrong – I don’t want to simplify or underestimate years of research – but as UX Architects (designers, specialists…) I think we are on the right track by considering Flow, which is, at least if we trust Hassenzahl, “just” a very special shaping of what we create every single day.

Let me give you a short example: Presented in the chart below I basically compared the different items of two questionnaires – the Heuristic Evaluation of Playability (HEP – Desurvire et al. 2004) and the the Game Flow Questionnaire (GFQ – Sweetser and Wyeth 2005). As you can see, the HEP, which generally stands for UX concerns, covers almost all Game Flow dimensions (except for the Social Interaction), which is totally logical as UX Specialists just try to build a good user experience – and what is flow if not a good, or as Czikszentmihalyi entitled it, an optimal experience?

In the end it’s all about the focus we take during our analysis. In this regard, it is important to remember that User Experience cannot merely be seen as an offshoot of usability that adds a focus on emotions to the previous concept. In fact, while usability focuses on how usable an interface is, user experience does include usability, but also encompasses other dimensions about the user’s interaction such as desire, joy, credibility, usefulness, trust and more. Especially when we talk about or analyze user experience in games, it is important to concentrate on dimensions that are directly linked to an experience and to stop overrating Usability. In short: Usability in a game is like money in life – if you have it, you don’t care! Therefore getting rid of all Usability issues is not going to make your game a better game – it will just aid you to make it less frustrating and annoying .

So, what does this mean? Well, I can only speak for myself: I know, that User Experience, and especially User Experience in Games is a very juvenile area of expertise with yet to be defined concepts, methodologies and standards. All I know – as most of UX Specialists do – is that usability is simply not enough. Yet, even literature that can be found about UX in games (e.g. Desurvire 2004) could not really tell how it can be determined. Thereby, during months of research on UX in games for my master thesis I was always missing this light bulb moment and it almost looked forlorn, until I made the connection between UX and flow.

Today, I have an entirely new understanding of what user experience in games means and I am very eager to transfer these approaches and definitions to my daily work – you might hear from me soon

Related articles:

Hassenzahl, M. (2008): User Experience (UX): Towards an experiential perspective on product quality. (http://www.marc-hassenzahl.de/pdfs/hassenzahl-ihm08.pdf)

Desurvire, H.; Caplan, M.; Toth, J. A. (2004): Using heuristics to evaluate the playability of games. In: Extended abstracts of the 2004 conference on Human factors and computing systems – CHI ’04: ACM Press, S. 1509–1512. (http://www.behavioristics.com/downloads/PlayabilityOfGame-04CHI-Desurvire.pdf)

Sweetser, P.; Wyeth, P. (2005): GameFlow: A Model for Evaluation Player Enjoyment in Games. In: Computers in Entertainment 3 (3), S. 1–24. (http://cgit.nutn.edu.tw:8080/cgit/PaperDL/HGC_120223075158.PDF)

We have some applications with clear and definable responsibilities which interact to support company-related processes. This is not a monolithic application but rather loosely coupled services. A significant added value to decouple the service brought us the usage of RESTful HTTP. The resulting API is protected with the OAuth2 protocol.

The published PHP-SDK can be used to access these kinds of APIs. It is straightforward and in the early stages of development. However the project builds upon state-of-the-art standards and techniques. So, for example, the PSR-2 coding style guide is used as PHP coding conventions. The installation and the dependencies can be managed with Composer. In order to write and execute the tests, PHPUnit is used.

We look forward to read your constructive “GitHub issues and pull requests”.

In the first part of my blog article, I gave a little introduction on the concept of Flow and its dimensions by the Hungarian psychologist Mihalyi Csikszentmihalyi. Even though this theory is not linked to video games or User Experience, flow is a much discussed state people strive for, which leads to the question, how flow can help us in the game development and especially in User Experience Design.

Read the whole article

Part II: Flow in Games

Compared with many years of scientific research in other fields, applying the flow theory to computer games is still quite juvenile. The approaches basically reach from “Well, flow is important” up to first steps into different evaluation tools to measure flow in games. So let’s have a quick look at these different approaches:

The first specific remarks on flow in games can be found in research from Järvinen and his colleagues in 2002. They used Csikszentmihalyi’s flow concept to draw up a so-called Game Flow Framework. They determined that many flow dimensions can be used in terms of computer games and elaborated a four-part analyzing tool to evaluate playability in games. Playability here is understood as a connection between usability and flow on the one hand and a collection of criteria to evaluate gameplay and interaction concepts in a game on the other hand. To sum this up in a less academic way: Järvinen and his colleagues had the idea to use flow in games and found a connection between flow and playability, usability or general user interaction, but did not find any definite criteria for flow in games.

Three years later (2005) Sweetser and Wyeth published a list of different points, which they called Game Flow, in order to reach flow in games. They concentrated on specific game related literature, not least from the research fields of usability and user experience, and combined different measurement tools with the flow dimensions to create a number of heuristics to evaluate flow in games. With eight sections: concentration, challenge, player skills, control, clear goals, feedback, immersion and social interactions, they proposed a list that translated the not-game-related flow dimensions from Csikszentmihalyi into a first draft of game related flow heuristics. Sweetser and Wyeth received wide spread attention with their Game Flow – at least in academic circles – as they laid the foundation of what we call today: Flow in Games.

So what happened with this foundation?

Well, I personally enjoyed following two different researchers in my thesis. The first one is Kristian Kiili. Even though he concentrated on flow in educational games, therefore on flow as a positive effect on learning outcomes, he also discussed the flow concept in general. Together with his colleague Timo Lainema he worked on a three-part flow model that first of all separated the flow concept in Flow antecedents (how can a flow state be reached), Flow state (the actual experience) and Flow consequences (which are in his researches the learning outcomes). It just seemed logical to me to concentrate on the Flow antecedents (which are defined as clear goals, immediate feedback, gamefulness, frame story and playability), because it wouldn’t make much sense to talk about flow, if we didn’t understand how it arose. As Sweetser and Wyeth did in 2005, Kiili and Lainema developed a framework to evaluate these Flow antecedents. (Unfortunately I never found the related questionnaire, so if anyone got it, please contact me )

At this point you might have the same questions in mind that I had back then when writing my master thesis and digging deeper and deeper into the academic flow discussion: How can a state be “created”, if it is described as a state that actually “occurs”? How can there be measurement tools telling you flow is not likely to occur due to negative test results or flow is very likely to occur due to extraordinary good test results? Is there a possibility to measure flow?

Well, if you have the answers to these questions, you should definitely think about changing your career and become a researcher (if you ain’t one already, otherwise you are absolutely pursuing the right career) . But be prepared that there are already people out there searching for answers to this particular measurement issue. This leads me to the second researcher I would like to introduce you to real quick.

His name is Lennart Nacke and he is trying to prove a theory that has never been scientifically proven before: the flow theory itself – the state I am talking about for at least two articles and others for around about 40 years now. Even though we all agree that this state exists and some among us have even experienced such a state – we still focus on experiences and stories from different people, which make flow a very blurry concept. While the first group of researchers concentrates on different heuristics or criteria how to initiate a state of flow, Nacke’s approach is to understand what flow is and how this state can be measured.

So what did we learn today: Flow is still an enjoyable state and in the past 10 years researchers have tried to translate this concept in order to employ it in the computer game development industry. The different approaches show, that it is not a question about, if such a transfer is possible, but mainly about, how this transfer can be made. The fact that most of you might not even have heard about anyone of the researchers I named before simply shows, that we are still somehow far away from having a cool, new measuring tool …

Yet, are we really that far away? Give me chance to go even further: We are talking about experiences, right? And Flow is somehow an experience that people strive for – so let’s just say it is a good experience or an enjoyable experience. And now remember that guy you all know quite well, Mr. Don Norman, who taught us important lessons about user experience… Even though User Experience  does not describe Flow in detail – it is really not that far away as we think it is, but let me show that to you next time .

Part III: Flow and UX

Related articles:

Järvinen, A.; Heliö, S.; Mäyrä, F. (2002): Communication and community in digital entertainment services. Prestudy research report. Tampere, Finnland: University of Tampere Hypermedia Laboratory.

Sweetser, P.; Wyeth, P. (2005): GameFlow: A Model for Evaluation Player Enjoyment in Games. In: Computers in Entertainment 3 (3), S. 1–24.

Kiili, K.; Lainema, T. (2008): Foundation for Mesuring Engagement in Educational Games. In: Journal of Interactive Learning Research 19 (3), S. 469–488.

Nacke, L. (2009): Affective Ludology. Scientific Mesurement of User Experience in Interactive Entertainment. Doctoral Dissertation Series No 2009:04. Karlskrona, Schweden: Blekinge Institute of Technology.

So what is this all about? Stoos Gathering was a quite spontaneous meeting of people with similar experiences and goals in the field of management and leadership. My perception is that these guys who met in the small town “Stoos” in Switzerland in early 2012 all recognized one thing: on project level, we have modern tools and processes. We have the Agile Manifesto, we have Lean Software Development, we have Scrum, we have Kanban, we have the Software Craftsmanship movement – the list of awesome stuff is endless. But on management level we have… shareholder value? MBO? Bonus programs? There seems to be a mismatch. I personally encountered this mismatch over and over again working for several IT companies.

Stoos Gathering hit a nerve I think. One consequence was, that more events labelled “Stoos” popped up, like Stoos Stampede in Amsterdam in summer 2012 which some of us from Bigpoint had the pleasure to attend. So-called Satellites formed: communities of interest all over the world dealing with “stoosian” topics. DenkanStoos is a Satellite located in Hamburg. We meet every couple of weeks to discuss, share new things we tried and test new tools.

A good source of new tools is Management 3.0. It is an approach to define how agile leadership can be done. It was created by Jurgen Appelo who also participated in the Stoos Gathering. One of the tools Jurgen provides is Meddlers. Meddlers was derived from “Die Siedler von Catan” or “The Settlers of Catan” in English, hence the name. It is a game consisting of different cards representing teams, stakeholders and team members in different roles. You can use it to model team structures without thinking about org charts or hierarchy in the first place. The actual goal is to make organizational dependencies in terms of communication and interaction visible.

Last year the DenkanStoos group decided that playing Meddlers would be a nice thing for our January meeting (01/21/2013) and since we used Meddlers already for different organizational challenges at Bigpoint, I had the pleasure to present the game to the group. In three teams we created different models of a new department in an imaginary company. After that, we checked if these models would work in three critical situations:

• Overambitious development of a new feature for a given software product
• Rewrite of a messed-up software component which requires different teams to work together to meet the schedule
• Software development under pressure while there are too few people to deal with it

Meddlers in action – ©CSH

In the end we found 3 very different results with different focus:

1. Cross-functional teams reflecting the key components of the target software architecture
2. Two-tier organization consisting of R&D groups for prototyping and development groups for productization
3. Matrix-like organization consisting of equally designed, cross-functional teams and communities of practice for knowledge transfer

All these models revealed a special attention to the communication between the business side and the technical side of our imaginary company. We saw many hubs and proxies meant to simplify and direct communication. In my eyes this is not too surprising, since I believe most problems in business start with poor communication.

After finishing our models, we shared the results and started an open discussion about it. Regarding Meddlers, I think it is not a 100% and not even an 80% solution to define company or department structures. But it is an excellent tool to make pain points very visible early thus providing a solid starting point for further planning. Even better: using this tool, planning of these structures allows participation of everyone affected by them. If you are ready for this kind of democracy

Nils talking about Meddlers – ©CSH

I think we had a great evening in the rooms of ergon, kindly provided by their CEO Daniel Kresin. Christine S. Hartmann did a great job chairing the event, she also took the pictures. I am really looking forward to our next meeting in March hosted by our neighbours at Xing.

References
Find some further information about Stoos Gathering here:

• Stoos Gathering: More Ideas For Jumpstarting The Transformation Of Management
• Invitation to a cool event (later known as #Stoos)
• Stoos: Facilitating A Tipping Point For Organizations

In this article, I will try to reveal current conventions by comparing a multitude of games from different genres, identify requirements for a proper placement and design of the mini map and provide design recommendations, so that next time the “where?” question arises, we are faster and more certain in out answer.

Why games do or don’t need a mini map

My initial thought was that – historically seen – the mini map is an evolutionary branch from the world map, as known from adventure and role-playing games. However, I did not find any clear evidence supporting this theory. Early C64 racing games already included mini maps (e.g. Pitstop, Buggy Boy, Night Racer). Nevertheless, the main function of world map and mini map are similar: Providing orientation, hence easing navigation.

While there are game genres, which manage to get along without a mini map very well like Fighting, or Adventure games and, obviously, Puzzle, Board and Card games, most genres nowadays make use of mini maps:  Action, Shooter, RPG, MOBA, Construction, Sports and Vehicle simulation games. Of course there are also exceptions – especially very linear games, such as Heavy Rain or Call of Duty: Black Ops 2 (Single Player), usually do not use mini maps.

Current conventions

Looking at games in general, the only thing that mini maps have in common is the perspective. Mini maps show an abstracted view from the bird’s eye perspective. Furthermore, I recognized genre-typical locations for the mini map. The following conventions are based on a sample size of N=66.

• MOBA games place the mini map exclusively at the bottom.
• Strategy games use mostly the bottom left for placing their mini map.
• MMORPG’s place the mini map exclusively at the right and mostly at the top.
• Racing games use predominantly the left as mini map location.
• 1^st person shooters use also mainly the left side for placing the mini map.

There was no genre in which games have their mini map placed on exactly the same location (like bottom right or top left). Even games from the same series are not consistent (not even when the same studio developed the games).

The scope of the mini maps differs per genre: Action, Shooter and Role-playing games show only a limited field of view including your immediate surroundings (or your current sector), whereas in Sports, MOBA and Vehicle simulation games, the mini map functions as a miniaturized world map. Which makes sense because the game world is much smaller in the latter game genres. In games of the first category, the scope is sometimes adjustable to the extent that zooming out of the mini map results in opening the world map. Interactions are sometimes also twisted around: Setting a destination (path) in the world map can be mirrored in the mini map. Funny to notice is also a design difference: Mini maps in RPG’s and Action games (1^st and 3^rd person) are most often placed in a circular rather than rectangular frame. I suspect the reason to be is mainly aesthetics. Mini maps in games with big virtual worlds often include cardinal directions and a round mini map fits well the metaphor of (a round shaped) compass.

Recommendations

Does it make much of a difference, where the mini map is located? In some cases, yes, it actually does! Learning the UI is one major part of a game and in most cases there is no better or worse between right and left. Though, fast-paced games are recommended to place the mini map on the left (at least from a western cultural perspective), as it gets more visual attention than the right side¹. Most games follow this rule. In this sense, a badly placed mini map can not only lead to prolonged reaction times but also to miss-clicks and miss-perceptions (depending on where you place other HUD elements). In order to avoid that, prevent long distances between core game elements and the mini map. This will decrease effort and time to look on the mini map and increase the peripheral visual attention for the mini map. In this sense, it is also recommended to divide areas of the UI in pure information and interaction (e.g. top for information and bottom for interaction). Depending on if your mini map is interactive or not, you should place it in the appropriate area.

Here are some general recommendations. The word “general” implies that it might not fit perfectly to every game.

How should a mini map look like?

• Keep in mind where genre-typical games from the competition have their mini map (see current conventions): Some core user might get used to it, develop a preference and therefore be annoyed if they have to learn a new positioning.
• Do not cover up essential parts of the playfield. An exception is when the mini map is displayed by a toggle function.
• Integrate it well within the UI/HUD in terms of proportions and aesthetics.

Assure good readability!

• Choose your colors carefully: Keep in mind vision impairments such as color-blindness.
• Use high contrast between distinct elements, e.g. allies and enemies.
• Build on known metaphors for your sign language, e.g. a house for your base/home. But keep it simple! Small icons have to be distinct in order to be recognized and understood immediately. If you cannot find an appropriate metaphor, then rather rely on known geometrical forms than on fancy symbols. In the end, no one expects more than dots.
• Keep in mind the scalability!

Which information can a mini map provide?

Must have

• Barriers: Usually represented by dark parts on the mini map, while accessible parts are portrayed brighter. In general, the color white is associated with importance while black is mainly ignored.
• The player’s position
• Enemies’ and friends’ positions
• Points of interest, e.g. checkpoints, domination points, buildings, save points, traders etc.

May have

• Fog of war
• Unit status, e.g. wounded or dead unit members
• Additional terrain information, e.g. altitude differences or other levels

Sometimes, the mini map is used as a hallstand for mini map unrelated HUD icons (e.g. a health bar). These are intentionally disregarded.

In case of large virtual worlds

• A peripheral arrow, showing you where you have to go. Plus, additional arrows or other symbols representing important points, which are not visible yet.
• The four cardinal directions (plus the four ordinal directions and eight further divisions)
• Your sector’s, city’s or whatever’s name

 
Which interactions can a mini map allow?

• Navigation through the mini map: Setting waypoint by one click and/or drawing the path with the cursor (e.g. Strategy and MOBA games). Only if the map is not transparent.
• Setting various kinds of alerts (Pings) like Target or Retreat (especially in multiplayer games)
• Tooltips
• Zoom out/in
• Change the map segment by mouse drag
• Change between a fixed and a rotating map

Did I forget something? Just let me know by posting a comment!

References
1. http://www.useit.com/alertbox/horizontal-attention.html

We use Icinga in combination with Check_MK to automatically provision our distributed monitoring setup throughout our datacenters. After doing some code cleanup and extensive testing it has been approved for a public release. Please check our Icinga Github respository for the latest version. Next is the development branch, Master is the stable branch pushed to by our build process after passing all tests.

We have also split off two other cookbooks used in Icinga: pnp4nagios and rrdcached. They should run standalone with some adjustments to the appropriate Nagios/Icinga configurations but are really designed to work with the Icinga cookbook.

If you would like to try it out, Vagrant is fully supported (when using the Chef Solo search library). With some effort you can even monitor a live setup from your Vagrant instance provisioned via Chef Solo.

If you are having any issues or would like to improve the cookbook feel free to help us out with pull requests!

Complex, or not complex: that is the question

I won’t start with an introduction about what complexity is or is not. I think we all (we, who play games) have a feeling for what complexity is, especially when we encounter it in the games we play. In this blog post I am referring to the complexity of gameplay only (in the sense of complex gameplay mechanics). Of course, there are more levels, on which a game can be complex. I propose the following classification:

• Gameplay complexity: Characterized by sophisticated gameplay mechanics including interrelations between different in- and output variables (Tower Defense <->  Anno).

• Narrative complexity: Elaborated decision trees with impact on key elements of the game (Super Mario <-> Heavy Rain).

• Skill complexity: Requires fine dexterity and accurate timing in the execution of physical actions to manipulate game states (Minesweeper <-> Street Fighter).

• Cognitive complexity: Includes higher cognitive skills like spatial & temporal mental transformation, planning and reasoning (Tetris <-> FoldIt).

But let’s get back to the topic: Imagine you have the honorable task to design a game. How many features are too little and how many are too many? How complex must your game be to squeeze the most fun out of it?

There is one evil superstition circulating, that casual gamers demand simplicity and core gamers complexity. Although this might be true in many cases, explanations are not theory-driven but occur in hindsight. Furthermore, no one really knows how to define a casual or a core gamer. But before talking about the when and how, let’s talk about the why.

Complexity and fun: a love-hate relationship

The blog post prior to this one² discusses the concept of Flow³. For Flow (the mother of fun as we could call it) a necessary condition is the right balance between challenge and skills. Obviously, an increased complexity comes often with an increased level of challenge. And when we use fun as “just another word for learning” (like Raph Koster does in his book “A Theory of Fun for Game Design”⁴), we can assume (and as gamers we really know) that the skill factor is successively improving as a function of playtime. So what does this mean? Complexity increases fun and contributes to long-term motivation when it unfolds at the right time and at the right speed. But beware of exposing too much of it too early: you will make your users run (not in-game but away from it). This is exactly what tutorials and balancing (the guidance of mastery) try to prevent.

Complexity: getting the right dosage

One main principle in user-centered design is KNOW YOUR USERS. This doesn’t mean that we simply label our users as core or casual gamers. A tactic I suggest is to develop research-based personas. To identify the right degree of complexity for your game, your persona template should include:

• Basic demographics, such as age (for spotting limitations in cognitive abilities and information processing) and gender (for gender-related preferences).

• Preferred platform like browser or mobile (which has an influence on the expected mean playtime per session and the design-relevant ease to access/use for complex features)

• Personality attributes like frustration-tolerance and need for cognition (to determine how eager for rewards your users are and how to design the balancing curve).

• Of course you can add more points, depending on what makes sense for your game vision.

Notice, that this data can be helpful to build a conclusive theory-driven game design but is no guarantee for success. No matter, how detailed your use cases are and how well you mastered the method of cognitive walkthrough, you still have to do extensive user testing in order to get it right.

References

1. List of best-selling video game franchises, http://en.wikipedia.org/wiki/List_of_best-selling_video_game_franchises, 06.11.2012.
2. Flow, Games and User Experience – Part 1, http://blog.bigpoint.net/ux/flow-games-and-user-experience-part-1/, 06.11.2012.
3. Csíkszentmihályi, Mihály (1975), Beyond Boredom and Anxiety, San Francisco, CA: Jossey-Bass, ISBN 0-87589-261-2
4. Koster, Raph (2005). A Theory of Fun for Game Design. Paraglyph Press. ISBN 1-932111-97-2.

Since I happened to write a thesis about Flow and User Experience in Serious Games I realized that this theory is not only a ground-breaking and much discussed academic phenomenon, but also something that is barely included in my personal working field, even though it should be.

But let’s start from the very beginning. Mihaly Csikszentmihalyi is a Hungarian psychologist living in the United States. He is almost 80 years old and professor emeritus at the University of Chicago. When he started his research in the 1970s he was surely not analyzing videogames, nor was he trying to invent complex theories. As a psychologist he simply tried to determine, what makes people happy.

For that, he interviewed people all over the world about their own happiness or special moments in life. There he found out, that there is this one special experience people describe a “state in which [they] are so involved in an activity that nothing else seems to matter; the experience itself is so enjoyable that [they] will do it even at great cost, for the sheer sake of doing it“.  He ends up calling this enjoyment “optimal experience” or as it is known nowadays “flow”. From then onwards he starts research on when and how these moments occur.

His results are somewhat logical; to sum it up, Flow occurs…

• when activities are perceived to be challenging.
• when people are fully concentrated on the task and they stop thinking of themselves as separated from the immediate activity.
• when goals are clear and feedback is provided, whereas the content of the goal or the feedback is depending on the peoples interpretation.
• when everything besides the activity becomes totally unimportant and people feel a moment of presence.
• when loosing seems to be impossible.
• when people lose fear or scruple and stop thinking about themselves.
• when time perception is changed.
• when activities are autotelic and people just do them for the sheer sake of doing it, not because of any result.

So much for the theoretical part – but in practice people are individuals, everyone has his perception of life, his own experiences and feelings and also his own definition of flow or an optimal experience. Flow is therefore not only something that can hardly be defined – but it is also something that is based on people’s own interpretation – and as we all know people’s interpretation may vary greatly.

So what does this tell us?

1. First of all Flow in his original theory has quite nothing to do with videogames or User Experience.
2. Second, Flow is something that happens to people and that can be described through some dimensions, but is not a defined state that can be measured through any common metrics.
3. Third, Flow as an academic theory has never been approved in the last 30 years – so why should we bother?

Well, in the end Flow is an enjoyable state people strive for and games should be enjoyable – so we should skip the academic discussions and have a closer look at how Csikszentmihalyis theory can help us in the game development and especially in the User Experience Design.

Part II: Flow in Games

Some days ago I had a rather confusing experience with an ATM (automated teller machine that allows people to withdraw cash from their bank accounts) around our office that gave me the motivation to write about this topic and start a series that will cover some good or bad examples from the world around us. When I told my colleagues I was to write about ATMs, all of them had something to add, but more of this later. Let’s start at the beginning.

I’ve been using my debit-card for many years now, all around Germany and abroad and I would say withdrawing money from an ATM is a quite automated task for me by now. I don’t really think about the process or read instructions anymore, because I regard myself an experienced user in this area and, as I thought, “all ATMs behave more or less the same”.

Until this very day, when I inserted my card into an ATM as usual and it just gave me a general error message: “Card not accepted”. It took me several minutes and a couple of attempts, until I realized that nothing was actually wrong with my card, but I was trying to insert it the wrong way. It seems like EVERY ATM I was using in the past years wanted the card with magnet stripe bottom left, but this one bank had its ATMs configured differently. Here, I had to enter my card with the magnet stripe pointing top left. They even had a visual hint explaining this, right next to the slot where you enter the card, but I unintentionally ignored it.

In our business we also try to explain everything to the users, give them help and tutorials. But as I experienced myself, all of this is useless, if users simply ignore provided help. And ignoring these hints or tutorial messages often happens unintentionally, because a user considers him-/herself experienced and thinks “I know a lot about XYZ, so I don’t need help cause I know what I am doing. Help is only for newbies.”

The question that came to my mind after this incident was: Why does this specific bank not stick with the behavior of 99% of the ATMs out there? Is it on purpose? Is there maybe even a reason behind it? We don’t know, but we do get annoyed. It is not like ATMs are very new being invented 1965 in the USA by a guy called Don Wetzel or that there never has been a usability-check for ATMs. Actually, a short Google search just brought up two large studies conducted on ATMs, both concerning the change to touchscreen-ATMs: Wells Fargo (USA) hired Pentagram in 2005 and FIDUCIA IT AG (Germany) hired User Interface Design GmbH (UID) in 2006.

Yet, these two studies only covered the software issues and didn’t cover the whole UX an ATM provides. All I could find in these articles was about the UI and that touch and non-touch hardware should work with the same software during the migration process, which is long and expensive, especially when considering the amount of ATMs. Researching and improving the whole experience, not just the usability of the software is also an important point in our daily business. UX is not just about software and UX is not just about Usability. UX is a very big package and one should not forget the “simple” details around the software.

Now back to our example and let’s end this article with some pictures that show good examples what one can forget to consider but is also part of the User Experience:

Sources:

• http://www.rolf-iven.com/blog/wp-content/uploads/2009/04/geldautomat.jpg
• http://img.gawkerassets.com/img/17iqx7ara2rjcjpg/original.jpg
• http://files.myopera.com/vikaskhan/albums/4208722/ATM-Too-High.jpg

After completing our first kids study, the issues that we had found were fixed by the Ice Age team and we had the chance to run a second study with children and an improved version of the game. Picking up on what we had learnt before, this time we made sure that each child had one moderator at his or her side the entire time, we took a lot of notes instead of letting the children fill out questionnaires and let them rate different levels of the game with school grades instead of scales from “strongly disagree” to “strongly agree”.

Still, when we finished conducting the study, there was one striking new lesson that stood out and that we could not have learnt in the first study:

Run tests with two children, preferably friends, in parallel

Due to the fact that there were so many children who wanted to participate and we had only one day to conduct our first study, we always ran three tests at the same time. All children were sitting in the same room but everyone had their own computer to play on and was wearing a headset.

This time, fewer children participated and we also had more time to run the study. This is why we could afford running the test with just one or two children at a time. We observed considerable differences in the behavior of children who participated together with a sibling or friend compared to those who carried out the test alone.

Children who participated in pairs appeared to feel much more comfortable. They were easygoing, talkative and did not shy away from expressing criticism. While playing, it also often happened that they became quite competitive resulting in question like “How many points did you score?” or “Did you complete the bonus level yet?”

On the other hand, children who did the test on their own seemed quite uncomfortable with the situation. They talked very little and were rather quiet and shy. Even though we repeatedly encouraged them to be critical, they said that they liked everything about the game.

When preparing and running user tests, it is one of your most important responsibilities to make sure that the participants feel comfortable, no matter if they are children or adults. Even though we always emphasize that the test is about the game and not about them, some people may still experience a user test as a stressful situation.

Also, you want your test participants to be critical. In the end, you run the test to find things that cause problems for potential users. Yet, if participants do not dare to express these things, it limits the value of your test.

So when you recruit children for user tests, ask them to bring a friend, brother or sister. Even if this means setting up your study with additional resources, personnel and hardware, the results are worth the effort.

Market of Skills

This method accelerates team building and raises awareness for skills available in the team or where skills need to be improved. Focus is on concrete expertise, so no-one has to bare their soul.

Each participant creates a poster, representing a market booth with three sections:

• On display are skills and competencies that will probably be useful for the team and upcoming project. (e.g. database programming)
• Under the counter everyone provides more skills. These might not seem directly relevant for the project, but may still be interesting to the other team members (e.g. German board games)
• The third section of the booth states skills the owner of the poster is looking for, but cannot provide herself. (e.g. Scrum)

The participants have 20 minutes to create the posters. Then they present their booth to the other team members.

After each presentation the audience gets the chance to give feedback and add colored sticky notes to the poster:

• Green sticky notes mark skills the participant is excited about, e.g. because she didn’t think there would be an expert for the topic.
• Red notes state skills that the presenter did not mention about herself. If she forgot something or was not even aware she had a certain skill, those will appear now.
• Yellow notes can be put onto the third booth area, if a team member can help with a skill someone is looking for. (putting your name on the note helps)

Lyssa Adkins points out that it is important to stay constructive when giving feedback and stay away from unwanted criticism or advice.

A difficulty may arise if the participants come across very differently when creating and presenting their poster or if junior colleagues can only provide a few relevant skills.

To reduce reservations, you should make clear that the results stay in the team.

Values Activity

Every participant gets 50 cards with different values, like productivity, patience, fun etc. As an example, here is a list of values provided by Jurgen Apello: http://www.noop.nl/2009/10/the-do-it-yourself-team-values-kit.html

Each participant reduces the stack to five cards by repeatedly discarding half of them, continuing with those values that are most important for them.

After this each member pins their cards with their name on the wall, so everyone can see each other’s most important values.

The moderator starts the discussion by asking thought-provoking questions like:

• Where are we divergent? E.g. is there someone who looks for discipline, respect, dependability, teamwork and commitment, while every other member looked for fun and humour?
• Where are we harmonious? E.g. was perfection mentioned by everybody? What do the participants actually mean when thinking about perfection?
• What surprises you? Was there only one who asked for honesty? Is this value not important for the others? Is it self-evident?
• Why are exactly these values the most important ones?

This exercise also helps to spark curiosity and better understand each other. It is not about criticism or agreeing on good or bad values.

Challenge Cards

This game helps verifying assumptions about a software architecture for an upcoming project. You need assumptions that are concrete enough to be challenged, naturally.

You need two groups: The solution team and the challenge team. The Gamestorming book recommends 5-10 participants. To get more feedback we also invited competent colleagues from other teams, who made perfect members of the challenge team. For introduction, we presented our proposed architecture and then split up into the two teams.

In the first phase the teams discuss internally. The challenge team thinks about where the architecture might be attacked, which parts have potential risks or which assumptions are erroneous. They write down potential points of attack on red cards.

The solution team tries to anticipate the points of attack. They write green cards with highlights of the proposed architecture, solutions for known problems or how risks can be reduced.

Afterwards the game starts: The challenge team starts the attack by playing a red card. The solution team now has to play a green card that counters the attack. If it can provide a reasonable answer it gets one point, if not the challenge team gets a point.

Though in principal the team with the most points wins in the end, it is much more important to look at the unsolved problems. After the game both teams should think about solutions together. Maybe the challenge team already discussed solutions when writing the challenge cards or new ideas come up in the discussion. If no solution can be found, a flaw in the architecture has been uncovered and should be evaluated. As always it is easier to correct flaws which are recognized early, instead of throwing away big implementations.

The German version of this blog entry can be found here: http://scrumburg.wordpress.com/

References

The methods “Market of Skills” and “Values Activity” are explained in the book “Coaching Agile Teams“ by Lyssa Adkins.

“Challenge Cards” is presented in the “Gamestorming“ book by Dave Gray, Sunni Brown and James Macanufo.

What does it measure?

So, why bothering to use all these fancy methods anyway? Well, the goal for applying any method is to gain new and deeper insights about our users. And through physiological measurements (called bio feedback these days) we hope to acquire implicit knowledge straight from the unconscious.

Just ask yourself how the term “unconscious” works on you… somehow we tend to overestimate “its power”. It’s like “we can measure the unconscious”, “we know how to influence your mind”, “we can control your soul!”… It’s not always that exaggerated but you know what I am trying to say.

So to get back on track and be more specific:

• EEG measures brainwave activity. So, what does this mean? Well, first of all, it doesn’t mean that we measure what the subject is thinking! It just measures the electric activity on a very specific point on the scalp. And to do this correctly, you need a lot of data points (electrodes) that correct the various sources of distortion. The insights we gain from this, is knowing in which part of the brain something may be happening. Triangulating EEG with EMG helps identifying physiological artifacts (confounding peaks from body movement)
• EMG measures muscle activity. Here again, electrodes measure the electric activity. As the subject’s facial and gestural expressions can be detected, it provides us with insights about the inner state & emotions. Additionally, EMG can be used for eye tracking (although it is not as precise as traditional eye trackers).
• EDA measures skin conductance. The underlying concept of this is measuring the skin’s electric conductance through its moisture level. High moisture levels are usually associated with a high level of arousel, which can be interpreted (depending on the valence) as either stress or excitement.

What does it cost?

• Costs. I asked the speaker of the presentation how much a test like that would cost. For 20 participants, including conduction & analysis, it would be around 20.000 EUR. Pretty expensive if you ask me… If you would like to do it yourself, proper (medical) equipment would cost you about 100 times as much. Yet, there are also a few low-cost EEG devices on the market (called neuro headsets), with fewer electrodes and lower resolution. Measuring EDA is the cheapest of the three methods mentioned, you just need one finger clip connected to an ohmmeter.
  Fun Fact: Scientology uses EDA to “measure” how pure your soul is.
  
• Time. Preparation & conduction is more time-consuming than usual usability tests are. Above that, data analysis is much more sophisticated and will cost you (at least) more than twice the time.
• Know-how. You need real experts to analyze and interpret the data properly (which will cost you in the end money again). You would wonder how much the data varies between participants! It is not advised to simply read into the topic, if you are a complete newbie. The only thing worse than no data, is false data.
• Stress. Your test subjects have to go through some procedures, which can be quite stressful for them. Electrodes must be placed on the participants’ bodies and hair, often by using conductive gel. Let me ask you, would you like to have to wash your hair after a study?
• Data Validity. You need to spend some time to “train” and calibrate your machines (e.g. for a proper baseline). There are several confounding factors and error sources that may incluence your raw data, while normalizing and filtering it might change its nature, endangering the validity of your data. Above that, test preparation (remember the sticky electrodes) and conduction (strictly controlled lab setting) pose serious consequences to your data’s ecological validity.

Will it actually improve results and recommendations?

The data acquired from the above described devices will surely tell us, how the bodies of our participants behave during the test session and how they react to our stimulus material. Let’s take a closer look at what we can derive from these methods when applied in games research.

• EEG data will tell us, which brain regions are probably associated with processing information of a particular game element. Potential bottlenecks could be identified, which then would provide information architects with insights for a redesign or optimization of a specific part of the game. User researchers could use event-related potentials (ERP’s) to identify critical game incidents and do further research for its determinants. This knowledge can be passed on to game designers to create user-centered experiences (literally).
• EMG can be used to evaluate game sequences for their elicit emotions (although that is very difficult). More easily, emotional dead spots can be identified, telling which parts of the game appear to be boring and which parts of the recorded video might require special attention. Additionally, EMG is of particular interest in researching and designing motion controls. It provides immediate feedback of the users’ movement, which can be used as input for designing game-specific ergonomic control methods. Unfortunately, only very few big developers afford to apply R&D.
• EDA is the easiest to measure out of the 3 methods mentioned. It can be used to provide indicators for emotional repsonses at a given state of the game. However, emotions cannot be identified, so its application is of complementary nature only.

As for all of these methods, we cannot be 100 % certain that the collected response is a reaction to the presented stimulus and we cannot make definite implications in terms of “this seemed to be a great moment, therefore repeat this one over & over to improve the game”. Meaningful, engaging and fun UX cannot derive from a formula, but is certainly easier to achieve the more “useful” information we collect. It makes great sense to me and is certainly of great aid to have an arousal-valence-timeline for the whole progress of the game so that we can easily look up where exactly we need to change something to improve UX (e.g. on the third tutorial step users get frustrated). However, measuring and interpreting bio feedback data is not that straight forward and needs a lot of investment in terms of time and manpower.

Bottom Line

I do not doubt the significant value of neuroscientific methods for fundamental and clinical research. However, in the domain of UX, the added value, in my opinion, simply does not justify the costs (especially for game developers). Furthermore, in the fast-paced testing cycles of game user research there is just no room for sophisticated analysis. Results have to come fast! And although the prospect deriving from the data appear to be quite promising, we first need to focus much more on fundamental game research before we can apply these kind of methods. As for now, game user research is best advised to stick to traditional UX testing methodologies for producing fast & valuable practical recommendations. However, if you have the chance and  time left to play around with new ways of doing research, I would say, go for it! It will certainly give you an extra XP Boost!

Discussion

What do YOU actually think? Do you agree or do you disagree? Be welcome to share your experiences on this topic! Just post a comment to discuss this topic with it us!

The PHP user group Hamburg was created initially in 2001. Why it became inactive and was only used for small get-togethers in a pub is hard to tell, especially as I wasn’t even in Hamburg at that time. Since I moved to Hamburg in January 2011, I asked a lot of friends and colleagues about the PHP user group. Most just replied, that it’s inactive and no presentations or real meet-ups have happened for a long time.

When I got the chance to talk to Judith Andresen and Arne Blankerts at the PHP Summit in Munich, I asked them about their opinion and what can be done to revive the PHP user group in Hamburg again. They told me, that the main problem is the lack of some people who organize the meeting and the speakers. Back in Hamburg some colleagues and I talked about the situation and decided it’s time to change this. We turned to the still existing mailing list and asked about opinions and who else would be interested in reviving the user group. It was very clear from the beginning, that a lot of people are interested and it was decided to talk about this in detail on the next official PHP meetup. About 10 members showed up and it was decided that mindworks and Bigpoint will host the first two new meetups.

On June 12th the first new meet-up was hosted in our Bigpoint offices, and to be honest, I don’t think anyone expected such a huge success for the first revived meet-up already. With up to 50 registered participants on the new meet-up website and about 35 participants showing up, it was a clear proof, that there is a lot of interest in an active PHP user group in Hamburg.

Development with Chef and Vagrant (Slides in German)

After some introduction from Martin Stoll and me, Florian Holzhauer (digital pioneers) started the first presentation about “Entwicklung mit Chef und Vagrant”. He described how Chef and Vagrant makes it easy to setup environments for their prototype projects and how they can use Amazon Cloud Services to handle load spikes. Overall it was interesting and it shows that not only build automization and continuous integration, but also automatic server setup are a tremendous help for developers.

PHP – QA-Tools (Slides in German)

Second presentation was from Melwin Meyer (mindworks) about “PHP – QA – Tools” and he showed us some insights about PHP QA and all the tools that help developing and testing high quality software.

Both presentation were especially interesting from our perspective, and they showed us that we are on the right track with all the stuff we are doing already or that is currently in development and will hopefully be used by our developers in the future.

In conclusion it was a huge success for a first revival and we are looking forward to keep this user group alive. The next meet-up will take place at mindworks on July, 10th and anyone interested is welcome to join and meet us there!

I started the first day with Ulf Wendel’s (Oracle) talk about the PHP extension mysqlnd_ms that supports clustering for MySQL. It also saves a lot of client side code because read-write splitting or load balancing is already integrated. This extension will be default in PHP 5.4 and is definitely worth a look. Ulf is an absolute expert in his topic. I can recommend attending his talks whenever you get the chance.

The IPC Welcome Session followed just afterwards with Thomas Wießeckel (S&S Media) and Pierre Joye (Microsoft) who is one of the PHP core developers. Pierre talked about how the community can participate in the PHP ecosystem. They are aware of the barriers that existed in the past but have moved forward. Examples are an easier decision process for feature requests and the move to GitHub. It’s now easier then ever to contribute with bug reports, feature requests or documentation.

Jesper Richter-Reichhelm (Wooga) talked about the evolution of their backend technologies. Starting off with a classic LAMP setup, they tried Ruby, Redis and Erlang. He highlighted the importance of DevOps to make code production ready from the beginning.

In another case study the rewrite of wetter.com was presented. Gaylord Aulke and Andreas Streichardt (100 Days GmbH) shared their experiences with Symfony 2, nginx, PHP 5.4 and Varnish. It was their first Symfony 2 project and after a high learning curve they really fell in love with it, especially with Twig (the template engine). Varnish as reverse proxy was a great help to reduce load from their webservers. Most of the requests are served from the cache. They mentioned that Varnish was difficult to debug though.

The last session of the day was a discussion panel about frameworks. Derick Rethans moderated (very well) and Matthew Weier O’Phinney (Zend Framework), Lukas Smith (Symfony) and Robert Lemke (Flow 3) were in discussion. I liked that the audience could ask questions via Twitter that were directly visible for everyone. It was a very diplomatic and peaceful discussion so no flaming or religious wars.

The second day began with Stefan Priebsch (thePHP.cc). I liked his talk about Experimental tests and how you can implement them object-oriented without using if-else statements all over the place. He pointed out that you need a good architecture with dependency injection to get this working. If you don’t have a framework solution for this you can also build this yourself e.g. with master/child factories.

Sara Golemon (Facebook) showed HipHop and XHP. There wasn’t really anything new that she could talk about so the questions and answers afterwards were more interesting for me. On the GitHub profile there is not so much activity recently. It’s because HipHop is developed internally and only releases are pushed to GitHub. There is a new version in development. Sara agreed that the communication isn’t good at the moment.

I can recommend going to David Zühlkes talks. They are always fun to follow and rich of information. He showed the difference between REST and HTTP and pointed out bad and good practices. Matthew Weier O’Phinney gave a short intro into Zend Framework 2. It’s definitely a change from the first version: Different folder structure, no ZF tool and lots of new concepts (event based, DI container and service manager).

The last day was kind of slow. Maybe this was due to the Conference party the night before. If there aren’t specific sessions you want to see, I can recommend not booking the third day. I followed some QA talks starting with Sebastian Bauer (inovex GmbH) about Regression tests. He motivated me to have a look again at Behavior Driven Development with behat.

Jakob Westerhoff talked about testing in the JavaScript world with js-test-driver and Sinon.js. Sinon.js looks pretty nice so if you write unit tests in JavaScript (which you should do) this might be a help. The last talk was about Continuous Performance by Manuel Pichler and Kore Nordmann. They suggested using JMeter instead of AB.

Apart from the talks this conference is always a good opportunity to meet other guys from the community. I enjoyed my time in Berlin and hope to be back next year.

Additional Links:

• MySQL DB Cluster Usage made easy: mysqlnd_ms
• Games for the Masses – Wie DevOps die Entwicklung von Architektur verändert
• wetter.com: A complex high traffic website with Symfony2 and Varnish
• This Way or the other Way?
• Designing HTTP Interfaces and RESTful Web Services
• Quick Start for Zend Framework 2
• Regressionstests in Webprojekten
• Immer am Optimum, Continuous Performance
• Ulf Wendels photos of the conference

In March 2012, two of us went to the Atlassian Unite conference in Frankfurt where we learned that there is a very active Atlassian community in Germany. We talked to Sven Peters, Atlassian technology evangelist for the German area. He told us about the Atlassian user group Hamburg of which we were not aware before. He also gave us a couple of contacts to talk to. This was when the idea popped up to host an AUGHH meeting at Bigpoint. After conversations with Christian Dähn, the moderator of the user group, we aimed for early June to do that.

On June 6th we finally met: starting at 18:00 about 20 guests and 5 Bigpoint employees got together in our meeting area for discussions, snacks and a few talks. I talked about how we migrated from MediaWiki to Confluence last year and what our learnings were. Frank Regel, our Jira product owner, did a second talk about Jira possibilities and current limitations, especially in an enterprise environment.
After that, Sven and Wolfgang Tank, CEO of catWorkX, told us the latest news from the recent Atlassian Summit in San Fransisco.
In between, we had pizza for dinner and talked about various topics as they appeared in our lively discussion. We finished the meeting a little bit late at 22:30. Since this was mainly because discussion just wouldn’t stop, I think this is a good thing .

We will definitely join the next AUGHH meeting and I hope this was not the last time we host it at Bigpoint.

What is the UXCamp Europe anyway?

The UXCamp brings together Europe’s foremost user experience (UX) thinkers and practitioners of different disciplines like UX Architecture, Interaction Design, User Research, Psychology/Sociology, or Computer Science to share the big ideas and experiences that inspire us all.

Like any other BarCamp, the UXCamp is an unconference, meaning there is no set agenda for sessions until the very day of the camp, when everyone gathers. Any attendee can present their topics that are collected on a board after the scramble for slots; choosing is the only tricky bit with the UXCamp.

This year, I managed to catch nine sessions. All of them covered very different topics, yet each was equally refreshing and enlightening. From the insights I gained I’d like to share a few in this post:

We drive on conflict!

For most software or applications, conflicts should be absolutely avoided as the overall user experience may deteriorate due to issues or bad experiences. Yet, in games conflict situations may even be desireable. For instance, the very notion of Battlestar Galactica Online, one of our major browser-based MMORPGs, is a conflict-driven story between humans and robotic homanoids (cylons) fighting for their right of being. Here, the player actively resolved to enter a conflict by deciding to play the game.

I got really excited when I heard that there actually would be a session about on conflict, called “We drive on conflict”. Hester Bruikman, the moderator of this session, argued that humans do need conflict situations for their own happiness and social hierarchy. The example, she provided, was called “The last cookie” – after eating up a box of cookies, one cookie is left behind. Due to our social rules, no one in the group wants to take this last cookie, yet, when someone takes the cookie and offers it to another person, he or she will feel good about himself. In conclusion, conflicts can be important emotional triggers, and applying conflicts in games can increase the entire experience.

Always start with a “Wish-Song”

Games can be really fun for players, but every now and then, evil bugs and issues sneak their way into the games and impact the overall game experience. Running into these kind of problems – as you all may know – can be very frustrating for players. As User Experience specialists we then try to determine the issues and improve the experience with – for instance – a feature redesign. The tool we mostly apply are wireframes.

Now ever since the UX camp, every time I see a wireframe (and believe me, I see many of those throughout the day) I start humming a song written and performed by Holger Eggert from uxcafe.de. He took us completely by surprise when starting to sing this amazing song and got 400 people to join him during his session “Make a wish” – successful projects and Disney songs.

The song Holger Eggert was performing was called “Hit me user one more time”, his very own cheesy interpretation of Britney Spear’s “Baby one more time”.  Although I cannot post the entire song, here is an excerpt of its refrain:

“My wireframes are killing me (and I)
I won’t achieve usability (-bility)
I’m sorting cards till I lose my mind.
Give me a sign, hit me user one more time!”

In between fun, laughter and standing ovations, Holger Eggert managed to teach us a very important lesson through his analysis of various Disney movies. Most Disney movies as he had determined usually start with a so-called “Wish-song”. In this kind of song the main character sings about his deepest desires. The example he showed us was “Part of your world” from The Little Mermaid, a song about Arielle’s desire to become human and be part of our world. A in fact unreachable desire, yet, she sticks to her dream throughout the entire movie trying to fulfill it. And despite various obstacles she succeeds in the end and lives happily ever after.

So, what does it tell us, when we transfer this type of wish song onto user experience in the game industry?

Well, it tells us to clearly define our goals, to collect player’s expectations, desires and wishes for upcoming games, and working towards these in order to get the most out of the games and “make our players live happily ever after” in them.

It also means no matter how many obstacles or problems we run into to never lose focus and continue to fulfill our wishes and desires as well as those of our players.

Finally, it tells us to continuously validate if we still follow the path of fulfilling the wish song by for example implementing personas or testing the games with players.

My final five cents

The entire UXCamp was a huge success. I was able to gain valuable insights, a ton of snippets of information and many inspiring moments from people coming from many different areas where User Experience is effectively applied. The only thing missing was our very own area. There was not a single session dedicated to User Experience in Games. So, what does it tell us? It tells us that our field is still very young, it needs to grow and it needs UX people to speak up and tell others from their experiences and what it means to work in a Game User Experience Team.

Of course, in the end, we are all using the same recipes and methods, no matter if we work in the mobile area, in the game industry or in e-commerce, yet a major difference between us and other areas is that our interactions force us to draw much more attention on criteria like fun, desired conflicts, user mistakes and flow, something we are looking forward to share with other like-minded people in the future.

P.S.: If you want to know more about User Experience in Games, don’t hesitate to get in touch! Maybe we can also write blog posts for you.

Building Blocks

If you look around in the real world you’ll start to notice some sort of self-similarity on various levels: On the macro-level for many human-made things, and on the micro-level for many natural things. Just looking around me right now I can see that there are a lot of monitors, desks and chairs of the same model in our office. Looking out the window, buildings may look different, but they often have dozens or hundreds of similar windows. Plants and animals of the same species often look quite similar, at least from a certain distance. But still the real world itself isn’t boring or repetitive (well, most of the time at least!).

In the context of a computer game, this self-similarity can be used to dramatically reduce asset sizes by placing the same object many times at different positions, orientations and sizes into a map. But this only works if the object is small and not too distinctive, otherwise it would be too obvious that the same object is repeated over and over again.

In Drakensang Online we use a very radical approach: maps are built from tens of thousands of extremely simple and small 3D building blocks, which are reused and combined in different ways so that the reuse isn’t too obvious, as can be seen in this screenshot:

Each of the wireframed objects is one of those simple building blocks. A complete map usually consists of about 50k to 100k of such “micro-objects”, but only a few dozen different objects. Here is another screenshot of a complete Drakensang Online map to give you an impression:

Hardware Instancing to the Rescue

If you’re interested in real-time 3D rendering you might have heard of the “small batch problem”, or the “draw call problem”. There’s a small fixed overhead everytime a 3D object is rendered. This overhead is pretty much the same, no matter if the 3d object only has a few hundred triangles, or several millions of triangles. In fact, for a low-polygon object which only covers a small area on the screen, this “drawcall overhead” may be bigger than the actual time spent rendering the object. For this reason, it is a lot faster to render 10 objects with 100000 triangles each, then to render 100000 objects with 10 triangles each, even if in both cases the same amount of geometry data is rendered to the same area on the screen.

And it happens that this drawcall overhead is the main problem with our approach to construct a map from tens of thousands of small 3D objects, it saves us a ton of download time, but it is tricky to render such a scene efficiently, because the drawcall overhead to render a small low-polygon object may be much higher than time the GPU actually spends with rendering.

Hardware instancing fixes this problem by batching all ‘instances’ of a 3D model into a single draw call. So the drawcall overhead no longer scales linearly with the number of objects on screen, but only with the number of object types. Rendering 5 crates has the same drawcall overhead as rendering 100 crates.

With hardware instancing we’re able to reduce the number of draw-calls in a typical Drakensang Online frame from about 5000 down to fewer than 300.

…but how does it work?

Okay, let’s use a very simple example: we want to render a vertex quad 4 times at different positions, orientations and sizes. Traditionally, you have one vertex buffer with 4 vertices in it, and then for each quad instance, compute a 4×4 transform matrix, write this into a vertex shader register and call a draw function of the 3D API of your choice. That’s the straight forward way to do it, but also the slowest way, since there’s 4 times the draw call overhead.

What we want is to have a single vertex buffer with 4 vertices in it, and “magically” render that at 4 different locations with a single draw call.

Let’s first look at how vertices are fetched and processed in the traditional rendering case for a single draw call:

A 4×4 transform matrix is set into a vertex shader register once, and the vertex shader is invoked once for each of the 4 vertices, producing a quad after rasterization. I left out a lot of details here which would just distract (like the whole rasterization stage).

Hardware instancing mainly changes the way how vertex- and transform-data is fetched into the vertex shader. We can ask the vertex fetcher unit to loop a number of times over the vertex buffer. We wanted to render the vertex buffer 4 times at different positions, so we need to loop 4 times over the input data (I used several colors to visualize the “loop count”):

Hm, okay. It’s cool that we can loop the same vertex data several times into the vertex shader, but that’s not very useful, since we simply rendered the same quad 4 times at the exact same position! We need a way to somehow switch to a different transform matrix for each loop to make this work…

The second cool feature the vertex fetcher unit on GPUs can do is to feed vertex component data from different vertex buffers and combine them before invoking the vertex shader. We create a second vertex buffer and call this the “transform buffer” (we can call it whatever we want, it’s just a normal vertex buffer which should provide transformation matrices). Each vertex in the transform buffer is one of the transformation matrices where we want to render our instances.

So now we have a vertex buffer with 4 coordinates, and another “transform buffer” with 4 matrices:

We need to tell the vertex fetcher unit to interleave these 2 data sets so that for the first run over the vertex data, the first matrix is used to transform those vertices, for the second run over the vertex data the second matrix, and so on. The vertex pointer in the transform buffer should basically only increment when one loop over the vertex data is completed:

Each vertex now consists of a coordinate and a transformation matrix, and the vertex shader simply has to use this per-vertex matrix to do the transformation. All the instancing magic happens during vertex assembly when vertex data is fetched from different sources into the vertex shader, and after rasterization our original quad has been rendered at 4 different locations with a single draw call. Just what we wanted!

Conclusion

With hardware instancing we are able to render scenes with tens of thousands, or even hundreds of thousands “micro-3d-objects” efficiently without running into the draw-call-overhead-problem, which in turn lets us explore new ways in reducing download size in Drakensang Online. Integrating hardware instancing into an existing 3D engine for general objects may be a tough technological challenge, and whether this is even worth it depends very much on the type of game. But even outside of rendering general objects hardware instancing has its place, for instance when rendering particle systems, or ground vegetation or rubble. So it definitely makes sense to understand how instancing works and what’s going on behind the scene.

In the next part of this mini-series we’ll have a look at Drakensang Online’s dynamic lighting system, and how dynamic lighting helps to the download size of a 3D game even further. Stay tuned!

Yet, due to parental consents, special invitations time restrictions, etc., it can be very time-consuming to recruit minors for user experience studies.

That said, we were very lucky to have the opportunity to run a kids study for our new game “Ice Age Online” with 27 children during the “Girls and Boys Day 2012″ at Bigpoint, a yearly repeated event where both girls and boys can visit companies to get hands-on insights into working life.

Kids Studies

In total we conducted 9 kids studies with a group of 3 children playing and testing Ice Age Online at the same time. Before we started we gave them a short introduction about the purpose of the research and briefed them about what to expect in the study. We also asked them to be absolutely straight forward in telling us what they liked, didn’t like or had problems with, the very thing, we didn’t actually need to brief them about as children have amazing error detectors and are anything but shy in telling you where you failed in your game design.

The kids played the game for about 20 minutes, while two moderators observed them and sometimes asked questions about the gameplay, how much fun they had and if the game’s interface was easy to understand.

In the debriefing sessions, children had again the chance to state their opinion about the game and make suggestions for changes and improvements. We received great feedback and a lot of ideas how to improve Ice Age Online.

Lesson learned

After this very first experience with testing browser games with children, there were several insights and learnings for next time, some of which we’d like to share here:

1. Whenever given a chance to play, they will. Once children had started the game, there was no stopping them from playing. They showed strong drive to explore everything they could find and instantly restarted a level after failing to complete it over and over again. This was quite challenging for us, when we wanted to interrupt the game to ask comprehensive questions about elements on the screen. Most of the time, children had already continued playing before moderators were even able to finish asking a question.  So be prepared that you may not be able to ask all your questions. During preparation you should always carefully consider, which questions to ask during a session and which should be postponed to the debriefing sessions.
   
   
2. Provide guidance. Even though children like to explore games on their own, they sometimes seem to need someone they could address in case of issues, especially when a game is still a prototype.
   In our first test session, we allowed the children to play freely for a few minutes and were later told by our observes that children quickly seemed lost and were turning their heads looking for someone who would give them a new task, ask a question or simply be there for assistance. Thus, if you conduct multiple tests in parallel, as we did, make sure that you have as many moderators as children playing, so that every child has always someone to refer to.
   
   
3. Minimize reading and writing. Children like reading and writing even less than adults do. Many complained about having to fill out questionnaires in the debriefing phase of the study. Especially for younger children, writing is connected with a certain physical effort that makes filling out questionnaires even more unpleasant and tiring.  Better consider conducting short interviews or small group discussions after running the test.
   
   
4. Use familiar rating concepts. When you want your game to be rated, use concepts that children can easily relate to. A great alternative to standard Likert scales is to use school grades. This is a system that all children know, love and hate. Plus, children actually enjoyed being the ones grading instead of being graded for once.
   
   
5. Don’t underestimate their knowledge about games.  We were surprised by the experience children had with games. Some of them actually asked very technical and specific questions about the game prototype.It also seems very common that especially for boys around the age of roughly 12 years to know about and play games that feature action and competition. When we asked them for their favorite games, we received answers like Call of Duty, League of Legends, World of Warcraft, Battlestar Galactica or Seafight. Children seem to get in contact with these types of games at a much earlier age than we expected, a very valuable insight that will help us to better understand children as a target group in the future.

A good browser game should start as fast as possible. The player clicks on a link, and (ideally) a few seconds later the action should start. No lengthy client download (or box unwrapping!), no installation process, not having to wait through splash screens, flying logos and endless loading screens. True click-and-play!

On the other hand, realtime 3D rendering is associated with huge asset sizes today, it’s not uncommon that even game demos are several gigabytes in size, too large for a “click-and-play” experience even on fast DSL lines.

These are the two – probably most important – conflicting targets for us browser game developers. We want to get the player as fast as possible into the action, but we also want to present detailed 3d graphics which rival or even best the quality of games which can afford to download and install gigabytes of data before the game even starts.

For Drakensang Online this conflict was our starting point. The Drakensang team was used to work with big asset data, our previous single-player offline games had around 5 gigabytes of data, and when entering a new game area, loading times of more than one minute was not uncommon (from the hard disc!). Of course this was not acceptable for an MMO running embedded in the browser, so when we started planning Drakensang Online we had to define some “rules of thumb” for data sizes, taking average DSL bandwidths and maximum acceptable waiting time for players into account.

After some experimenting we arrived at:

• 5 MByte until gameplay has to start
• plus 20 MByte via background streaming during gameplay

So around 25 MByte of data for one whole map, and this has to include audio, and player characters! It’s an understatement to say that the graphics and level design team was a little bit shocked, since we were used to spending hundreds of MBytes per map for graphics assets alone. It was clear that we had to rethink our asset production and level design process very seriously.

But in the end, those puny 25 MBytes can still give you a very pretty game as you can see from those Drakensang Online screenshots:

In the next post in this series, we’ll have a look at how hardware-instanced-rendering helps us to reduce data sizes dramatically by rendering a huge number of recombinanable 3D objects on screen. Stay tuned!