Case study: side-scrollers (Part 1)

As perhaps most of you already noticed, side-scrollers made their way back into the gaming scene. Most of this success is due to an increase in releases of endless side-scrollers on mobile and tablet platforms. So being one of those kids that spent hours and hours (and tons of coins) in classical side-scrolling arcades I felt the need of offering an analysis of their audio. The first part of this study will focus on sounds and how a typical session for a SSG (short for Side-Scroller Game) may look like.

Back to basics

Speaking of sounds, SSG are the easiest games for what concerns implementation. There are usually few sounds and their only purpose is to communicate to the player a specific action which can be an attack, a jump, getting a coin and so on. It is almost never the case that sounds need to portray a feeling such as anger, sadness, love, etc. etc. Very rarely, in the end, ambience sounds are present. This leads to a fairly light and simple implementation session. The same cannot be said for the design of such sounds. Being the only element of communication to the player of the actions it is quite important that these sounds are carefully crafted. Many of us still remember, roughly 30 years later, Nintendo’s Super Mario Bros and its sounds: coins, pipes, jumps and so on. There are of course modern exceptions (i.e. Little big planet, by Media Molecule) where there are evolving ambience sounds, 3D objects positioning, physics interaction sounds with velocity layers, and the sonic characteristics of the sound sets the overall mood of the scene.

Quantum mechanics

Quantum mechanics, aka the building blocks. Let’s examine together what are the smallest elements that constitute a SSG. We can divide them in 3 main categories:

  1. GUI sounds
  2. Cutscenes sounds
  3. In-game sounds

GUI Sounds

GUI is an acronym that stands for Graphic User Interface and in videogames it is used to refer mainly to the menus (main, pause, inventories, …), but also to on-screen elements that inform the player of their current status, health, magic points, bullets, and so on. Very rarely though these latter elements have sounds associated with them, so from here on when we’ll talk about GUI sounds we’ll refer to menu sounds. After this brief introduction let’s delve deep into what are the sounds that make up the GUI sound environment:

  • move selection arrow
  • select
  • go back
  • pause the game
  • resume the game
  • start the game (optional, otherwise can be the same as “select”)

That’s it. Super duper easy.

Cutscene Sounds

Some SSG can include cutscenes, either as an introductory clip to set the background of the game, or as a device to develop the story further. Cutscenes are very much alike all cutscenes from the other games, but with the limitations of the game considered. So if no footsteps or physical interactions are heard throughout the game, then the same applies for the cutscene. Sometimes ambiences and other sounds relevant to the narration, including dialogues, may be included though (see Castlevania: Symphony of the night).

In-game Sounds

Last but not least the in-game sounds. These are, depending on the kind of SSG, generally:

  • Player sounds:
    • Moves (walks, runs, sneaks…)
    • Jumps
    • Attacks
    • Dodges
    • Blocks
    • Gets Hit
    • Dies
  • Weapon sounds:
    • Hits
    • Misses
    • Gets blocked
    • Blocks
  • Enemies sounds:
    • Attacks
    • Gets hit
    • Dies
  • Other sounds:
    • Miscellaneous objects interactions
    • Miscellaneous objects movement

As already mentioned, in this case, the care in the design is what sets apart a great game from an okay one. All the above sounds must be designed so that the player can really connect to the game and wants to play again, or wants to perform again an action. An example of this technique is the reward feeling that one gets by grabbing coins in Super Mario Bros. or the sense of empowerment in Metal Slug when you get the “Heavy machine gun” weapon.

The importance of this design consideration becomes very clear if we consider some recent Endless-Scroller Games (ESG) available on mobile platform that feature monetization systems. The rewarding/fulfilling feeling a player gets, not in performing the transaction itself, but by playing the game (or sub-game) will lead the player to complete a transaction. Of course it is a Game Designer duty to make the system enjoyable and drive a player to actually make the transactions. That said, it is our duty as Audio Designers not to disrupt the Game Designer vision and to help him/her in conveying that idea in the absolute best way possible, as the monetization system is incredibly important for a mobile game.

Final thoughts

So as you can see we are talking about a very small number of elements here, ranging from 20 for a simple game to 40-50 for a more complex one. This makes the session very manageable, but also the design difficult. Even though the sonic quality of the audio has improved dramatically on SSG the same cannot be said for the variety in sounds. in fact due to size limitations of the hosting platform memory the sounds are still limited to 2-3 variations per sound in the best cases. This makes it hard because the designer will have to create a sound that is engaging when heard for the first time, and that won’t sound annoying when repeated over and over. Even though this may look like a huge limitation I think that it is actually one of the most characteristic traits of SSG audio and what makes SSGs immediately recognisable as such.

In the next part we’ll deal with interactive music, its function and a dynamic music implementation session.

Author: Lorenzo Salvadori

a video game audio specialist with a B.Sc. in Physics (specialisation: Astronomy), and with an extensive background in music. He is always researching and opening his mind to the new frontiers of technology. Bringing together all of the technical and audio skills he is constantly looking for new people to work with and new challenges to thrive on.

Leave a Reply

Your email address will not be published. Required fields are marked *