Just an open discussion question, curious about others methodologies for level design. In this example I consider a character based action game. Could be a shooter or a melee combat game or a platformer. You may be some dialog sections or even cutscenes
.
My methodology so far has been to just sketch out story beats that I want to hit, gameplay encounters, and then place those in as landmarks and build the level from those as start points. Then play test and tune for pacing, difficulty, etc.
This is fine. Maybe it is as good as it gets. But I feel that there is a lot of inefficiency. It seems like no matter what I have to go through like three iterations with large overhaul before I get to where I want.
I wonder if thinking about the level more in terms of time chunks might be more helpful. And also as player attention chunks. So we might define a chunk of the level by how long it takes to get through and how mentally taxing it is.
With that in mind, I’d bet that big developers who have psychologist involved probably have some basic guidelines for how to manage the player attention cycle. I suppose much depends on the player and tons of other factors. I doubt that as a solo dev or tiny team we can do anything more than just play test and use our intuition. But still, if anybody is familiar with any ideas like this, maybe knows some vocabulary that might be helpful, or thinks about level design in a different way, I’d love to hear your experience.
This is to be expected, especially if you’re new to this kind of gameplay or if you are in the midst of developing a game but don’t have all the mechanics set in stone yet, and possible even other things like art, animations, audio and so on. You will often find reason to tweak or completely redo encounters or entire levels / areas while adding more content, or because you’ve become more experienced in what works well within that game.
A widely accepted best practice is that you should design the first levels / areas of a game last (or completely overhaul / redesign them). This is because you will have the most experience with the mechanics and gameplay at that point. And you want to make sure the first few minutes are the best possible experience for players all around.
If you’re interested in this kind of design thinking I’d recommend A Theory of Fun for Game Design. It’s a quick and inspiring read, with tremendous value distilled into it and great artwork to make the ideas really stick.
That’s a good idea!
For now I’ve been working on a vertical slice, and I chose to do the first level for that, which is kind of like a lengthy tutorial.
Perhaps it would have been better to do a random level from later in the game though. But its good chance I end up changing the first level significantly after vertical slice anyway. I suppose we might consider the vertical slice a trial run.
I think I read that book a few years ago, but I should revisit it now that most of my game development energy is actually going into design, rather than just technical matters.
Experience with mechanics comes from playtests. You can’t really have playtests, if your tutorial is missing. And if you want feedback on your story and your story starts at the turorial level, this is also a major issue.
I don’t really have a solution, just from my experience, there is no way to make the first levels at the end of the development - but it’s good to keep them at a greyboxing state or just very simple, so re-iterating over them costs as less time as possible.
Compulsion Loops: Using techniques like variable rewards and near misses to create addictive feedback loops that encourage players to keep playing in the hopes of winning.
Loss Aversion: Leveraging the psychological tendency of individuals to be more sensitive to losses than gains, leading players to chase losses and continue gambling to recoup losses.
Anchoring and Priming: Using initial wins or low-value rewards to anchor players to a specific expectation of winning, priming them to keep playing with the belief that they are “close” to another win.
Social Proof: Highlighting other players’ wins or achievements to create a sense of social validation and encourage users to emulate successful players.
FOMO (Fear of Missing Out): Creating a sense of urgency or exclusivity around limited-time offers or events to prompt players to engage and stay connected.
Availability Heuristic: Manipulating players’ perception of the likelihood of winning by displaying recent wins or highlighting the odds of winning without providing the full context.
Sunk Cost Fallacy: Encouraging players to continue gambling because they have already invested time or money into the app, even if the expected return is low.
Optimism Bias: Fostering the belief in players that they are luckier or have a higher chance of winning than others, which can lead to excessive gambling behavior.
Cognitive Dissonance: Influencing players to rationalize their continued gambling even when it might not be financially or emotionally beneficial.
Escapism: Promoting the use of gambling as a means of escape from stress, boredom, or real-life problems, making it a coping mechanism for some individuals.
Targeting Vulnerable Individuals: Using data analytics and profiling to target individuals who may be more susceptible to these psychological strategies, such as those with past gambling behaviors or financial difficulties.
Gambling vocab
I wonder if we have similar terms for games? And probably some variation across different genres?
So like, for a ton of mobile games, and loot games like Diablo, Borderlands, etc, a lot of these gambling techniques just map over 1 to 1.
But in other genres, these sort of tricks don’t really map, at least not directly. We still operate on a human but they have different expectations and same techniques can’t apply. But basically we have some sort of event that manipulates players attention somehow. Some will test the players focus for a time and either leave them feeling accomplished at the end, or anticipating the next encounter with uncertainty.
And we want to find the frequency to have these events happen so that player is in the zone where they are completely immersed in the game and compelled to come back to it after quitting.
There are types of games that I like to play which have other types of hooks that I sort of understand intuitively, but would be great to read about to. Some of my favorite games pretty much don’t have any obvious hooks at all, it just has satisfying gameplay that gives a satisfaction similar to what you get playing a sport… like you just enjoy the feeling of the movement and forever trying to get a little better at it. But the difficulty is such that you rarely ever completely win, but you often get close.
It seems like planning the level around time and then having these sorts of hooks, compulsion catalyst, whatever we want to call them, as landmarks might be better than what I’ve been doing which was just kind making up a rough plan, building it, testing it, then redoing it over a few times.
So my current idea is to not just note story events or gameplay encounters, but try to assign a length of time to each portion of the level. Because if that is the constant, I can figure out the other side of the equation more readily I think. But if we dont control for time I think we stand to lose more players from oversight in design.
If we assumed this was a good way to design, then the next question would be like, “well how long should a section of the level take. How long should a player grind before getting a reward? How long should they muck forward in dreadful anticipation? how often should the have to replay a section before achieving victory?”
that is all variable of course but if we at least have a common vocabulary then it is easier to share notes.
Also curious if there is anybody out there like me who might have enjoyed games like dark souls, but had a strong desire to play an alternate version where you just go through a level like the first ones but it last like 30 hours. Like moderate difficulty, no hard skill checks, an environment that isn’t too dark or grim, and you just have tons and tons of gameplay that is basically the same but just slight variations each time.
Like, is there anything like that out there? I’ve found very few games like that, almost everything these days is full of too much obvious gimmicks that end up giving empty rewards. Not that I am looking for a game recommendation to play, just curious if there might be some vocab to describe such games.
[/spoiler]
That sounds pretty normal. The intended outcomes of level design are human experiences. They’re pretty difficult to predict and have a huge number of variables, so an iterative approach is pretty much the only way I can think of to achieve goals apart from becoming some kind of savant.
I mean, sometimes you’ll get pretty close the first time, and with practice that might even become often, but if you’re making interesting experiences then at least some of them have to be new experiences, so there’s a necessary amount of unknown you’re dealing with there. Exploration and experimentation are the nature of the pursuit.
I think it depends a lot on what type of game you’re making. There are quire a few ways to “chunk” things, time is certainly an important one in many cases. In a game I’m currently working on we often chunk things by what new thing a player has had to figure out (as the game is about figuring out new things and combining them with old things).
I think a better way to describe it is to make the final version of your opening levels late in development, but also that it’s not to be taken overly literally. Our current version of our first level is heavily informed by bunch of stuff that wasn’t known until a lot of the other content was planned out. It’s the 3rd or 4th major revision, and it’s had at least that many minor revisions, and probably has more to come.
For the exact reasons you raised, we never expected to keep our earlier versions of the opening levels, but we made them anyway because we needed something in place to prep players so we could test other content. The stuff we learned from those placeholder levels was one of the things fed into the design of the current revision.
An “engagement loop” is a bit of terminology that applies to game design here. Similar to a “compulsion loop”, but typically used in hierarchies to represent everything from the high-level goal (Find the MacGuffin and use it to defeat the Evil Lord) down to low-level goals (get past the guarded bridge) to actions (sneaking / fighting / whatever). In multiplayer it often extends outside of any given match, e.g. leveling up, unlocking perks, cosmetics, etc.
When I’m designing levels I find it very useful to actively identify where the player is at each level of the engagement loop hierarchy at a given time, and what my intentions at each level are (e.g. challenge, motivate, rest, etc.) and to have some idea of how long / difficult each loop should be relative to the ones above / below it.
But, anyway, the best most addictive games don’t just find a frequency, they manipulate it. Back when I first learned about this I think World of Warcraft was the contemporary example, where certain loops started out being quite fast, but gently got stretched over time, so that players are making larger and larger commitments the more they play.
Thanks, great post as usual. This quoted part strikes me as an important thing I’m missing.
I have been trying to write down the “meta goal” for each section of the level but I started flaking on that because I didn’t have a good way to define it consistently.
I think I have a good way to diagram this out now:
The game could be broken down into a few cycles:
Meta game - the players perception of the game as a whole
New Game - what sort of goals and expectations the player has when starting a new cycle of the game
Level - a single level in the game
Level Beat - a portion of a level, composed of many recurring gameplay loops
Within each of these cycles, questions arise and eventually get answered:
Some questions may be answered very fast. Others may not be answered for awhile (like for a few minutes, or not until a later level, or not until a whole new game cycle)
Perfect classification of the cycle these questions categorize under isn’t so important… I think the important thing is that at any given moment, there should always be at least one outstanding question on most fronts. This should ensure that from a range of personality types, there is always some question begging to be answered. Having many outstanding questions could also be a problem as well. There is probably an optimal range, just as in a fiction story if you introduce too many characters or situations the reader is just going to give up.
So, a lot of gamers wont care about the story. So we lost that front with them. But they may be interested in testing build strategies. So if we make sure there is plenty of questions raised there that take 3+ game cycles to answer, then we know that we’ve got them fixed on that front. And for the sake of redundancy, I’ll try to ensure that before 1 question might possibly be answered, at least one more ought to be raised in the interim.
Some players might not care about story, or builds, but just want the core game loop to be satisfying. So as long as questions stay consistently raised there they should be satisfied, and of course there may be some cheap tricks to try and attack them from other angles as well. Like sexual tension, or tease of new goodies in the future.
So with this graphic helper I’ll be able to visualize where questions are raised and when they could possibly be answered. Then it should be possible to notice any gaps. It certainly isn’t a sure science but at least now I have some template to work from so I can be more consistent and feel more confident in decision making.
Thanks, that’s exactly what I needed to organize my thoughts about all this.
For us the level’s goal is easily derived from the context of where that level sits in the game, and the level’s broad design comes from breaking a way for players to achieve the goal into chunks. We don’t even write them down, partly because deriving them is that easy.
While mileage will vary from project to project, if figuring them out or writing them down for yourself is hard, or a point of friction, then I wonder if there’s a lack of clarity somewhere else in the design? If so then ironing that out may smooth this part.
yes, that is about right. I am partly doing this to try and find holes in my design, because I am iterating on that still.
So for instance, I’ve made some changes to how skill progression works, therefore I want to view it in broader context and see how it might effect decision making throughout.
What I call a “meta goal” for the player would be a goal that extends beyond a single playthrough. So for instance you might start out like, “this play through I’m only going to level stats X and Y and see if that is viable. If it is, I’ll try to take it to NG+5.”
or
“I’m going to do a luck only build, and see if I can finish a full run without leveling any offensive skills at all”
or
“I’m going to do some sort of challenge run as training for skill development, and then I’m going to try and beat the game on IMPOSSIBLE difficulty level.”
I call those meta goals because its something the player does to interact with the game at the broadest level. Like they recognize that it is a game and choose to play it a certain way with their own goals as driving force.
Versus something more direct in the level, like “this bad guy is trying to crush my skull and I need to dodge so I can keep my brain all in one place”
So this seems like a good way to summarize everything that happens in a level and be able to zoom out and view at a broader context as well. The tiny white button links to some “answers” cell elsewhere. This way I can easily see that if we propose some question at some point, where could it possibly be answered.
This should better allow me to iterate on the broadest aspects of the game design before the entire thing is finished.
A lot of that might be story / character stuff, but it could broader things as well. Like at some point we might introduce a special weapon, and then player can begin to think about the implications of that. New build strategies, etc. Being able to visualize it in broader context should allow for better pacing from the get-go and save some time play testing. Like it would be easier to see that too much stuff is front loaded, or too long a period without any new developments.
There is also timing and pacing considerations. On my first pass of level it had some great encounters but it goes too fast and difficulty curve is way off. So then I need to shuffle around the level a bit, extend some parts, shorten others. Being able to start with a desired time and work backwards from that I think should keep a tighter control on pacing and difficulty without winging it so much. And by reviewing the answers for a level should be able to understand the max extent of what player could reasonably be expected to know.
For a small game I’m sure this could all be held in head and done intuitively but I don’t think its possible for me as a solo developer with game of this scope. Just too much stuff to remember because I have to make art pipeline, code, etc. So this is a way to organize and make concrete the level/game design so when I return to it in future for more levels I can just jump straight into work.
Another important thing is that it can be difficult to define backstops. Like how do I know when the level is complete? I can just go with a gut feeling but those change constantly. So if I can view the level in a context of “how long does it take, what has player learned, what might have possibly intrigued them to continue?” then I can more readily say “the level accomplishes everything necessary, its finished”.
(this is all in context of a 3d action adventure game, btw)
If you’re allowing the player to make gameplay-changing customizations, it seems like that might compound the difficulty for you. Will you need to playtest all of these possibilities?
My skill up system is very simple. You select a deity during gameplay and all your kills go towards that active deity. This determines what passive skill upgrades you get.
So for the player it doesn’t majorly change how the game plays, just over time it can benefit playstyles. But it is not big differences like “magic or melee?” It’s just “do I want to run faster, or shoot faster? Or a little of both?”
So I think it should be manageable for me to test like that as I can just set the maxed stats directly and make sure a playthrough is not broken. The entire length of the game wont be such that I cannot play through it entirely a few times myself in one go.
Agreed, and they also span across more than one game, so I think they’re good examples of “meta goals” per your diagram. However, you’ve said that you’re trying to write down the meta goal for each section of the level, which seems like a mismatch to me? Per your diagram and examples, meta goals sit at a much higher level and should be the same for all sections of a given level.
Are you clear on your design goals / the player engagement strategies the “New Game Cycle” and “Level Cycle” parts of your stack? I’m not 100% clear on what they are from their names, so I’m assuming that “New Game Cycle” is when the player starts a new game from the start (but potentially with an existing character), and “Level Cycle” is each time the player starts a new level within the game.
What decisions is the player making at each of those levels of your engagement loop stack?
What design considerations are you building in to facilitate / support those decisions?
How do those design considerations interact up and down the stack?
Looking at your diagrams (now that I’m not on my phone) one thing that immediately comes to mind at the lower level of your diagram is: what is “non-combat”? At each level of the hierarchy the engagement loop is a loop. How does the player go around in that loop? I’d suggest drawing it out.
The other thing is that you’ve got it drawn in a question → answer kind of format. That’s useful, but also keep in mind that these are loops in which the player is performing activities. Can you draw a state diagram of what activities the player performs at each level of the stack?
E.g., in my contrived case we’ve got a dungeon crawler where, at the level-to-level loop, the player just plays a level, then spends their rewards to progress their character:
Inside the “Play Level” state, the player is exploring, finding enemies to fight and puzzles to solve. Sometimes they have to clear some enemies before they can solve a puzzle, but never the other way around, which is completely arbitrary but captured in this little sketch.
Can you draw something like this for each level of your stack? It’s ok if some of them are a single state that loops back on itself, that’s still a loop!
Just sloppy wording on my part with that. It’s correct that each beat in the level (beat is just what I call like an experience unit in the level, it could be a chunk of gameplay, or dialog, or exploration) doesn’t always have immediate correlation to any meta goals the player might be working towards.
What I had been trying to do is justify the reason for each beat existing. I mean in the beginning that’s easy, for example player needs to learn that you push X to do a backflip or whatever. Or firefight B goes after A because once you fought five enemies it is then natural to fight 8. But eventually while blocking out the level it just becomes a process of, “what could go here? This would look cool!” insert cool thingplay it in isolation, it’s pretty cool
But later after some rest when you redo it all through as a whole you realize the pacing / difficulty is off.
It seems that defining each beat in terms of linear difficulty progression and just going on gut feeling for each could be improved, and also having to replay the level (and eventually game) in full to get any handle on the larger picture is not very efficient.
As it is now, it feels like it is more possible for me to insert beats and consider them as they fully effect the players experience. Like in NG+5, what might this beat mean? Is this a firefight that just after a few playthroughs will be so annoying that you have to just run past it each time as the time/effort isn’t worth the skill points earned?
That is correct. New Game cycle is beginning an entirely new run, from Level 1 to Finish. It is similar somewhat to a Souls Game in that you carry-over stats but not equipment. There is not point to a NG+ cycle though if we have no incentives for it so it’s something I want to question for during development. “Am I providing proper incentives to make repeated playthroughs likely to be worthwhile?” (for some gamers, of course, not everybody)
And level cycle is replaying a level. It is a central HUB based game where you can go to levels in any order and replaying levels is a tactic for grinding up your passive skills. I believe such a design will make for good content-to-playtime ratio. Basically as a solo developer it is very difficult to be motivated to put much effort into a bazillion art assets if its something you know player only sees in passing for 2 seconds. But if they will likely spend a ton of time in a level such that they become very familiar with the place, then it’s easy to emotionally justify like, “okay, this rock is darned important!”
These are all good questions to ask. I think here you are just asking rhetorically. I am able to answer them, but in a few ways, not just one… because I’m not settled on the exact design yet. I have a few competing options that I feel like I can’t pick which is best just from paper planning so I am trying evaluate each as iterate on the level. So like, if it would be “roguelite style A”, during a playthrough I consider if the likely metagoals it would foster do a good job of encouraging replay value, if it might make different beats more or less interesting, and so on.
I had an initial plan for the meta game design (like how is death and checkpoints handled, how is player skill progression handled, etc), but after a bit of actually playing the game it started to feel like a bad fit. Bad fit meaning, in order for the design to really work, I’d have to expand scope of game.
So eventually I got to a point where it’s like, “okay the level of sophistication in gameplay code is good enough - gameplay is fun and I can easily see how to add more content to make plenty of variation on this core gameplay. So whats the optimal game design to squeeze the most juice from this so that I only need to generate content and iterate on refining the experience, rather than getting bogged down with technical problems?”
Sure, here is a go at that:
It’s not a bad model but it seems most useful at a broad level. What I mean is, if I want to look at the specifics in a level, like say a beat with some NPC dialog that advances the story somehow, this doesn’t really give me any insight into that.
So like if I wanted to know, what is the overall frequency of level 3 combat beats (e.g. moderate difficulty), or how long is average non-combat beats, or where is optimal place provide conclusions for this NPC’s questline - questions like that I think need a more tabular model.
Things I want to be able to do is A/B test like, “okay right now the average time for Level 3 combat beats is 5 minutes, and Level 5 combat is 20 minutes. What if reduce the contrast and bring to 10 and 15? Does that give us better flow state gaming experience, or does it reduce the apprehension of challenge areas such that player loses tension and thus disincentivizes some meta-goals?”
I think if its tabular based then I get a few benefits: I can first of all collect the data and summarize it, then I can easily find the beats to adjust, and lastly I can adjust the values and have it update in the levels (to some degree, may always be necessary to go in and do some manual changes in order to effect play time).
edit: One other thing that was floating around in mind for awhile - one problem with the loop model (or any model that is only operating at a high level but cannot drill down to the actual implementation) is that you could easily lie to yourself. What I mean is, say we have an arrow that returns us from “shop / loot” to “combat”. The arrow implies one thing leads to another, but it doesn’t tell us why or how.
So if player defeats five waves of enemies, does the looting state, how do we know they want to ride that arrow back to combat? Like, because I picked up loop, that does not make me want to use it, you know? There has to be some impetus to go from one state to another. So that’s why I try to think more in terms of question and answer, or intrigue and payoff.
Absolutely. It’s more for planning, and for visualising, than it is for detailed analysis of the levels once they’re made. I agree that spreadsheeting is better for that, and also for figuring out things anywhere it intersects with balancing.
The state / loop diagrams themselves are helpful to visualise and reason about the the set of activities the player is performing and how they relate to each other. For instance, in my earlier example diagram I represented the design decision that puzzles follow fights, but fights do not follow puzzles. If I added a conversation mechanic, how would I want that to interact with the other states? Etc. Which gives me a bunch of rules I’d apply while designing levels (and possibly build into functionality).
In old games it was often a literal mode switch. In modern games it’s really up to us as designers to figure that out.
It could be anything, but for me it’s typically one of two things:
A decision by the player to change what they’re doing. E.g. “I found a mob of enemies while exploring, blocking my progression. I can either fight them or sneak past them.” In the code there’s probably no difference between fight / explore / sneak, but at some point the player either decides to do something different (“I’m going to attack the goblins”) or is forced from one state into another (“The goblins saw me and are chasing me”) or actively avoid a state change (“I’m not going into that room because I don’t want to fight the goblins right now”). So they’re pretty “soft” state transitions.
A literal change in the game’s state. For instance, the level has finished and now the player is… looking at the world map? Or whatever. In older games it was pretty common for player decisions to require software mode switches, e.g. even today many JRPGs have fundamentally different explore and fight modes. These are often “hard” or explicit state transitions, but not always. For instance, once the player has defeated all the goblins they’re not in the combat state any more because there’s nothing to fight.
On one hand you’ve got decision points where they’re deciding which arrow to ride. I know the player wants to be able to fight enemies and sneak past them, so I facilitate both options. Theoretically, I “know” they wanted a fight because they chose to get into one.
But not everything is an active decision like that, which is ok. Broadly, we know that they want to ride the arrows in general because they keep playing the game. There’s kind of an implied transition out of every single state where “the player stops playing”, which they’ll do if it’s boring or frustrating or a shinier game comes along or whatnot. So approaches such as the question → answer strategy are definitely a useful way to generally maintain engagement outside of the active decisions our players make (which applies to basically any kind of media).
