7 things to show your skills at the practical CAT exam

At the practical exam for the Certified Agile Tester, there are 7 product types in which you need to show your mastery. Before my CAT exam I took some time to reflect on the essence of each of the products and how I could best show that I know how to test in an agile team. In this article I’ll list my notes on the 7 things to show your skills at the practical CAT exam. I strongly suggest that you take some time to do that as well.

  1. Sprint Plan
  2. Test Strategy
  3. Task Board
  4. Sprint Burn-down Chart
  5. Session Sheets
  6. Sprint Review
  7. Sprint Retrospective

When you’re done reading through my notes, please leave a comment about how you will deliver your favourite .

Because there are seven product types, it doesn’t mean that you’ll pass if you only deliver seven – it is said that it has been done, but whoever made it with only one of each must have been very exact and to the point. Remember that the more content you deliver, the higher your chances are for success because what ever rubbish you deliver just doesn’t count. You can never lose marks only gain them, so train your handwriting and produce as much as you can.

1. Sprint Plan

This is the first thing I did at the exam – even while the instructor and the invigilator where setting up the computers, I was scribbling away just to get it out of my head.

At the practical exam the SUT simulation is delivered in three drops that all need initial testing, regression testing, and eventually some re-testing of the defects that you will find. Apart from that you’ll spend your time on planning, analysing the material, and creating the products that you’ll deliver (i.e. each of these seven products)

It is crucial to set time boxes and to be strict on yourself to uphold them. Start practicing now: how much time will you spend on reading and commenting on this article? I found that my time scheduling slipped when testing the drops, so in retrospective, I’d like to have made smaller time boxes than I initially did (have a look at my initial plan below).

First I thought it was okay to slack a bit on the time boxes in the testing time, but it turned out to be where I needed to be the most strict.

Because my native language is Danish, I had more time for the exam because it was in English, so my sprint plan looked like this:

30 min: Planning
* Test Strategy
* Task board
* Initial Burndown

30 min: Drop 1
* Analysis
* Testing
* Reporting

30 min: Drop 2
* Analysis
* Regression & Re-Testing
* Testing
* Reporting

30 min: Drop 3
* Analysis
* Regression & Re-Testing
* Testing
* Reporting

10 min: Review
* List defects (before the exam I planned to list passed and failed stories, but I ended up listing > those at the Sprint Retrospective)

20 min: Retrospective
* Listed the passed and failed stories. I.e. I was behind my planning so I didn’t get to test the third story properly. I compensated by explaining what parts of it that I did test and that it would go into the next sprint in a real life situation. (Before the exam I really did plan to explain how to mitigate any of the types of failures that I’ve seen in the exam.)
How much detail will you put into your Sprint Plan and how will you practice and enforce the time boxes that you set for the tasks? Share your thoughts in the comments.

2. Test Strategy

Start by making a bare-bone strategy with only the most basic statements that describe how you will test throughout the practical exam.

After each test session, or after you’re done testing a drop, take a minute to update the strategy by adding any methods that you’ve used during the session. Also make sure to take notice of which methods that you added earlier and have not used yet. This will be valuable information for the Sprint Retrospective later on.

These are examples on the basic methods that I wanted to use for my exam. Be sure to use your own favourites, and go through those listed in the manual, then take a look at the stories that you will need to test and add any that will make sense in your specific exam situation.

  • Risk assessment: how to start with user stories that has the highest business value or user stories that have other depending stories (this one didn’t make sense in my situation because each drop had a specific story and the order was predefined with the highest business value first. It would however make a lot of sense to include this statement in a real world test strategy)
  • How tests will be conducted: which test activities, types, techniques, regression testing, re-testing, testing levels, etc.

    • Exploratory testing
    • Regression testing after each new drop
    • Re-testing of defects reported in earlier drops
    • A short description of the use of session sheets for documenting the test sessions (more why than how)
    • How acceptance criteria are used to design tests that the Definition of Done (DoD) include that all acceptance criteria must pass before a user story can be accepted at the sprint review (I really struggled with this at the exam, because all of the stories had some AC that didn’t make it. My conclusion is that the exercise here was to make a DoD that made room for technical and testing debt and to set a threshold for what was acceptable for the product owner)
    • That the tester will inspect both the front-end (UI) and the back-end (database)
    • That any defects will be reported on the session sheets (i.e. not on separate sheets)

Take a look in the manual on what else a test strategy should contain. These notes are reflecting my style and I am looking forward to reading about yours in the comments.

3. Task Board

At the practical exam, there are no real opportunity to use a task board, so you are only asked to make a sketch of one. Make sure to clearly show how it would work in a real situation and include a legend and any additional explanations that you need to clearly explain how your Task Board would be used.

Because it is not actively used, it only eats your time , so you should be very careful not to spend too much time on the sketch.

What does your favourite Task Board look like? In what genius ways have your team’s task board evolved over time?

4. Sprint Burn-down Chart

Compared to the Task Board, the Sprint Burn-down Chart can actually be used, so here are my notes on how I did it at the exam and what I had planned.

In my first attempt at the exam, I found so many severe defects that I didn’t feel I could pass any of them. In hindsight, I should have passed some of the defects on to “the next sprint” as testing debt and passed the (some of the) stories with notes on that in the retrospective. At my second attempt, I only passed two out of three stories and my Burn-down Chart was more interesting to look at and not just a flat-line.

In your planning you will give each of the stories story points on a given scale (in both my cases it was 1 through 6), so you will simply plot the initial sum of the points at drop zero and draw a line for your expected velocity – i.e. when you have estimated the stories and create the Sprint Burn-down Chart. As you finish each drop, plot your progress in the chart.

5. Session Sheets

The Session Sheets are used throughout the practical exam. The difference from the rest of the products is that there is a special way to name your testing sheets so they can be traced to the user stories. Be sure to check the syntax in the practical exercises that you’ll get at the course.

At the exam I also got copies of the user stories with a field for my notes. I was not entirely sure what to do with it, so I simply made some notes related to the acceptance criteria that were listed on the story card.

Because the Session Sheets are the core products of the practical exam, I set up some rules for myself before the exam:

  • Refer directly to Acceptance Criteria and make notes in the actions taken to test them.
  • Not all AC are fulfilled in one code drop, so be specific on which AC are and can be tested in a certain session/drop.
  • Name defects according to AC and any other odd behaviour should be noted as Issues (there are a field for defects and a field for issues below a larger field for session notes on each session sheet)
  • Make a note in the strategy that any AC that are not mentioned is passed. I crossed this out and made a note that the danger of this is that the AC will too easily be forgotten. Instead: Note which AC that are tested and which are left for later drops – even if they are so simple as “The site can be accessed”.
  • When AC pass, create a regression test sheet per story per user story in Drop 2 and 3. On them make a list of the passed AC and check them off as they pass your regression test.
  • If there is a regression, make a specific note on it and note a defect. This actually happened in my second drop. In my first attempt at the exam, I didn’t make any specific regression tests, so I hope this makes a difference.
  • Only create regression test sheets for AC that previously passed and are not implicitly tested with other AC that specifically belong to the current drop. E.g. if an AC says “The site can be accessed”, it will be implicitly be regression tested with any new testing that you do.
    The point of my rules was to be specific about what to make note of and what not to waste time on. In essence, my rules reflect my weaknesses and act as a declaration towards addressing those. Make sure to reflect on your own weaknesses and how you’ll keep them in check during the exam.

In the comments, share the one most important rule that you will set for yourself when taking session notes?

6. Sprint Review

As you can see in my Sprint Plan, the Sprint Review has the smallest time box. All I found necessary was to list the unfixed defects, related to the user stories. Then I added a note simulating a product owner’s decision taken on the customer’s behalf.

Any defects not directly related to acceptance criteria, but related to the additional requirement specifications will also be listed here if they were not fixed. Don’t add any details about the defects. I didn’t even write out the descriptions/titles of the defects, just the IDs that were also listed on the session sheets.

Bear in mind that the Sprint Review should simulate a demonstration of what a team has a accomplished during a sprint, so it is an honest report on what happened and what was delivered. The core value to both the customer and the team, in relation to the collaboration, is the honesty because it makes it clearer what can be expected in the next sprint. The same holds true at the exam where you need to show your professionalism regarding the state of the SUT and that you have done what was in your power, as the tester, to contribute to the product.

As with the other topics, make sure to read the manual and take some time to reflect on how your sprint review will turn out at the exam. If you already have a clear idea, put it in the comments.

7. Sprint Retrospective

The sprint retrospective sheet contain notes about how the process can be improved in the future. In the exam situation, it will should give rational ideas on how your behaviour in the exam process was and how it could be improved.

The retrospective can explain symptoms on what the simulated team can improve. E.g. if there are many security related defects, you can suggest to bring on a security expert to test the product. Likewise with any performance and user experience issues or defects you may find.

If you can see that a majority of the defects could have been prevented with code reviews, unit tests, clearer user stories and acceptance criteria, the Sprint Retrospective is where you should address those.

Most important is to address all the issues that are noted on the session sheets during the tests – and make sure to make notes on any issues like these, on the session sheets, when you find the issues.

Explain which issues are most important to the team and the customer and how the team would mitigate these.

Issues are e.g. if stories are too big, label them as epics and break them down into smaller stories. If acceptance criteria are unclear, explain that the testers should pair up with the product owner to make them testable.

If you have an additional example, post it in the comments and explain what a symptom could be and how the issue can be a problem in the future.

Can metrics improve agile testing? Measure, Analyse, Adjust

As a tester in an agile project, I want to make visible how I spend my time, so my team can act accordingly and stakeholders know what to expect.

As you’ve probably experienced, plans and estimates are revised during a sprint. I have never heard of any healthy project that has not done that. In an unhealthy project, stakeholders may stick to a loosely estimated initial plan because they do not know better and cannot act on any historic data

Consider a scenario with a release date getting closer. A stakeholder, who is restrained by a contractual budget and a promise of timely releases, asks the team when they are done testing the stories. The team can’t answer with any acceptable margin, so the stakeholder start drilling down into the stories asking specific questions about how many hours are needed for exploratory testing, test design, and GUI automation – basically taking over the test strategy. At the end of the meeting the testers have committed to some arbitrary forced number of hours for each type of testing on the remaining user stories. The only benefit of that is that the stakeholder is satisfied until it is discovered that none of the new estimates are useful at the next status meeting.

In this article I provide an answer to the question: Can metrics improve agile testing. The best way to answer that is to split it into these four sub topics which I will answer in sequence:

  • Why collecting metrics is helpful
  • What metrics should be gathered during a sprint?
  • What is the easiest way to gather metrics during a sprint?
  • How can metrics help improve testing?

Everyone must know why they are collecting metrics

Imagine recording data without knowing what it is used for and why it is gathered in the first place. The first thing I could imagine myself doing was – consciously or unconsciously – making up reasons. Adding to that, I would become insecure if the metrics are in any way connected to my performance on the team. Building on that and the uncertain reasons behind the metrics, some might even alter those in a direction that would be of no benefit to anyone.

Say, for example, that you are recording how much time you spend on testing a story. You have no idea what the data is used for. You want yourself and the project to look good in the statistics, so you start rounding the numbers down here and there – just a tad. Over the duration of the sprint, that become several hours. Then it is time for stacking the backlog for the next sprint and guess what more stories are taken in than you and your team can test within the sprint.

So be transparent about why and how metrics are gathered. Be vocal about why you measure any performance on the team and project. If you are in any doubt of why you are collecting a metric, ask about it and discuss what it can be used for and how it can benefit the project.

What metrics should be gathered during a sprint?

In other words: What does testers spend their time on? The answer is in my experience always some version of these three things:

  • Testing (including running tests against the application under test)
  • Investigating, reporting, and re-testing bugs (including collaborating with coders and product owners)
  • Setting up and waiting for environments or other resources such as test data (including designing scripted test cases based on notes from previous ET-sessions)

One of the most efficient test techniques in agile testing is exploratory testing because there is less preparation and setup required compared to scripted tests. It is not always easy to gather metrics while focussing your energy on finding creative ways to test the system, so you will need a simple system for doing so.

What is the easiest way to gather metrics during a sprint?

One such system I’ve been using for gathering metrics during exploratory testing sessions is a light version of session-based test management or SBTM, which was developed by Jon and James Bach. The core idea is simply to take notes of what you are doing during a time boxed session and mark each entry. The notes have to really simple so it does not take up all your creative testing energy.

The wikipedia entry defines session based testing like so:

Session-based testing is a software test method that aims to combine accountability and exploratory testing to provide rapid defect discovery, creative on-the-fly test design, management control and metrics reporting. wikipedia.org/wiki/Session-based_testing

A genius of the tool is that you will take specific note of how much time you use on
1) Testing, 2) investigating Bugs, and 3) Set up. These are also called TBS Metrics. When you gather the metrics, you can see where you spend your time, so if you see less time testing than investigating bugs or even setting up the environment, you can take action on for example getting the environment setup automated. If e.g. you spend a lot of time investigating bugs, perhaps the programmers should be more involved in testing or the user stories should be analysed with the product owner to get more specific acceptance criteria.

The important point is that if you collect these 3 simple TBS metrics, you have come a long way towards being able to analyse your results, you can continuously improve your testing effort based on those numbers.

The full SBTM may be a big bite to start off with, so I recommend that you start with SBT Lite which was defined by my mentor Sam Kalman who worked with Jon Bach at Quardev. SBT Lite is much more free-form, but is still able capture the metrics you need.

In practise, a tester would take notes on his/her actions during an exploratory test session.
Before the session starts, a session charter is chosen and noted on the session sheet along with the esters name. The charter could be one of the acceptance criteria in a user story or an entire user story depending on the size and scope of them. A meta session charter could also be to come up with session charters for a set of stories. The charter is basically the mission of the session.

During the session, the tester marks his/her notes as T, B, or S, along with a time-stamp and a one-line description of what happened. The result should look much like a commit log from healthy pair programming session.

When analysing the session logs, it would be evident how much time is used on testing, bug, or setup time respectively. In the full SBTM resource there is a link to Perl tool that can analyse session notes if they are formatted in a specific way, but you should make your own session log parser if you prefer to follow the simpler version or even design your own set of metrics (which I recommend once you’ve tried this for a few sessions).

How can metrics help improve testing?

As I suggested in the scenario in the introduction, it is not only managers and stakeholders that benefit from the collected metrics. Testers can benefit on a personal (professional) level, the team can benefit, if there is a cross-team test organisation that too can benefit from the TBS metrics.

The individual can use the analysis of the metrics to hone his/her skills. Perhaps compare how much time is spent on each task type compared to other testers. If the numbers differ significantly, have a conversation about why. Maybe you can find new ways to be more efficient or maybe you have some important advice for one of your colleagues.

The team can use the analysis to find bottle necks. E.g. if a lot of time is spent on setup, perhaps the testers need a dedicated test environment that is hooked up to the CI-server or if that is already the case, perhaps it should not re-deploy every time there is a push to the development branch.

So, can metrics improve agile testing?

Yes, if you start measuring right now!

My final recommendation regarding metrics is simply to start collecting data immediately.

Start simple by introducing a simplified version of Session Based Test Management to your testing colleagues on your team – talk to them about it and discuss how your team might benefit. Next, present the idea to the rest of your team and get some feedback on how simple it should be if everyone should be able to use it.

Now, collect some data, analyse it, present the results, and adjust.

Leave a comment about how you use metrics in your organisation and let me know if this helps you in any way.


Here’s a list of the tools you can use to look more into session-based test management an starting a simple measurement of your team’s testing effort:

CAT Exam

In this article I’ll give you an idea of how my exam for the Certified Agile Tester (CAT) went, how I prepared, if I was nervous, and if I thought it was hard.

How did I do?

The first time I took the exam I didn’t pass. With the risk of sounding like an excuse, I’ll try to explain why I thought I failed the first attempt. Perhaps my reflections will help some of you pass the exam the first time. The iSQI does not provide any other information than whether you pass or fail the exam and the percentage of correct answers in each test (the practical exam and the written exam).

Reasons why I may have failed my first attempt at the CAT Exam:

  • Read too little
  • Wrote too little answers (focused on being right in every answer)
  • Had higher thoughts of my knowledge of agile testing than anticipated
  • Practical
    • Missed “required” sheets
    • Unclear traceability between strategy, plan, tests, defects, and re-tests
    • Too few defects reported
  • Written
    • Need more corrects answers (remember that no incorrect answers can subtract from your score, only correct answers can add to your score)
    • Practice more with the sample questions in the CAT Manual
    • Need to write faster to give more answers

In the time leading up to my second attempt, I worked on these issues and it seemed to have worked as I passed the exam with much better scores than the first time. You may need to work on the same things, but try to think about what issues you may run into and work on those before you may have to compile a list like this after a first attempt.

How did I prepare for the exam?

I have always hated preparing for exams because there is so much pointless tension connected to it. It is really stressing me out. On the other hand I really love researching a topic for use in a presentation, an article, or similar. Given I had a bit extra time in the weeks before the course, I decided to create a website about the CAT course, to help others study for the CAT exam. With that decision I added a real purpose to my effort and removed the pointlessness of the tension.

Was I categorising too much?

In the beginning I spent a lot of time grasping the structure of the CAT Manual 3.0. I listed all the learning objectives for each module with their K-levels. I phrased the learning objectives as titles on articles that would become part of the website. For each of the articles/learning objectives, I listed a handful of questions that would answer the key topics of the learning objective. The idea was then to simply fill out the questions, supplement with what would learn from the CAT Manual, and later from the CAT Course itself.

In hindsight, this was a big mistake and it is completely against the Agile manifesto and principles of just-in-time learning. Even though I wanted to get an overview of the CAT Manual to be able to start with what I would find the most important or the hardest to learn, I ended up wasting time on categorisation, prioritisation, and the whole idea of how the website would be like. The CAT Manual is carefully designed for the students to follow from start to finish and I should simply have done so, writing my notes to my articles as I went through it before the course.

As I am writing this, I worry that I am making the same mistake again, by spending time on reflecting on the exam outcome. However, this will be my only opportunity to do so. The next steps after this reflection is to read the CAT Manual again and fill in my notes in the article scaffolds that I already created. While waiting for the exam results, I wanted to use the opportunity of having them fresh in memory, to summarise my experiences of each day on the course. I didn’t expect that I would have to take the exam again.

Was the exam hard?

Before giving my subjective opinion on it, I will try to retell some of the other participants’ concerns especially on the practical exam, which we discussed in the lunch break.

There is a lot of handwriting involved in the exam. As I suspect most people in IT, I am not practicing pen writing at the level required by the CAT exam. Of course at the written exam, there is a lot of writing to do, but there it is really simple and you only have to concentrate on one thing: answering the question within the given time. At the practical exam, you need to write a lot as well, only using another technique. You also have to juggle a lot of things and be careful to make all your notes traceable all the way from the bugs that you find and back to the specifications and the user stories. On top of that, there are the required products that you need to deliver.

At my first attempt at the exam, one of my colleagues had some technical issues with the linux distribution that was running the assignment. I really felt for him while I was glad that it wasn’t happening to me. I’m not sure I could have handled the added stress very well. Believe it or not, at my second attempt I found myself in a similar situation, where I wasn’t provided with the credentials to the database. In both instances, it was handled very well by the instructor and the invigilators and both my colleague and I were given extra time as compensation.

The written exam questions were very much like the sample questions. At least, I did not find them hard to understand at all. That said, I should probably have put more effort into answering them with more variations – I only answered with the required number of answers and no more.

Why is the exam so long?

There is a lot to cover, so it probably cannot be any shorter. Many topics are covered in the CAT Manual and the CAT Course, so to test the participants in as many of them as possible, the exam has to be long.

Was I nervous about the exam?

I wasn’t really nervous because I was confident that I would pass the exam. I based my confidence on the fact that I work by the principles presented in the CAT Manual and that my first encounter with software testing theory was a lot of self studying and reading. I felt that I had seen and heard of everything in the CAT Manual and had tried most of it. To say the least, I was very confident that I knew the subject matter.

How was my effort before and during the exam?

Perhaps I lost track of the primary goal, of passing the exam, when I shifted focus from only studying for the exam to using what I learn to building a website to help others take the exam. My first impression of my effort is that I spent a lot of time and energy on researching and studying the CAT Manual, but thinking back on it, I spent too much of my time and energy grasping the structure of the CAT Manual instead of memorising the actual content.

Leading up to the exam I let myself be tricked into thinking that the Lean principles of delivering just enough to give value also applies to the exam situation. That is NOT the case here! I would answer each question in the written exam with just enough information to satisfy myself. I did not give any variations on the answers, making my answers more clear and increasing the chance of gaining extra points.

Simplify Game Development: Think of it as a Toy

The Toy is built through iterations of development, play and tweak using the technology that will be used to build the final game.

One of the basic and most important components of a computer game is how the player interacts with the game. Many games rely on characters or objects that are controlled by the player. Very few players are consciously aware of this interaction and this is often the way it should be if the engagement in the game should be maintained. Therefore the feel of the game should be a central part of the game and iterated upon throughout the production.

This is the second in a series of articles on how to simplify game development based on my master thesis on game production. I hope that game developers will be able to simplify game production with these ideas in mind.

I will not go into details about what the definition of a toy other than it is something that you can play with. There are certain similarities to game development that I find interesting: Toys are made for play, which is an essential part of most games. Toys can be played with for hours at a time. Toys are mere tools for play and immersion – suspension of disbelief. Likewise will people probably play your games as much as possible if the toy their tool of choice when it comes to play. This is why it is important to perfect the toy.

I read in a book about game feel that Shigeru Miyamoto, the creator of Super Mario, spent a lot of time iterating over the Super Mario 64 controls in what he referred to as a “garden” – a virtual test environment containing elements of the game that have an impact on the feel. I am sure that iteration on controls is time well spent. I myself will not play a game for long if the controls are annoying.

I am currently in the process of porting a prototype to tablets where the controls are giving me a hard time. The initial prototype was made for 2-4 players using keyboards or joypads for input and was a thrill chasing each other around in a maze with different speed and drag attributes. At some point we decided that the game format would be better for 2 players on a tablet where each player had to control their character with touch input. The entire feel that we worked hard to achieve was lost. It was a brilliant idea to use the tablet for the immediate face-to-face interaction between the players, but the controls could not be ported directly. Mainly because we had spent some time tweaking the controls to the natural haptic feedback that the joypads and keyboard give, where a touch screen with a rendered image of a joystick is nothing like it.

Thinking of your game as a toy is one of the fundamental things you can do for your game design. If the toy is not fun to play with, why would anyone ever play a game? Start early playing with the toy, make sure it is fun, discard unnecessary features, hone what makes you want to keep playing it. Above all, get other people to play with the toy and tell why they want to keep playing and what has no significance.

Simplify Game Development

I has been some time since I reflected closer on ways to simplify game development. This article is the kickstart to set of articles on my views on it. Since my graduation I’ve seen different software productions, mainly from a quality- and process oriented perspective. I’ve also experimented with different game development processes in smaller teams. This experience has given me some new takes on some of the initial ideas that I studied at the university.

The main idea with these articles on game production is to review the core topics of my master thesis on game production. I hope that with these ideas in mind game developers will be able to simplify game production.

First of all, I see these seven topics as the most important in game productions:

Each of the above topics are still the way I like to simplify game production and perhaps even any software production. The topics should not be seen as phases in a production but rather as elements that are iterated upon throughout the entire development of the game. At some point each of the topics will reach a mature state and more effort can be put into the other areas.

As I release the articles on the topics, I will add links to them in this article. Thus is this article better seen as an index or teaser to the following seven articles in this series.

Why are in-game tutorials important to some and not to other video games?

These are some of the questions about in-game tutorials that have always nagged me: Why are in-game tutorials important to some and not to other video games? How can in-game tutorials be made seamless to avoid breaking the player’s suspension of disbelief in a video game? When does a game need an in-game tutorial? Should the player learn the game by failing? What kinds of players will put up with the frustration of not being tutored? Which games can do without tutorials? What different types of in-game tutorials are there? How can in-game tutorials be made interesting and seem like an integrated part of the game?

In a way, there are three types of video games: the illogical, the intuitive, and those with in-game tutorials. The illogical game probably has the hardest time settling with the players. The intuitive game is a bit better off once the player knows what to do and where to go. Those with in-game tutorials give the player a head start in complex concepts. However, there is a fine balance to keep: do not underestimate and patronize your players. I have an opinion on some of the strengths and weaknesses that should be considered when talking about in-game tutorials.

Each of the types, illogical, intuitive, and with _in-game tutorial _are of course mixed and graduated in reality, but for the sake of the discussion, I’ve taken them to the extreme.

The Illogical Games

In these types of games, the controls are often hard to learn and the objectives in the game often don’t make sense unless the player knows about the game world. The controls and objectives doesn’t necessarily make sense even when they are learned. The games must be interesting for players before they learn the controls and objectives.

Games with illogical controls or objectives often have a steep learning curve. Some may categorize these as hardcore games. I remember sitting in front of my brother’s Amiga 500 immersed in a variety of games with great enthusiasm, but often after having been frustrated by having to figure out the controls by trial and error.

Practically no games were translated to our mother tongue and if they were, we wouldn’t waste precious gaming time reading the tome that came with the game. That meant that a hard judgement fell on the illogical games: discarded! (i.e. because the games simply fell outside of our zone) So, what made us grant the games our attention back then, was most likely the scarcity of videogames in general.

If games was as ubiquitous as they are today, I think that we’d been more demanding and the most illogical would not be granted a second.

The Intuitive Games

Intuitive game controls and objectives are easy to learn may not need to be taught to the player. Controls and objectives make sense the first time you’re learning them. The games does not rely on being overly interesting for players to learn to play. Intuitive games have a gradual learning curve. Some may categorize them as casual games. Some controls are so obvious and easy to learn that it does not really require much effort from the designer nor the user. Just play the game. However, varying complexity in games are often reflected in the controls and how the objectives of the games are given to the player.

Consider a player that has never played a first person shooter. To him, Doom is something that awaits and not one of the founding fathers of what evolved into a standard control scheme in subsequent 3d shooters.
This player need an incentive to play the game and learn the controls. Back in the day, it was fancy photorealism in VGA and the compelling story about… killing monsters. And that was more than enough for most of us. Frankly, I do not recall if the controls were taught in-game or only in the manual – some of the controls wasn’t event in the manual.

The point is that to the player that never played with these controls, they would not be illogical after some time getting used to them, perhaps even intuitive if using the wasd/mouse configuration that is pretty much standard these days.

The Games with In-Game Tutorials

Even though I named this the third type of game, it serves more like a transcendent category: In-game tutorials are both used in illogical and intuitive games because both may benefit from in-game tutorials or in some cases in-game tutorials are a disadvantage for the intentions of a game. First of all, in-game tutorials lets the players learn the controls and objectives fast and really get into the intended game play sooner. The downside is that there is a risk of patronizing the player if the controls are super intuitive  and still spelled out, so I guess there is a fine balance to keep depending on the players:

  1. Continuous throughout the game,
  2. once per game session, or
  3. once per player (stored in a user profile or the like).

In the end, remember that videogames are mostly entertainment and if the player ends up frustrated, the game fails its purpose.

Simple Game Design by Polish, Appeal and Measures

The cycles to achieve simple game design
The cycles to achieve simple game design

If you would like to read my master thesis, go ahead and get it here. Otherwise, read on and get an overview of my thoughts behind Simple Game Design through Polish, Appeal & Measures.

With a vantage point in the term Game Polish, I have proposed a simple method for designing games independently from any specific production methodologies.

The study was made in the spring of 2009 through correspondences with members of the International IGDA Game Design SIG and other forums dedicated to game development.

The main cornerstones of the study is Polish, Appeal, and Measures – all elaborated in the report.

Simple Game Design through Polish, Appeal & Measures. This method proposed in my master thesis, explain how to make a game or on what to focus designing it.

An Idea in a Master Thesis

In this thesis the reader will be presented with a definition of the nebulous term Polish used in relation to computer games, mainly derived from literary sources. The term has been processed from different perspectives and split into three overall topics: Polish, Appeal, and Measures.

The topic of Polish relate to the elements used to add Appeal to a computer game. The topic of Measures relate to how the intentions of the game’s Appeal are being verified through the pre–production and the production phases in the making of a computer game. These three topics will form the cornerstones of this master thesis.

A Simple Game Design Method

The overall methodology of the study consist of two parts. The first part being a series of correspondences with game designers via e–mail and online discussion forums dedicated to game design issues. The second phase of the methodology has been to verify the responses through a series of interviews with professional game developers working at different levels in the game industry.

The results are presented according to the cornerstones, Polish, Appeal and Measures reflecting the respondents’ opinions on how the elements of Polish are being evaluated in pre–production and production of computer games. It is clear that players are not included in pre–productions as much as in productions. The elements of Polish should not be treated as those with functional and pleasing purposes separately, as there are rarely added any elements of Polish that does not have a distinct function in the game.

Several aspects of game design are being discussed, however an effort is made towards making the proposed methodology independent of the established definition of staged software development. In relation to this there is being proposed a more fluid way to describe the process of game development through the terms Concept, Design, and Content.

The conclusion of the thesis proposes a simple methodology of designing games that is independent of software production methodologies.

Audio and game programmer at DADIU’s Exodroid

While doing my MSc in Medialogy, I took part in two productions at DADIU (Danish Academy for Digital Interactive Entertainment).

My second production was Exodroid and was made in Unity using C#. This production took place in March 2009 while I was writing my master thesis, so these projects are highly interconnected.

As game programmer on this project, I gained experience using C# with Unity. Furthermore, I took an active part in developing the design and the production itself.

I participated in the project while writing my master thesis, therefore much of the discussion and conclusion is somewhat related to this project.

Casual game, -gaming, -playing, -gamer, -game player…

Well, ain”t that a rant…

I”m writing this post because I recently read a paper seeking to define the term casual in relation to video games (check the presentation slides that comes with it). Then I found a post on indiegamer.com discussing this very question.

My approach is grounded in the academia but moving towards the real deal, the practical implementation, or you might say, the geeky know-a-lot-but-haven”t-really-tried-it-properly-yet approach. That is except for my experimenting in my spare time and at the university not to mention my recent internship in a game company called Titoonic in Copenhagen.

In short the paper categorizes terms of “casual” in relation to games into the following:

  • Casual Games:
    The games that are casual or designed to belong to a subset of games, meant to be played casually. Mostly defined as having “generally appealing content, simple controls, easy-to-learn gameplay, fast rewards, or support short play sessions” [Kuitinen et al.].
  • Casual Game Player:
    A person that plays games labeled or designed to be Casual Games. The stay-at-home wife 35+.
  • Casual Gamer:
    A person who play ANY games casually (notice the difference from above).
  • Casual Gaming:
    The general attitude or approach towards gaming. (Hardcore gamers do not play for leisure).
  • Casual Playing:
    Describes the way a casual gamer would play a game. “… in small time bursts or in a low cognitive state” [Kuitinen et al.]. Playing without effort.

In my humble oppinion it is nice to have a clear definition eventhough some people think it is waste of time and goes “no speak – make game”. I wonder where the cultural and technical evolution would be if everyone thought like that when they discovered the wheel.

Anyway… I want to give my support to the guys in Tampere that like to explain the buzz. Kudos!

Using Game Design Patterns in Casual Online Game Productions

9th Semester/Internship

Spending time in “the real world” was a great lesson for me. Besides the academic work, described below, I gained first hand experience in what it takes to deliver production quality flash games. Through this I tried using game design patterns in casual online game productions.

Games should be fun and plenty. If game developers should make plenty of fun games they need efficient tools to design them. Game designers today use existing games as references when discussing game design. Pattern languages may offer a common reference frame and Game Design Patterns may help game developers design more efficiently.

This case study was made to find what it would be like using game design patterns in casual online game productions in a small casual game company. Among the findings was a positive attitude towards the methods, however if a company is to benefit from them there has to be taken measures towards educating staff and redesigning production models.

Whether Game Design Patterns are in fact useful remains uncertain. This study offer suggestions to what is necessary to succeed in implementation of Game Design Patterns based on Björk’s and Holopainen’s research.