Wednesday, August 17, 2016

Making Difficult Fun: How to Challenge Your Players

We are game developers. Most of us love games (which is why we got into this business in the first place), so it's likely we've played hundreds of different games over our lives.

The thing is, though, that gaming is a skill. Much like playing an instrument, it is something that can be honed with practice over time. Therefore, it's not unreasonable to assume that most of us are pretty good at gaming.

But not everyone is great at playing games. When you develop a game, you need to bear your target audience's abilities in mind, and that our own preconceptions of “simple” and “hard” can be skewed. Let's have a look at what you need to think about, and how these ideas were put into practice for my game, Cosmic Logic.
A level from Cosmic Logic
What Do Players Want?

One of the most fundamental elements of gameplay design is challenge. Without challenge, a game isn't a game: at best, it's an interactive movie. And while there are "game-movies" out there which are successful, developing one is closer to a movie maker's skill set than a game designer's.

So when playing a game, players generally want a challenge. But, importantly, they want a challenge they can complete. If I play Street Fighter with a friend, then we'll most likely be evenly matched, having fun button bashing away an occasional victory.

If I challenge a pro-player to a game, then I will just get repeatedly destroyed. It's not fun for me, and simply emphasises how bad I am at the game. As a rule, being reminded that you are bad at something is not a positive experience.


On the flip side, however, players also want to feel as if they've earned a victory. When I play games, I don't sit down and play children's games. Sure, I can probably set a record time for "work out which hole the square block goes into", but it doesn't provide me with any real stimulation. The purpose of challenge within a game is to test the player, and once a player has mastered that challenge, it no longer serves a purpose.

So, when we design our game, we need to decide how difficult it's going to be. All players want to play a game that provides a challenge, but that challenge is relative to the skill of the player. Someone who only plays games for a few hours a month might enjoy solitaire, whereas a serious gamer might only play a game like Starcraft.

Neither of these games is necessarily better than the other, as their audiences are vastly different. Regardless, the basic rules of game design apply to them both, and we have to appreciate that difficulty means different things to different people.

Making Difficult Fun

So what is the difference between an easy and a hard game? Games are complex, and it's not possible to simply say, "Oh, if you change this one variable, then the game becomes difficult."

In fact, taking the simplistic approach of changing variables is a very good way to make a game "unfun hard": you can double the hitpoints of the enemy boss, but you're not changing the actual difficulty—you're simply making it take more effort. The term "bullet sponge" is often used to describe these fights, as it often feels as if the boss just constantly soaks up damage with no regard.

As I mentioned earlier, the purpose of a challenge is to test the player until they have mastered that challenge. Bullet sponge enemies don't really modify the challenge—they simply make the player repeat the challenge an additional number of times. Worse, if the player dies, then they have to repeat said challenge from the start: and then you find yourself in the position of playing something which is no longer fun.

We can think of every gameplay element as a mini-challenge. When you're playing Mario, you move to the right. First challenge, jump over a pit. Jump over a goomba. Jump on a koopa. All of these things are challenges that must be overcome.

If the game was simply "jump over a goomba" ten thousand times, it'd be tedious. But because the challenges differ slightly each time (oh, this one is on a platform, and this one is protected by a Hammer Brother, etc.) it provides enough variation for the player to keep interest.

Mini-challenges: cross the pit, avoid the goombas, hit the ? block and navigate the platforms.
So a basic rule to keep things interesting is to slightly modify the challenges. In fact, you can get away with quite a simple gameplay premise if the "mini-challenges" are constantly changing or evolving. In a game like Mario, you can keep reusing the same basic challenge (jump over a pit) if you make slight modifications to it (this one is guarded by an enemy, this one has a moving platform).

Patrick Holleman has talked about this idea of designing challenges within Mario previously, but the base principles are applicable across almost any game.

Forcing a player to repeat content is where "difficult" becomes "tedious". For example, if a player dies, then you don't necessarily have to force them back to the start of the game. Recent Mario games contain infinite continues, or even mid-level checkpoints to ensure that if the player dies, they don't have to replay the same content over and over.

A difficult game should be one which pushes a player into mastering their skills, rather than forcing them to repeat something over and over until they make a mistake.

A Game Everyone Can Enjoy

Ideally, we want to develop a game that appeals to both serious and hardcore gamers. One popular solution is to include a choice of difficulties (easy/hard) at the start of your game. However, there is no guarantee the player will choose the correct difficulty to maximise enjoyment. There exists the possibility to design your game for all skill levels: where a crossover of players can enjoy the game without being forced into a particular path.

Grand Theft Auto is arguably the most popular of the "crossover" games. It's an incredibly successful title series, and for good reason—for the most part, it has something for everyone to enjoy.

Part of the reason for this is because the game is so expansive, you can choose what you want to do. In fact, there's a rather cute story about a four-year-old playing GTA (under parental supervision, obviously). If a four-year-old can have fun playing a game that 30-year-old veteran gamers can enjoy as well, then you're probably doing something right.

But your game doesn't necessarily have to be GTA big to have mass appeal. A game like Jetpack Joyride is very much aimed at the casual market, but is still playable for more seasoned gamers. The game is an endless runner, which means levels have no "win-state"—you play until you die. The aim of the game is simply to see how far you can get. In this sense, the player is playing against themselves—can you beat your own score?


It should be noted, however, that designing for casual and experienced players can provide difficulties. Team Fortress 2, which is a fairly popular game across the spectrum, has "the sentry", a unique weapon which uses a very rudimentary AI. The sentry is powerful enough to instantly destroy almost anyone that walks in front of it, and clever positioning and teamwork are required to take one down.

For unskilled players, however, sentries can act as a sort of impassable barrier. They may not have the tactical positioning or teamwork skills to effectively destroy turrets, which means turrets provide "binary gameplay", something the designers themselves were aware of. This sort of "casual player wall" is not unique to complex games: when we test our own games, we designed the puzzles, so the solutions are obvious.

Casual players may not be able to see these solutions in the same way, so no matter how obvious we consider it, we need to make sure they don't end up hitting an impassable wall.

SpaceChem, one of the best puzzle games around today. And also one of the most brutal.
In Practice

So how do we actually go about developing our game? Well, first off, decide what sort of game you want to make. When we started developing Cosmic Logic, we had a fairly solid idea of what we wanted: a simple puzzle game, essentially snooker/pool with a twist, which challenges the player to solve puzzles within a limited number of shots. We wanted to attract as many players as possible, so we needed to make it relatively casual, but with enough content to keep more serious gamers engaged.

Here are some basic points to consider.

How Difficult Is It to Understand the Game?
Generally speaking, serious gamers are more tolerant of tutorials than casual gamers. Serious gamers don't necessarily enjoy tutorials, but because of their "advanced gaming skill", they tend to enjoy games which are more complex. This complexity means additional rules, which must be explained.

When you look at a game like Bejewelled (or any match 3), the game is designed to be immediately accessible. You start a game, and you are given one objective: line up three objects of the same colour. Compare this to a game like Crusader Kings 2, where the objective can very loosely be described as "control Europe", and one of the best tutorials is a six-hour YouTube series.

For Cosmic Logic, we took the simple approach. As soon as the player hits the play button, they are given a simple goal: hit two balls together. In fact, the first level is designed to be very difficult to fail. The first level is not designed to be a challenge, but to let the player recognise the most basic game concept: hitting balls together is good. As the game progresses, additional concepts are added (some balls are bad), and each time the player solves a level, they learn a new way to manipulate the playing field to their advantage.

Where Is the Challenge?
What makes your game hard? Is it devious puzzles and tests of skill, or is it lengthy boss battles and pixel-perfect jumps?

It can be hard to make the distinction between "fun hard" and "unfair hard"—all players are different, and some players may find gameplay elements frustrating that others find trivial. In fact, you can look at a game like "Super Mario Frustration", which is little more than a series of unfair challenges. It's obvious someone out there liked this, and although the market for this style of difficulty may be tiny, it does exist

The key to testing hard vs. unfair is feedback. Watch people play your game, see which parts provide difficulty, and try to figure out where people are getting annoyed and where people are having fun. Test with everyone: children, grandparents, serious gamers, people who barely touch games. Take notes, see where they get stuck and where they get annoyed, and ask yourself if the challenge is providing a positive gameplay experience or is just obtuse.

This is exactly what we did with Cosmic Logic. I did the bulk of the initial testing myself: I've run through the game so many times I'm thoroughly sick of playing it. The advantage of this was that I could see which levels are tricky: if I'm unable to complete a level first time, then it'll likely be frustrating for a casual gamer.

Can a Challenge Be Easy and Hard at the Same Time?
This might seem like a stupid question, but easy-hard challenges have been used in gaming for some time.

The principle revolves around what the player perceives as the challenge. Winning a boss fight is hard; winning a boss fight without getting hit is harder. Some players will happily self-impose these sorts of additional rules upon themselves, but a better way to approach it is a rudimentary reward system—giving the player additional points for completing challenges with restrictions.

When you complete a level of Angry Birds, you get one to three stars to indicate how well you did. Hitman players get graded A+ to F. In Lego Marvel, collecting a certain number of studs awards the player with "True Believer" status. Getting a high score doesn't really mean anything, but it gives players an additional goal to aim for.

Miss a note? Doesn't matter, keep playing.
For Cosmic Logic, the level difficulty was designed backwards. Each level was created to have a very specific solution in mind. Once these solutions had been established (i.e. complete a level in three shots), we would then make it easier (but you have five shots to do it).

Players who could complete each level with the “true” solution would earn a gold star, and completing each level with a gold star unlocks a “bonus” ending. The gold stars and bonus ending don't really change the way the game is played, but they ensure that players have something to aim for beyond simply crashing through levels.

What Happens If I Fail a Challenge?
With any challenge comes the possibility of failure. It's important that we make the separation between failing the player and punishing the player, however. As we said earlier, challenges are only fun while a player hasn't "solved" them. If we make a player go back to the very start of the game every time they die, then it's very likely they'll get bored of seeing the first level very quickly.

In a skill-based game (such as a platformer or first-person shooter), there is some leeway in making the player repeat content, as the longer they play the game, the better they get at it (hopefully). With a puzzle game, this leeway doesn't exist, meaning puzzles are often very binary: either a player can solve it, or they can't. If they can solve it, then great—unless they die and have to solve it again. If they are unable to solve it, then the player becomes stuck.

There are several ways to avoid this problem. The first option, used by games like flow free, is simply to make all levels open to the player at the start of the game. In flow free, every level is unlocked. Players can choose which puzzles to solve at their leisure, and can entirely skip the first half of the game if they so desire. Flow free has so many levels that skipping a few doesn't really affect the game, but for a more "story-driven" game (such as Mario), allowing a player to skip right to the last level might not be an option.

Flow free puzzles are entirely independent and self-contained, so each can be solved at leisure.
Another possibility is allowing a player to skip levels. Some puzzle games allow a player to skip a certain amount of levels: a player might have three free passes at the start of the game, which means that particularly hard levels can be avoided. This can be partially replicated in other games, by giving the player branching paths, optional fights, or even warp pipes to allow them to skip content.

In Cosmic Logic, we took a third approach: making each level incredibly easy. As we mentioned above, we had an idea of how each level was to be completed, and we simply allowed the player additional shots for them to complete it. We wanted to avoid a level skip mechanic, for there is a gradual learning curve—something you used on level 11 might be necessary to complete level 25. We wanted players to grasp the fundamental concepts of how to play the game, so we simply gave them the leeway to be really bad at it.

Does the Game Get Harder as the Skill of the Player Increases?
This is a problem that simple games can face. If you're playing something like Space Invaders, then once a player has cleared a few waves, they have essentially "mastered" the game, and it will no longer provide a challenge.

Most games use a difficulty curve system, which is what we did with Cosmic Logic. As the game progresses, the player learns more ways to clear tables, and new challenges are provided to ensure they are constantly challenged. Nearly all games with a level system use this mechanic.

However, not all games use level systems. For "endless" games, having the difficulty increase as the player continues is one option: but if the player has to play through "easy" content to get to the fun part, then the game might just be boring.

This was one of the major flaws of Starbyte, another game I worked on some time ago. In retrospect, allowing the player to select a difficulty level would have been smart, but at the time we decided that simply increasing the game's difficulty as the player progressed would be enough. In practice, it meant that the game got too hard too quickly for novice players, and was too easy for too long for advanced players.
Starbyte gameplay. The player has to wade through four or five levels to get to the "real" challenge.
A game doesn't necessarily have to be harder to be fun, though: allowing the player to skip through easy levels, or even offering a "turbo" button, allowing the player to play at double speed and thereby cruising through the simple challenges, are simple but effective ways of keeping your more skilled players engaged.

Bringing It Together

Not all of these techniques are applicable for all games, but they're worth thinking about. A good general rule of thumb for providing a challenge is: "Is this something the player can be realistically expected to do, or are they going to fail?"

There's nothing wrong with failure, but players don't want to feel cheated out of victory. If a player says, "Well, I should have jumped earlier, that was my fault," then you've provided a good challenge. If a player says, "There was literally no way for me to avoid that," then you're punishing the player for no reason. Most of these design techniques are applicable to all games, as no player likes unfair gameplay.

And remember: although we like to talk about a casual/hardcore divide in gaming, this divide is somewhat arbitrary. With careful planning, there's no reason a good game can't be enjoyed by everyone—and if a four-year-old child can enjoy Grand Theft Auto, what else can we achieve?
Written by Darran Jamieson

If you found this post interesting, follow and support us.
Suggest for you:

Mastering HTML5 Game Development

Code Your First Game: Arcade Classic in JavaScript on Canvas

Mobile Game Development Gamemaker Studio

Game Development Crash Course w/Corona SDK: You Can Do It!

Make VR Games in Unity with C# - Cardboard, Gear VR, Oculus

Tuesday, August 16, 2016

Simple Xbox Controller Input in HTML5 With PxGamepad

Gaming on the web has come a long way with HTML5 technologies like Canvas, WebGL, and WebAudio. It's now possible to produce high-fidelity graphics and sound within the browser. However, to provide a true gaming experience, you need input devices designed for gaming. The Gamepad API is a proposed standard of the W3C, and is designed to provide a consistent API across browsers.

The Gamepad API allows users to connect devices like an Xbox Controller to a computer and use them for browser-based experiences! Our helper class, PxGamepad, then maps the button and axis indices to the more familiar names as labeled on the Xbox controller.

If you have a gamepad, try plugging it into your computer, click the picture of the Xbox controller below, and press a button. You’ll see the controller light up to mirror each movement you make!

This tutorial is the third in a series on Flight Arcade—built to demonstrate what’s possible on the web platform and in the new Microsoft Edge browser and EdgeHTML rendering engine. You can find the first two articles on WebGL and Web API, plus interactive code and examples for this article, at flightarcade.com and here on Tuts+.

Flexible API

The Gamepad API is intelligently designed with flexibility in mind. At a basic level, it provides access to buttons and axes. Button values range from 0 to 1 inclusive, while axes range from -1 to 1 inclusive. All values are normalized to these ranges so developers can expect consistent behavior between devices.

The Gamepad object provides detailed information about the manufacturer and model of the connected gamepad. More useful is a “mapping” property which describes the general type of gamepad. Currently the only supported mapping is “standard”, which corresponds to the controller layout used by many popular game consoles like the Xbox.

The standard controller mapping has two sticks, each of which is represented by two axes (x and y). It also includes a D-pad, four game buttons, top buttons, and triggers: all represented as buttons in the
Gamepad API.

Current Xbox controllers report button state as either 0 (normal state) or 1 (pressed). However, you could imagine that future controllers could report the amount of force applied to each button press.

The Xbox D-pad also reports discrete values (0 or 1), but the sticks provide continuous values across the entire axis range (-1 to 1). This additional precision makes it much easier to fly the airplane in our Flight Arcade missions.

PxGamepad

The array of buttons and axes provided by the Gamepad API is forward thinking and perfect as a low-level API. However, when writing a game, it’s nice to have a higher-level representation of a standard gamepad like the Xbox One controller. We created a helper class named PxGamepad that maps the button and axis indices to the more familiar names as labeled on the Xbox controller.

I'll walk through a few interesting pieces of the library, but the full source code (MIT License) is available on GitHub.

The standard Gamepad API provides button state as an array of buttons. Again, this API is designed for flexibility, allowing controllers with various button counts. However, when writing a game, it's much easier to write and read code that uses the standard mapped button names.

For example, with the HTML5 Gamepad API, here is the code to check whether the left trigger is currently pressed:
  1. function isLeftTriggerPressed() {
  2.      
  3.     var leftTrigger = gamepad.buttons[6];
  4.     if (!leftTrigger) {
  5.         return false;
  6.     }
  7.  
  8.     if (typeof(leftTrigger) === "object") {
  9.         return leftTrigger.pressed;
  10.     }
  11.  
  12.     return (leftTrigger === 1.0);
  13. }
The PxGamepad class contains an update method that will gather the state for all the standard mapped buttons and axes. So determining whether the leftTrigger is pressed is as simple as accessing a Boolean property:
  1. var isPressed = pxgamepad.buttons.leftTrigger;
Axes in the standard Gamepad API are also provided as an array of numerical values. For example, here is the code to get the normalized x and y values for the left stick:
  1. var leftStickX = gamepad.axes[0];
  2. var leftStickY = gamepad.axes[1];
The D-pad is a special case, because it is considered to be a set of four buttons by the HTML5 Gamepad API (indices 121314, and 15). However, it's common for developers to allow the D-pad to be used in the same way as one of the sticks. PxGamepad provides button infomation for the D-pad, but also synthesizes axis information as though the D-pad were a stick:
  1. var dpadX = pxgamepad.dpad.x;
  2. var dpadY = pxgamepad.dpad.y;
Another limitation of the HTML5 Gamepad API is that is doesn't provide button-level events. It's common for a game developer to want to activate a single event for a button press. In Flight Arcade, the ignition and brake buttons are good examples. PxGamepad watches button state and allows callers to register for notifications on button release.
  1. gamepad.on('rightTrigger', function() {
  2.     console.log('right trigger fired!');
  3. });
 Here is the full list of named buttons supported by PxGamepad:
  • a
  • b
  • x
  • y
  • leftTop
  • rightTop
  • leftTrigger
  • rightTrigger
  • select
  • start
  • leftStick
  • rightStick
  • dpadUp
  • dpadDown
  • dpadLeft
  • dpadRight
Obtaining the Current Gamepad

There are two methods for retrieving the gamepad object. The Gamepad API adds a method to the navigator object named getGamepads(), which returns an array of all connected gamepads. There are also new gamepadconnected and gamepaddisconnected events that are fired whenever a new gamepad has been connected or disconnected. For example, here is how the PxGamepad helper stores the last connected gamepad:
  1. // start listening for gamepad connection events
  2. PxGamepad.prototype.start = function() {
  3.  
  4.     this.reset();
  5.  
  6.     this.listeners = {
  7.         'gamepadconnected': jQuery.proxy(function(e) {
  8.             var gamepad = e.originalEvent.gamepad;
  9.             if (gamepad.mapping === 'standard') {
  10.                 this.connectedGamepad = gamepad;
  11.             }
  12.         }),
  13.         'gamepaddisconnected': jQuery.proxy(function(e) {
  14.             var gamepad = e.originalEvent.gamepad;
  15.             if (this.connectedGamepad === gamepad) {
  16.                 this.connectedGamepad = null;
  17.             }
  18.         })
  19.     };
  20.  
  21.     jQuery(window).on(this.listeners);
  22. };
And here is the helper to retrieve the first standard gamepad using the navigator.getGamepads() API:
  1. // helper to retrieve the currently connected gamepad
  2. PxGamepad.prototype.getGamepad = function() {
  3.      
  4.     // default to connected gamepad
  5.     var gp = this.connectedGamepad;
  6.      
  7.     if (!gp) {
  8.  
  9.         // fetch all available gamepads
  10.         var gamepads;
  11.         if (navigator.getGamepads) {
  12.             gamepads = navigator.getGamepads();
  13.         } else if (navigator.webkitGetGamepads) {
  14.             gamepads = navigator.webkitGetGamepads();    
  15.         }
  16.  
  17.         // look for a standard mapped gamepad
  18.         if (gamepads) {
  19.             for (var i = 0, len = gamepads.length; i < len; i++) {
  20.                 if (gamepads[i].mapping === 'standard') {
  21.                     gp = gamepads[i];
  22.                     break;
  23.                 }
  24.             }
  25.         }
  26.     }
  27.  
  28.     return gp;
  29. };
The PxGamepad helper class is designed for the simple scenario where a single user is playing a game with a standard mapped gamepad. The latest browsers, like Microsoft Edge, fully support the W3C Gamepad API. However, older versions of some other browsers only supported pieces of the emerging specification. PxGamepad listens for the gamepadconnected events and falls back to querying for the list of all gamepads if needed.

The Future of Gamepad

While PxGamepad is focused on the simple, most common scenario, the Gamepad API is fully capable of supporting multiple players, each with their own gamepad. One possible improvement for PxGamepad might be to provide a manager-style class which tracks connection of multiple gamepads and maps them to multiple players in a game. Another might be to allow users to remap or customize the button functions on their gamepads.

We're also excited about the potential of the Gamepad API for non-game scenarios. With the rise of WebGL, we're seeing a variety of innovative uses for 3D on the web. That might mean exploring the Mt. Everest region in 3D with GlacierWorks, or viewing the Assyrian Collection of the British Museum thanks to CyArk's efforts to digitally preserve important world sites and artefacts.

During the development of Flight Arcade, we frequently used Blender and other 3D tools to process models for Babylon.js. Some developers and artists use a device called a 3D mouse to help manipulate and navigate 3D models. These devices track movement of a single knob through six axes! They make it really easy and quick to manipulate models. Beyond gaming, they're used in a variety of interesting applications from engineering to medical imaging. While adding gamepad support to Flight Arcade, we were surprised to learn that the Gamepad API detected our 3D SpaceMouse and provided movement data for all six axes!

It's exciting to imagine all the possibilities that the new Gamepad API offers. Now is a great time to experiment with the new Gamepad API and add precision control and a lot of fun to your next game or application!
Written by Robby Ingebretsen

If you found this post interesting, follow and support us.
Suggest for you:

Mastering HTML5 Game Development

Code Your First Game: Arcade Classic in JavaScript on Canvas

Mobile Game Development Gamemaker Studio

Game Development Crash Course w/Corona SDK: You Can Do It!

Make VR Games in Unity with C# - Cardboard, Gear VR, Oculus


Thursday, August 11, 2016

6 Games That Succeed Because They're Interesting, Not Because They're Fun

Imagine if you designed your games to be interesting, rather than fun. That might sound a little counter-intuitive; you might say, "if a game is fun, wouldn't that already make it interesting, in some respect"? That's true, but I'm talking about giving the player a drive to play the game outside of simply completing the goals you have set. The player also plays to experience and explore the game itself, to see what the world you have created has to offer.

This has far more retaining power than straight up fun, and is amazing (thanks to the huge synergy bonus) when combined with fun.

It's hard to get a grasp on the fuzzy concept of "interesting", so rather than try to define it, let's look at six great examples of games that are "interesting", and at how they used "interest" to drive and support the game.

Note: This article contains spoilers for the following games:
  • The Stanley Parable (not free, but has a free demo; available on Windows and Mac)
  • Frog Fractions (free online)
  • Shadow of the Colossus (not free; available on PlayStation only)
  • Corrypt (free; available on iOS, Windows, and Mac)
  • Papers Please (not free; available on Windows, Mac, and Linux)
  • Calm Time (free; available on Windows only)
If you haven't played them yet, I recommend you do so before reading on; they're all excellent experiences that deserve to be played through with fresh eyes—and they have plenty of lessons to teach any game designer.

The Stanley Parable

The Stanely Parable, on paper, is not a "fun" game. You walk through hallways, you get talked at the whole time, and you get different endings based on whether you walk down one hallway or another. Then you play again and walk down the hallway you didn't walk down before. Sounds boring.

However, the designers used a powerful tool to keep the player interested in the game: player agency curiosity. It makes all the difference.

Player Agency Curiosity
This refers to the state where the player is engaged with the game by poking and prodding it—sometimes in hope of breaking the game, sometimes to see how it reacts, sometimes to find the limits or seams of the system, and so on.

When trying to harness this style of engagement, you must be able to predict what the player will try to do and what they are thinking. When they try to do something, your game must react to it, and these reactions must also provoke some sort of reaction from the player: fear, laughter, mystery, a clue, or even just a little Easter egg.

The Stanley Parable makes amazing use of this. The design tightly restricts the possible interactions for the player, and so the designers are able to predict what the player will do at any point. Because of this, they are able to be proactive in their reactions to player choices.

The best example of this is in the iconic two door room the player is presented with at the start of the game. The game tries to tell you the "story" of the game by saying "Stanley, when presented with two doors, walked through the left door." A player might say "Aha—nice try, game, but I won't let you control me!" and walk through the right door. However, the game recognizes this mindset and both acknowledges and responds to this by telling the player that they aren't following the proper story.

It's a small thing, but it makes the player want to see how far they can go: if I do this, what will happen? If I do that, is anything going to happen?

Frog Fractions

I really hope you played the game before you read to this point. This is a one-time surprise.
Frog Fractions is an educational game about fractions... sort of. It doesn't look like anything you haven't seen before. The gameplay is predictable; you know what you're getting as soon as you start playing it. You're a frog that needs to eat some bugs. Simple. But the game knows this, and it uses whatever assumptions you may have made about its gameplay against you in a brilliant way, through its unfolding gameplay.

Unfolding Gameplay
This is the act of constantly introducing new concepts and mechanics into your game the farther into your game the player gets. Games that use this device generally start out boring or mundane or predictable, but they need to. This is because when the player is in that state of boredom, they will perk up to anything new, and anything unusual.

Once the player starts to see the game expanding, they begin to wonder what else it has to show them. They want to know where this rabbit hole of a game leads. And since the game starts out as mundane, stale, and boring, when more of the game is revealed it's a big juxtaposition against what they were playing previously. This allows mediocre gameplay to become so much more, because each new gameplay element is new, shiny, and interesting.


In Frog Fractions, this first instance of unfolding generally happens at the perfect moment. The gameplay mechanics seem to boil down to eat some bugs, catch some fruit, unlock new power-ups so you can be more efficient at the process. It's nothing new and is easy to understand (aside, perhaps, from the quirky humor the game has).

However, that idea of the player having a full grasp on what the game is is quickly turned on its head as soon as the player moves downward just a little too far and bam. There are infinitely many pieces of fruit underwater! This immediately tells the player, "this game isn't about upgrading; it isn't about what you thought it was." Through this, the game creates a new rush of interest because now the game is broken—or is it? What is this game trying to do? The player continues to play to answer these questions.

Shadow of the Colossus


Shadow of the Colossus has a lot going on under the hood. Its a game about traversing over expansive lands that is home to the colossi (giant enemy beasts). The game doesn't have a lot of conflict; there are only 16 enemies in the whole game. For each enemy, you must do the same thing: travel to the colossus, figure out how to get on top of the beast, find its weak points, kill, repeat.

Now, while that is simple when written, the game and how it was pieced together makes it insanely compelling because of differences in kind.

Differences in Kind
This is a term I picked up from the lovely Extra Credits team. It refers to the concept of a game changing tones throughout, in order to break up similar gameplay, to make sure that the player doesn't get fatigued from the gameplay—to give them a break of sorts. It is also used to make certain aspects of the game more impactful. Action, for instance, is much more refreshing when you are able to take a small break instead of having a constant barrage of endless fights until the game ends.

Shadow of the Colossus uses differences in kind beautifully. Since each of the battles with the colossi are intense puzzle/action segments, the player would quickly become tired if they were constantly playing this segment of the game. To prevent this, the fights are separated by calming, meditative traveling segments. These allow for the player to take a break from the action while also creating a sense of anticipation, adding additional value to each of the fights.

This is the absolute opposite of high stakes, intense puzzle-solving action.
Differences in kind, when used properly, can also create different "lenses" through which to view the game itself. In Shadow of the Colossus, you view the game through both the lenses of action and calm. It's a hard feeling to describe, but a game that can be viewed through multiple lenses feels fuller, like more of a complete world. Games that have one lens tend to be games that feel more traditionally game-like.

While it's no bad thing to not have differences in kind, just know that it is a tool in your arsenal that won't (in most cases) diminish, only create additional value.

Corrypt


Corrypt is a weird game. It starts out normal enough: it's a down-to-earth Sokoban box game. Nothing special about that. But once you get far enough, you obtain magic. However, this magic actually ends up breaking the game, in some ways making it unplayable. This gives the player repercussions for agency.

Repercussions for Agency
What made this game absolutely brilliant for me was how it used a simple mechanic to expand the game in ways I didn't even know were possible before playing. You can use magic in order to permanently freeze a tile; when you go to any other room that tile will stay as what it was when you froze it.

This made me personally care about the repercussions of what I decided to do as a player. That is extremely important: the player themselves is invested in the decisions they make, but not through a binary "kill him or save him" situation where the outcome changes one ending to a different ending. No—this game made me stop and think, "if I freeze this tile what will happen? Is this smart? What rooms are going to be impossible to solve because of this?"

Some of the most nerve-wracking decisions I've ever made in a game.
While having the decisions themselves be important to the player is significant, nothing is more essential than having those decisions impact the gameplay itself. In this game, the player's choices can change the layout of every room from then on. However, the effects doesn't always have to be as prominent. For example, in that hypothetical "kill him or save him" scenario, perhaps the player's character could be mentally scarred if they were to choose to kill, which in turn could make their accuracy go down, giving the choice a meaningful gameplay repercussion. If the player chose to save him, he could become a merchant that sells you some valuable items. These repercussions are simple, but far more meaningful to a player than a selection of two cut scenes.

Papers, Please

n Papers, Please, you play as a border control worker who spends their days checking passports for authenticity. That is the game. It would have probably been completely mundane as well, if the developer hadn't put such care into making sure the game was constantly evolving, thus requiring perpetual mastery of the system from the player.

Perpetual Mastery of the System
This is when a game constantly changes how it is played. What makes this different from unfolding gameplay is that the genre and style of the game never changes. The actual changes are small—little additions to already established mechanics that make the player use what they've learned and apply it to different situations. Although they have mastered the actual mechanic itself, by being used in different situations the application of that mastered knowledge will change.

This isn't a new concept. Nearly any decent game uses this concept: Mario, Dark Souls, and The Last of Us are all good examples. However, this isn't something that every developer grasps. Artificial difficulty by way of increasing numbers does not create perpetual mastery; in these cases, the player has mastered the system but just has to continue executing what they have learned. This quickly becomes boring, and is a large part of why many games fail.

In Papers, Please the game requires perpetual mastery by changing how documents work. There's different paperwork for different countries, different occupations, and so on. As soon as the player has a grasp on the most recent twist on the mechanic, something new is thrown in. On top of that, there are a few special characters thrown in to make sure that the player never falls into a routine and can easily "game" the game.

Calm Time


Calm Time is a horror game with a unique twist. It isn't scary, in a normal sense. It's slow paced, twisted, and methodical. It places the player into the shoes of what would normally be the object of fear: a killer who has gathered their victims under the pretense of a dinner party. Throughout the game, you must kill each guest one by one, as they plead for their lives and run to live maybe just a second longer. It's a great example of forced perspective storytelling.

Forced Perspective Storytelling
This concept refers to when the game forces you, as the player, to tell the story of the game through the mechanics. This means that the mechanics and the player's use of them places the player in a certain mindset. Their goals align with the character's goals.

In Calm Time this becomes unsettling—not because of the actions of the character, but because of the goals of the player. The player's goal is to kill all the guests they have invited to their home. As the game goes on, it might become fun, tedious, or just a mindless action to complete the game. But through this we also come to completely embody the mindset of the character. The character becomes a mirror onto ourselves. He is clearly insane because he find this act of murder fun, tedious, or just a mindless action.

I never actually finished this game; I got too creeped out.
This is different to roleplaying, since instead of us choosing our actions based on the character we want to be, our character is defined by the actions we take and our reasons for taking said actions.

Fun Without Purpose

There are plenty of games that feel like they should be fun on paper, but aren't when actually played. We see this a lot in clones, which end up copying the "fun" gameplay, without much else of what made the original interesting. The game has the same ideas, but the execution falls flat. Why is that?

It's because these games mostly copy the games on a mechanical level, but they fail to understand how those mechanics were used in the games to make them compelling to play.

If you are going to try to remake a game, you must not only recreate the mechanics, you must also recreate the design. Games do not exist as a jumble of mechanics thrown together to make a game. Design is what gives the mechanics meaning, gives the player purpose, and creates the reason for the player to play your game.

Conclusion

Games can be fun, don't get me wrong, but it is important to remember that that's not all games can be. Games can be compelling in other ways, through use of intelligent design. Games can be interesting without having to overstimulate the player with explosions and the like.

There are many ways to go about this; I have only listed but a fraction of what is possible in games. Don't restrict yourself by thinking, "people won't play my game if it isn't fun." If your game is interesting, people will enjoy it.
Written by Jord Farrell

If you found this post interesting, follow and support us.
Suggest for you:

Code Your First Game: Arcade Classic in JavaScript on Canvas

Mobile Game Development Gamemaker Studio

Game Development Crash Course w/Corona SDK: You Can Do It!


Thursday, August 4, 2016

Amazon Lumberyard: Introduction, Installation, First Hours_part 2 (end)

Editor Layout

Before using Lumberyard Editor, you will need to learn its layout configuration and how to navigate within the Perspective Viewport.

The Lumberyard Editor interface is divided into the following areas (each numerically represented in the following image):
  1. Main menu: Access to all game engine functions and settings.
  2. Editor toolbar: Most commonly used tools (Select, Move, Rotate, Scale, Lock on, Ruler, Snapping, among others). It is composed of three bars: EditMode, Object, Editors.
  3. Viewport header: Search bar and several display options for  (display resolution, ratio, helpers, among others).
  4. Perspective Viewport: A preview of your 3D environment. It is where the action occurs.
  5. Viewport controls: Several controls for selected objects, mouse location, navigation speed, camera collision detection, AI/Physics, and others.
  6. Console: Display of input and output between the user and the Editor.
  7. Rollup Bar: Access to objects and tools for building and managing content in the Perspective Viewport.

The Rollup Bar is more complex than it initially appears, since it handles all properties, definitions and characteristics of all objects within the Perspective Viewport. Therefore, it's important to enumerate its tabs:
  1. Objects: Contains options for Artificial Intelligence, Entities (Actor, Archetype, Component, Geometry, Particles), Audio, Brushes, and Prefabs, among others.
  2. Terrain: Contains options to apply, modify, and remove terrains, vegetation, holes, Fog, Wind, Clouds, Skyboxes, and others.
  3. Modeling: Contains options for geometry handling, such as selection of geometry types and display types (wire-frame, flat shading, full geometry).
  4. Display: Contains options regarding the rendering settings, i.e., clouds, roads, Fog, Terrain, and Sky box, among others.
  5. Layers: As the name suggests, it contains options to organize your assets by layers.

Open the First Level

It is now time to open your first level and play with it. Inside the Welcome to Lumberyard Editor window, click on Open level.


Then, expand the GettingStartedFiles, choose the getting-started-completed-level, and click Open.

Note that the list of files and samples presented here belongs to the project that is set by default.


Soon a small 3D village is presented:


3D Level Navigation

Navigating inside the Perspective Viewport is easy, since it uses traditional First Person Shooter (FPS) controls.

                                 Action                          Keyboard Key
                                 Strafe forward                         W
                                 Strafe backward                       D
                                 Strafe left                                cell
                                 Strafe right                              cell

For the record, note that you can modify these keys if you want (more on that later).

Since 3D scenes are composed of objects or entities, you can interact with them using the mouse.

                    Action                                                 Mouse Button
                Select objects                                            Left mouse button
                Turn left/right, look up/down  Right mouse button
                Pan left, right, up, or down Middle mouse button
                Zoom in, out                       Mouse wheel or (Right mouse + middle mouse button)

Before continuing to read the tutorial, you can invest some time playing with these controls within the village demo (or load any other demo from the available ones). To load another demo you only need to select File > Open and choose another sample.

Assets Installation

Lumberyard currently offers three additional ready-to-use art assets and code that you can use as examples:
  1. Woodland: A collection of wilderness (forest, vegetation, and other natural features) assets.
  2. Beach City: A dark and stormy night containing several assets (cars, houses, vegetation).
  3. Legacy Game Sample: A ready-to-go FPS game, including complex animated characters, vehicles and game IA. This sample uses the woodland sample assets.
The first step is to download them all.

Step 1: Woodland

The Woodland asset is the easiest to install since it comes packaged as a Gem. Unzip the Woodland zip file to the dev\Gems folder inside your default Lumberyard installation.

To verify that everything is fine, open the Project configurator > Enable packages; at the bottom you should now see the Woodland Asset Collection.


To add the Woodland asset to the SamplesProject (your current default project), you only need to check the box and wait for the Asset Processor to load all resources.

Step 2: Beach City

To install the Beach City, you must follow the following steps:
  1. Unpack the Beach City zip file into your Lumberyard \dev directory.
  2. Navigate to dev\_WAF_ (inside the installation folder).
  3. Edit the file *projects.json and add the following to the end of the file before the last closing brace:
  1. {
  2. ...
  3.     "BeachCity": {
  4.     "product\_name": "BeachCity",
  5.     "executable\_name": "BeachCityLauncher",
  6.     "code\_folder": "Code/BeachCity",
  7.     "project\_directory" : "BeachCity",
  8.     "modules" : ["BeachCity"]
  9.     }
  10. }
Now open the Project configurator, click Configure project, select BeachCity and click Set as default.


Open the Editor and open the level (Open level > BeachCity_NightTime). If everything is working, you should be able to navigate within the Beach City environment. Note that by default this asset doesn’t have a Camera Framework, so you can only (for now) navigate in the Editor mode.



The Legacy Game Sample installation is similar to Beach City.

Unpack the Legacy Game Sample zip file into your engine directory.
Navigate to dev\_WAF_ (inside the installation folder).
Edit the file projects.json and add the following to the end of the file before the last closing brace:
  1. "GameSDK": {
  2.     "product\_name": "GameSDK",
  3.     "executable\_name": "GameSDKLauncher",
  4.     "code\_folder": "Code/GameSDK",
  5.     "project\_directory" : "GameSDk",
  6.     "modules" : ["GameSDK"]
The complete projects.json is now:
  1. {
  2.     "SamplesProject": {
  3.         "product_name"      : "Samples Project",
  4.         "executable_name"   : "SamplesProjectLauncher",
  5.         "code_folder"       : "Code/SamplesProject",
  6.         "project_directory" : "SamplesProject",
  7.         "modules"           : ["SamplesProject"],
  8.  
  9.         "android_settings": {
  10.             "package_name"  : "com.cryengine.sdk",
  11.             "orientation"   : "landscape"
  12.         }
  13.     },
  14.     "MultiplayerProject" : {
  15.         "product_name"      : "Multiplayer Project",
  16.         "executable_name"   : "MultiplayerProjectLauncher",
  17.         "code_folder"       : "Code/MultiplayerProject",
  18.         "project_directory" : "MultiplayerProject",
  19.         "modules"           : ["MultiplayerProject"],
  20.  
  21.         "android_settings": {
  22.             "package_name"  : "com.cryengine.sdk",
  23.             "orientation"   : "landscape"
  24.         }
  25.     },
  26.     "BeachCity": {
  27.             "product_name": "BeachCity",
  28.             "executable_name": "BeachCityLauncher",
  29.             "code_folder": "Code/BeachCity",
  30.             "project_directory" : "BeachCity",
  31.             "modules" : ["BeachCity"]
  32.         },
  33.     "GameSDK": {
  34.         "product_name": "GameSDK",
  35.         "executable_name": "GameSDKLauncher",
  36.         "code_folder": "Code/GameSDK",
  37.         "project_directory" : "GameSDk",
  38.         "modules" : ["GameSDK"]
  39.     }
  40. }
Before you test the Legacy Game Sample you need to perform an additional step. Open a Command Prompt in your Lumberyard dev folder and run the following command:
  1. lmbr_waf configure
If you get any error, it should be solved by the following steps:
  1. Open the Launcher.
  2. Select Compile the engine and asset pipeline.
  3. Install the required software.
Run the lmbr_waf configure command again.

To test these assets you just need to open the Project configurator, click Configure project, select GameSDK and click Set as default. Wait until the Asset Processor loads all the assets. Now you can play a complete FPS within Lumberyard.


To enter game mode, you must select from the Main menu the option Game > Switch to Game.

Conclusion

This concludes this introductory tutorial to Lumberyard. You learned where and how to download, install, and configure it. Then you learned the basic notations of the interface and navigation. Finally, you found out how to import, configure and use the available external assets.
Written by Orlando Pereira

If you found this post interesting, follow and support us.
Suggest for you: