Sponsored By

How to design a sequel. Cut the Rope: Magic Post Mortem

Any time you start thinking about designing a sequel, the first question you ask yourself is: how is it going to differ from the previous part? It was quite a challenge to add a fresh note to the already many-sided Cut the Rope gameplay.

Ivan Verde, Blogger

February 4, 2016

12 Min Read
Game Developer logo in a gray background | Game Developer

Any time you start thinking about designing a sequel, the first question you ask yourself is: how is it going to differ from the previous part? And that’s exactly what we did when we kicked off the development of this new project. It was quite a challenge to add a fresh note to the already many-sided Cut the Rope gameplay, while still preserving all the good things that have kept the series going for such a long time.

To begin with, we needed to come up with some new premises to base our game on. The general principles of the game were based on these and later developed into the game system that you can see now.

3 Conceptual Bases

To start with, we set up a number of brainstorming sessions within the company, concentrating either on mechanics or settings. One core message ran through each session – Om Nom should have even more freedom in his movement. As a living character, he already possessed lots of opportunities to modify the initial gameplay. So his potential agility became the first basis of the new game’s concept.

We considered several ways to stir up our lazy monster:

  1. Simply walking under direct control

  2. A certain object on each level attracting Om Nom and thus making him move

  3. Various additional abilities that Om Nom acquires as you progress

  4. Potions changing Om Nom’s characteristics in some way

We prototyped several types of direct control to test the concept of point 1. It appeared that having Om Nom walk under the player’s direct control created a great emotional response. It broke the fourth wall of the original “game in the box”: where the player is rather an observer with quite limited influence on such a closed ecosystem. Controlling Om Nom meant letting the player into the game world and thus made their connection with the game stronger. But every control type we tried inevitably led to creating an extra control dimension in addition to the previous taps and slides. It also drew attention away from the ropes, the elements that created the  initial fun. It was a very hard decision, but we took the new skill away from Om Nom. In the end, only the walking functionality remained as one of his abilities.

The idea in point 2 never made it any further than the paper stage. The problem is that an attractor would certainly take up a certain amount of space that is always precious due to the small level size. So we can’t afford an object which is compulsory in each level and can occupy any part of the screen. Another disadvantage is the short x-axis. In portrait orientation, the attractor could only lead Om Nom a very limited distance, especially if the two are not on the opposite sides of the screen horizontally.

Our choice between points 3 and 4 was determined by the second basis that we assumed – RPG. You may think it’s rather strange for our game type. However, there is a trend that still exists in the casual market of introducing some mainstream gaming elements to the casual audience. The sequel to Angry Birds was successfully soft-launched at that time, with its upgrading and card systems. Another example was Bear vs Art by Halfbrick Studios, in which introducing a number of RPG elements has significantly  improved the retention metrics. Generally, RPG as a genre contains powerful mechanics in terms of retention and monetization, revealing its potential in any game if used wisely. The personal factor was also significant here. It’s no secret that most developers are hardcore gamers themselves, or at least have been at some time in their past. The same holds true for me as a game designer. So the RPG premise was my central focus for future construction of the game’s system.

What we intended to implement:

  1. Om Nom’s special abilities (again!)

  2. Upgrading

  3. Bosses

  4. Exploration in the form of big levels

I’ll start with the the ideas that we abandoned. First, you don’t find selective upgrading in Cut the Rope: Magic. Actually, there are some possible designs that naturally fit the true grading system, for instance, where you choose what ability to unlock and to what extent. But all these designs require a great deal more content, and the expected improvement of experience simply doesn’t justify the costs.

The second RPG premise that didn’t withstand the ruthless iteration process was “exploration.” We prototyped various forms of big levels, experimenting with the camera and controls. However, as Om Nom stopped walking under the player’s control, a contradiction arose between the agile view and a much more stable character. To explore the given space, you need to move, and if you don’t, the resulting restrictions to the view bring your adventure to nothing.

To sum up, we settled on bosses and Om Nom’s abilities allowing him to perform certain actions as the new game’s main characteristics. The only major thing that still needed to be determined was the game setting. The criteria we set were:

  1. Relevance to the current market

  2. Great flexibility to let us freely introduce various gameplay features

  3. Some support of already existing abilities

The magical setting met all these demands and inspired us to come up with plenty of design ideas. In fact, most of the gameplay elements supporting the abilities appeared or got their final functioning after we chose a course of magic. That’s why the setting was our third basis that helped us drive the concept to its complete form.

Enabling Abilities

The idea of abilities was still quite broad, and our next task was to narrow it down to provide the best experience.

During their early life, the abilities were optional. You didn’t need them to complete a level with 3 stars. They were used only to collect bonus items scattered on levels. This system favoured nonlinear unlocking of the abilities by the player. But the freedom given resulted in a great challenge for level design. Imagine that you had to arrange a bonus item so that it’s unreachable for most abilities and still those abilities don’t reach the initial stars. It’s a challenge that inevitably ends up turning into a big restriction – and that’s something we’d prefer to avoid.

To bring a greater degree of control into the levels’ dynamics, we’ve fixed the abilities on each level. But under the condition of strict assignment, abilities seemed to be most interesting if they were obligatory. And as they became fully fledged game elements, the next step was their improvement for frequent use.

Our first approach was feeding Om Nom with special candies that would give him a corresponding state. This interpretation of transformation inspired by the Alice in Wonderland book series seemed the most consistent due to Om Nom’s nature. To feed him, you have to drag a treat right from the HUD to Om Nom. This control type provided a great relation between the player and his pocket “pet” that had never been seen in Cut the Rope series before. The player could finally feed Om Nom directly and without much effort and get feedback immediately. But there were some potential problems. The first one is usability. It was pretty tiring having to drag each time you need a transformation. We were able to solve this by simplifying the controls, but there was another issue – the delay before actual activation. If you allow players to feed the monster, you should show them how it’s being fed. Unfortunately, any showing takes time. It means an ability couldn’t function immediately after the player’s input. Although we avoid making speed-solving levels, this factor restricted the gameplay in some way. So after a few iterations we ended up with simple tap on an ability icon.

At that stage, a level had one or more abilities which could be used in no particular order. It was one of the challenges for the player to find the right order that led to puzzle solving. And the game was now way more difficult. An ability was a kind of element that you always carried in your “inventory.” It could be activated any time and with no hint as to what time is actually right. With the resulting variability, a level with two abilities was a big challenge for an average Cut the Rope developer. And a level with 3 abilities was possible to beat only by its level designer and a few geniuses around the world. It quite bothered me that we could only use our new features to a limited extent. Nonetheless, the first friends&family playtest was taken at that exact period.

One of the most noticeable things we found out while playtesting is that activating an ability by using its icon wasn’t intuitive enough. People tried to transform Om Nom by simply tapping on him. Shortly after the tests, we held a small meeting with Semyon, the creative director, to discuss implementing the most desirable type of control. The biggest problem came when there was more than one ability on a level. Semyon suggested activating the abilities in a row and thus locking the order of activation so as not to mislead the player. And then I realised that locking the order of the abilities was just what we needed to minimize the high variability that our levels suffered from.

Right the next day, we started making levels with 4 or even 5 abilities to check my theory. This check was made without even technical prototyping of the fixed order. What we saw was that – regardless of the number of abilities – we could still balance the level’s difficulty. That means, for example, a level with 5 abilities can be made pretty simple or deadly difficult depending on how we want it to be. It’s exactly the same as with any “classic” Cut the Rope element addition which doesn’t automatically mean complication.

Having defeated all the visible problems, we retained the functionality of these controls and abilities so that you can see them in the released game.

Doing Magic

It’s no secret that magic is not an easy thing to do. The abilities contain several unique specialities which we learnt to cope with. It’s not only their inventory-like nature – allowing the player to use them meaningfully at any moment – but also their relation to one of the most important elements of the puzzle: the candy.

As the main idea of the game is to drive the candy to Om Nom, the whole level thus revolves around these two elements. All other elements simply serve as additions to this pair, facilitating the route from one to the other. The problem is that the abilities don’t support but annihilate the candy. For example, most of the characters (Nommies) from Cut the Rope 2 can interact with both Om Nom and the candy and create a unique path between these two objects. But when any ability meets the candy: well, the journey that has only just begun simply ends because Om Nom eats his target. It means the abilities can’t interact with the key objects directly, unlike the other elements of the game do.

One step we took to cope with this was providing the abilities with as much influence as possible. For example, the bird was planned to be quite a passive ability yielding to the rest of environment so that it could be easily moved. But we had to add a contradicting feature of resistance to the phase in which the bird takes off just to give it a means of actively changing a level’s arrangement. The same holds true for the fish. There was some concern that it would be unclear to players that they could force their way through dynamic objects rather than be stopped by them as they would be by any other surface. But this resistance to the environment also created a few possibilities for indirect interactions between the ability and the key objects. It was quite valuable for level design and thus accepted.

Another way of enlivening interactions was the supporting elements. You may notice that they have a bigger role in Magic than the supports of Cut the Rope 2 had. They are introduced to the player as early as possible within a level pack. And although the abilities’ mechanics allowed us to save some hard-to-find space, the empty areas had to be filled with the supports most of the time.

The relations between the elements were often full of contradictions. But we fought for each one because the whole Cut the Rope gameplay is based on its elements’ interactions. A certain relation may only be used once or twice, but – level after level – such possibilities create a diverse game experience that would be much weaker if there were more restrictions in level design. The old problem of the Cut the Rope series is that increasing the complexity of level design diversity leads to technical inconsistency, which inevitably restricts that diversity in the future. So, during the development phase, we had to find a balance between making the gameplay flexible with the least amount of exсeptions and yet not to break everything down.

There was also some good news with interactions, though. The abilities being so demanding most of the time then relieved us of the problem of having no relations – at least with each other – as Om Nom cannot transform into two creatures at the same time. Not yet, anyway!

Except for the experience itself, there is one more important thing left since the development process. It’s inspiration. The more I worked on Cut the Rope: Magic, the more I realized how the initial gameplay was actually deep and flexible. You can take some basics out or add a twist and get a new and meaningful result. So I think the potential of the series is far from being exhausted!

Co-author: Irina Shvetsova, lead game designer for Cut the Rope: Magic. She also participated in the creation of every other game in the series by designing content updates for original Cut the Rope, Cut the Rope: Experiments, Cut the Rope: Time Travel and Cut the Rope 2.

Read more about:

Featured Blogs

About the Author

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like