In the first part of this three-part series, we talked about “level creation cycles” and outlined a six-phase approach for building them. We discussed concepting, internal testing and feedback loops. We talked about usability testing and balancing, and explored the virtues of automated tools. And we concluded with some thoughts regarding going live and further tweaking. In this part, we’re going to talk about common issues and goals.
Before you begin building many levels, you will likely run into a few issues such as how design is communicated, how content releases will be planned and technical obstacles that may arise. Such issues are often addressed during prototyping or early development, but sometimes they aren’t. Sometimes they linger well into production and can become a roadblock for good level and content creation. Regardless of whether they are solved quickly or not, it’s important that level designers be aware of these issues before real production begins, and plan to accommodate them. Trust us: trying to fix a level design process when it’s already on fire is a horrible task that we wouldn’t wish on anyone. Planning is everything.
The main issues that you will likely encounter are:
- Feedback cycles
- Release pipelines
- Progression pacing
- Development readiness
- Retention goals
Design teams are often split into sub-groups based on their sub-discipline. A common split exists between game and level designers, for example, but sometimes there are further divisions of content, narrative, system or economy designers. Design is usually a shared vision as a result, one that requires extensive communication and collaboration to be realized. All groups must work together to achieve the desired user experience, game feel, progression and difficulty. But it’s very easy for them to fall out of sync.
Disconnects often arise over time, usually because they go unnoticed. Sometimes design teams fall out of sync because they were hired at different times and have grown used to working on their part of the game in certain ways. Sometimes they work on such different parts of the game that they don’t naturally have much contact with each other. Sometimes the issue is to do with location, for example level designers building content in one office and systems designers balancing economies in another. And sometimes the problem is one of perceived pecking order, where one type of designer, or one person, is considered “the boss”, such as a game designer who routinely ignores level designers’ needs (or vice versa).
None of these disconnects are productive, and sometimes they even become actively disruptive. Good teamwork and structure are essential as a result, and that means a good feedback cycle should be mandatory.
“Feedback cycle” is a fancy way of saying that designers of all types should regularly meet and play each other’s work. As levels are deployed, game designers should be testing them. As economic balance is updated, level designers should be trying the new balance against their existing levels to see if it fits. If a game mechanic is tweaked, all designers should be examining its impact. All opinions on quality should be heard and all worries about integration into the main game should be aired. (All with professional respect).
Feedback cycles should be very regular, as this serves iteration. Try to ensure that there is always time set aside in the production schedule for feedback between designers and stick to it. For example you could create a regular Feedback Friday event on the calendar, where team members play each other’s work and then meet to discuss issues.
Always work to ensure that your feedback cycle is about evaluating work in progress, to encourage team members to submit their materials rather than be protective of finished products. (It’s generally a bad idea to allow a designer to disappear “into the cave” to work on levels or systems for long periods of time with no feedback.) Encourage objective assessments rather than opinions, and constructive feedback rather than criticism. Feedback should always be in service of building others’ work up rather than tearing it down.
Designing levels can be like running a busy restaurant, not just about making one perfect dish but figuring out how to deploy thirty dishes for a hungry audience and yet maintain a high bar. It’s about creating a release process that pushes content of a consistent quantity and quality.
This requirement for consistency is especially important for mobile games. Many mobile games need a lot of level content because they’re generally less difficult to play than games on other platforms. Players often burn through new content faster than you think they will, and so if there are long gaps between one content release and another, there is a strong risk of churn: Players who believe they’ve maxed out their enjoyment of a game tend to stop playing, and it’s hard to reacquire them later.
So as a beginning step, it’s always good to have more than one level designer on a team to be able to serve the need for content, as this reduces risk to deployment (quantity). It’s also good to have a clear target in mind for the amount of content you intend to deploy. On a puzzle game, for example, releasing 20 levels per week is a good target as this provides 5 hours of play to most players.
You need to think about how your level creation cycle will serve that need while maintaining quality. Do you assign a team lead to vet for quality and guard the release schedule, for example, like a head chef in a restaurant? That can sometimes be good or bad, but is very dependent on that one individual and can be a cause of burnout. Another option is to defer responsibility to the team, where each designer plays the other’s work. However be careful not to overly systematize this part of the process (such as with grading or other objective assessments) as doing so often breeds disconnection.
No release pipeline ever gets it right the first time, by the way, but with some adjustments they tend to achieve a regular cadence that works both for the team and the audience. A key consideration is whether to commit to a cycle based on time or volume. Do you guarantee to release every Thursday with whatever levels are ready? Or do you guarantee release once 20 good levels are ready? Generally you’ll need to pick one philosophy or the other, as this will form the basis of your audience’s expectations and affect how your pipeline works.
A further consideration is how progression itself paces, meaning the difficulty of levels, the curve that the game follows and when or how it increases or decreases. For example if the game designers invent a new object that clears rows of a puzzle, that has considerable knock-on effects to the design of all future puzzles. It fundamentally changes how the players approach the game, and therefore its difficulty. With a single change like this, many puzzles that would have previously been very difficult might suddenly become very easy.
In order to map the pace of progression, many teams aim for a “saw curve”, where difficulty raises throughout play in a series of peaks and valleys. A boss level, for example, is often a peak. On the other hand the introduction of a new mechanic is often a good time for a valley, an easy level or two that allows for a learning phase. Our row-clearing object, for example, should come with a couple of easy levels that let players get the hang of it before ramping up the difficulty once more.
It’s also generally good practice to push game designers to deliver clearly defined and detailed documentation that describes content overview and distribution. This kind of material helps level designers to plan ahead, to anticipate impacts and craft saw curves that will help design changes shine. Such documentation should include all available information on game progression, new obstacles and mechanics and at which level each of these is intended to be introduced. It also helps if level designers can get access to prototypes and early builds of mechanics to see how they will likely behave, and give feedback on whether they might run into unforeseen problems.
The clearer the overall game progression and the more that level designers can anticipate its consequences, the better resulting levels will be.
One other thing: Progression pacing can also have significant consequences on release timing. For example level designers might need more time to work with a significant game design change in order to start creating great quality levels, and so sticking to a weekly release schedule might be impractical if quality is to be maintained. It’s also possible that a big change might become a significant marketing event, such as running a new ad campaign for a cool mechanic, or even getting some media coverage. That could slow down the release schedule or increase the demand for great quality levels, both of which impact the level design process.
Pre-release, many games are not ready. In some cases this means that a few features take a development team longer to deliver than anticipated. In others they’re building the rocket while going to space by trying to create an engine, tool and game all in one simultaneous push. It’s more common than you might think, and a regular source of trouble for level designers. It’s extremely difficult to create a level for a mechanic that doesn’t yet work, for example, or for an obstacle that has yet to be implemented.
Obviously this is not ideal and something that level designers should push against. Development of key objects and systems should always be completed and tested before a new level is created using them. Artists and programmers should always finish a new piece of content to at least a functional standard before level designers include it in their levels. Otherwise level work will end up having to be redone.
The same applies to tools. Just as mechanics and systems may not yet be ready, many games are hampered by the need to build required tools. Crafting a level without a comprehensive editor can be very painful, for example, as can trying to define a set of KPIs without the requisite analytics hooks in place to test if they actually work. A comprehensive editor (or similar tool) that offers a playable version of the game is always best to have, because it allows you to directly test your levels on a device and get a first hands-on impression of what works and what doesn’t. Whether that’s using an in-house tool or a commercial engine like Unity or Unreal, working tools make level designers work five times faster than broken tools, and immeasurably aid the release pipeline.
If readiness remains an issue, however, there are two things that level designers can productively do. The first is to create a plan for content that will probably work when tools, objects and other items are ready, and to make sure that that plan is detailed and surfaced to the game’s producers so they understand likely impacts of further delay.
The second is to work on prototype levels, meaning a few basic levels that explore what working objects and tools in the game actually do. Level designers should avoid moving into full production at this point (if possible) as that will create compound problems down the road, but actively working to build demonstration levels and other support materials is usually good. Such demos and materials really help engineers and other team members to understand level designer needs. If the level design team is very clear about its requirements and can demonstrate prototypes that show them in action, everyone knows what to aim for.
It’s also important to anticipate the key performance indicators (KPIs) that you will likely need to track the impact of your levels. This is especially important for considering how the live phase of deployment and rebalancing will work (as we discussed in the previous article). Here are some KPIs to consider, but you’ll also want to think about unique KPIs for your game:
- Win and fail rates
- Number of moves left (if applicable) before a level is lost
- Percentage of level objectives completed (won or lost)
Knowing this kind of information will help you empirically make decisions to tweak your levels, such as modifying layout, cutting or enhancing obstacles, adjusting available moves or spawn rates, reframing level goals and much more.
Besides meeting all technical requirements, it’s good to set some general design goals as a reliable foundation for level production. Design goals can be a kind of yardstick against which to measure level designs, to see whether the game takes shape as expected.
We generally recommend trying to tie your design goals to realizable KPIs where possible, including all important activity, but especially those that concern retention. As mentioned above players often have a hunger for new content, and so it’s important to keep supplying them with new and fun gameplay experiences to explore. They will only come back (retention) as long as a game is interesting to them, and this is especially true for so-called “most valuable” players. It’s the job of the level designer to keep serving those slices of interestingness to retain players.
New level releases should increase retention and keep players motivated, always enhancing the game experience. Pay attention to those awesome players who might have reached the end of content and are waiting for more. Offer new gameplay, obstacle combinations and visually appealing content. But remember that retention strategies are not just about increasing difficulty. In fact excess difficulty can drive players away. If players feel they cannot beat a level because too much is going on, they’ll leave. Similarly if they do not feel skilled enough to beat the level, or the pre-set win strategy is too linear, or too dependent on luck, they’ll leave.
Great level design can feel like walking a tightrope, where too much or too little of anything one thing can upset the balance of the game and cause it to fail. Try to always keep a sense of balance. Slowly ramp up the difficulty curve with proper tutorials and regular relief phases. Make sure that you’re always following this classic loop:
- Learning/relief levels
- Build-up levels
- Climax or boss level
- Goto 1
And most importantly: A level should always feel beatable without using boosters or extra moves. If this is not possible for the player, if they do not feel they can have enough moves to master a level, or otherwise have no faith that they can succeed, they will churn.