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. 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. 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. 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.
In my previous entry I wrote about the definition of game rules and what it could induce in a game production. Let's now talk about something more design oriented: coherence and inconsistency in game balancing. Designing difficulty is never easy for several reasons. When you work on a game, since you know the exact mechanics you are never surprised. It's hard to understand and imagine the discovery state of a player. I use to say quite often Hey guys, we are the best *insert game name here* players of the World!. Weve solved TURN rooms you couldnt even imagine. Yet we're designing a game for newcomers, not for hardcore progamers. When youre working on a puzzle game, you try to make something that the player will find difficult and rewarding to solve. Its all about measuring the right amount of difficulty. If its too easy then its boring, if its too hard then its depressing. To design difficulty, you have to follow specific rules. If you go blindfolded youll hit the wall, theres no doubt about it. Game Design is now "serious business" since the video game industry has achieved a certain maturity. I'd like to share and suggest 3 things that I learnt about Level Design on TURN: Progression: one small step for the dev, one giant leap for the player Youll want to teach the player each and every move, but youll have to introduce them one at a time. Its easier to learn digits before numbers. Sometimes during development, you design complex things that look cool, and you forget that the player will have to endure a rough progression before seeing the whole thing. Yeah, falling dominos are great to enjoy, but placing each single domino to build the course could prove tremendously boring. Try to decompose each and every action the player will have to make. You can and you have to use and define small bricks if you want the wall to be solid. For example, in TURN, a brick could be push the crate or rotate the room so that a stone roll in that corner. Think small, because thats how the newcomer player will think too (well, if hes no Rainman). Teach him how each brick is useful and could be used before using them in a complex structure. Because theres no chance a player would be able to understand something if you directly put him in a situation where this thing is hidden among others. Misdirection: wrong way is wrong If the player is driving the wrong way, tell him immediately that he is wrong. Otherwise you will create an outstanding frustration. Imagine that after a collision you are driving the wrong way in a racing game, but the game only tell you so at the end of the race Too bad, youve done a mistake 5 minutes ago, you lose. In a puzzle game like TURN, that means you'd have to design each room so that if the player makes a move that forbids him to solve the room, he must be killed / blocked in the next two moves at the most. A badly designed room means you dont know where you failed, and therefore you cant really progress. Thats something you want to avoid at all cost. One of the main purposes of puzzle games is to induce the player into thinking hes growing wiser and wiser, not to tell him youre dumb, noob!. Objectives: long term objectives are chimera You have to show reachable objectives. Despite the problem you present the player with is complex and needs many moves to be solved, you have to clearly highlight some main goal. That could be different things like: to access this door you have to put the crate here or if you break this crate you wont be able to solve the room. Thats something the player will have in this mind during the whole completion of the puzzle. Thats why you have to be very careful on the visibility of such objectives. The best way to achieve friendly difficulty is to continuously add elements on a basic thing, without too much disruption. Its like the Simon game. If the player has gone from the first series of 3 moves he will surely be able to remember a series of 10 or more. But if you directly ask him to remember a big series without the previous steps, the results will be terrible. Even if it could seem strange, the actual difficulty depends on the location, the same problem in two different levels doesn't have the same difficulty. As a little side note about iOS specific development: By the way, the iPhone gaming platform has also some specific constraints you have to know and understand. They are quite nicely summarized in that article on Slide to Play. While many designers blame and hate working with constraints, as a producer I praise them since they are useful to avoid the irrelevant. Hope this has been of any interest to you, critics and remarks are welcome.
