GAME JOBS
Contents
Not Puzzles, but Scenes: Cinematic Gameplay Interactions
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
June 6, 2013
 
YAGER Development
Multiplayer Programmer (f/m)
 
Hansoft
Senior Production Expert
 
Secret Location
Unity Developer
 
Insomniac Games
FX Artist
 
2K Marin
Lead Network Programmer - 2K Marin
 
Bluepoint Games, Inc.
Senior Graphics Programmer
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
June 6, 2013
 
Cracking the Touchscreen Code
 
10 Business Law and Tax Law Steps to Improve the Chance of Crowdfunding Success
 
Deep Plaid Games, one year later
 
The Competition of Sportsmanship in Online Games
 
Gamification, Games, Teams and Competitive play
spacer
About
spacer Editor-In-Chief:
Kris Graft
Blog Director:
Christian Nutt
Senior Contributing Editor:
Brandon Sheffield
News Editors:
Mike Rose, Kris Ligman
Editors-At-Large:
Leigh Alexander, Chris Morris
Advertising:
Jennifer Sulik
Recruitment:
Gina Gross
Education:
Gillian Crowley
 
Contact Gamasutra
 
Report a Problem
 
Submit News
 
Comment Guidelines
 
Blogging Guidelines
Sponsor
Features
  Not Puzzles, but Scenes: Cinematic Gameplay Interactions
by Lucas González [Design, Console/PC, Indie]
7 comments Share on Twitter Share on Facebook RSS
 
 
June 5, 2013 Article Start Page 1 of 5 Next
 

During the last year I've had a lot of opportunities to think about what puzzles are and what their role in video games is. I know that I'm not the first to write about this, and that many other experienced game designers have their thoughts on this topic, but I also had my own, personal, trial and I do believe that the lessons my team and I learned will be helpful for any designer that has to face a similar situation.

As a new member of the Tequila Works team, I was specifically hired to be in charge of the "puzzle design" of the studio's first game, Deadlight -- a cinematic platformer set in a post-apocalyptic Vancouver, published on Xbox Live Arcade by Microsoft.



When I came aboard, one year before the estimated ship date, I was told that the team already had a game -- actually a nice one -- running, but that they needed someone to "design the puzzles." After several years designing video games, it was the first time I had to deal directly with this essential part of many video games.

Getting Started

I should probably explain my previous experience as game designer. It will be enough to mention that I worked on the design of some of the levels of NyxQuest: Kindred Spirits and The Fancy Pants Adventures, which are pure 2D platformers. These required from me to create interesting layouts, gameplay situations, and simple switch on/off puzzles for the player to solve.

 

Top: NyxQuest: Kindred Spirits. Bottom: The Fancy Pants Adventures

The situation I was facing now was different that then most of the gameplay situations I had created or polished -- these were twitch-oriented, skill-based situations in which the player was supposed to react accurately under stressful circumstances (i.e. perform a series of jumps while the floor is falling down). In Deadlight, the puzzle situations would be much more deliberate and slow-paced.

It should be understood that the puzzles were considered key to Deadlight, together with the navigation and the combat, to the initial core game design.

One of the main objectives of the puzzles was to extend the game experience without increasing the size of the levels (which were really expensive to produce).

As you might know, one of the classic problems you find while creating a new platformer is that the player can move forward pretty fast and go over many "screens" if he has nothing to do but navigate. It's simply impossible to fill the world with so many scenarios. Given that, it's important to slow down his progress. Common solutions are to force the player to go back to a location in order to find something, to revisit areas to perform different actions, or to introduce vertical gameplay.

When I began work on the project, Deadlight had only combat situations to slow down the player. But this wasn't enough, as the combat system wasn't designed to sustain hours and hours of gameplay by itself.

Apart from this practical consideration, it was decided that Deadlight should be much more slow-paced than a typical platformer thanks to its theme. We were creating a game about studying the environment as a survivor would: to find useful items and to bring them with you, and to be smart while navigating a devastated world.

The Inventory

Deadlight used to have an inventory system. As in the old graphic adventures, it was possible to keep, use, examine, and even combine items.

Deadlight's inventory system

As a game designer, the first time I heard about this feature, it totally made sense for me. Randall was a survivor in a zombie apocalypse, and survivors need to make the most of the environment in order to maximize their chances of surviving. Looking for useful items in piles of trash, searching rotten bodies, carrying apparently useless items that suddenly are the solution to deadly problems -- these are clichés in the genre.

An inventory completely suited the mood and the concept of the game. Something necessary, a game mechanic that would support the direction of the concept -- perfect!

At the same time, it looked like it would expand our gameplay, providing us with a powerful tool to create hundreds of different variations on puzzles. Everyone in our team had played classic graphic adventures, where the inventory was key for solving the puzzles.

Finding, using, and combining items seemed it would be the solution to our problems. It seemed that it would allow us to increase the length of the game without relying upon the size of the levels.

And so we started to design graphic adventure-like puzzles. I still remember most of them; for example, at one point in the first act, the player needed to find a gas can, fill it with the fuel of an abandoned car, and then use the gas to fill the fuel tank of a fire truck. After doing so, it was possible to move the ladder of the fire truck and continue.

This is where the fire truck was 

 
Article Start Page 1 of 5 Next
 
Top Stories

image
Keeping the simulation dream alive
image
Video: 10 bite-size talks on progressive game design
image
The diversity of game dev students: Who's joining the industry?
image
Amazon launches dedicated indie games storefront
Comments

Sylvain Vanderhaegen
profile image
The axe moment definitely got that Prince of Persia feel. Great job!

dario silva
profile image
Thank you for sharing Mr González, its good as an outsider to get such deep information on the game development process from a level designer. I do have a question though, and im asking it because Deadlight is a game that i felt let down by and i'm curious why this decision was made. My question is, why did you not take the approach of games like Super Metroid and rather have respawning enemies/mini-boss/boss areas built into the environments with interesting combat patterns? Sure Limbo didn't really have that, but in Limbo you were a little child in a world of giant monsters, whereas in Deadlight the shoe is on the other foot. Just a thought.

Lucas González
profile image
Thanks for your comments.

Absolutely. Super Metroid was one of our references, but to create a game like this, you need to make this core not only to the level, but to the game design.

Just to mention two key features: new skills you are learning now and then, and easy to spawn, varied, enemies that fight with nice patterns and that create interesting combinations.

At some point of the development we haven't implemented yet these features, but we needed to keep building levels if we wanted to meet the deadlines.

So we built them with the "tools" we had at that moment. It's a nonsense to build levels assuming that you will have core features "in the future".

With the tools we have, we only could create a linear-one way experience, so we focused on that.

Travis Fort
profile image
"As old school players, we tend to look for games such as Braid or Monkey Island, which try to challenge players. But the kind of immersive, cinematic experience we wanted to deliver fitted better with the other approach..."

I'd argue that Braid and Monkey Island are just as immersive as more cinematic games. If the player is expecting a cinematic experience, and runs into challenging puzzles (as you wrote about), that immersion is lost. Similarly, if you were playing Braid and ran into a bunch of cut scenes and heavily scripted events, the immersion would be lost, too. Perhaps priming in the early stages of the game is essential to communicate to the players what to expect from the rest of the game.

Lucas González
profile image
I agree with you. For me, Braid and Monkey Island (or Tetris) are immersive; but I wouldn't say they are "cinematic".

I guess that achieving "immersion" is always one of the goals of any game designer, in any case.

With Deadlight, however, we also wanted to craft a "cinematic" experience, and for that, variety seemed to be more important that depth.

Joaquin Estrago
profile image
Thanks for sharing! I loved the game - cinematic platformers are my favorite genre and you guys made a great one.
I applaud the team not only on the design decisions, which I agree made the game a better one, but also on the production decisions that allowed the game to ship on time. Scraping a feature that isn't core to the experience, and instead embracing the available systems to create content - this should be mantra among game devs.

Javier Lucas
profile image
Thank you for this great article!
How important and sadly sometimes undervalued is playtesting!


none
 
Comment:
 




UBM Tech