A casual gamer in a hardcore world - Part 2

Several days ago, I wrote about getting a different perspective on the games that influence what I'm trying to create. I wanted to follow up and talk about a few more things that I noticed while watching my fiancee play Castlevania: Aria of Sorrow.

I plan to go into a little more detail this time with each issue, describing a way that I think would work to counteract the negative side of things. Anyway, picking up where I left off...

Not at all like a dice game in this context.

When looking through the special abilities, there was no way of telling how much damage a skill would do. I sympathize here, because it's a frustration I've experienced too while playing these games. The only hint available to how much damage would be done is the mana cost per use of the ability, and possibly how difficult it was to acquire. Even a simple rating for abilities like a scale from one to five stars would greatly improve the player's confidence that the ability chosen is the right one for the job. It's completely trial and error, which isn't inherently fun. People would argue that they have fun with systems like this, but it's only because they have to deal with the system in the first place that it "grows on them" - implementing a rating system would solve the problem before it's a problem.

Another game mechanic that was unclear was how the character would react to being exposed to water. One of the first rooms has a lot of water between platforms, with enemies constantly popping up to make sure it's not too easy to get to the other side. Again, an issue solved by trial and error, when you fall into the water for the first time (probably an accident), you see that the character safely floats in water. It's nice that the learning process here happens so very quickly, but the player shouldn't have to dive in to see what happens. It's tricky to think about how it could have been explained beforehand without explicitly telling the player "you float in water", but maybe water should be introduced for the first time a bit later in the game, and there could be some handwaving before the player gets there. Something like having another character say to him "don't forget to tread water if you need to cross a lake"...that's pretty bad writing, but it just popped into my head.

Just as a note about this, to really drive home the point of not knowing what to expect from water as even a seasoned veteran of the genre, in Castlevania: Symphony of the Night (which was the first Castlevania series game to use this style), water causes great harm to the player for every second he remains in it until acquiring special abilities late in the game.

The low ceiling makes it impossible to avoid the water here. Sink or swim!

The game is divided into rooms, each of which can be multiple screens wide or high, but the transition from room to room is a quick fade out and back as you cross the threshold into the next room. This presented an issue with rooms that were entered by jumping up through a hole in the ceiling area, because it was necessary to continue jumping and aiming in the correct direction to stay in the next room. A simple fix for this issue would be adding already-implemented "drop floors" in these places, that is, a platform that the character can fall through by crouching before pressing the jump button.

The way I look at it, these things may not necessarily take away from the fun of the game, but they certainly don't add to it. Look, I'm not saying that these game elements don't have their charms, but it really seems like there's a little bit of game designer vs. player going on here. It's the designer's job to make sure the player is challenged, but fighting the game mechanics isn't anywhere near as fun as fighting through challenging enemies and solving challenging puzzles.

There's still more to come, so tune in next time for more insight on how to hopefully use the past as a map to the future.

Drawing inspiration from the genre

The other day I spent some time "researching" (ah, the things I go through for science...) to see what other games have to offer above and beyond the typical standards of the genre.

I played through an interesting flash game called Arzea, which was made by Arkeus for Ludum Dare 22, a 48 hour game design competition. What really stood out to me in this game was the sheer simplicity of it, and yet it felt like it had quite a bit of depth. In addition to locked areas requiring keys, game areas were gated by having higher and higher walls, which required collecting max jump height increasing power-ups. The fact that the player character becomes significantly stronger throughout the game, in addition to the way save points completely restore health, made the game easy, but given the rapid development, it's certainly forgivable.

How much more tutorial could you possibly need?

Another game that really drew me in was Treasure Adventure Game by Robit Studios. There were several things that stood out about this game, but I would have to say my favorite would probably be the hats. In the game, your character can obtain several different hats, each of which serves a very specific purpose. For example, wearing the blue hat will trick flashlight-wielding robots into thinking you're the janitor at the company building, so they won't sound the alarm if you walk into their path. Overall, this game was unique for a lot of reasons, and it's definitely worth a look if you haven't played it yet.

The Magic Bottle from this game was a huge step into unfamiliar territory that really paid off. Many of the puzzles in the game are solvable by using a different function of the bottle, whether it's capturing fire to spew at thorns blocking your path, or capturing wind to make a propeller work, and several other uses. At one point you could even capture hallucinogenic smoke created by burning mushrooms to make invisible blocks appear while distorting vision of the world around you.

Blue hat makes this area a snap. Without it, not so much...

I could probably go for pages and pages about Metroid games like Metroid, Super Metroid, Metroid Prime, and Castlevania titles such as Symphony of the Night, Dawn of Sorrow, Portrait of Ruin, and so on, but it's almost too obvious to talk about Metroid or Castlevania games in the context of the Metroidvania genre (see how that works?) - The most important thing I take away from looking to these examples is that each of these games expanded the style in different ways, and it's incredibly rare to see stagnant gameplay in these series. The core concept and style stay the same, but so many gameplay options change in so many drastic ways.

This part of the Metroid wiki page pretty well sums everything up:

Common gameplay elements

The Metroid series contains gameplay elements from shooter, platformer, and adventure games. The series is notable for its non-linear progression and solitary exploration format where the player only controls Samus Aran, with few or no other characters to interact with. The series has been a 2D side-scroller in all its incarnations until the Metroid Prime series changed the perspective to a first-person perspective, leading to a new first-person shooter element. The player gains items and power-ups for Samus's cybernetic suit by defeating alien creatures through real-time combat with her arm cannon, which enables further exploration. A recurring upgrade is the Morph Ball, which allows Samus to curl into a ball, roll into tight places and plant bombs.

The original Metroid was influenced by two other major Nintendo franchises: Mario, from which it borrowed extensive areas of platform jumping, and The Legend of Zelda, from which it borrowed non-linear exploration. The game differed in its atmosphere of solitude and foreboding. Metroid was also one of the first video games to feature an exploration to the left as well as the right, and backtracking to already explored areas to search for secret items and paths.

That's right, you could move left and right. 1986 was a year for radical new thinking.

Building worlds, not just games

It could be argued that the key element in any video game is immersion. Even games like Angry Birds and FarmVille, which most "serious" gamers would say they can't stand, put the player in a situation that captures the imagination.

When someone sends out a request for their needs in FarmVille, the message that they send says something like "help water the crops" and not just "click this hyperlink to help" which, on a subtle level, helps immersion by establishing that the goal is to complete an action in the game. The game puts the player in control of a little world, where his actions have consequences and things happen while he's away. Like it or not, it's actually a great example of how games are able to give the player a sense of purpose in the world they've created.

Think of the poor, delicate strawberries!

Some games set up the game as a complete escape from reality, and the experience is heightened by turning out the lights, putting on some headphones to drown out the outside world, and delivering a theatrical experience to make the player feel as if he is another character in the game, like someone watching the story unfold from just out of sight. It's usually first-person games that work this way, but it's a method that also sees a lot of use in horror/survival games, such as Resident Evil or Silent Hill. Look out, Pyramid Head is just behind that next corner!

In other games, the gameplay portion takes center stage, and the player becomes immersed by identifying himself with the actions taken by the character. In a platform game like Super Mario Bros., when the player presses the "jump" button, he doesn't think "I pressed the button that made the character jump," but rather "I jumped." In this way, the player projects himself onto the main character in the game, and with good storytelling, this can evoke emotional responses.

Ok, so Mega Mario doesn't really need to jump...

In the game I've been working on, I hope to achieve the latter of these methods with the story that I'm presenting. The story is a bit of a roller coaster ride, with the character going through periods of enthusiastic optimism, followed by suspicion, which leads to trying to fight off hopelessness, and I can't say much more than that because I want the ending to be a surprise.

Ultimately, it's ideal when a game gives the player a high level of immersion, whether it's hoping your crops make it through the night while you're asleep, or the world is going to come to an end unless you defeat the nasty villain and save the day. The player's mindset certainly plays a big part in how immersive any game can be, but every designer should work hard to help draw the player in and really let their imagination run wild.

Death and rebirth in video games

In most games, death of the player character (or player-controlled adventuring party) means failure at the game. I've done a lot of thinking about what I want to happen when the player dies in the game I'm building.

Castlevania: Symphony of the Night, a flagship entry of my chosen genre

Many games simply announce that the game is over, forcing the player to restart either from a recent saved game, or even restart the entire game from the beginning if the game doesn't allow saving. It's very easy to program this type of scenario, and it requires very little thinking for the designer, which probably explains why this mechanic continues to be prevalent. I personally feel that this is very harsh, and it's caused me to completely put down games where it meant that I'd lost a good chunk of progress.

I'm curious about the implications of treating death as simply taking control away from the player, and seeing what happens if that isn't the case. There's a general consensus among game designers that if the player is going to lose the ability to interact with the game, it better be for a really good reason; stories are often told in cut-scenes which I'll save for another topic. Thinking about this got my gears spinning and I came up with an idea for how death might play out in the game I've been working on.

What if, when your character dies, he becomes a ghost. He must return to the previous save point (they could be explained as altars to add immersion) as a ghost, but gameplay would be greatly simplified during this time. There would be no more concern about height, or failing at platform puzzles, because the player's ghost could simply float through the air as he pleases, and be invulnerable to attack. Upon reaching the save point, he becomes reincarnated into his human body, and the player resumes adventuring from this point. The ghost would need to be disallowed from forward progress, since his ability to travel greatly dwarfs the physical body of the player's character, which can be handled with some careful programming.

At a glance, this looks to be close to the above method where the player must simply restart from a recent save point, but I think that it's not. It's important to note that the player will still be in control of the game the entire time, and that it's another style of gameplay, almost a "bonus" mode where the player can move freely around his already-explored map. The other thing that sets it apart is that the player would not lose any items found or any of the benefits of exploring areas and defeating monsters such as money or experience points. This means that while the player loses some progress in the form of needing to retrace his steps to get back to where he had died in the first place, he won't feel the harsh loss of all progress made.

A suggestion made by a friend of mine was that instead of turning the player into a ghost, control could be given to a friendly companion or npc, like a monkey that carries the player back to the save point. Again, to make navigation easier, the monkey could climb walls or something. In this method, again, the player is still participating in the game, which I feel is one of the most important things possible when designing games. I worry that when developing this method, the monkey could be vulnerable to causing another death for the player, which could compound frustration instead of relieving it.

Death is handled quite differently in this game...

Something that I recently got turned on to was the death mechanic in Prince of Persia: Sands of Time. The game was played as if it was the manifestation of the imagination of someone having a story told to them, and when the player died, the storyteller announced that "you misunderstood, that wasn't the way the story goes" and the player's progress is reset to a nearby checkpoint so that he can retry the mission from there. It's enough to make the player think, while simultaneously reprimanding him for failing.

However death is handled in a game, an effort should be made to reduce the player's frustration in direct proportion to his expectations for the game. If a game advertises itself as being incredibly difficult, then death should have a severe sting, but for most games, the player should be able to stay in the action as much as possible. At the end of the day, making games is about providing a fun experience for the player, so frustration should be the last thing you'd want them to feel.

First (and second) look - early mechanics

I've gotten some work for the game engine going, so I thought I'd share a couple early videos of what there is so far.  Don't be put off by the placeholder art, although it's lovingly crafted, it's not representative of what the final game will look like.

Here's the first video I posted, where you can see how the character jumps and interacts with terrain...there's still so much to be done to make it work, but it's a start.

This next video showcases the fact that the terrain is built on black boxes to indicate where the ground would be, which would have a graphical layer drawn over it.  It also shows the game camera which follows the character to the middle of the screen, then scrolls the background until it hits an edge.  This way the character will always feel like the center of attention.

All feedback is welcome, positive or negative.

A casual gamer in a hardcore world - Part 1

Maybe the title isn't exactly what I'm going for, but close enough. Since I'm planning to have a game that's landing in a genre traditionally considered somewhat hardcore, I wanted to get opinions from someone who's not familiar with this type of gameplay.

I put the task to my fiancee (whose only gaming experience is World of Warcraft), and set up a copy of Castlevania: Aria of Sorrow for her to play. In my opinion, it's a fairly accessible example of the Metroidvania style, but I was about to learn what player-friendly really means… I should point out that I have a lot of information at hand, so I'll be spreading it out over multiple posts so this one doesn't run on forever.

Soul Trade isn't explained in-game at all...

I want to preface this by saying that besides explaining how the various buttons work on the controller, I tried as hard as possible not to interfere, tell her where to go or what to do. I wanted to hear her untainted feedback about a game that can be rather unforgiving. Don't worry, there's some good in with the bad. Let's begin, shall we?

The first thing I noticed when she started up the game was that the screen where you get to start a new game was not very intuitive. Before you could choose "New Game" there was a menu screen where you can choose from the options "Select Data", "Copy Data", "Erase Data" - it doesn't take long to figure this out, but it can easily make the player feel like they fell into some data management nightmare by mistake. Maybe the New Game option is back on the main menu, she thought, and went back to it.

During the opening cutscene, there was a part where the player's character is about to be attacked. She told me she pressed the attack button in response to the enemy coming in to attack. This means the cutscene did a great job of capturing her attention and even bringing on a little intensity.

When I asked her about it, she said she wasn't very interested in the opening dialog, although it may have been mostly due to the fact that she wanted to jump in and start playing. She did tell me that she tried to pay enough attention to characters being introduced so she hopefully wouldn't be confused later.

Doesn't this make you want to fight back?

The lack of in-game tutorials really hurt the starting experience for her, I had to explain how the special attack abilities worked, like what button combo used them, and how they cost mana (and how mana recovers over time or from collecting hearts from breaking candlesticks), which really added a whole new level of strategy to combat. I know the game comes with a manual, but game designers shouldn't rely on expecting every player to have read it before turning on the game for the first time.

There were some issues that came up that could be better described as classic game conventions, so I won't chalk those up to being faults of the game. Things like not understanding that the enemies hurt the player on contact, or that opening the menu pauses the game, or how to know that your character can't attack again while the attack animation is still playing. It's still worth noting that, while rare almost by definition, there may be some people playing that don't know these rules, and it's probably ok to quickly explain the basics if it's done in an in-game manual or something.

In conclusion, I'd like to point out that these issues came up in just the first few minutes of playing, which can be a crucial time period to get new players interested in the game. Especially with demos and Let's Play videos being so prevalent, it's important to make sure those first impressions count as much as possible. Stay tuned, next time we'll talk about getting into dangerous territory with various enemies and unexpected situations like not knowing whether or not the player character can swim.

Putting ideas together

One of the things I've found to be trickiest about designing a game is expanding in all the necessary ways from the initial idea.  It's nice to come up with something like "let's make a treasure hunter guy like Indiana Jones and put him in all sorts of historical settings like Egyptian ruins!"  That certainly sounds like a solid idea (forgive me for my bias, this is the game I'm currently working on...) but it's a far cry from being specific enough to actually build a game on.

There's a lot more to it than that, including but definitely not limited to things like what enemies/conflict will there be, how big will the game area be, whether or not there will be non-hostile characters for the player to interact with, and so on.

I've been working on nailing down more specifics to get the game more fleshed out, and when I do this it's easy to take things too far.  For instance, in a side-scrolling action/adventure game, to get to higher platforms or across wider gaps, double jump is a pretty standard game mechanic, but what if I think about adding areas that are a little more out of reach than that, the player would need an ability that can allow him to get to those areas...should the player be able to fly with a jetpack or something?  It's too early to tell on things like this, and that's the point where I have to step back and say, "I'll come back to this later."

Flexibility is important in a game's design, I think, but changing and adding design elements should be considered carefully.  I remember reading something that went something like, in contrast to thinking outside the box, it's better to think on the edge of the box.  To put it in my own words, it's good to expand your thinking, but stay in familiar territory or things can quickly get out of hand.  To the above example of player movement abilities, giving the player a jetpack may not quite be the perfect idea, but it's probably a lot closer than, say, having the player turn into a bird to be able to fly.  Both examples here accomplish the same goal, but one would feel far more abstract in the world I'm trying to build.