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
Breaking Down Breakout: System And Level Design For Breakout-style Games
View All     RSS
September 26, 2020
arrowPress Releases
September 26, 2020
Games Press
View All     RSS

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


Breaking Down Breakout: System And Level Design For Breakout-style Games

August 21, 2007 Article Start Previous Page 11 of 13 Next

Level Editing Tools

The Game Engine

Classic Breakout has very low performance requirements. So if all you want to do is create a retro Breakout clone, you can pretty much use anything. And I mean ANYTHING (

If you intend to create a competitive contemporary game, and aren’t planning to create all of your own technology from scratch in C, C++, C#, Java, etc., there are a host of open source and commercial game development engines to choose from ( Among general interactive media tools, Adobe Director and Adobe Flash are obvious first choices. In the case of Adobe Flash, be advised that for serious work you’ll want to use ActionScript 2.0+ and you may run into performance issues if your game system requires large numbers of simultaneously moving objects and effects.

The Level Editor

Most dedicated game engines come with some form of level building tools. But let’s be honest, you can use just about any old text editor to build levels for a simple Breakout-style game. All you need to describe the static level archetypes is an array of data – e.g., comma delimited values typed up in notepad. However, this type of editor is not exactly interactive, and will probably start to introduce syntax or logical errors when your game evolves to include complex functionality (settable properties, motion coordinates, named triggers, named groups, nested groups, etc).

Reflexive Entertainment’s Ricochet Recharged is known for having an extremely wide variety of levels, produced by designers from all over the world. Ricochet levels include animated backgrounds and an extensive amount of level-object motion, all features that suggest an advanced editor. Let’s take a look at Ricochet’s level editor and then discuss its evolution with James Smith, its producer and lead programmer.

What were your most critical considerations in building a level editor for use with a geographically distributed design team? Was building a player-accessible level editor ever a factor?

James Smith: We really just build the level editor to be a tool for our internal level designers to use. We built it to be as flexible as possible to allow many diverse types of levels to be built. It is not designed to be extremely simple to learn. It is designed to be efficient and effective in the hands of our practiced level designers. It takes a little bit of time for new user to figure things out, but once they do learn how things work, they are not held back by simplistic concepts or limited hand-holding user interfaces.

To facilitate diverse development we were careful to not have bottleneck files that must be edited by many different people. For example, there is no master file that lists all the levels in the game. Each level designer can work on their own pack of levels independently of each other. We also had to build in tools to make it easy to merge and split level packs. This is primarily done by just copy/pasting groups of levels from one pack to another.

The Ricochet series is known for its large number of moving objects. Can you describe the evolution and thinking behind some of the more complex motion controls of your level editor?

JS: You won’t find any time lines or key frames in the Ricochet editors. Motions are constructed using in rather unique system that evolved from many simple parts.

The editor and the game scripting engine were heavily influenced by similar systems we built for RPG and RTS games we made in the past. The core concept is to construct complex behaviors by assembling collections of smaller building block parts. The scripting commands (plug-ins) are all very simple actions that could be used for many different purposes. Some example are move to a point, orbit around a point, mimic the movement of another object, wait for an object to be destroyed, wait for a message, broadcast a message, destroy self, or move along path.

These can be assembled into groups of simultaneous actions, or an ordered series of actions, or a shuffled (random order) series, and so on. Any combination of action and groups can be nested inside each other. There is no scripting language that gets typed or parsed. Everything is constructed though object composition. You put plug-ins into slots and many of those plug-ins contain more slots to plug more things into. A single brick could easily have ten plug-ins attached to it in a tree like structure with one or two plug-ins at the root and more plug-ins inside of each of those.

Complex animations are usually constructed by making a few bricks work together including hidden bricks called position markers. An invisible position marker may have a few plug-ins on it to make it move around. Then many other bricks may use plug-ins of their own to make them mimic the movement of the position marker or they may use the position marker as a reference point, and do their own motion relative to that moving reference point.

Any time a level designer requests a new high level behavior they want to perform, we always break it down into a few simpler components that can be assembled together to make the behavior that was requested, or reused in other combination to make new behaviors no one has thought of yet.

What factors led you to include animated backgrounds, and how do you expose this feature to your level designers?

JS: Each environment is designed to look like a particular place (real or imagined). Including animation was one of many things that seemed obvious to do to help make the environment be more complete and convincing. How could you make something look like an ocean without fish swimming, plankton floating, and bubbles rising?

Each Ricochet game has a different set of environments which level designers can build their levels in. Each environment has its own sound track, its own background, it’s own background animations, and it’s own pallet of bricks (some would call this a tile set). Level designers select an environment and then build their levels with the bricks available in that environment. They can animate the bricks to mimic some of the animation happening in the background, such as the fish that swim in the underwater environments, but level designers don’t really have any control of the background animation that are part of the environment. The artists, not the level designers, are responsible for setting up the animations that will always be part of each environment.

Did your level editor and game design evolve simultaneously? Or did you build towards a pre-determined list of features?

JS: Everything was evolved iteratively. There were often over arching design goals we were working towards, but many unexpected features were invented along the way. Many times design goals would mandate that a new feature be added to the game and therefore the editor. But other times new features of the editor would inspire new design ideas.

Can you describe some key moments in the development/revision process of building your level editor?

JS: All our editors have always been based on a very powerful object property system. This system uses a home brew “reflections” mechanism that allows us to enumerate all the member variables of a object/class at run time so that all the member variables can be edited as properties in a dynamically generated editor and saved in files on disk. Using this system has made building editors very simple.

With the second Ricochet game we started to really take advantage of our property system by building the composition based scripting system discussed earlier. The first Ricochet game only allowed for very simple movements and no triggers. When we added the plug-in building blocks to the second Ricochet game the possibilities for new level types grew exponentially. Suddenly levels became much more dynamic and interactive with some event triggering other events to happen.

The next key moment was several months after the second Ricochet game was released when players started making some very unexpected things with the level editor. They used some features in some unintended ways to make any piece of art from the whole game show up on top of any brick. Suddenly levels had bricks covered with pictures of power-ups, explosions, game-over messages, UI elements, and all kinds of misappropriated images from other parts of the game. At first we were impressed, then we were disgusted, and then we realized that the level designers were desperate to find some way to add more color and more decorations to their levels.

This inspired us to add many new abilities to Ricochet Infinity to allow level designers to add color and decorations of their own, in addition to enabling new and improved ways of misappropriating even more images from the game itself. Now they have more freedom to make things as colorful, elegant, or disgusting as they like.

Did incompatibility problems arise between level files generated by the various builds of your level editor?

JS: We have never had a problem with level incompatibilities due to changes in the editor. Ricochet levels are stored in a very flexible file format based on hierarchical text files much like XML but with a simpler syntax. There are name values pair like “X Position = 40” and “Brick Style = Underwater/Blue Stripe Power-Up” to store each property of an object. These are wrapped in curly braces to nest object inside each other in a hierarchical fission. Level packs contain levels which contain bricks which contains plug-ins (scripts).

This hierarchical text based property system allows us to add new properties to bricks or levels without breaking old levels. Occasionally we add special code to convert older property types, but for the most part, old levels just work even in newer versions of the editor since there is no rigid binary structure to the level data.

Article Start Previous Page 11 of 13 Next

Related Jobs

Visual Concepts
Visual Concepts — Agoura Hills, California, United States

Camera Designer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Cinematic Scripter
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Technical Designer
Insomniac Games
Insomniac Games — Burbank, California, United States

Lead Level Designer

Loading Comments

loader image