Suspiciously Spherical


Suspiciously Spherical is a stealth puzzle game. You are an anthropomorphised rolling ball, in a place where it is not good to be an anthropomorphised rolling ball. You must escape detection by the sentries, and make your way to the exit.

Be warned this is far from a complete game, and is more of a prototype. It consists of a short tutorial-style opening, and an abrupt end. Play it if you’re interested in seeing what I was up to at the end of 2008. Don’t play it if you’re expecting something awesome that will change the face of gaming. I’ll make one of those later.

Download link: Click here to download Suspiciously Spherical
Version: 1.01a
Size: 1.66MB

Use the arrow keys to move

Below, you can read some of the thoughts that went into making this little practice piece.

This was made for an assignment on my game development university course. We were given a couple of months to familiarise ourselves with Game Studio‘s 3D engine and world editor, and make a game with it. There were a few game design goals I set for myself in addition to the assignment requirements.

I wanted to try my hand at Valve’s methods for what they call ‘player training’, which they describe in the developer commentaries of their games, and elsewhere. To make a game which had no explicit instructions or explanations of the game mechanics, but instead taught them to the player through the level design itself.

“Training is one of the fundamental tenets of our design philosophy. Before the player is required to utilise some new game mechanic, or new weapon, or face a new monster under pressure in a dangerous situation, we always introduce the concept in a relatively calm but still entertaining way.”

“The light bridge ball sockets are a clear example of our training approach to new gameplay elements. We train the players with a leading example, confirm they understand the concept, then switch up the problem set and make them use it in a new way. The first bridge shows players the solution, the second one confirms they understand it, and the third, knowing they understand the gameplay mechanic, challenges them in a new way using that mechanism.”

– Scott Dalton, Valve Software (Valve Software, 2007)

I attempted to follow that in my room designs. I organised them into two ‘sets’, one for teaching the core goal of getting to the exit without being seen, and one for teaching that the player cannot be seen when hiding behind an object, in shadow. This second one was particularly necessary as Game Studio’s 3D engine was incapable of casting real-time shadows from dynamic lights, so the spotlight that the sentries cast to indicate their field of view appears to pass through objects into the shadow behind. The player had to be taught that this didn’t mean the sentries could see through objects.

Unfortunately, I didn’t fully implement the entire Valve sequence of training. By the quote above, I should have had an interesting challenge using the mechanics learnt so far at the end of each room set. But I ran out of time to implement those before the due date of the assignment.

Some of you may recognise the game mechanics of this as being inspired by Beyond Good & Evil’s stealth sections. I always thought BG&E’s stealth puzzles were underappreciated. I saw some really clever bits of design going on in those, so I was using this as an opportunity to demonstrate some of them and test them out for myself.

Stealth as a game genre, or stealth elements in a more varied game, are usually all about tension. The thrill of not being seen enhanced by never quite being sure if that’s going to continue. BG&E rejected all that, and used the idea of sneaking around and not being seen but removed all of the ambiguity and vagueness of it, and made it absolutely clear what was happening at all times, which made it into more of a puzzle.

The use of light was the thing I liked the most about it. There’s no light detection used by BG&E, as there is in Thief or Splinter Cell. But all of the light sources in the world are placed near the guard’s sentry positions or patrol routes. Therefore wherever a light doesn’t shine is a spot that the enemies will never see. The shadows themselves didn’t conceal you – they were merely a visual marker to communicate safe places to the player. I used this in Suspiciously Spherical, and I think it worked well.

What I think didn’t work so well was my attempt to replicate BG&E’s enemy suspicion mode. BG&E communicated the state of the guards with bright clear colours. An enemy had a green light from his visor when nothing was wrong, red when he was chasing you, but purple when he had only just spotted you. This was a vital moment when you were given the opportunity to recover from your mistake. If you had exited cover in the belief you were safe, and the nearby guard’s visor went purple and he started looking around, you could quickly return to your hiding place and wait for him to forget about it in his cute cartoony way. The game didn’t want you to fail just because it had failed to communicate the boundaries of safety to you.

I tried to do this ‘suspicion mode’ in Suspiciously Spherical, but the physics-based movement I had used for the player’s avatar meant they were unable to rapidly change direction. The stationary nature of the sentries that I had chosen due to my programming/scripting inexperience meant that lengthening the suspicion period would allow the player to dash across a sentry’s field of view without raising the alert. So in the end, my suspicion mode has no real gameplay function, and is mostly just a visual effect.

The status screens on the walls that show random messages came about from thinking about narrative and setting in games. In the same way that I didn’t want to stop the game to explain the controls or goals to the player, I didn’t want to have to interrupt the player to present a crappy games design student’s story to them either. Simple games like this shouldn’t need a plot or narrative to be enjoyed.

But games often do have some kind of background story attached, even the simplest ones. I think the reason for this ties back into the subject of training the player and doing away with detailed instruction. The reason games so often depict familiar things rather than new and abstract situations is to reduce the amount that needs to be explained. If you’re making a game featuring shooting, and you present two of your weapons to be named and modelled after a rifle and a shotgun, most players will already understand that one is a long-ranged weapon, and the other is a short-ranged weapon, even if the game is a strange far-future space RPG.

So by presenting a small amount of background setting, possibly something that evokes existing knowledge or experience in the player, I could help them understand what’s going on in my game that is, by technical necessity, otherwise visually simple and abstract.

But I still didn’t want to have to prevent the player from playing while I forced them to read or watch some introduction that explained things. So I went for a systemic method of presenting it.

While the primary purpose of the status screens is to communicate to the player whether they have been spotted or if the alert has been raised, some of the messages that the screens rotate through subtly suggest the kind of world the player is in, why there are sentries, and why they are looking for the player. As the player will see the status screens before they enter the areas with sentries, they should have time to see these messages, think about them, and hopefully better understand what their aim in the game is once they start interacting with the game elements.