Designing for single player

I, for one, is eagerly awaiting a long response from insta

I like to start out by doing a Layout Flowchart in Microsoft Visio, connecting each area where roughly the spaces would line up, and use a brief bullet point system to describe each area's visuals and rough events. Then I do a high level layout flowchart along a similar style but without the descriptions to give a rough idea of the layout. Then move on to an event layout, going into more details of the events of each space, how long should theoretically be spent in each area, etc.

To analyze the pacing, I like to assign ratings to each area ratings like in Mark Davies' Pacing Analysis (link: http://%7boption%7d), ranking Movement Impetus, Threat, Tension, and Tempo from 1 (very low) to 5 (very high). Then add those those values up to measure player stress, and plot out an Excel graph with time in seconds as the X-axis, and the Player Stress measurement on the Y-axis. I'm a huge data nerd though, so that might not be for everyone.

Once that's done, I'll create the actual layout in Photoshop, marking all key points of interest, like the player start, critical player path, enemy spawns, area labels to match up with the flow charts, etc.

Then it's on to the prototyping phase in the editor.

Note: I didn't put that much planning into the maps I posted on here, but I am doing so on the current team project I'm on.

Writing up documents and charts and spreadsheets might be the most professional way, but it's certainly the least fun.

If you're making this for yourself, just draw a loose sketch and start building off that.

I mean, I was watching thisvideo about how Sid Meier made a game in 48 hours -- he doesn't mess with these spreadsheets and design documents and stuff. Rather, he prototyped an interaction (say, shooting zombies) and started exploring variations on that to make it more interesting.

I won't say I'm an expert at designing SP levels, insta is probably wayyyy better than me, but here's my way of designing SP levels.

I begin with writing stuff on paper, like the main purposes of the singleplayer level, the general feeling, some puzzle ideas and I sketch some architectural details. Later on I begin to do various sketches like layout prototypes (that always end up changing anyway ), puzzles, game phases (like anguish/ambient phases and combat phases). I also write down my inspirations for this particular level, that will help me later if I forget things.

When I have a solid base, I begin to write the synopsis, I flesh out characters when I want to introduce some (it is the case with E.Y.E), I detail the puzzles and phases and I add new ideas.

Then, and only after this, I open the editor and start the real work. I always thought and still think SP levels should be built a bit like MP levels. To explain it further, I'd just say that when I design a SP level, I always put one or more paths to get out, so you'll never get stuck. Of course there are some areas when the player needs to take an unique path, but they are very rare. After I get prototypes of puzzles (if it has some, of course, it's been a while since I designed puzzles, E.Y.E doesn't have a lot of them), playable areas, combat phases and ambient sections, I begin to add more stuff and when I think the level is playable after some playtests by myself, I give it to some trusted people whose feedback is great, and then I rework stuff.

My work on E.Y.E SP levels is more about designing big and atmospheric levels, since I don't really put NPCs and stuff (someone else does and this dude is awesome), but I always start imagining and writing stuff down like I said at the beginning. That's how I roll.

Oh and sometimes, but rarely, I do something and see what happens. If I find it good, I keep it. Otherwise I rework it, or I ditch it.

It is of course very individual which way you "plan" and build levels, but I'll try and write down how I usually try to work at home.

I like writing down stuff for my non profesional stuff, but trying to keep it really basic.

These small documents is very good when you get back to a level after a while, as simple reminders.

I usually decide the "doors" first in a very basic document. These Doors are the end of events/puzzles, and will serve as points which the player must reach in order to progress, be it an actual door, a lift, an enemy which must be killed with a special weapon etc.

When I have all my Doors decided to support progression from start to end of a level, then I start thinking of the puzzles/events which the player must solve to get them. This gives me a frame to work within, I will not change the doors, but it also gives me a lot of freedom inside the frame when iterating the actual gameplay/puzzle/combat which gets the player there.

The door stays the same, but the way to get the key can be iterated a hundred times. This helps me to get the feeling of progression and pacing in early prototypes.

I usually try not to draw a layout before this, I rather do some iterations in the game first, with the main events, and then if needed, for me myself or someone I'm working with, I try and do an overview map where I do some tweaks/big changes, before doing them in the editor.

This is a part of the progression-tree me and Peris did for a puzzle-level set on some cool planet far away in space.

Part 1

Rocket’s tale

Mission 3 – Search the perimeter

a.Find energy source (Green Cube)

i.Find a way to disable energy field to gain access to the cave.

ii.Disable first energy emitter. (activate a platform that the player can jump onto, in order to reach the button)

iii.Turn of second energy field.

iv.Disable second and third energy emitters.

v.Pick up Cube

Mission 3 Completed

Mission 4 – Activate the bridge

a.Complete the bridge

i.Initiate bridge system (1 button)

ii.Insert Cube in socket

b.Pick up Cube on the other side of the bridge

Mission 4 Completed

That helps a lot, we can place the objects where we want them, and always have the level playable from start to finish. Then we can tweak the actual gameplay when the player is aiming to collect said keys.

Here in the level, it is important to show the player the bridge before giving telling him to find the energy source, or it will feel like a railshooter without shooting. But that is the iterative process, and up to how the level is built in geometry/lighting i.e. directing the player.

On another note, the level hasn't been completed, so maybe this way isn't the correct one for me either

Edit:

For singleplayer another thing which is very helpful during the development. Watch people play your level, if possible. Ask people you know to come over and test it. This is very valuable together with e-friends writing down feedback after testing a beta or whatever. It is easier for you to see what works/doesn't work. And do not help them in anyway.

If they get stuck for too long/frustrated it is always up to you as a designer to fix this, and never their fault because they didn't get it!

I read a very helpful article on this very subject on gamasutra.

I think you need a diegetic narrative. What emotions are you aiming for?

This is a very promising thread, keep it up guys =)

I agree with Mino, great read so far!

I'm actually designing a ep2 solo map too so I'll probably take part to this discussion.

For multiplayer levels it is usually the flow and the layout which is the most important thing and it is therefore usually also what one starts out with getting right. For SP however, it is imo just as much the events/puzzles/whatever that happens along all the key locations in a game. The interesting part about the design of these key locations is that it is an area where one has to think in terms of story and gameplay while not so much layout.

This means splitting your level into key locations and glue/corridors in between. This makes it useful at least for me to design SP maps as two parallel processes: A) Layout and B) Key locations. Giving these areas individual focus will usually increase the final quality of each. With a number of quality key areas designed, one can then move them around in a very flexible way and connect them with varying amount of glue depending on what the layout/flow dictates.

The hardest part about SP is not designing the actual map, it's trying to figure out what the game is your making and how that fits into designing a level. If your modding something like HL2 the scary bit is done, you know what you have to work with and what previously worked. It's an entirly different ball game when you don't have those pieces but instead have to request them and prove your theories

So, cut out all the risks and your left with endless possibilities to make a HL2 SP map and it all starts with a little story and theme. The rest is pacing, variety and balance. That only happens when you start to build something and play it.

interestingly i enjoy the balancing the most. which pieces fit where, and exactly how much of each piece is just right and not too much... ahh

Me being a jerk aside. I think the most important thing you need to look out for is pacing. If you know the dramatic structure, this should be applicable to pretty much everything: individual chapters, the chapter plan itself, enemy composition, weapon distribution etc. Although, most people don't use this kind of structure anymore, you want to build, build, dip, climax, drop (but don't reset).

When designing your levels out you want to make sure they all build to something and you have something in mind that's going to be the pay off. When I used to design single player levels I always used to just take it an area at a time, if anything amazing happened it was something that came to me when designing the area - but it certainly didn't fit any kind of pacing. You're actually at a disadvantage here because all your reveals and climatic moments are going to be using assets HL:EP2 used already so a weapon or enemy reveal doesn't really work unless you use them in a fresh scenario or add your own content.

theories aside, it ultimately comes down to playtests to properly tweak your level(s). the smaller sections you can release for test, the better you can adjust each section to fit with the next and previous. after you've done a section, you could essentially stop working on it and release it to your friends for a test. while they test it (assuming you won't be there to watch or take notes etc.), you can work on the next section before you get feedback from them. since you're now working on the next section, you can take the chance and correct the things through the feedback you get from the previous section; they'll give you something extra overall to work with.

but like evert said, if you can be there to watch them or take notes, tweaking will be much easier for you as you can directly see what they are having trouble with/are frustrated about/etc.

EDIT: i actually remember i once wrote a document on how puzzles worked for my portal level. while the theory isn't flawless, it still gives some insight into puzzle creation. i'll upload it and link it here.

You need to make something before you can iterate it with playtests. The "theory" is all valid as long as it comes with something practical.

Quote from Taylor

You need to make something before you can iterate it with playtests. The "theory" is all valid as long as it comes with something practical.

it was assumed that at the testing stage you already have something done, obviously. my point was to test sooner in order to get in the early build "feel" so you can build and polish on top of that.

The way I made HL2:Awakening, I just had some general idea's for landmark locations and a rough story.

Then winged it pretty much all together as I went forward and filled in the blanks:

- Filling in the puzzles as I made them up during playtests.

- Connecting the levels.

- Add Enemies where I see fit.

- Even using one of my multiplayer maps to save time.

- Lots of testing and iterations.

And eventually cutting some planned levels because it was taking to long to get everything done

The first thing I figure out is the kind of game I'm designing the level. Creating an additional level for one game is one thing, creating a level for a game being made at the same time as your level is a whole different thing.

My modding experience is only for MP levels, but the approach is exactly identical because it applies for everything: I figure out the strengths and weaknesses of the game in its current form and try to think of variations of the formula and ways to provide a different vibe to the whole thing. It's risky and harder to do properly than a simple rinse and repeat of the proven concept, but that is the motivation I need to finish the work in the end.

Once I have found that idea, I try and come up with top down layouts that could help provide that experience, but as it turns out I quickly hammer them out in Source to get a proper feel for them and don't look back on paper design. That lack of actual planning and focus is detrimental to the cohesion of the entire level, but I find that it's more exciting for personal projects to try multiple things at once. The downside is that you have to be ready to redo everything multiple times, but that's half the fun.

Once the basic shell is done, I usually have a playtest asap. Try and find out how common my own experience of the level is, and how well I carried over the gameplay I was going for. And if that's positive, I just go full on with the design, making it pretty etc.

When making games at work however, it's an entirely different thing. My experience is mainly in production phases of AAA SP projects, so game design has to be followed instead of experienced against. The twist to make interesting levels is to introduce new mechanics or rythms to the existing formula by relying on LD tricks alone instead of asking for brand new gameplay mechanics no one ever has the time or will to try out. In a platforming game, this can be achieved in the rythm you ask from the player (speed, traps, size of platforms, etc). In AC2, the gameplay mechanic was mine to toy with so that was even more exciting to work on. In Crysis 2 right now, I am also using the existing concept and turn it on its head a bit to drive different emotions and gameplay experience. Environment can be your best friend to achieve that, as well as story twists, but that should obviously be more planned with the story writer ahead of making the level.

If I had to put the different processes down in a bullet point list it would go something like this:

1) Study of game design, strengths and weaknesses

2) Brainstorming of different twists to add in

3) 15 minutes layout drawing session

4) quick hash in a game engine

5) playtest, rince and repeat until formula is found

6) go as far in that direction as you can

Ehm.

Make a list of fun gameplay ideas. Then plan these around the setting and pacing.

Then create!