I find it very hard to design levels to be challenging. Once Twice Thrice, Dweep and Fitznik are among some excellent examples of great level design work. My question is, do you guys work with level designers? Or do you think of these levels on your own? Finally, if you do work with level designers, how much percent of your royalties are you usually paying? Thanks.

The Levels for Fitznik are largely the work of myself and two friends. A few other people made a couple of levels each. I did the largest amount myself.

Pretty much everone doing levels didn't expect to get paid, but once I started getting income I paid them a set amount per level. They were pleasently surprised.

The problem with level design is that it leaves our brains very drained of ideas. I find my limit is about 15 levels before I run out. During the original develoment I managed to make a good amount by having a six month gap between making levels while I was working on other aspects of the game.

Pretty much everyone was having the same problem. Since I am having the same problem with making levels for Fitznik 2, I'm thinking of going to Student Job search and seeing if I can get a bunch of students to do a few levels each. The problem with that is I need people who have the right idea about gameplay. While I was making the original Fitznik I had one person offer to make levels and he would make levels that were a lot of work but very obvious. The best Fitznik levels are the other way around.

Ideally good levels would have entirely new tricks. One of the last Fitznik levels to be designd involved placing a bomb and while the bomb fuse was burning Fitz had to use it as cover to hide from a snake and get behind a rock. It was designed by a friend and took me ages to figure out even though I had played some 60 odd levels by then.

I would actually offer the level designing work here but Paying US$ would make it seem hardly worth anyone's time. But hey, if anyone wants to work for peanuts, drop me a line :-). [Do we have a help wanted forum here? I should go look.]

Yes, that's a good idea, I'll ask a copule of friends to help me out. If that doesn't work, then I'll try and see if there are any designers on gamedev.net forums. You are right, 15 levels is about the barrier before you start running out of ideas. It's a pitty we only use 10% of our brain:)

Originally posted by Mman
You are right, 15 levels is about the barrier before you start running out of ideas.

Yes, that sounds about right. For Miko & Molly I think my first 15 were probably the easiest to make. After that it got really tough, and some of them started to seem a bit less inspired. I still think the very first level I made is the best, though a few of the last ones I made do rival it.

Making 45 levels in total was very tough. However, now that it has been several months since the last level I designed, I have at least half a dozen ideas floating in my head without even really trying to design any. If you can, I suggest Lerc's idea of designing half of them early in the game, and then coming back and designing the rest later. Of course, if you can get a second brain to help you out that would be even better.

Another idea is to do something along the Duck Tiles route. Earlier this year (or maybe it was last year...the year seems to have gone by quick) gamedev had a contest designing levels for the game Duck Tiles. There were prizes for the winning levels. While I didn't see any clear explanation, I assumed the purpose of the contest was for the author to get someone else to design some top notch levels that they could package into a sellable game.

I did all the levels in Once Twice Thrice. The next time I do a level-based puzzle game, I'm going to definately get some help with level design.

I'd be much more likely to pay a flat fee per level than a cut of the profits. Its easy to find folks without programming or artistic talent who want to be a part of the project and have played enough games to understand what makes a challenging puzzle. They should be thrilled just to have their hand in a proffessional project, you shouldn't have to sign over a share of the profits to them.

I agree with what everyone else has said. The first few are easy, then you probably need to get some help to keep things fresh.

For Dweep I personally created the original 30 levels, 1 hidden level, the 5 bonus levels, 20 expansion pack levels, and 1 custom level, so that's 57 levels total. Our artist Ryan created the 20 levels for expansion pack 2, and dozens of different players created 76 more custom levels (now included with Dweep Gold).

Level design was a challenge to be sure, but I focused first on developing a rich set of game objects that would give me lots of design flexibility. Dweep's levels are all single-screen, 16x10 tiles, so actually laying out the levels is trivially easy and only takes a few minutes. The hard part is designing the puzzles to be the right level of challenge.

One thing I did that helped with the original 30 levels was to pace myself. Level 1 uses only lasers and mirrors. Level 2 adds wrenches. Level 3 introduced placeable lasers. Level 4 adds bombs. And so on. It's not until somewhere around level 15-20 that all game objects have been introduced, and then I start combining them in different ways.

Before I started, I mapped out a basic plan for the first 30 levels, just setting a general goal for what I wanted to do with each level, such as, "This level should be around a 7 out of 10 on challenge, and it should focus on using fans, heat plates, and water buckets."

Some levels took 3 full days of solid work to design and tweak. Others took only 20 minutes (and these were some of the more complicated-looking ones). A few times I would wake up from a dream or be out for a long run along the beach, and suddenly the whole layout of a level would pop into my head, fully formed. All I had to do was go to the computer and input it, and it played perfectly the first time. I used my written level plan as a guide, but I was flexible in being able to fit inspired ideas into the game as they came up.

During the time when I did level design, I did little else. I would eat, sleep, and dream Dweep levels. Ideas were constantly swirling in my head. Even while I did other things, my subsconscious was still working on levels.

I spent a lot of thinking about what the player would be thinking at each point during a level, trying to make the game challenging by making the obvious path the wrong one. I thought of level design as something of a cat and mouse game. First I would usually map out the solution path that the player would have to take to reach the goal. Then I would obfuscate it by adding subgoals to collect needed tools and laying traps to mislead the player (such as items you shouldn't pick up).

I really enjoyed doing the level design. It was challenging, but I still felt that I had an abundance of creativity left when I was done. The interesting thing is that when Ryan created the 20 expansion pack 2 levels, I was finally able to play the game for the first time (i.e. feeling the challenge of playing a level I didn't know how to solve). And that was a real treat.

So I think the main reason my experience was so positive was the rich set of tools in the initial design. Most objects in Dweep have multiple functions. For instance, a water bucket can make Dweep wet. A wet Dweep can then cross through a laser beam without frying or pass over a heat plate without floating. A water bucket can also bring a floating Dweep back down to earth. If I had given water buckets just one function, it would have been harder to design good levels because when the player sees a water bucket, the place to use it would be more obvious. What gives the designer more flexibility also gives the player more challenge. For instance, if I place a water bucket on the level, the player has to figure out what to do with it -- should it be used to cross a heat plate, cross a laser, or bring down a floating Dweep? If the player sees a hammer, should it be used to destroy a laser, destroy a fan, bring down a floating Dweep, or free a frozen Dweep? And if it's the latter, when Dweep becomes unfrozen, he remains wet, so where might you use the wet Dweep? I believe this flexible tool set is the main reason I was able to design an abundance of interesting levels.

The flip side of a very flexible tool set is that players can sometimes find shortcuts that use the tools in a way you didn't anticipate. I actually chose to see this as a benefit, so we documented multiple solutions to certain levels. For instance, level 13 has three different solutions documented, and there are actually several more that we haven't documented:
http://www.dexterity.com/dweep/dweep-hints/dweep-solution-level-13.htm

By the way, one thing I did a couple years ago was create a level design tips page for Dweep:
http://www.dexterity.com/dweep/dweep-level-design.htm

The page was geared towards helping players make better levels with the game's level editor, so most of the ideas are Dweep-specific, but perhaps some of you might find the more general level design tips helpful....

I've done all of my level design so far on paper only. I'm planning on introducing new objects as the game progresses, similar to Dweep, because I think this gives the player new things to think about and gives your game new dynamics over time. It makes your game easier to learn, and exciting to keep playing. However, I'm probably going to introduce new objects with short training levels that illustrate the purpose of the new object. These levels will have only one-way through, and no dead-ends. And they'll be very very short, possibly with explanatory text. I won't count them with the normal levels, and they won't affect score, but I can market them as a bonus (and not only that, includes 20 training levels!).

What I've seen so far with my levels is I can either design the level trying to exemplify a principle (if you push this object into that one, you won't be able to get it out later), or I can lay down some random objects and obstacles, and then work from there. The latter approach works well for me; it's a repetitive cycle of asking yourself how would I solve this puzzle and how can I make that more challenging? So it starts with the player takes a direct route to the exit. Using the existing objects I dumped around, I add some obstacles to create a different, round-about path to the exit. But what else might the player try? What if the player did it in a different order, bypassing an obstacle? I put in more obstacles and objects to force the player down the intended path. Then I look at it again and see if it's too straight-forward; does the level give you pause before committing to action? What prevents them from seeing the solution immediately? That's when I add in red-herrings, and these are fun. These are obstacles and objects and a lack thereof placed near the intended path. A good number of red herrings seems to "fill" the level out, give it meat. A more direct route is straight to the exit, so provide a seeming path that way, but oh no player, you've blocked yourself in. As I add herrings, I begin the process again of asking what might the player try, what if they changed the order. At some point I feel pretty satisfied that the intended path is the only path, that this path is not immediately discernable, and the player will have fun trying to detect my traps before commiting themselves to a dead-end.

I find this process very tricky on paper, because it requires a lot of edits. I'm looking forward to my first prototype, where I'll be able to lay down some levels quicker and get a better feel for the gameplay value of each of my objects. I can see why others have said after designing 15 levels they're drained. :D I'm still at the early stages, and I can see this is going to take a lot of effort. Most of my designs so far either illustrate the versatility of some objects, or demonstrate the uselessness of others. Some ideas for objects seem great on paper but I can't seem to fit them cohesively into a level. And that's when the gardening mantra kicks in and one of my objects makes a permanent visit to the Home for Ideas that Seemed Like A Good Idea At The Time.

Originally posted by Dexterity

So I think the main reason my experience was so positive was the rich set of tools in the initial design. Most objects in Dweep have multiple functions. For instance, a water bucket can make Dweep wet. A wet Dweep can then cross through a laser beam without frying or pass over a heat plate without floating. A water bucket can also bring a floating Dweep back down to earth. If I had given water buckets just one function, it would have been harder to design good levels because when the player sees a water bucket, the place to use it would be more obvious. What gives the designer more flexibility also gives the player more challenge. For instance, if I place a water bucket on the level, the player has to figure out what to do with it -- should it be used to cross a heat plate, cross a laser, or bring down a floating Dweep? If the player sees a hammer, should it be used to destroy a laser, destroy a fan, bring down a floating Dweep, or free a frozen Dweep? And if it's the latter, when Dweep becomes unfrozen, he remains wet, so where might you use the wet Dweep? I believe this flexible tool set is the main reason I was able to design an abundance of interesting levels.
[/url]

Very interesting, I think thats it! I need to spice up my levels to be challenging. Use the chain reaction method to make palyers think ahead. Thanks for the tips! I already got a friend who is interested in helping me out with some levels. The downside to my game is that I can't include a level editor because my levels are not tile based and they scroll like in Sonic.

you should always have some form of level editor... otherwise you are going to go insane in a very short time.

Well I DO have a level editor, but it was designed by me for me, and not too many people will find it useful or easy to design levels with it:) That's why I have to make my levels excellent once and for all.

My original level editor for Dweep was just Notepad. Levels were simply text files with 16x10 characters. I later added some editing capabilities to the game itself, but I didn't intend to release a level editor for the pubic.

But after the second expansion pack, so many players were asking for a level editor, that I finally decided to release one and packaged the editor, the original game, and both expansion packs together into Dweep Gold. Programming a nice interface for the editor was actually pretty easy.

I find a good level editor is a must. I used to do levels by hand, either using text editors or (egad) long lines of hardcoded data, but no more.

As for level design, I often start with a very tough level, then work my way backwards and ask the question "what skills must the player have learned to have a fair chance at this one". For example one of the first levels in Wonderland

OUT NOW!!! GET YOUR FREE DEMO NOW!!! ORDER NOW!!!! ORDER TWO COPIES!!!! ORDER MANY MORE!!!!!

... whoa, sorry, where did that come from <g>, anyways, one of the first levels in Wonderland had the player being "trapped" in a teleporter, which had to be disabled. This was actually Level #75 (of 85) in the final game, but one of the earliest I built. Then I went backwards, and designed smaller and simpler levels that introduced teleporters, then "how teleporters not work", then how one can disable a teleporter by knowing "how teleporters not work", etc.

A second way to design levels for me is to pick a particular theme. E.g. an underground volcano. What kind of stuff would you find there? Well, Lava. How does Lava interact with your existing gameplay elements? What kind of puzzles can be built around those interactions, etc, etc.

If you happen to have a copy of LucasArts "Pit Droids", they included a nice little two page article on how to design good puzzle levels. The game itself was pretty good too, iirc.

Sometimes the most difficult thing is to be objective and determine how hard your levels actually are. When I made levels for Pharaohs' Curse sometimes I would think a level was too easy. When you are the creator of a level the solution can be so obvious to you that you think it might not be challenging enough. I've found this is not the case. All the levels were tweaked many times over before we even had QA. After that they were changed even more. It's good to have an additional designer or at least someone who can test them and give you feedback. The best thing is to just push yourself and get some layouts going. Ideas for tweaking and changing come easier when you can see something on the screen.

It's 100% impossible to predict how challenging levels are, when you create them yourself.

On top of that, I've had problems with one person solving a level in 2 minutes, and another playing through 35 restarts. (The amazing thing is, he didn't stop....)

One thing I know about good level design:

If someone plays through 1-2 of your levels, compliments you and moves away, it's back to the drawing board. When they don't say anything and spend four hours playing through all the levels you've made, and then ask if there's any more, you know you've got a winner =)

Thanks for the suggestions everyone, I'll try everything and see what works for me. I'm also gonna look into old abandonware games and see what kind of tricks and puzzles they used, maybe I can get some more ideas that way.:)

Sorry I'm so late to this thread.

For my game Rocknor's Bad Day, I developed a set of tutorial levels, but after that I made levels in no particular order. I just designed them. Some hard, some easy. Whatever came to mind. I knew I would re-sequence the level order based on player feedback.

When i first playtested the game, I included a tracking system that logged the number of deaths, resets, and the time it took each person. And I also included, at the end of each level, a "rate the level" GUI that asked people to rate each level for "frustration" and "difficulty". I used the data somewhat to determine the order of the levels, but mostly how I determined level order was by actually watching people play. There's no subsitute for that. Also, watching people play was a good way to find bugs in the level. And also to see how people thought through the level-sovling process.

As far as making MORE levels, I asked people (and used the level data) to figure out which levels people enjoyed. And then I made more like that. More variations.

Whenever I got stuck for designing levels, I went ahead and built a new element into the game. I could do a few more levels featuring that new element.

Hope this helps.

Hanford

That's interesting. I was afraid of adding new elements to my game. Always thought it would destroy the meaning that I envision of my game. But I hear lots of people just add elements as they go along, this will be very useful in creating levels indeed.

Early on I envisioned the game as a world. At the beginning of the design process I envisioned a long huge list of objects that would work in that world, and wrote them all down. I knew I wasn't going to program them all, but I made an engine that would support it.

I would program some elements then build a few levels with them. I tried my best to get as many levels as I could out of those first few elements before I went ahead and added more. This forced me to get creative early on and to work with what I had. And I built a series of levels that leveraged off the previous ones.

An important part of doing a game for me is knowing when enough is enough; so you can ship the game. Sometimes that's hard call to make, either becuase you haven't done enough, or because you want to keep adding. But I knew it was a decision I was not going to be able to make on paper. Designing a world that could accomodate, but not require, all these extra elements was key to this. As I went along my plan was flexible. I could evaluate whether or not I needed more stuff as I went along.

As it is now, I have a long list of elements still to be added that could be done as a sequel. Towards the end I wanted to keep adding more and I kept having to tell myself "Enough is enough! Hanford, you can add all this other stuff to the sequel. You have a good game, why don't you finish it so you can call it done?" Playtesting friends agreed.

Just remember you are the judge of whether or not adding an element will ruin your game, but why not experiment? If it does hurt it, just scale it back, or don't ship with it at all. In another thread I talked about Waypoints and how at first I thought they were going to ruin the difficultly of the levels. But I came to the conclusion that I could add as little or as many Waypoints on a per-level basis as I wanted. So I could actually use it as an assist to further balance the playability of my levels. It becuase just another element of the game.

Sorry this has kind of gotten OT but I hope it helps!

hanford

By the way, when I said I knew it wasn't a decision I was going to be able to make on paper, what I meant was that I knew I couldn't predict if a game design was fun until I actually had it working. You can design all you want on paper, but ultimately you're going to have to play it.... and when you do, if it's not fun, or you don't have enough levels, you're going to need to make a change.

Just some thoughts.

~Hanford

I deliberately picked a small number of objects for Fitznik. I felt that adding too many would lose the puzzle element of manipulating the objects. I have far fewer ojects than most of the games in this field, but I stuill managed to make 63 good levels. The idea was that by the time you get to the really tricky levels, you should be intimately familiar with how the objects behave and therefore if you get stuck then there must be some interaction between them that you haven't figured out yet even though you have all of the required information.

On the other hand, Steve tells me one of the common customer feedback comments about Fitznik is 'Not enough objects'. To an extent I can put this down to customers not knowing what they want. But it is something that I am working with for Fitznik 2. I have made another 4 entities that work well with each other. I'm thinking of adding some more though, but I don't want to overdo it.

I guess my problem now is, knowing when to draw the line. Lerc used little number of elements, and manipulated them to work with each other. While Hanford looks like he is making a game that is rich in all sorts of elements. So how do I know when to stop designing elements and start to think of a way to manipulate and interact them with one another. If I introduce new elements in every level, that might be fun, for some people, but the slope of the game's learning curve will be undefined if you know what I mean.

So how do I know when to stop designing elements and start to think of a way to manipulate and interact them with one another.

Design a basic set, but think about how you can extend it if that basic set is not rich enough for your game. You won't really know what's going to be good enough without testing. I think the only elements I had working in my game Rocknor (which by the wayt is done and out, http://www.monolux.com ) when I designed my first fun level was 4: speedramps, blocks, doors, and teleporters.

The absolute best thing you can do is watch people while they play it. Don't just email copies to friends to try, actually be in the same room as them while they play. I ask them to "think out loud" and I just sit there silently. Only if they run into a bug or an otherwise-unfinished part of the game will I give them feedback. You will learn so much from that. You'll see what people are enjoying, what they're hating, what they're not getting, and what's too easy. I do this without saying a word to the player. I highly, highly recommend watching people play your game.

Hanford

You might be interested to know that silent observation and elicited response observation (where you get people to talk continuously about what they're thinking and trying to do while using your product) are two incredibly useful (and by now fairly standard) usability techniques. I've used these and others for many years in a wide variety of software settings.

The trick to silent observation is not to say anything, no matter how much trouble the user gets into. You really have to restrain yourself from pointing at the screen, from saying, "no, you just have to..." as they flail around (I've escorted execs who could not shut up out of the room during such tests!). Those things that cause them to flail around are your problem, not theirs. These are the rough spots to work out in your program.

In games, if you can see where people are bored or confused or find something too tedious or pointless, you can learn a lot very quickly (and hopefully fix them to make the game better).

Like it was said before, you need to write down the ideas for the puzzle elements. Once you start making the game you'll know if they are fun. Don't really stop yourself from writing down new ideas as they come. You may stumble upon some that complement or are better than the ones you already have.

The more elements you have in the game, the more levels you'll be able to design before you burn out, as it instantly multiplies the number of possible scenarios before you even make them. This doesn't mean that you have to have every single element you introduced in the current level. You can introduce a newer element later. The greatest benefit is that you have the opportunity to renew the player's interest every time you do it. If you can't add all of them to the game you can always save them for a sequel. I doubt anyone here had the time and resources to add everything they wanted into their game, but it doesn't hurt to try.

One person mentioned having a form for the testers to fill out after each level rating difficulty and such. What about the game recording the entire play session at a mouse and keboard level? The tester then emails you the log file. This would let you watch the player even if they were not local.

Jack

hey Jack,

Cool idea. I thought about this too but building the engine to record and play it back was not worth it for me. That is to say, recording all the movement would have been somewhat easy, but for that information to be useful to me I would have had to make the engine play back the data so I could watch it. That would have been hard.

This would be pretty cool though. It would be great for testers who are not first-person accessable, and it would be a great way to test a puzzles in a level, since sometimes my testers found (much) easier solutions to puzzles I thought were going to be challenging.

It's not a replacement for watching people play first-hand and having them "think out loud" though. Knowing why they did something is just as important as knowing what they did.

I had users rate the "frustration" of each level. I left it up to them to interpet what that meant. But sometimes people would have 30 tries on a level before solving it and rate it with a low level of Frustration. Other times, some levels people could solve the first try though, but give it a high frustration level.

In the end it really taught me a lot about what types of puzzles and interactions I should be focusing on.


Hanford

I have an input recording mechanism. It's what I use for solutions.

I don't use it while getting people to test levels though, you would just lose too much not having the person there.

I have used it when people have come up with better solutions that the intended one. I get them to make a solution and send it to me and often I change the level so that their better method is necessary.

Unfortunately this method has come back to bite me a bit. The game has to run totally deterministicly to run the same each time from the same input. There seems to be a tiny number of machines where spiders act slightly differently. They still work the same way each time, just a different same way each time :rolleyes:

What are you talking about guys :P