Digital Prototype: Iteration 1

It has been two weeks since our last blog, but we made some huge progress! First of all: Our first digital prototype is ready and playable. You can go and test it here.

The main menu screen has 3 buttons, like in the final paper-prototype. The play,mute and highscore - buttons. Highscores are (for the moment) only stored on your local device, or per browser. The mute button disables all music and sound in the game.

Once the user selects play, there is no going back to the main menu. The pause button in-game has been switched to another mute button. We felt like a pause menu was superfluous. Because we want to test the controls of the game, the user gets a choice which type of controls he wants to use. The different controls we offer in this iteration are:

• Tapping the left half of the screen makes the dino go up, and tapping the right half makes it go down.
• Tapping the upper half of the screen makes the dino go up, and tapping the bottom half makes it go down.
• Tapping the left half of the screen makes the dino go down, and tapping the right half makes it go down.

In this first digital prototype the user has to choose his controls everytime he reboots the game after pressing the play button. We implemented it like this to make it convenient for our testers to try out all the different types of controls. This feature is furthermore only present in the Android version of the digital prototype, since the browser version uses the arrow keys on the keyboard as controls instead. In later iterations of the game the control selection will either be migrated to a settings screen, or be dropped entirely, depending on the feedback we collect from this first iteration.

Once the control scheme has been selected a tutorial screen pops up, this shows where you need to tap to move your dino. At the bottom it also shows you which obstacles you need to eat and which to dodge. Tapping once on the tutorial screen immediately starts the game.

The gameplay hasn'y changed a lot. Only a multiplier has been added. If you are on a good dino streak or survive long, it increases. If you miss a small dino you lose your streak, but you won't die. Hitting an obstacle however immediately kills you.

Below you can see video of the gameplay to clarify everything. Only the option to select the control scheme hasn't been included in the video yet, but you can see that in the screenshot below. Now our evaluation period begins and more updates will follow quickly. Stay classy and play dino top hat!!!

The controls selection screen

The delicate art of pruning: Getting to a minimum viable product

Another friday has passed, which means progress! This session we were asked to create a minimum viable product (MVP), and turn it into our first actual playable digital version.

The first step into creating our minimum viable product (MVP) was, stripping our game concept down to just the bare necessities. We quickly decided that the multiple game modes would not be viable for a first iteration. We still like the idea, but it would require a lot more content to properly implement. The only available game mode that will thus be provided in the MVP is endless, which will consist of you, the tophatted dino, eating smaller dinos, while dodging bigger dinos and obstacles. We decided to not yet include evolution/growth into this version. This is actually a game mechanic that we do hope to implement in a next iteration. It would be something that distinguishes our game from other similar games. However for a first iteration, it was not something that would be necessary to make the game playable.

With this in mind, we made a new paper prototype, because one should not dash into the next development step without evaluating. Upon testing this new prototype with the assistant, we came to the conlusion we still had a couple more elements that could be stripped, including the settings and about screen, and the health bar. This reduced our grand project to a lean mean gaming machine.

This left us with a single entry screen, which displayed the possible options: play, highscores and mute. This screen would only be accessible when starting up the game, and you will not return to it any more. When you die you see a game-over screen, which allows the user to start a new game. The game-over screen will also display the highscores. This is all summarised into some neat lists!

What we have:

• A main menu
• Highscores
• Single game mode that consists of endlessly eating small dinos, while dodging bigger ones.
• A mute button
• A dino with a tophat.

What we really want in the future:

• Growth and evolution game mechanics
• A story game mode.
• More variation in dinos.

What we have stripped, and not necessarily plan on adding again:

• Settings screen
• About screen

We hope that our MVP will provide us with answers to some questions we still have, that were difficult to evaluate with a paper prototype.

• Which control scheme do people prefer? 
• Do we need to add a tutorial, or will people understand the concept just by playing? 
• What about the pacing. Are the game mechanics actually fun?

Future blogposts will answer these questions!

Further paper prototype evaluation

During the first evaluation session, it became clear that every test subject had his own opinion on how we should design certain aspects of the game. Some opinions, especially about the tutorial, were even contradictory. Because of this more evaluations were needed.

Before we searched for test subjects, we first made some adjustments to our prototype, based on the feedback we had already received during the first evaluation. This week we found six more people who wanted to test our prototype. Another two also shared their thoughts after they watched one of their friends test it. We tested with both our old prototype and our new version, to see whether they agreed with our adjustments. 

Two of our subjects thought that our controls didn't feel very natural. One of them suggested that swiping or tapping the top/bottom side of the screen would feel more intuitive. However we think that this approach would not be fun to play with, when the difficulty and speed of the game go up. Our other test subjects agreed with our choice for the controls.

Another major point of discussion was the placement of the tutorial button/screen. Most agreed that a tutorial should be present somewhere in the game, because some aspects of the game are not self-explanatory. The opinion we encountered the most was that the tutorial should start automatically the first time, but that there should be an option to skip the tutorial. They also feel like there should be a way to accesss the tutorial later on.

Based on everyone's feedback we have created a final version of the paper prototype.  Only the tutorial screen is not present, but there will be a button in the right upper corner that can skip the tutorial and let the player continue with the game.

Start screen

Pause menu

Highscore screen

Options screen

In the start screen you can see a play, highscores and settings button, each with their respective icons. The play button activates the tutorial only when it is first pressed. Otherwise it starts the game. The Highscore button and screen haven't changed alot since we only got positive feedback about it. In the settings button will be two options. One to mute the music and another to reactivate the tutorial. The game screen has received some minor tweaks in the pause button. Only a resume, restart and menu button will be available. If the player doesn't like the music he now has the possibility to mute it in the pause screen's right upper corner.

Stay RAAWRED for more!!

Reflection on paper prototyping.

Last Friday (10/10/14) we had our first encounter with paper prototyping. In this blogpost we will reflect on our experience, and the pro's and cons of paper prototyping.
None of us had experience with paper prototyping, thus the whole experience was new for us. So without further ado, a summation of the main pro's and cons, according to three inexperienced paper-prototypers.

Pro's

One of the of the main advantages of using a technique like paper prototyping vs a software implementation, is the speed with which new concepts and ideas for our casual game can be explored and evaluated. Adjustments, as well as complete new ideas, are cheap, resource and time wise. Draw a couple of lines, and you'll have a new pop up box. Think of some additional menu you would like to add? It's just a piece of paper away. The ease with which things are adjusted makes it easy to iterate ideas. Iteration is good. It is impossible to completely plan a big project ahead, without forgetting or misjudging some things. Building a project in small iterations will allow you to discover minor screw ups early on, minimizing the time and effort it takes to fix them. Paper prototyping fits perfectly within this philosophy.

We found that paper prototyping works best when modelling discrete states. Having users interact with a mock up of the interface, will show what they expect in terms of functionality, and what you might have forgotten (apparently users want return buttons). Having users think out loud about what they expect a button to do, helps identifying areas that are vague and should be improved.
Finally paper prototyping is also good for the exploration of ideas. After the main concept has been established by brainstorming, paper prototyping can help discover new ideas, that you wouldn't have thought of without actually interacting with the system. New game mechanics can be inspired by how users expect things to work differently than the developer originally envisioned.

Cons

Once a prototype has to display a dynamic system, it is harder to model with a paper prototype. For example, in the case of our casual game, showing multiple moving object during our game play is more difficult. It is thus harder to verify whether the envisioned game mechanics are actually fun, which is a major part of a casual game. Of course it is still possible to see if users understand the game mechanics, which is important. However when the main appeal of the game should come from the dexterity of the user, it is not a viable tool to see if users enjoy it.

Conclusion

Paper prototyping definitely has its merits. It is a useful tool to explore and evaluate the design of interfaces and game mechanics. It allows the developer to more accurately reason about which parts would work, and which parts require more attention. Improving at this stage in the development cycle is still cheap, thus a lot of iterations can be done. However paper prototyping is not a holy grail. Its limitations show the moment you get more and more different states in which the game can be. The moment you actually want to evaluate the fun of a game, as well as the difficulty, a more refined technique would probably be needed.

That being said, we will definitely be conducting several more paper prototypes with different people. This will hopefully lead to a more polished product, and will save us time, once we get to the actual development process.

First evaluation of the paper prototype model

Our first paper prototype was finished and now we needed people to test it. In total we had 4 test subjects, 3 students and the assistant. They played it and so the flaws in our design came to light.

One of the first big thing we forgot was return buttons in the menu screens and a pause button on the game screen. This was something that we could fix quickly.

In our first paper prototype a pop up screen would come up when selecting "play" the first time. This immediately bothered our first test subject. We then chose to put the tutorial as a different mode on the "mode" screen.

After one of our members had tested the game of another group, we noticed we were maybe putting too much content in our first iteration and we decided to drop the story mode and only continue with "endless" mode for now. This made the "mode" screen obsolete and we decided to drop that too. This caused troubles for the tutorial mode and we decided to move it to the "start" screen.

We proposed both ideas to our second test subject and he preferred the latter. So, the tutorial button was moved to the "start" screen. Another remark he made was that simple text buttons were a little old and that we could just use icons. For example a triangle for "play", a sprocket for "settings" and a podium for "highscores". We are still considering whether we will go for a full icon only approach or both icons and text. This will need to be tested later this week.

We asked the assistant if he wanted to be our next subject. One of his immediate remarks was that there were too many useless buttons on the "start" screen. He would personally never press the about,settings and tutorial buttons. He proceeded to press play and without a small tutorial it was unclear how to move the dinosaur. Our fourth test subject also ignored the tutorial button and had the same problem in the game. Another thing we learned from the assistant's feedback was that the settings screen could be replaced with a simple mute button.

That ended the first evaluation session and there were some major things to consider. Our design at the moment looks like this:

A "start" screen with only a play, highscore and mute button. Both the icons only and icons with text approaches will be tested. On the first start up the play button will show the tutorial and then proceed to endless mode. After that, pressing the play button will immediately start endless mode. In the pause menu of the game the player can still mute the sound.

This week we will continue to test and improve our prototype with other people. More updates on the design coming soon!

Paper prototyping conclusions and recap on session 1

The second session is over and a lot of new good information has come to light. But before we dig deeper into this session, let's go back to session one first!

Session 1

First we talked about things that we really wanted to have in the game. A dinosaur was quickly mentioned. Then after writing down some key concepts, we started on discussing some cool and fun concepts a casual game really needs. Highscores and leaderboards (and later maybe achievements) seemed like a good way to keep people playing.

The next thing we did, was writing down just anything that came to mind when we thought about casual games: existing games, play-types, features, concepts, ... . A game called Feeding Frenzy was mentioned. In this game you are a fish and you need to eat other things to grow bigger. This was a feature we liked and we considered using it in a dinosaur themed game.

So two big things were already pretty much decided after 2 hours of brainstorming: We want a dinosaur and we want it to grow. We didn't just want to make a copy of Feeding Frenzy, so we still had to find a new and fun way to let our dinosaur move around. We first played a little with the idea to make a Super-Mario-platformer-type game, but we weren't really convinced. Another concept came from the game Audiosurf. In this game the player hovers over a road, split into different lanes. While the player moves forward, he has to switch lanes to catch coloured blocks that appear in front of him, and dodge the grey ones. We agreed that we would take this concept and turn it into a side-scroller with growing dinosaurs.

So the game was born!! Next came the feedback from other students.

A couple of useful ideas were given. Among them was the concept of evolution (evolving from a small raptor all the way to a big T. rex as you feed your way to the top). The idea of putting a top hat on our dinosaur also came from another student. They also mentioned a few things that we needed to pay attention to, like making sure our game has enough 'replayability' and making sure our game doesn't resemble Feeding Frenzy too much.

As you probably guessed, we used the top hat idea and the dino top hat game was born!

Session 2

In session 2 the game idea was clear and we could start designing all our different screens and transitions. Naturally, we designed the start screen first. Immediately a few problems rose: "How many buttons should we use?", "Should we use icons or buttons with text?",... . Buttons with text won the fight and we chose to have 5 buttons: Play, Highscores, settings, about and exit. Nice, we have our first screen!

Start screen

Since we wanted the game to have levels with each their own highscores, a new problem found its way in. A few levels might not be enough to keep players entertained for too long. So a new screen "Mode" was made. The Mode screen had 2 buttons, "Story" and "Endless". In story mode the player can play through small levels and learn why the dino has a top hat. In endless the player can play for as long as he can survive, with the difficulty increasing all the time.

Mode select screen

When selecting story mode, the player will get a screen with all the levels. Each level would have a little story about our dino and why he is wearing a top hat. The difficulty would also rise with each level. Selecting endless mode would immediately start the game on an easy difficulty and increase it every few minutes.

Level select screen

A game should in our opinion have a tutorial which explains the basic rules. When selecting "play" for the first time, a pop-up screen will ask the player if he wants to play the tutorial. The tutorial will also be available as the first level in story mode. In the tutorial small instructions in the form of text bubbles will explain the mechanics of the game. We estimate the tutorial to only take about 1 minute.

Game screen

We continued by making the screens for the other buttons on the start screen. On the highscores screen, the player will see his name and his score for the selected game mode (endless or one of the story levels). At the top the player can switch through the game mode and see his 5 best scores for that mode. On the settings screen, the player can adjust the music volume and sound effect volume.
On the about screen, the player can read a little funny text about the game, told by a dino with a top hat. The exit button would just exit the game.

High scores screen

Settings screen

About screen

After all buttons and screens were made, it was time for testing!

The birth of Dino Top Hat

Teams have been formed and ideas have been shared, the Dino Top Hat game will be brought to life. For the course Fundamentals of Human Computer interaction at the KULeuven, we, Maarten Tegelaers, Joren Van den Brande and Wander Bavin, will be making a new casual game called "Dino Top Hat". It is a fun and fast-playing, highly addicting game where players try to beat levels and get highscores.

The Main Idea
The player will be controlling a dinosaur with a top hat. The dinosaur will be running through a constantly moving screen. There are four lanes on which the dinosaur can run, and the player can let the dinosaur switch lanes by tapping the left and right side of the screen. The goal of the game is to let your dinosaur evolve, by eating the smaller dinosaurs and avoiding the bigger ones it encounters on its run. Below is a simple drawing of how the game will look, to further illustrate our idea.

Users, technology and job
Since we are building a casual game, a few important factors should be considered. The game should be fun, simple, addicting and played in small time chunks.

Of course playing with a dinosaur might not be fun for everyone, we aim to target people between 12 and 40 years old. Those are also the majority of smartphone owners which will be our main focus, nonetheless shall players be able to play on their laptops or anything that can access a browser.

A good casual game needs to be simple, for that we only have 2 buttons that can be pressed to switch the dino lane. A highscore system will be available to keep players hooked even longer. We don't want players to play for 10 minutes before they can beat their previous highscores, so we will implement short levels with each their own achievements, highscores and awards.

Stay tuned for more!