An important aspect to understand as a Game Designer is the Flow Channel Theory. This is a very powerful concept that helps you keep the flow of your game in order.
Flow Channel is defined as the state of mind that keeps a person focused on an activity. As a Game Designer, this is one of your many aims. You must keep the player’s attention by perfecting the flow channel otherwise players will switch to another activity.
Jesse Schell explained the different states of the flow channel in his book “The Art of Game Design.”
When the skills in the game increase slower than the difficulty of the challenges, the flow of the game creates a sense of anxiety for players. This is A1 to A3 on the graph, where the skills are too low, and the challenges are too high. When the skills increase faster than the difficulty of the challenges presented, then the flow of the game becomes boring to the players. This is A1 to A2 on the graph, where the skills are too high, and the challenges are too low. The flow that you want to create in a game would be A1 to A4, which is directly inside the flow channel. This is where the skills and challenges are balanced effectively, and the player is neither anxious nor bored.
If the player is too anxious, or too bored, it will drive them to frustration. Frustrated players will not continue playing your game.
Let’s say the player’s goal is to fight 10 enemies using a magic sword. The challenge is fighting the enemies, and the skill is using the sword that was given to the player. This is known as the "Naïve Design Approach" in which the player is given the necessary skills to beat the challenge. After so long, this approach would start to bore the player, too.
Since the core mechanic of the game is what the player will mainly be interacting with the most, you have to find ways to keep it interesting. The recommended solution for this problem is called the “Oscillation Method.” This is a series of “tense and release” situations within the game to keep things interesting for the player. In a nutshell, taking the same task and making it seemingly different by changing the challenge.
The oscillation method rides on a basic level design rule: never give a player a new skill without teaching them, or allowing them to become adjusted to it. You do this by giving the player a new skill, or weapon, and then intentionally lowering the difficulty of the enemies. Once you are sure that the players are comfortable with their new skills, you then ramp up the difficulty of the enemies only to, later, lower it again. This is what is meant by “tense and release” because the situation is easy, then hard, then easy again.
Let’s use the magic sword example again. So, the player is given the sword at the beginning of the level. To start things off, the enemies only require two strikes from the sword to be defeated. You would let the player play around with this skill, and allow them to get adjusted to the controls, and fighting enemies. Then, for the second batch of enemies, the player must now strike each enemy four times in order to defeat them. This increase’s the difficulty of the challenge for the player, and hopefully, adds a little excitement to the same task they were already given.
Once the player completes a task that required more skill on their part, it is recommended that you reward players afterwards. So, using the same example, once the player defeats the enemies using four strikes each, you present them with a shield, and lower the difficulty of the enemies.
Now, it should go without saying that the reward the player receives should be beneficial to the player: bonus points, coins or, in our case, a shield. So, just to go a little further with the same example, let’s say the shield they were rewarded with will help with the next set of enemies. These enemies now hurl items at the player, and the shield is used for blocking.
Using the Oscillation and Reward method, designing levels for your game would become a little easier.
It is important to get a working prototype done quickly. This is so you will be able to test the main mechanics. In order to not slow this process down, the oscillation method should be implemented after the working prototype is done, and you are sure the mechanics will be fun.
My advice would be to get the game to the "Naïve Design Approach," and then work in the Oscillation method. Once you have the basic game play, it would be easier to figure out where the player needs to learn a different skill, or how to use a new power-up or weapon.
One way to do this, write down a list of challenges that you want the player to overcome in the game. Then, write down the skills that will be needed to complete these challenges. Take the naïve design approach, where you program the game to where the player has a challenge, and the necessary skill to complete that challenge. Pay no mind to whether the game is too easy or too hard. Once you have all the challenges and skills in the game the way you like, then go back and tweak the areas using the oscillation and reward method.
So using our magic sword example, for prototyping purposes, we would just put the enemies in the game, and the player would be able to hit them once to defeat them. Once we’re sure this is the game play that we’re aiming for, we go back and add in the difficulty for the challenges: this set of enemies requires two hits, the next set requires 4, and finally, two hits again while rewarding the player with a new shield for the next challenge: stronger enemies with weapons.
The Oscillation Method can help greatly when it comes to designing levels and adding excitement to a game.
I want to analyze one of my favorite retro games: Bosconian.
Bosconian was developed by Namco, and published in November of 1981.
The objective is to reach the highest score possible by destroying enemy missiles and bases. These bases consist of six cannons arranged in a hexagon that surrounds a central core. In order to destroy the bases, the player can shoot all six cannons, or shoot the core to blow up the entire station.
Doing so advances the player to the next level. Enemy bases can protect themselves by hurling missiles, releasing ships that attempt to collide with the player, and also opening and closing the central core doors.
Bosconian uses the oscillation method for the flow of the game well. The game starts the player off with three enemy bases, and a few enemy ships. The pacing is slow and allows the player to get a feel for the objective of the game. Asthe game’s levels advance, they are filled with more enemy bases placed in varied positions.
Bosconian uses the “tense and release” idea, but in a slightly different way. The player’s goal always remains the same: destroy all enemy bases and earn the highest score. There is no time limit to the levels so it would seem the only thing that forces the player to complete the level is their own free will. Not quite.
When the player takes too long to clear a round, the game enters into a mode referred to as “Condition Red!” In this mode, the enemy’s attacks become more aggressive. If the player wishes not to lose a life, or the whole game, they must fight harder to clear the round.
So, Bosconian allows the player to take their time, which is the release portion, but whenever the game play starts to drag due to the player clearing the level too slowly, it enters into the tense portion, and ramps up the game play. The player is now aware, “I can take my time to clear the level, but if I take up too much time the game will push me to complete the objective.”
I like the way Bosconian has their Flow Channel/Oscillation Method set up. It’s designed in way where players can create their own fun. For example, players can purposely enter into “Condition Red,” and make the game tense, or they can play it safe, and complete the objective in a timely manner to avoid consequences.
I’m sure there are more games that take advantage of these ideas in game design, but Bosconian is one of my favorites. To gain a better understanding of this approach, look for this technique the next time you play your favorite game. Try to see if the designers and developers added their own twist to the idea.
To gain an even better understanding, try implementing this idea into your own games you are creating!
I am currently active on twitter: @KaeTheDev