In the beginning there was a cube...actually... it wasn’t a cube...Fear of Floating is being developed in Torque 2D, and cubes are not as comfortable with 2 dimensions as one might think at first. It was more of a rectangle. In the beginning there was a rectangle. And the rectangle was floating in a slightly desaturated pink world . Dull and unhappy world. If you have absolutely no idea at this point what I'm talking about, see Fear of Floating video here. Hopefully, all my words will have more meaning after seeing it. And that was all the rectangle was doing – floating. While rectangle was having so much fun disobeying the laws of gravity, the player who was controlling it was not as happy. Sure, player was happy once he mastered skills of controlling game character (become his friend on Facebook), but this particular kind of happiness didn’t last long. Something radical needed to be done. The fun needed to be injected in game. Player needed to be rewarded for his hard work of floating around and mastering not-so-easy-to-master control scheme. So, the question arose. What is fun? It seams that we take this term a bit for granted, because once you stop and analyze it, you realize that it is not as simple (and fun) as it sounds at first, especially when you need to create something that is fun for wide range of audience. Fun as a focal point of games is a topic of giant proportions and I will write in this article only about a small part that concerns Fear of Floating.
One aspect of fun can be roughly brought down to and simplified to a "goal and reward" system. It works quite simple: you impose a small challenge before player and let him deal with it. These small challenges are called "micro goals". When thinking of micro goals, one should think about something that player does naturally and doesn’t have to think a lot about (i.e. collecting coins, etc) and that occurs quite often. If player is successful in completing micro goals, he should receive a small reward. Should he fail, naturally you would like to punish him. But stop. Punishment is not a wise solution. Or, better to say, not always. Punishment should not happen too often because the game with a lot of punishment tends to become annoying for majority of players and it should be used with caution. In light of this statement, it is obvious that micro goals should not carry punishment for not achieving them, since they occur quite often. Punishment should be left to some less frequent disobeying of the rules. Perhaps a wiser approach would be to suggest a player that even bigger reward lays beyond completing certain amount of micro goals rather than punishing him for not completing them. By doing so you motivate player by teasing him rather than making him fear something. In our case (FoF) player needs to collect “stars” that are scattered through the level. Reward for each star is increase in total number of “stars” and fancy (but subtle) visual & audio effect that gives that nice & appealing feel. Total number of stars latter plays a role in buying extra skills, (but it is not topic of this article), and is reward on its own. Once all stars on level are collected, the "level exit" unlocks and player can proceed to next level, which is a kind of “bigger” reward. There is no punishment for not collecting stars, rather the progress is blocked and it is up to player to decide – if he wants to advance, he needs to collect all stars. If he doesn’t collect, he will stay stuck buzzing around on level (and that doesn’t make any sense to any player and it is natural to avoid it).
Nice thing that lays hidden behind this concept of collecting is the simplicity in which you guide player along the way he needs to go. The problem of guiding player might sound trivial for games where player is on the ground and has limited movement ability. But in our game, player is floating freely, and it is not always obvious where to next, and stars turned out to be a perfect guide. Obviously, placement of stars lets you mess around with player in ways that are only limited by your imagination. For a simple example, you can put “end level” right beside “start” and still make player float around entire level and then return to starting position which gives much freedom and chance for releasing imagination in level design.
One thing that games similar to FoF incorporate as a mechanism of preventing player buzzing pointlessly around is a time limit. I cannot discuss whether it is strictly good or bad thing, but I can tell you that I personally don’t like it. If it turns out to be good thing at some point of development, it will be incorporated but in slightly different manner. Let’s analyze time limit in following way: if you break it down to goal-reward elements, you can look at it in following way:
Goal: finish level under x seconds
Reward: you get to live and continue game
Punishment: you die and restart level
As stated before, let’s try to avoid punishment, and at the same time lets try to keep the time limit. This can be achieved by letting player finish for any time he wishes, but giving a tip that there is a reward waiting for finishing level under certain time limit. Naturally you would want to give “gold” “silver” and “bronze” “medals” (or their equivalents) for different level of player’s swiftness proportionally. This gives flexibility that enables players to chose and shape their own play style. Obviously there are people out there who play games purely for fun and the others that play it for competing. And you have to take care of both groups. Don’t punish less ambitious players, promote the hardcore ones, and turn punishment into award. It sounds flawless. And it is. Almost. Almost? Why almost?
There is a small trivial down side (ah..there always is), that can quickly turn into nightmare if you are not aware of it. Let’s say that you have 20 levels in your game, and that each lasts around 20 seconds. In best case it will take you 3 (medals/difficulties) x 20 (levels) x 20 (seconds) = 20 minutes. It doesn’t sound like much, but 6 minutes of game play doesn’t sound much either, so you can count on much more time spent on measuring level times as the game grows. Additionally, if you decide to alter the, let’s say, speed of player, it will take you 3 seconds to change it and 20 minutes to measure new level times. As it doesn’t sound really scary, it can will become as the game becomes bigger and complicated, and tested over and over again. The reason why I’m taking this into consideration, is because on our previous game Pyroblazer I was measuring time trial level times. There are 14 tracks in Pyroblazer. Each track can be driven normal/backwards, and there are 4 levels of difficulty, and each track lasts around 2 minutes. Mathematics says that it takes around 4 hours to set / test those times. And that’s in ideal conditions. And as much as you think you can be organized and avoid doing it multiple times, I’m pretty sure that you will end up doing it at least few times.
This digression was not meant to discourage you for implementing features like this in your game, but rather to give you insight that time consuming tasks await in the places you never suspect of, and that careful planning sometimes can make difference whether you finish your game at all or not.
In part 2 of this article you can read about some good things that popped out of measuring time in Fear of Floating, such as asynchronous multiplayer game mode that we simply named “challenge”, some new rules in level design, etc. In the meantime, follow FoF on Twitter.