informa
4 MIN READ
Featured Blog

Designing Invisible Walls: Thoughts on Level Design

I'm writing here about the Game Design of our first iPhone Game. It was also the first puzzle game I worked on. This first part is about the importance of defining the rules of the game.

Hi everyone, I’m currently working on the Level Design of our next iPhone game and I thought I could share things with someone, and it happens to be you. Perhaps you may take any interest in it.

Let me begin by a small reflection about one of our previous game: TURN.

TURN Episode 1, world 2

We began working on TURN with several Game / Level Designers. The gameplay was quite simple: you move your hero through levels, your main power is to rotate the room and the difficulty is to solve each puzzle room, avoiding falling objects. It’s a turn-based (the name speaks for itself) game, which is to say that you have time to consider each move, you can’t avoid something that is falling on you once it has started to fall.

It was our first puzzle game, and we made several mistakes.

The first one was to define rules during development, creating exceptions and behaviors as we test the game. This is a major mistake. Because the coders were overwhelmed with issues such as “what happens when a rolling stone meets a falling crate? Is that behavior right?”. We met such complex issues that we had to organize a special meeting with the team to define the precise rules of TURN, the exact behavior of each item, etc. We even had to rebuild the engine around those rules.

The first game engine was pixel-based: each item moved pixel by pixel, and collisions were very weird. We had overlapping stones and crates, and some moves could cause unpredictable behaviors that completely ruin the “reflection” aspect of the game. Try to imagine if you had to roll a dice before any move in a Tetris or Chess game, that could be quite fun but that completely changes the perception of the game by the player.

TURN Episode 1, world 1


Actually, TURN’s rules could be well defined in a step-by-step based environment. You could play “paper TURN”, despite it’s a bit slow and boring to move each item separately. However, that’s the way you should write and test such puzzle game rules before sending them to any coder if you want them to love you :). Because if you can explain and detail every behavior, you save time and mental sanity. And actually, that’s your job if you’re a Game Designer, you’re here to design game mechanics.

Each TURN action could be divided into those rules:

  • First of all, you check what items are in a “moving” state. A “moving” state means that the item possesses inertia due to the player’s action (rotation or push).
  • Each item is ranked upon its location. The “first” one is at the bottom – left or right of the screen (that depends on the rotating direction since rolling stones should carry on their move smoothly). That rank is very important to determine which item we move first on each turn. Bad definition of this could result in severe issues during multiple falls, the bottom crate blocking the upper ones.
  • The screen is divided into squares, and movement is based on these squares. We move items square by square, so that there isn’t any overlapping issue occurring.
  • You repeat this until there is no longer any item in a “moving” state.
  • Each item has also a unique behavior: for example crates fall in straight line while stones roll to the left or to the right depending on the room rotation direction.



TURN Episode 1

I asked Game / Level Designers to create a “TURN board game” to test every possible and tricky situation, such as a falling crate blocking a rolling stone, etc.

The whole definition took about two days, and the refactoring of the engine took two weeks. This is a very long time considering the fact we were almost done with a project that must remain a “small production”. But what is really a shame is that we spent perhaps two or three weeks on a broken engine with constant bug fixes that look later like rubber repair patch on a square wheel. And that wasn’t the coder’s fault involved here, but the designer’s one. You have to design a circular wheel and not to ask someone to make a square one turn.

That’s the first part of my reflection on TURN. I’ll speak later about coherence and inconsistency in game balancing.

P.S. I wasn't sure if I should post a link to TURN Episode 1 on AppStore, since I didn't write this as marketing material. But well, for those who might take any interest, here it is.

Latest Jobs

Xbox Game Studios

Redmond, Washington
10.5.22
Technical Lighting Artist

Innogames

Hamburg, Germany
10.5.22
Game Designer - Elvenar

Six Foot

Houston, TX
10.3.22
Six Foot Director, Player Relations

Hometopia Inc.

Remote
10.7.22
Lead Engineer
More Jobs   

CONNECT WITH US

Explore the
Subscribe to
Follow us

Game Developer Job Board

Game Developer Newsletter

@gamedevdotcom

Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Browse
Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Subscribe
Follow us

@gamedevdotcom

Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more