Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
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.
4 Min Read
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 screenshot
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 screenshot 2
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 screenshot 3
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.
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
Latest News
Trending
Featured Blogs
