Case Study : Puma RS-0 Play the Game

For the Love of the Game

Here at Superhero Cheesecake we love video games. If you’ve ever been in our office you’d probably have noticed the games cabinet with our old Nintendo, Sega, Playstation and Xbox systems, or perhaps you may have heard the shouting during the daily FIFA challenge. Similarly, we also love shoes, but I’ll get to that in a bit.

We’ve been lucky to have worked on a number of games here and for a smallish studio like ours building such an application can be a real challenge, but one we love. Unlike AAA game studios which focus large teams on a limited number of titles a year, we have to design and develop an interesting and challenging experience in a very short time, which means we need to develop strategies to quickly iterate, test and (most-importantly) play as we’re going.

A short time ago we were contacted by the team at Puma to help them launch their RS-0 sneaker collection re-boot. For the briefing they requested a game in the classic side-runner style and with a classic retro arcade style look. The original collection was launched in the 80’s and was the first shoe to contain a computerised electronic chip which could track steps, they wanted an experience and aesthetic to match.

We began by designing a game with multiple levels, but we eventually settled with a single infinite-runner game with a quasi-procedurally generated landscape. We wanted to create an experience which was easy to play but impossible to master, the idea of starting and stopping levels seemed too impending to the game play.

Chunks

To create our generative landscape, we initially began with a number of simple platforms, holes and points which were distributed randomly as the game progressed. By focusing on quick release cycles and prototypes we quickly realised the limitations in this approach, we just didn’t have enough control over the difficulty and also the randomness felt too obvious. If a game is going to be truly immersive the user needs to have a certain level of faith that the game designers have thought through the ins-and-outs. When the game play is too obvious or too simple it becomes distracting. We decided that if we could predefine chunks of level we would be able to mix and match pieces to create a unique and seemingly random experience.

Designing individual chunks, we had much greater control over creating challenging actions, bite-sized challenges which the user needed to solve.
Often when creating experiences and games, it become necessary to develop tools or software to facilitate the process of design and/or development. We ended up developing a tool that our design/ux team could use to could use to design and edit these chunks. An exported configuration file could then be used to dictate the gameplay.

Background — Clumps, Lumps and Slumps

Initially we spent a lot of time researching the retro video games and eventually the history of game development and found many rich stories about the transition of computers being used for research to purely entertainment. One of the first video games was Spacewar! developed by Steve Russel in 1962 on a 1,600 pound fridge-sized computer called the DEC PDP-1. Spacewar! would later inspire innovators like Nolan Bushnell having worked in carnivals as a kid used his engineering skills to help create Atari and the first commercially viable arcade game in Pong (1972).

By the mid 80’s arcades started to slump with the advent of home computers and specifically the popularity of game platforms like Nintendo and Sega. With these consoles came a certain homogeneity with the side-scrolling/runner style of game play. Nintendo first manufactured handheld Game & Watch devices, though cheap and cheerful, the games weren’t good for anything other than for what they were designed for, minimal/static graphical versions of arcade smashes like Donkey Kong. This constrained approach would later be capitalised with home gaming consoles such as the NES and the Sega Master System. The machines were optimised with hardware called Picture Processing Units (PPU) for storing sprites, tile-based backgrounds and scrolling much in the same way how graphics cards are designed to render 3D graphics.

By the 90’s game engines were utilising a modular approach to storing game elements. Starting around the same time as the original Doom elements of the game play would be stored into ‘lumps’ encapsulated into larger .WAD files. (see http://www.di.ubi.pt/~agomes/tjv/praticas/01-genres-briefhistory.pdf).

Curious? Find our chunks tool here : https://github.com/superherocheesecake/chunks-tool

Look and Feel

Aesthetically we wanted a game to reference the console games of the 80’s but with an updated modern feel and this modern/retro approach informed everything from the visuals to the music. In the beginning we’d collected a lot of references to 8 bit graphics, but we preferred the sprite based feel of the early platform games like Super Mario Bros. and Sonic. As with the RS-O Play shoe, we wanted to create something which spoke to the past without necessarily living in it.

For motion graphics, we spent a lot of attention getting the animations and movement of our character (the shoes) right. We had the challenge of making a pair of shoes feel somewhat human, adding music and variations in movement helped .

Conclusion

Taking a game from realisation to completion is a huge but rewarding challenge and we’ve been pumped about all of the positive feedback. As of writing our current top score is 75.807 (FRA) about 3 times the achievement of anyone here in the studio. We were also excited to achieve the dwell time Puma was hoping for with the average time on the site staying at around 5 mins a user.

Have a play! : https://www.rs0playthegame.com/

 

Comments

comments