Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
May 25, 2020
arrowPress Releases







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: A Rationally Designed Funny Game - The making of 'biped', in hindsight

by ding dong on 03/27/20 04:07:00 pm

1 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

1. About biped

Biped is a coop action-adventure game using ragdoll physics. What makes the game unique is that players directly control the 2 legs of the protagonist via 2 joysticks on the controller, not the characters themselves. By moving around the legs in 3D space, players can perform actions such as walking, gliding, grabbing and interacting with various objects.

Close collaboration is another strong focus of the game. Two players (in couch coop) need to constantly talk to each other, form plans and move side by side in order to overcome many of the challenges and puzzles in the game.

In actual gameplay, thanks to the richly organic dynamics fed by the ragdoll physics, unexpected play, a.k.a. mishaps take place and often times inevitably lead to a parade of hilarious incidents.

I wish to take this opportunity and try to cover what was the key design thinking behind the creation of the game. It will by no means be the full story, but it will shed some light on the methodological and practical path in forging biped which hopefully will get applied somewhere in future games.


2. A happy accident

About 2 years ago, two of the best GPPs (gameplay programmers) in our studio were working on an original project with a secondary mechanic involving robots climbing a mountain. They soon discover that having a humanoid character carry out convincing climbing animations using ragdoll was not only no easy task, but probably not the kind of simple and efficient action they were looking for. There was no elegant solution to making the 4 limbs look natural and believable and asking the player to control 4 limbs respectively to perform climbing seemed too much.

In an iteration one idea popped into their heads. What if we lose the arms? If the limbs are capable of clinging onto the mountain there is no reason why less of them wouldn’t suffice for climbing. Essentially players would just need to ‘walk vertically’ onto the mountain.

The armless robots prove to be not only much more effective and user-friendly in climbing but also lovely and unique to behold. In fact, just watching them clumsily cat-walk across the floor is a weird delight.

Since that day the focus of the project was shifted towards developing around 2-legged robots. What was once a world-charting-adventure project was abandoned for the incubation of the “new kids in town”. If anything, this was in the true essence of a bottom-up game dev approach: driven by passion, iterative work and quite often, luck.

3. Where do we go from here

Among many of the experiments that followed, including experiments to create giant, long-leg version and big-headed version of the robots, one thing validated early on as something of high potential was COOP. The fact that a single robot with only 2 legs seemed lonely naturally motivated the developers to start trying out multiple robots moving together. To make things interesting, at the beginning of the iterations there were robots of different sizes who were referred to using their colors such as ‘yellow’, ‘blue’ and ‘green’. Blue is big, tall and slow, while ‘yellow’ is small and agile. Many puzzle-oriented ideas were generated in accordance with the different shapes, sizes, weights and physical characteristics: in once scene the little one needs to climb onto a big one in order to cross a high wall, and in another scene 2 different sized robots need to delicately balance themselves on a seesaw.(a gimmick we kept in the released game) But most of the time, it is most emotionally gratifying when the two characters need to each do something to help one another. But like most game dev process, we were not able to immediately identify that as the core fun and resumed a lot of “beating around the bush.”  

4. Let’s try everything 

At Next studios we have a regular event called ‘big bang day’ on which teams working on different new projects get to showcase their WIP prototypes to the rest of the studio to gather excitement as well as peer to peer feedback.

It was before the March big bang day when the core team at the time decided for the first time to create a full level that would somewhat feel like a proper game stage. By then we would have had in our gameplay arsenal a number of semi-polished mechanics including walking, climbing and skating but still it would be lying to say we had a clear clue of what game we were making.

We ended up demoing 2 playable builds. One of them is a race for 2 players: to walk, climb, skate and speed through a triathlete-like course to the finish line. The other though is a figure-skating dance to the music, complete with its music-beat challenges.

The demos were met with a lot enthusiasm and more importantly laughter. The most common feedback we’d get would was the amazement at the ‘near endless possibilities’ to what the robots can do and therefore what the game could be.

Peter Parker’s Uncle famously said: “With great power comes great responsibilities.” I’d say the same thing about “expectations”. After the big bang day our team was so pumped with all the wild possibilities we entered a phase of trying out all kinds of random things.

There was a dark dungeon in which the robots needed to constantly raise their legs and use the torchlight on their feet to light up the environment.

There was a ‘death’ based level in which you need to strategically die, respawn and utilize the formerly dead robot’s bodies to solve some pretty tricky puzzles.

In the meantime, we also began to think about bigger questions for the game as a product, like what modes it could have, what would be the ‘beef’ of the experience, and how could we address the concern which troubled us from day one that the game might ultimately feel “small” and “childish”?

Our conclusion at the time was to go bold and create a multiplayer PvP map utilizing as many base mechanics we’ve developed as possible. The idea was to up the beat of the game by involving fast-paced competition and to use combat to aim for an older age range.

The end result, looking back now, wasn’t all that bad. Those who came to the playtest had a decent amount of fun, but they unanimously left one comment, that the whole thing doesn’t feel like the biped they knew anymore.

5. Finding the core again

The failed PvP test proved to be THE turning point of the project.

It provided a lot of clarity on what made the concept fundamentally fun and that we must return to that core.

We went on and defined the design foundation for the game, which is the sheer pleasure of controlling the legs at the player’s own pace and COOP – overcoming an individual’s flaw and achieve common goals by helping each other.  

What might have been the most obvious design choice took us a whole lot of trial and error to finally nail down.

The “returning to the roots” mindset also recalibrated our focus back to what made the early prototypes feel special: close, bonding coop.
One of the founding members began to design from scratch a new type of puzzle mechanic that requires 2 players to communicate, plan and execute their actions on a literarily step by step basis.
This “number” mechanic, which later on became a staple of biped level design almost immediately clicked with the feel of the game we were after: it is about thoughtful walking, the very molecule of our gameplay and tight coordination between 2 players, which is coherent with our rational design process. 

By combining the interactivity side and systematical side of the core, we further narrowed down the route to take and were able to concentrate on effectively creating more “bipedy” things.

6. The search for the face

Having a clearly defined core proved to be also useful in helping us find solutions to many related, yet long overdue problems. For example what art style we should have and what our characters could look like.

The kind of design thought process we adopted at the time is called the “rational design process”, a methodology commonly practiced in AAA production. What it does best is to help designers trace between different layers of design hierarchy in search of logic-based options and solutions.

This may sound like an oversimplification of what happened, but based on the fact that moment to moment action/activity in our game is quite input-tense and fail-frequent (but not too frustrating), we wanted the visual tone to provide a soothing backdrop to what otherwise might be a never-taxing experience. We also wanted the art expression to compliment the naïve and cute motion of the characters.

And speaking of characters, we had a long and hard journey in finding the right face for the robots. One particularly tricky thing to decide is their facial composition. We certainly did imagine them to be super expressive “cute kids” that respond constantly to the big and small interactions they go through in the game world, but we also didn’t want the faces to unnecessarily draw too much of a player’s precious attention from the subjects they ought to focus on.

To put it in another way, it was the legs that indisputably deserve most of the player’s focus and we went with the decision to be simple and restrictive about the robot’s faces and their expressions to offset our human instinct to center our pivot of sight around faces.

Even today, after looking at the robots for thousands of hours and totally having gotten used to how they look, we are not that confident that our intention to have them sort of work as half-empty-canvas for players to reflect their own emotional colors on has come across successfully. But I guess we will find out soon.​

7. A dangerous long skate

No memorable journey is complete without some hiccups and the voyage of biped is no exception. One detour in the middle of production is particularly worthy of reflecting upon. 
After having created several relatively slow-paced levels we started to get a little anxious about the lack of “dynamic range” in the game play. I knew from earlier phases that we wouldn’t be able to do everything but the idea of having a few moments that surprise and wow players via sudden changes in perceivable sensation kept haunting me.
Not being able to resist the temptation we tied to make a level that is essentially a 6km ski ride through an ice cave. A cool idea on paper but the affordance turned out to be a curse.
To make the trip interesting and varied we came up branching ways, jump pads and even static tornados. By the end of its 1.5 month “alpha state” we sadly came to the conclusion that not only wasn’t it able to give us the kind of wow we pursued, the sheer volume of design and production had also become unbearable for what was otherwise a very cost-efficiency-wary production. 
On the night of long internal disputes and frustrating silences we made the tough decision to cut the ski level, along with the majority of its visual assets that are unfit for scavenging. 
It was a hard lesson but a valuable one. It reminded us to face the boundaries of the game and to seek more pragmatic solutions. Knowing what can be done is equally as important as knowing what needs to be done.
In the final game, the “dynamic range” issue was mitigated by having pace-changing intervals between main challenges and we served up the wow moments primarily through “jump scare”-ish mini events.

8. The pool of fun

By the time we were nearing Alpha, we’d have built a “playground pool”. It is a bank where we save selectively the most unique and gratifying gameplay mechanics among all those that have been validated as working. The goal is to produce a game fully maxing out the potential of what’s in the pool and that alone.

Each locked-down gameplay mechanic was assigned a simple name to reflect its core idea.
“Color” represents the gameplay dictating a color-changing platform that alternates its color based on every step a robot takes on it.

“Cliffhanger” is a mountain-climbing mechanic in which 2 robots are linked by a rope and are capable of swinging over the surface of the snowy peaks.

“Balance”, one of our player’s favorite so far, has 2 robots constantly needing to balance their weights on a wobbly, tilty object like a seesaw.

Maps and their level design are created around these mechanics and in some cases the multiplication of them.

Similarly, knowing the atomic parameters of the mechanics inside out: the challenges, inputs, learning and difficulty curves, we were able to pace the levels and plan the aesthetics to fittingly match what’s imagined to be the optimal user experience.

This rational structure of design secured the “integrity” of the game and freed up a lot of the team’s mind to focus on much needed areas like breaking repetition, creating diversity and adding surprises in an otherwise very tight timeframe.

Moreover, as the mechanics are self-sufficient and aren’t reliant on any specific visual style, we retained the liberty to creatively choose the type of presentation for gameplay, hence the possibility of the “modelized” way of producing the pro-difficulty levels that are relatively light on visual assets and are easier to make.

9. Focus, focus, focus

Into the alpha phase, we are left with but a few months to wrap up the production, according to the plan at the time. We were facing the classic dilemma of deciding what to focus on with the remaining time we had.

Fortunately, the discussion didn’t last long. By then we were able to dodge the deadly bullet of creative indecision and we made choices, again, using the kind of rationale that had been working well. We concluded that we need to focus on areas that would directly contribute to our moment to moment activities and smoothen out anything that undermines their quality.

That means first and foremost, to polish the fundamental experience of controlling the robots to make sure there is always comfort and ease upon dealing with the tricky challenges.

One example would be about a puzzle element called “number platform”. By detecting the number of feet stepped onto it, the platform will respond and change its shape. Now in biped, the 1-1 physical control of the legs is always the central rule and because of that players are able to nudge their feet in really small increments. Therefore when they are around the edge between platforms chances are a tiny, unintentional input on the joystick might accidentally trigger the aforementioned “number platform” and cause unwanted results.

To fix the problem we reasoned that we simply needed to secure the basic accessibility before any pleasurable feature could work. By automatically shifting player’s feet and sliding them into invisible “comfortable locations around platforms, we unnoticeably helped players avoid a great majority of missteps that could’ve easily ruin their efforts to make the right move.

But to focus also means to be deductive of what not to focus on.

We didn’t have the time and capacity to produce enough meaningful narrative content that would contribute to the core experience.
Besides, there is no worse case than telling a bad story and demanding players to sit through unskippable cutscenes. 
After spending many years making games that take dozens of hours to finish I have come to believe that we as game creators should avoid making overly long games that too often resort to fillers(tediously repetitive content) to extend play-through length.
The volume of a game should be faithfully proportional to its core values and by its our sensible choice to deliver those values in its purest and ideally most concise forms.
With biped I am proud to say we stayed true to our vision for the game and left little undesirable fat and grease on the steak.

10. Extending the adventure

Being a coop-centered game through and through, when I looked at the product as a whole, I had always hoped that those players who are inclined to play alone, and when those who didn’t have pals to play with at a given time could have a way of enjoying biped.

It was not until we had made solid progress in NPC/AI behavior when we found the key. We designed the solo missions with 2 specific goals:
1. To give a lone player a sneak peek to what fun collaborative gameplay can provide   
2. To dish out challenges that better match the rhythm and mood of a single player experience

The solo missions are composed of precisely those 2 elements. There are chunks of gameplay that mimic their counterpart in the coop game, only that players are paired with NPCs to work with. There are also parts of the level that challenge players to be reach high precision in control, to have better reflexes and to be more adventurous in exploration.

Solo missions make biped a fuller package, and a more flexible game in different play scenes.

11. A happy ending?

I can go on and on about the thousands of little stories that happened but the above wrapped up what I believe to be the decisive junctions points in the project.

At the end of the day players will be the judge to how biped turned out to be, but I feel my takeaway at this point is abundantly clear: we managed to create the game we wanted to make, by staying loyal to the core fun, taking a rational approach in our design process and resisting the temptation to create more than what the team and time realistically allowed us.
Eventually, making a game is all about making choices and we feel lucky enough to be in control of the version we got to make.

Thank you for your time.


Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[05.25.20]

Experienced Game Developer
Heart Machine
Heart Machine — Culver City, California, United States
[05.21.20]

Quality Assurance Manager
Fred Rogers Productions
Fred Rogers Productions — Pittsburgh, Pennsylvania, United States
[05.21.20]

Digital Producer
Visual Concepts
Visual Concepts — Agoura Hills, California, United States
[05.20.20]

Producer





Loading Comments

loader image