Now this should be more expected as I’ve already done one of them so this should require zero explanation, let’s go.

What happened after the last Project Blog

Unfortunately, we found out a series of limitations within the Tango, so some of the initial design choices detailed in my last blog has been discarded, along with some of the planned features.

For starters, Tango’s mapping of space is 1:1 based, for every inch in the game, we need to map out an inch of area in real life for the game to be played. This completely shot down the idea of multi-roomed floorplan due to we cannot find a place that large in our school, or anywhere else for that matter. Additionally, because of this exact reason, it will create problems in our upcoming presentation and everyday testing due to needing a fair amount of empty space, which is not easy to come around between classrooms and force us to test our game in bigger areas. Even with greatly undersized room size, we still need a space to move around. Also we cannot undersize the room any smaller (to fit within the classroom) since that would defeat our core mechanic.

In the end, we shrink the original apartment down to an cabin with some clever placement of walls and other elements to fit with Tango’s limitation. We also simplified some other core game mechanics to fit with the smaller scope.

It’s entirely possible, if having enough time and budget, to fully map out the space for a full apartment room. However with the current time and scope, this is totally impossible.

Another problem with the original design is a bit of an irony. Prior in the design phase, we have already decided that if we want to effectively scare people. we should have the player play under the dark, i.e without any external lighting. However, we soon found out that Tango uses light to track player movement and more importantly location. Oops.

Of course that is easy to fix – If we cannot make the player play the game in a dim environment, the only way is to make the game itself dark. Of course, making the game dark meaning there needs to be something that tells the player about their surroundings due to the dim lighting would easily cause player to miss stuff. And we don’t want the player to miss anything especially in a gameplay focusing on finding things in the dark. We’re going to work out something from that.

Other than the limitations discovered (together with the one that Tango didn’t work well with heights but I thought I covered that already), our project is going smoothly according to the original design document.

Until next time.

Okay, time for something interesting.

Interviews and surveys are always interesting due to several reasons.

Firstly, most people are biased, and if nothing is done to tell them apart, we’ll get nothing but counteracting opinions, which is always bad.

Then, people tend to make their answers looks good or more towards the good part, especially if limited time is given, or the people doing the interview has a promised return but the interview/survey itself is not as interesting.

Because of those factors, an interview or survey should be crafted in a way that it spark the interviewer’s interest too.

Earlier, we already talked about human’s attention, or the lack thereof. While giving them prizes for completing surveys is a valid way of doing things, it would often leads to a heavily biased answer just for the quick prize.

Another valid way of doing things is to only cater to the people who would properly do the survey in the first place. Namely, there are lots of gamers that would agree to left down their impressions if they know their input would ultimately make the game a better one. This would at least get rid of the second possible flaw.

Then, it’s just the art of asking questions, or in other words, conduct a evaluation.

Talking about why, what, where and when

Why?

Normally, we need to know if our game matches the player’s requirements, and more importantly, if they like it and why.

For example (and I’ll use this game of mine a lot in this blog article), my own PHP Web Browser game, Battle Royale, is liked by players because it’s simple text-based MUD. It’s portable, meaning as long as there are internet access, one can play and drop out at any time. There are very few thing to download due to most of the game is text-based. Plus, the game is very fast-paced, which in turn means less time investments to play.

What?

We usually use a prototype of the game we’re making. In Battle Royale’s case, since the game is constantly updating anyways, we just use a production version of the game. The survey is located at the page bottom, any player can do it when they got time.

Where?

The location of the evaluation is important for some projects due to the evaluation needing more data. I could see the spooky house project being one of them since we’re working with devices and such. For Battle Royale, its MMORPG roots allows the evaluation be placed anywhere, due to we don’t need a lot of information and most of the information we need can be gathered from online means.

When?

It’s usually not a good idea to set evaluation sessions within the gameplay process because that would broke the immersion of the player. Personally, I’m a little uneasy with placing the evaluation before the game session either, unless it’s for prediction purposes (e.g. What do you think this game may about, etc.) since I found the idea of waiting to play a game – need to fill out something to play a game – seems counterproductive. Then again, in Battle Royale’s case, the survey link is always at the bottom of the page and one can access it at any time. From my observation however, most of the time it’s accessed after a player died in the round and is waiting for the next one to start. So my opinion isn’t alone, it seems.

In Battle Royale’s case, the data gathered from evaluation directly influences the next updates. From the replies, we can understand what our players want, and update the game to include more element they want. This also contributes to the game’s player groups since in their eyes, we as game developers actually hear what the players are saying, and is willing to change up our games for them. This alone earn us a lot of returning players.

However, there are more in it than just asking Why, What, Where and When. The last W, Who, is also an important matter.

As we discussed two weeks ago, there are lots of types of players, and each type is likely has their own requirements. It’s nearly impossible to produce a game that make every single player group happy. In Battle Royale’s case, what I did is before the actual survey, additional questions are added that seems random to the players but is actually testing their play style of the game. The results are then grouped into their respective play styles, with each play style with a different set of data. While this seems to be more work as I’m compiling the data multiple times with this approach. It proves to be useful in the long run as we can cater the game better to the type of players who enjoy playing our game.

In case this blog article is too egotistic – Of course I knew a lot of different other games that makes use of a good evaluation system. However, some of them are too complex while Battle Royale’s player group and developers are much closer. In larger games with more complex evaluation methods, the observation of evaluation result versus game changes usually takes longer time than intended. Recently as Battle Royale’s user group and servers growing, we too has this small problem of data coming in slower than we originally thought since we have more source of data but still the same resources to process them.

Well, this is for this week, for now.

Until next time…

Okay this is a little unexpected, isn’t it?

Since I got placed in a project group that deals with a spooky house game, I think I may write on that instead of user interviews. There are always next week to cover that topic.

Compared to the last few entries, this one would read more like a note, this is normal since I’m basically writing what I think first-hand.

Now, the concept of spooky house game is very vague. In a sense, the “Resident Evil” series of games, especially the first game, is a spooky house game, only instead of ghosts, the enemies are zombies. Then we have “Corpse Party”, a recent unique spin on Survival Horror by introducing some of the elements from adventure games. where players need to make selections and actually decide on what to investigate which alters the story and coming events.

As I’m looking at the requirements and doing the design, I noticed something very interesting. We’re using Google Tango, a device that allows for motion tracking and depth perception. So naturally, we want to make maximum use of those unique functions.

The inclusion of those functions can be used to properly simulate navigating inside a complex house with rooms, stairs and corridors. I admit the mansion in Resident Evil 1 crossed my mind for an instant when I realized this, then I reached the conclusion that a mansion as large as that one is not the best choice since that would greatly out of scope and is entirely impossible to do.

So what I do instead, is to use a software that centered on home creation to draft the mansion we’ll use. It can be treated as a certain way of prototyping since this only conveys the design of the house (the real house in the game would of course be a lot dimmer, a lot more evil and actually with ghosts)

The Prototype Apartment drafted in the software. Showing what room goes where, structure of the rooms, etc.

Of course, everything would change in the later prototypes.

With the concept out of the way, the rest is to decide how the narrative should go. I initially thought of a 2 player narrative where 2 main characters need to navigate the house from different locations with different goals. However since we only have 1 Tango unit available, that idea has to be discarded. So instead, I came up with the different types of ghosts we need to interact with (together with naming them):

• Chasers, which stays true to its name sake, chases the main character when discovered. When you’re caught by a chaser, bad things happen.
  • As for what bad things, it depends on the ghost entity. Personally I’m against jumpscares especially if they jump out from nowhere, though my teammates love that idea…
• Reactors, which reacts to the main player’s actions.
  • It’s the more puzzle like of ghosts, and will only be resolved by solving puzzle-like challenges in the house.
• Triggers, ghosts that just being there and would disappear once requirements has been met.
  • Basically gate that stop players from wandering around.

The core game mechanic would be to capture those ghosts with camera or some other tool, while navigating the house and not being captured by the ghosts, simple enough.

A simple mechanic leaves less room for error and makes sure that there are less to none room for player confusion.

Of course, everything still has a possibility to change based on the functionality of the Tango unit, the time and resources we have, and other factors. We’re still at the point where changing stuff won’t hurt much towards the developing of the project, so personally I’m not against any changes, and I’m always ready to fix and shuffle up the initial designs if it helps.

Hmm, maybe not the “Jumpscare-Game Over” mechanic, that mechanic has been done to death and won’t be effective if it always happens.

That concludes today’s project blog. Next week we’ll come back to user interviews.

So, until next time…..

Yeah the title is supernatural like that.

Last week, we looked into some factors that will grab player’s attention, and make them less confused. When the players know what they should be doing, it’s time to ask them what they really want.

So, how to know what they actually want?

However, what we human sees are often not what we really want. And human’s desires would sometimes lead them to a less better choice. That’s why asking the players directly for their ideas is not usually a good idea. There will be so much suggestions that would counter themselves due to each player has their own view on things.

Luckily, there is a way to break down various game design elements down, and that is Heuristic Evaluation (HE). It’s a set of standards and guidelines that can be compared to. Namely, we compare our game’s game design elements to the guidelines and see if anything violates them. If something does, that “something” would probably also turns out sour in most player’s eyes.

Obviously, there are multiple sets of heuristics since a single set of heuristic cannot cover everything. Normally, when we’re evaluating a game, we choose the heuristic that fits best with the game. One can actually treat the different sets of heuristics as different sets of players, and It’s only natural to pick the appropriate group of players when evaluating games.

Since this is only a blog article, I’m not going to do a heuristic evaluation of any game here since that’ll probably take pages and pages. There are other evaluation methods than HE though.

Another way of conducting evaluation to see if a game would come out right is to use Cognitive Walkthrough. It’s the practice of walking though the task from the user’s perspective and noting problems. While this sounds like basic, in fact I’ve seen a lot of game developers failing to realize that what they see and what they test are usually not what the player may see. For example. the MMORPG Champions Online boasts a Freeform Power System instead of regular Classes. In this system, players can freely choose, mix and match powers from different trees, creating the character they want to be. In the process, some players naturally choose a set of powers that are good in both offence and defense (In other words, meta). Everything worked fine until the game becomes Free to Play and a system that’s similar to the traditional class system is implemented for free players. As the entire game is balanced off the freeform system, the non-paying class-system users are having a very bad time. (Luckily, they’re solving this problem by more testing in between updates and make sure free users can also enjoy the content.)

In the above example, the reason why the game was suffering problems is that there are no indication anywhere that if contents are balanced towards whom. Initially, the developer’s approach is to try simply nerfing the difficulty of content to match the non-playing players. But then the freeform players start to dominate the content due to their advantage. The final temporary solution is to clearly label which area is for freeform users,  Until the re-balancing happens this small UI tweak seemed useful. While the balancing is a serious and hard matter, player’s exception can be somehow manipulated through the UI changes that give the players the feeling of belong.

Last week, I talked about player perception and how it could be manipulated. Usually, we’d want our representation to be perceivable without confusions. In the above example, the problem is caused by a game-play balancing issue. However, by splitting the player groups that are on the 2 sides of balance, a temporary solution is found. By simply labeling the balance of the content, the player could use the information to avoid content they don’t want. This is a clear case of manipulating the player’s perception by making everything clearer. While the players may not know what they want, we game developers can at least steer them into the right direction.

Of course, the better way of doing things is still to determine what the player’s requirements actually is, clever alternatives cannot work forever.

Getting those requirements out

There are different kinds of players, and there are lots of definitions of each type. To laying down the requirement, we must first determine what types our players are consisted of.

                                  ACTING
                  Killers            |                  Achievers
                                     |
                                     |
                                     |
                                     |
                                     |
          PLAYERS -------------------+------------------- WORLD
                                     |
                                     |
                                     |
                                     |
                                     |
                  Socialisers        |                  Explorers
                                INTERACTING

The 4 Playing Approaches in Online MUDs based on player interest. From http://mud.co.uk/richard/hcds.htm

The graph listed above is one of the ways to determine the types of players. It works on MUDs and by extension most of the MMORPGs. The different kinds of players will find different aspects of the game to be fun and interesting. For example, while the Killers would be more concerned on the balance of various powers in the above Champions Online example, Socialisers would care less than that and only care about how to Role Play better. That creates two kinds of requirements that’s far different from each other.

With different sets of requirements in mind from analyzing the types of players, one question remain – How do we know if one set of requirement is more important at hand?

It seems some direct data gathering is in order, which would be what we’ll talk about in the next blog.

Until next time….