next »

[RotateMe]

I stumble about this every time I get into a certain phase when creating new games that have levels (non one-screen-games). If I start to early I have to redo my levels but on the other hand I know how important it is to have something to play with early on. Another problem is that I often loose patience during the level designing process because I see how much stuff I want to add.

So basically I want to know what your approach is, finish everything and then get serious with the levels, or do the levels and add the stuff you need or a mix or something completely different?

Thanks in advance, and a screenshot from my current project in which I'm currently facing the question whether to start designing levels:

[sandcrab]

For me it's the difference between building and designing levels.

Absolutely build test environments, but at the early stage I think it's more important to focus on other things than the levels you'll actually for-sure include in the game.  I start designing levels  on paper as soon as the idea comes to me, because that way I don't forget, I have something to base off of when it does become time to build levels for real, and most importantly in this case, it doesn't actually matter if I knew at the time how high the character can jump, because the maps are not that detailed.  I just draw enough to remind me what was special about a particular area or how it is different from others.

[J. R. Hill]

I think the best advice I could give is start designing levels when you want to.  If you get the itch to start designing them now, do them while you're motivated.  If you say "nah, I should really be working on x instead," not only is it going to be a chore working on whatever you deem important, it will also become a chore when you do all the designing later.

Of course, if you really like level design to the point where it would interfere with making progress with anything else, then yeah take a break lol.

[SaturnineGames]

I think it depends on the game. If you have a very clear vision of the final gameplay - say you're making a clone or something very similar to an existing game - then you can put off level design until later on.

If you're experimenting with gameplay and trying to do something different from the norm, I find that it helps to work on level design as early as possible. You need areas to play with, both for the purpose of testing game mechancis, and also for testing how things flow.

One big thing to keep in mind - any level designs you do early on will probably change a lot as you get a better feel for how the game is coming out. Especially the intro areas, where you're introducing the players to your game mechanics. Don't be afraid to go back and change things. Once you have a solid amount of levels designed, you're probably going to no longer like the first ones you did and want to redo them.

[s0]

I usually finish the core gameplay first, then design the all the content and introduce some small additional mechanics as I go along.

Also, as an aside, I've noticed that a lot of the professional game design guides out there advocate a "checklist" approach where you write an incredibly detailed design doc and then sort of work through that in a predetermined order. That's because these guides are most often oriented towards team-based mainstream game development. The benefit of working solo on an indie game is that you can do things in any way and order you see fit.
 

[Dustin Smith]

The story goes that Miyamoto had an empty white space as the testing ground for Super Mario 64. If, say, you're making a platformer I'd follow suit and refine your game mechanics and whatnot before jumping headlong into level design. As edwdig mentioned, it's a good idea to test the waters when you're experimenting with new gameplay divergences -- stick with test areas to refine those mechanics, but I personally wouldn't make levels until you think you know what you want to do in them.

[dantheman363]

but I personally wouldn't make levels until you think you know what you want to do in them.

Yup, that's good advice. You don't want to pull the cart before the horse.

[Aquin]

(offtopic) is there a devlog for this game?

[ஒழுக்கின்மை (Paul Eres)]

i think a lot of people take this backwards: they design the engine, and put priority on that, and then spend almost no time on level design, or just give up at that point without creating any levels. i'd suggest the opposite approach, although of course you do need at least a little engine code before you do the levels. but i'd recommend doing *all* the levels as early as possible, very early. you can then improve them later, but they should all be there. for instance, if i remember correctly, we did all 96 of the basic levels of immortal defense in the first six weeks of production (the game itself took 6-7 months to complete; i added 4 levels later on to make it an even 100, and then added another 50 in a free expansion a year later). i think that helps a lot, because the levels are the core and heart of a game, nobody wants to play an engine, that's just a tech demo. people want to play a full game, and a game means all the levels.

[Aquin]

yeah, i agree with Paul on this one.  I tend to do as little engine as possible and start drafting levels.  Then the ideas I have for level design go into the engine, the ideas for the engine goes back into the levels, etc.

Level design + Game Mechanics Design should be done simultaneously, really. 

[mewse]

As a practical concern, you can't design real levels until you know how the game control works.

For example, in a game where you control a character, you need to how big that character is, how fast they move, and how high they can jump before you can design any real levels for them to move through.  This is because changing your character's behaviours can easily invalidate any or all of your already-created levels.  If you've already created 96 levels before you've locked down how the character moves around, you're going to be in a world of hurt if you change your mind about how high the character should be able to jump.


My usual approach is to make several levels in a "grey box" format as early as possible;  simple, few art assets, but functional.  Usually built out of grey boxes.  Then I build the game code until I have a prototype of the core game mechanics in those "grey box" levels, and then I return to designing true levels (which often include art-enhanced versions of the "grey box" levels).  And from that point on, the two sides evolve together, organically.

Of course, different approaches are best for different types of game, and where it's important to lock down controls in a platform game before getting too deep into building levels, that may well not be the case if you're making a tower defense game where you just need to throw more and faster baddies at the player in each stage.  (drastically oversimplifying, to tease Paul)   

[speeder]

My current game I made a generic level, with generic art assets, and then proceeded to make the controls, rules, etc...

After that was done, I designed some more level elements and made several levels.

Then I culled the most boring levels, until only some were left.

Then I made new levels based on those that survived.

Then I made new art for them, and some new-ish gameplay elements that are variations of old gameplay.

Repeat most of that...

I did that way because my game has no story, it is heavily gameplay centric.

[ஒழுக்கின்மை (Paul Eres)]

yeah, i agree that you should at least do the basic controls first, and that it depends on genre. but by engine i didn't mean how high you jump, i meant stuff like the various special effects, the animation system, physics (unless it's a physics game), that kind of stuff.

basically what i'm saying is don't spend 6 months just on the engine with no playable levels, that's a recipe for never finishing the game.

[Noel Berry]

I usually make a fair amount of the gameplay elements before I begin making levels that I feel will be in the finished game. However by the end of development I find that the first few levels, in particular, have been rewritten several times as the game changes and is added to over time. The only game I finished that had a considerable amount of levels (50, in the end) changed quite a bit from start to finish, so I ended up re-writing the first 20 levels about 3 times, but it was definitely worth it.

However, that said, I never wait until the end of development to start testing things, and making a few levels just to experiment with different gameplay elements. I'll often have a bunch of levels that I just keep adding to as I add new things to the game, and whether or not those levels end up in the final game is irrelevant - it's just there to experiment and find what's fun. If some of those make it to the final game, awesome, but I mostly create them to simply figure out how things are going to work, and if that new element I added is actually fun.

Definitely don't make everything without ever building a level. You need to be able to test things, and share it with friends to get some feedback on what's fun and what isn't.

[Triplefox]

It depends on how much iteration I want to do, and where.

If I have certainties about what the gameplay is - for example, if I were making a JRPG and the level design is primarily a matter of placing art assets - then the game is mostly content-based, so I should work on that almost immediately, and focus on features where they assist the content.

If if it's a mechanic that I need to work on, I should find some way of iterating on mechanics and test levels simultaneously. Just a little bit of tooling for a target of "80% procedural, 20% hand-crafted" content can work wonders in making this a gratifying process instead of a bottleneck. Playing with only one complete level isn't really enough to know how it works everywhere else.

[moi]

There are several ways to design a game.
Some are more difficult than others though

[s0]

yeah, i agree that you should at least do the basic controls first, and that it depends on genre. but by engine i didn't mean how high you jump, i meant stuff like the various special effects, the animation system, physics (unless it's a physics game), that kind of stuff.

basically what i'm saying is don't spend 6 months just on the engine with no playable levels, that's a recipe for never finishing the game.

I agree with this. I think more generally, it's important not to get sidetracked if you want to finish a game, especially a bigger project. Getting hung up on art is a classic example.

[chumez]

What I usually do is, since I just can't wait for a long time to see
basic results, write a test level which will more or less contain all
the features that your engine currently supports.

This way you can see whether your engine works, how the rest of the levels
will roughly look and what else do you want to add later on.

[Kinaetron]

Not sure if this the best way of doing it, but at the moment the designer for our project is working in game maker to get the mechanics down while I work away at getting a basic engine and editor up to refine later on when he has a decent idea how everything works

[namre]

I had this question with the puzzle platformer game I'm working on. I started doing the levels but ended up changing them when I wanted to change something to the core gameplay. So to avoid wasting time int the future, I will finish all the core mechanics first, make sure that I don't have anything else to add, and test them out in some test stages. Once I'm all done with this, then I go ahead and start designing levels.

Of course, when I'm bored of programming, what I do is I create level design assets like backgrounds and stuff to keep me interested.