NMFORCE BLOG

Last time we end our Project Blog #2, we left a question unanswered.

That is, since the limitations of Tango apply to our project, we cannot do our gameplay in a dim space, to act as substitute, we made the game itself super dim instead. However, the dim environment of the game world means that the player is very likely to miss something in the game world. As our core gameplay mechanics involves finding ghosts floating around in the room, and taking photographs of them while looking for key items, thus requiring knowledge of the game world.

Yay for conflict between gameplay and mechanics!

Of course, we need something to alert the player without letting them see.

Even though Google Tango is one awesome system, it cannot provide anything than visual and audio input. Since the visual input are out of the question, this left only with the audio input. Meaning that we can only tackle this problem soundly (pun intended).

So, we decided that for each event happening, in other words, when there are something that requires attention of the player, there should be a sound based on it.

Talking about sound, there are background sounds (BGM) and foreground sounds (SE). And that’s how they’ll work:

• BGM
  • A background track, consisted of drums, bass and some percussion constantly plays in the background as the game’s BGM. The track is composed in typical slow beat drum & bass fashion so the player won’t getting bored listening to something without a melody.
  • However, when an event is fired by the system – A ghost appears or a key item appears – The track’s melody part, consisted of flute, piano and guitar would kick in, since this also changes the genre of the background music, it’s considered as a sudden and apparent change in atmosphere. Because of the unexpected change, the player is then realized something has happened.
  • This is achieved by recording the two tracks in different files, and while the files are both playing, the melody track’s volume is at 0 unless something happens which would increase the volume. When the event ends, the volume is reset to 0.
• SE
  • A series of SE is prepared and is read by the engine as sound files.
  • Each SE is tied to a location within the game world.
  • When something happens, the SE that’s closest to the event would play. Its volume is calculated from the player’s position to the sound source.
• Aside from BGM and SE changes, when an event occurs, there would be something displayed on the HUD to further reminding the player that actions need to be taken.

As of now, the programming of those functions are coming nicely. I had to say, Tango would not be a that good choice on horror games, due to its various limitations. It is more fitting as something that is exactly the same in real life and in the game world. For example. an library or a museum, where the Tango can be used to provide additional information based on the user’s location (e.g facing a specific piece of art, displaying on Tango the detailed information regarding said art). But regardless, our game is still coming nicely and I think we are doing the best we can on this.

So, until next time.

Recently, Me and my programming circle of friends asked our artist to redone the UI of one of our long-running game projects. What project, you may ask? Why, Battle Royale, of course! (Known as Hunger Games in English Versions).

While the changes detailed in this article won’t be pushed to the English version yet, I found our train of thoughts behind the UI changes interesting so let’s talk about it here.

So, what got changed?

(Both screenshots are from the Chinese Version of the game, but the exact changes are unrelated to languages.)

Old UI

New UI

Aside from the obviously rehashed avatar artwork, the biggest change is the font used to label the player’s status, together with the changes of the visible HP/SP gauge. Let’s talk about them one by one.

Font and color Issues

The old UI used a font that’s remain unchanged until just now. Originally when we’re programming the interface, we’re thinking of something really threatening. Since we want to direct user’s attention to their status. Especially the part where player’s current health status is shown. (Fine in Green text, Caution in Yellow text, and Danger in Red text) Then if the player is also inflicted with a special debuff, the corresponding debuff will light up in different colors.

However, recently some of the player just felt that something is not right, but cannot pinpoint where. As what I said before in this blog, you cannot let your player spell out the problem for you. So we performed some testing and find out the colored text sometimes dazzle the players for some reason (I mean, at least I don’t think anything got wrong…)

Well, it’s true that indeed the contrast of fully colored text on a black background seems to be unnatural, and after looking into some design principles regarding colors, we eventually choose white on black since that’s the most attention grabbing combination without the unnatural contrast.

However, we still need the Green = Fine, Yellow = Caution and Danger = Red color coding to preserve the user’s habits. After years of playing, I doubt any long time player would see the “big red text” without any action. That’s why we added the appropriate glow on the white text. Due to the text is now glowing instead of being pure colored, the original sans-serif font proves to not showing the glow enough, forcing us to change the font into a serif font.

Let’s put it this way – This is easy on the eyes.

Fill Vs Outline

After dealing with the color and the font of the status texts, the original HP and SP gauge now seems out of place due to lacking a glow and using pure, brighter colors.

Of course, our first thought regarding that is to just change the color of the fill to be deeper, matching the hue of the new glow.

Then, we found out that against the black background, the changed gauges now is hard to see due to their colors being too dark. Time to change that as well!

If filling something with dark colors won’t work, then let’s just create some highlights. However, to the old players, suddenly changing the human shape to always filled human shape only with highlights marking their current HP and SP provides to be confusing – The players has get used to the changing fillings, and now the fillings won’t change which is met by some negative feedback.

Facing with that, we reversed our line of thinking a bit. What if we don’t include the fills in the first place, and just used the outline as the gauge, and highlight the parts of gauge to act as the indicator?

To the players, the highlight acts like a filling of colors due to we made the outline much bolder compared to the early design.

Well, that’s the story behind the game’s recent UI change. Originally we only wanted to change the color of the text, but that eventually leads to more changes that resulted in a much different UI, as long as our players like it, it’s good for the game.

Until next time.

Most users of Microsoft Office would probably think Clippy, or the other Office Assistants are unneeded, which is why it and its friends are absent from Office 2003 onwards – Well, they are kind of hidden and need to reinstalled in Office 2003, and is totally gone in the later version. But is it really caused by users not needing the service they provide? I don’t think so.

Well, let’s see some of the similar assistants and we’ll go back to my statement.

What if we give Clippy more functions?

Around the time Clippy is hot as an not-welcomed Office Assistant, over the seas in Asia, a certain program called Ukagaka came out. The word is from Japanese where the open-source program originated, meaning “Something to be fed”. Another common term of this kind of program is Nanika, literally meaning “Something”. It look like this:

A Ukagaka is consisted of 3 parts: A Shell, that’s what you see – a virtual character on the screen. A Ghost, which decides the response and AI personality of the Ukagaka in question. Finally we have A Shiori (means Mark, as in bookmark), which is pure script programming to utilize the Ghost and link the Ghost with the Shell, together with all possible functions the author want to program. Finally, the 3 parts are processed by the Engine named Ukagaka to present itself onto the user’s screen, providing various functions.

Since any author could program the script in their own ways, and the script program itself being very extendable, those desktop assistants can do everything, from chatting with you, randomly start some topics or display some trivia, to useful functions like a calculator, a dictionary, a search engine, etc. It can also track user’s actions and respond to them accordingly. (For example, close itself with an animation and a “goodbye” when it has detected user’s shutdown computer command)

Guess what, people like it a lot! They like it so much that new Ghosts and Shells are being produced everyday by everyone. Take the screenshot character for example, he’s from the 2015 game Undertale. While the Ukagaka is a thing from almost 10 year ago.

Why? Because it’s useful? Well, let’s see something else then.

Also desktop assistants, but does nothing aside from being cute

Around the same time, or even earlier than Ukagaka, there is another kind of desktop assistant, or better put, “pet” called shimeji. The name is also Japanese and roughly translate to “placeholder”. They’re little animated sprites that hang around your windows and desktop, doing nothing, taking over your computer memory and just being cute.

These little desktop pets don’t have any function, and is just coded to stick around based on the position of your windows and current actions. These sprites will do their proper animation when interacting with the desktop, for example, if you drag one off one of your windows, it will fall down onto your taskbar (or the bottom of the screen, if your taskbar is hidden), or when you’re writing something, it will look up or down as if looking at what you wrote. But only that, nothing more – these little guys don’t provide any function at all, and are just being there, hence the name “Placeholder”.

Weirdly, those are also highly popular, despite having a history of more than 10 years. Proving that yes, users could also like pets that hang around the screen for no reason and no function at all.

Then what happened with Clippy and Co.?

Let’s see what Clippy does.

When you’re writing something, it jumps out and ask if you want to write a letter, even though you’re probably not writing a letter.

When you get a word wrong, it jumps out and ask if you need more spellcheck options.

When you’re doing an action in Office, it jumps out and ask if you need any sort of help, no matter if it’s the first time or not.

The main problem surfaces – It jumps out on its own.

Neither of the above two assistants did that.

If a user wants help, they can always click the assistant. Or if a user just want a companion, they’ll also not wanting said companion jump out every two minutes offering unneeded help.

That’s the real reason why Office Assistant flopped. It holds a complete disregard to user needs, and would bound to disappear. Nowadays, the only trace of clippy is hidden as an easter egg in an optional setting, which is sad.

For me, i actually like them as a silent companion – Just turn all help off and let it watch me write.

Actually, it’s not Microsoft’s first time mess those assistant up, their first failure is in Microsoft BOB, but that’s another can of worms that I don’t really want to talk about here (Yes I used it, no it’s a huge failure).

So, until next time.

Recently, it’s true that VR & AR are becoming the hot topic. While there are already Youtubers showcasing the wonders of Oculus VR, and with Steam pushing their own VR hardware with HTC (Revealed very recently several months ago), the future of playing games seems to be very interesting.

VR and AR, where are we now?

The key difference between VR (Virtual Reality) & AR (Augmented Reality) is that while VR put the player in a virtual world using special devices (replace what they see and what they hear, and in HTC Vive’s case, also replace what they use with their special controllers), AR projects the virtual world directly in the real world. Currently, apart from the HTC Vive, which haven’t been released, VR devices still mainly uses traditional controls (isn’t it weird that you still need to use keyboard or game controller when you’re in a virtual world?) while AR’s limited usage is focused on displaying various information or bring virtual characters to life.

As one can see in the above screenshot. AR nowadays is as limited as VR currently is, the key to AR is that there needs to be some sort of vessel to project the virtual image onto the real plane. While Nintendo 3DS requires special AR Cards, it’s already proven that just printing the Card content on any surface would work due to 3DS displaying the models based on the content of the card. Similar AR technology such like Google Glass instead project the virtual data onto the wearable displays. In my opinion, AR technology has fewer problems to tackle due to Google Glass already did the job of enhancing what we see (and hear, if paired with an earphone). The only other problem is to iron out the cost of the system, and the convenience of said hardware (wearable hardware is definitely a right step). In the current form, Google Glass is still too expensive for everyday use, and its function is still limited, but it’s Google we’re talking about, so that would change in short time.

Current Problem with VR

While AR is more or less on the right track, VR on the other hand are having more problems.

The foremost problem is about the cost. In order to experience VR, suitable hardware need to be purchased. A key difference between AR and VR is that while AR only need one single device to use (a Nintendo 3DS is less than $200, think about it), in order to utilize VR, an entire solution, consisting of the VR devices, and a computer capable to run the VR apps need to be both prepared.

According to Steam’s recent statistics, there are only 5% of computers able to run a VR app smoothly. This is one key obstacle, if only 5% of the current users are able to utilize VR, then how many money does the rest 95% need to spend to upgrade their computer on top of the steep cost of the VR device itself? While it’s entire possible for Steam and HTC’s Vive, one could somehow got it to work with a Steam Machine. But Steam Machines are not cheap either: High-Ended devices could easily cost more than $1000, which is never a small cost.

Compared to the steep entry fee, actual programming of the VR apps would be the least of the concerns. However do note that to program VR apps, a system that is able to run VR together with that device is still needed, that still put the cost of producing VR apps much higher than intended.

So, my opinion on this trend: While both VR and AR are world-changing technology, one may still wait some time to fully enjoy benefits of them.

Until next time.

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 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…..

If there’s one thing that is well known within the circle of game developers, that is the players of their games are very, very hard to please. It’s true that game developers and designers aren’t telepaths and know everything the player’s thinking, but that still didn’t justify player’s actions sometimes. It seems they always have the way of getting the intentions of the designers wrong, then come back and blame the designers for everything they haven’t done wrong.

In other words, no matter what the developers do, there are always someone that’s not happy.

While this is indeed a very sad matter, there are ways to get around that.

Remove unnecessary stuff

We humans may have unlimited potential, but we do have limited attention. Most of the time, we don’t need every single piece of information, even if it’s something that seems important. One example comes from the Mega Man series. The first game in the series feature a score counter that’s shown on the top of the screen, there’s also an item that when collected, adds up a multiplier at the end of the stage which gives more points. Each Robot Master also comes with a Clear Point. (and I must add, I don’t know why some of them are higher than others when they’re equally hard, maybe that’s just because of me.) Then, Capcom found out that this game is so difficult that clearing the game is a feat in itself, and since score is only calculated from enemies and boss destroyed and multiplier items gotten, meaning people are going to get the same range of score anyways, later Mega Man games do away with the scoring system altogether, and never speaks of it ever again in all Mega Man games after that. (Well, some of the other spin-offs has a rank system, but players with better techniques are getting higher ranks thus make the system actually useful)

Obviously, Mega Man Series get away with the entire score system is just a Special case due to the game’s difficulty and linear gameplay. In most of the games, it’ll be confusing to throw every single unnecessary mechanic out. Thus, the more accessible way of managing unnecessary data, is to keep them under the hood so players can direct their attention elsewhere. A common practice in STGs (Shoot’em ups) is to blur out the HUD Elements when the player sprite is on top of them. Since the player’s current location, together with the bullets’ current location are something players want to have more attention directed to.

Make necessary stuff stand out – But not too many

While we’re still on the topic of STGs, it’s not uncommon for these games to notify the player, either by audio or video means, that they have extra resources. (Bombs, Lives or Power-Ups) which stems from the similar practice. The reason being that while we want to keep the user’s attention on the main gameplay, we also want to direct their attention to their available resources when these changes. Now, if they actually used said resources, they’ll get feedback in the form of actually using resources – It’s only fair that they’ll get some kind of feedback when things go the other way.

So we let the unnecessary stuff become hidden, and the core stuff becomes the center of attention. Then for the really necessary stuff, we’ll just make it stand out so it can grab the user’s attention.

Note that this tactic, while seems cool on paper, has a big chance to mess up if the player don’t know what to do. For example, say there’s an adventure game with some puzzle elements. The player is now facing a control panel full of buttons. Suddenly, a red button lit up. Most of the players will then reach for the red button since it grabs their attention. Then, after doing that, a green and a blue button lit up together.

Now the player is confused – which button should I press? The green one, the blue one? Or press them together? While the player is busy thinking about that, the control panel exploded due to inactivity, killing the player.

This exact practice is actually popular in older adventure games. However ultimately the trial and error approach would leads to more angry players than clever or lucky players that figured out the correct way in the first few tries.

In short, don’t overwhelm player with big number of “necessary stuff”, in most of the cases, one is enough. If absolutely needed to do two or more in one go, try using some way to warn the player (a.k.a grabbing their attention) first.

We can actually continue talking about perceptions and how that’s also unreliable, but for a specific reason, we’ll leave this to the next blog.

In the next blog, we’ll talk about how to extract what the player really want from their feedback. Yeah, this totally seems like telepathy now…

Until the next time….