Rune Skovbo Johansen
Creative Programmer & Designer
runevision
Menu

FLIPSIDE

FLIPSIDE is a fun platform game with a twist, set in cardboard world with two sides. It features the split-personality mental institution patient Hannibal on the run, as he imagines his own escape in a cardboard cut-out world with two sides. As his mood changes between extremes, the world reflects it and flips between a happy, fluffy world with rainbows, bunnies, and bumble bees, and a gloomy, hostile world with thunderclouds, evil nurses, and killer wasps. Make use of both perspectives of the world, in order to bring Hannibal to safety on the ship at the end of the level.

More information and free download of the game is at the official site:

www.playflipside.com

(FLIPSIDE requires Half-Life 2 and Steam installed to work.)

Credits:
DirectorJan Rahbek
Game DesignerThomas Pilgaard
Project ManagerTim Nielsen
Lead Visual DesignerMeta Bjerregaard
Visual DesignerJonathan Sachse Mikkelsen
Lead Audio DesignerKasper Aae
Audio Designer and ComposerMads Lykke
Lead Game ProgrammerRune Skovbo Johansen (that's me)
Game ProgrammerMorten Engel
Game ProgrammerStefan Glimberg
Lead AnimatorMatthías Bjarnason
AnimatorStephan Suessmann

FLIPSIDE is a Half-Life 2 total conversion mod created by Team 3 in May 2007 as the first of two game productions arranged by the Danish National Academy of Digital, Interactive Entertainment (DADIU). The team consisted of students from eight different universities and art schools throughout Denmark.

FLIPSIDE has won a 2008 Independent Games Festival Student Showcase Award (open IGF website) and is exhibited as part of the IGF Pavilion during the Game Developers Conference 2008, which is taking place February 18-22 in San Francisco, CA.

This page is a showcase and discussion of select contributions I made to the game in my position of Lead Game Programmer.

Screenshots

Below are some screenhots from FLIPSIDE:

View image 1
View image 2
View image 3
View image 4
View image 5

The main themes

The concept in FLIPSIDE revolves around two central themes:
  • A two-sided caricatured world.
    Seeing the world from two opposing perspectives was ingenuously represented in a cardboard world by literally showing the world from two opposing angles. All silhouettes remain the same, but the magazine cuttings glued onto the cardboard give a completely different experience on each side, and the music supports this. Central to the gameplay, both the main character himself and the creatures he encounter have different attitudes and abilities on the two sides.
  • An analog, tactile aesthetic.
    While the concept of a world made out of cardboard pieces is crazy, we still wanted it to feel very real, as envisioned by our Director. We pursued making the cardboard look, move, and sound like real cardboard and we used classical instruments for the music. Digital and electronic aesthetics were avoided.
All programming were planned and executed with support of these two main themes in mind.

State machines

In my position as Lead Game Programmer I was often faced with tasks of implementing features according to specifications that were not quite detailed enough to be ready for implementation. This is only natural, since the specifications are often written by non-programmers, who are not used to think about features in the very explicit level of detail that is needed when programming. Rather than burdenning the original designer with requests of additional details, I took it upon myself to fill in the missing details whenever possible and then present my re-worked interpretation of the design to the designer for approval prior to implementation.

One example of this is the behaviors for the enemies (NPCs) encountered in the game. The specification below is from the design document provided by the Game Designer:

UC_009: NPC2 - "Small" NPC
  • Lush side:
    • If the PC gets too close to the NPC he will be thrusted backwards.
    • If the PC attempts to jump over the NPC it will make a quick maneuver to block the move, which would result in the PC being thrusted backwards.
  • Gloomy side:
    • The NPC will use a deadly attack if it gets close enough to the PC and he hesitates long enough.
    • The NPC can be killed by the PC.
  • The NPC can move in space ie. it is not bound to a platform.
  • When the PC gets within a set radius the NPC will move towards the PC to attack.
  • When idle the NPC will move around within a set radius/area.

In order to prepare this design for implementation, I designed a finite state machine reflecting the written design use case, but with some additional states. In addition to the states Idle and Attack already implicitly specified by the design, I added the states Chase and Return. The finite state machine is illustrated here:



As can be seen, I also divided the Attack state into four sub-states that would control movements, animations, and deadliness (marked in gray) during the attack. This was in order to address some questions unanswered by the original design:
  • What exactly is the deadly attack of the NPC?
  • What does it mean that the player hestitates long enough?
  • What happens if both try to attack at the same time?
  • How can the player know when to attack and when to hurry away?
My proposed design answered these questions by dividing the attack into four states.
  • In the two middle states of the attack cycle, the NPC would strike by first noting the position of the player and then, after a short moment, strike towards that position. The player would have just enough time to move out of the way in the mean time though. Just prior to attacking, the NPC would shake aggresively, thus giving an advance warning to the player.
  • In the two other states the NPC would retract and prepare a new attack, and this would be the time for the player to attack the NPC.
This design was accepted by the Game Designer and I implemented it in the game in C++ by using the existing framework for finite state machines in the Source game engine, which basically consists of changing pointers to point to different methods.

Jumping heights

As part of the game mechanics in FLIPSIDE, the main character, on the lush side of the world, is able to jump increasingly higher when jumping several times in a row, as envisioned by our Game Designer. This was originally planned to be implemented using a counting based height: The first jump would have a specific height, the next jump a higher one etc, all measured from the ground.

However, after my suggestion, the mechanics were changed to a pseudo-physics approach where the height of a given jump is dependent on the velocity when landing on the ground after the previous jump. Since this approach mimics the behavior of a bouncing rubber ball, it is generally more intuitive than the approach based on counting jumps. When jumping on platforms at different altitudes, this potentially makes a big difference.



As a game programmer, I am familiar with basic knowledge about velocities and transfer of potential energy into kinetic energy and vice versa. Combined with the user interface paradigm of Direct Manipulation Interfaces, this made for a logical improvement in the game mechanics.

Aesthetic contributions

Though the primary contributors of aesthetics in the game are the Visual Designers, Audio Designers, and Animators, under direction of the Director, there is also some room for Game Programmers to contribute to the aesthetic experience of the game. Here are some of my aesthetics-related ideas that ended up in the game:
  • The game features a "Super Mode" that begins when the player have picked up three flower bouquets/mushrooms. However, it proved to be difficult for the play testers to understand that they had entered a "Super Mode". The run animations were different, but not the animations for jumping and attacking. There was also alternative music, but due to a technical limitation, it kicked in with a few seconds delay. To make the Super Mode more visible, I made use of a simple particle system in the form of sparkling stars on the lush side and a purple smoke cloud on the gloomy side. This was recognized as a good solution.
  • Originally the player and the NPCs were supposed to have death animations. However, I got the idea to instead make them freeze and fall over, like they were in fact just dead pieces of cardboard. This was in line with the "tactile, analog aesthetics" theme of the game outlined above, since it strengthened the idea that even the living things were made of actual cardboard. The realistic physics capabilities of the Source engine were used for this feature.
  • For the implementation of the hint text boxes in the game, I made them appear in a smoothly animated way, and I made the text color a bright yellow on the lush side and a nasty purple on the gloomy side in order to make it support the "two-sided world" theme.

Speech system

The main character in FLIPSIDE is brought extra to life by uttering short spoken lines of dialog in selected situations. The lines are in Danish, so English speakers may not understand them, though they still being the character to life.

The speech system was developed in close collaboration with the Audio Designers. To sustain suspension of disbelief, we needed to absolutely prevent that more than one line was played at the same time. To do this, we divided the spoken lines into a category of critical lines and one of non-critical lines.

The critical lines were ones accompanying attacks and taking damage. The non-critical lines were the rest, including lines spoken when bumping into NPCs at the lush side of the world, where they are harmless, and lines uttered at random times simply to add atmosphere to the game supporting the currently active side of the world.

The system was then designed such that a non-critical line would only be played if there was not already a spoken line being played. A critical line on the other hand would always be played and would immediately cut off any possible existing line being played.

Dynamic camera

During the game production a conflict of interests emerged regarding how close the camera should be to the action. The Director envisioned the characters in the game being very close up and big on the screen. The Visual Designers wanted this too, in order to show off their detailed textures of magazine cuttings glued on cardboard. However, the Game Designer and several others on the team pointed out that the game would be impossible to play if the user could not see very far ahead, because it would not be possible to anticipate approaching enemies and obstacles.

In order to satisfy all parties I proposed a solution where the camera zooms in when the player character is standing still and zooms out when he is running and jumping around. This turned out to work well, and by using formulas for smooth and fluid acceleration and deceleration, the zooming is almost not noticed consciously while playing.

Another problem arose when we inserted a skybox in the game. The background skybox was standing completely still on the screen because the camera was always looking exactly sideways. This looked weird and unnatural. To solve the problem, I made the camera follow the movements of the main character with a slight delay, causing it to point slightly upwards, downwards, and sideways when jumping and running around. This effectively solved the problem and gave a feeling of increased depth to the world as a bonus.

Animation system

During the production I had a close communication with the Animators to ensure a tight integration between the animations and the code. I have made sure that the animations were delivered in a condition where they could be used in the game in a way that was consistent with the vision of the Director.

For example, the Director had made concept drawings showing the main character jumping into the air with arms extended and then facing head down on the way down. I instructed the Animators to divide the jumping animation into several specific pieces, so I could use code to activate the animation where the head rotates down exactly when the top of the jumping curve is reached, which occurs at different times depending on the height of the jump.



Following this I could adjust the exact timing in collaboration with the Animators and their views on how it would look the best.