Levels before code?

[NothingLikeit]

Hi,

I'm wondering if it's more important to work on levels before doing the code or vice versa. In the past I've worked on levels and then came back to the code, figured out that I'm not good at it, and finally just used someone else's. The results weren't that good. So now I am wondering: How much time should I spend on creating gameplay code before creating a level to test it in?

[svero]

I don't know that there's any right answer to this. All I can say is that for my part I usually put the basic gameplay code together before creating or tweaking any final levels. I almost always test all the code on fake or dev levels.

[Hiro_Antagonist]

I recommend on getting your code as far along as possible as soon as possible, and consider any content you create along the way to be dummy content, and that content should act as a series of gameplay tests for your engine.

Especially for some types of games, you can't really create *good* content for your game until the engine is done and locked down, and by then, you will understand your engine better and theoretically be able to create better content.

-Hiro_Antagonist

[Artinum]

Though I agree with all of the above, I'd like to throw a small spanner into the works and suggest that designing your levels - at least to some extent - before you finish your code has an advantage. It allows you to accommodate for any new features you come up with.

Imagine designing a new thingummy for level five and then realising you'll have to rewrite your main code to allow for it.

[Sol_HSA]

I think these things go hand in hand. You may think of something in level design that you wouldn't in code, and some things may come up in code that are more or less "free" to implement.

It is, however, easy to go overboard with the code and build lots of things that are not really used or useful, and will only increase bloat (and burn time).

[Grey Alien]

yeah, do the basic code, then make a test level, then do more code, then add stuff into the test level, keep this cycle going until you are forced to make a level editor. Only right near the end should you make ALL the levels. Mind you it may depend on the game type a bit.

[amaranth]

My four cents...

1. Create your engine code.
2. Build your level editor.
3. Build your levels.
4. Create your game code.

[Bmc]

building your levels should be the last thing you do.

have a proto-level to test all your features. once everything is working pump out the levels/.

[Robert Cummings]

Definately code + placeholders first. In fact I coded my entire game, every last bit of it using placeholders.

Till it was *completely* finished. Only now am I doing the graphics. Consider for a minute what this forces you to do. It forces you to plan the entire game. Always plan... stuff gets finished then.

Something always arises in code that requires a graphics change somewhere down the line. If when you are doing your levels last, you come up with feature xyz then it is trivial to go back and add it to the code. Don't let it be your excuse for not doing code first. Thats gonna bite you.

[Game Producer]

My four cents...

1. Create your engine code.
2. Build your level editor.
3. Build your levels.
4. Create your game code.

No no no ;)

1. Don't create engine code
2. Don't build your level editor
3. Grap an engine WITH an level editor :)
4. Make "fake" level
5. Make code
6. Make *stuff*
7. Make level

[Steve Ince]

When I worked for Revolution Software I used to be a firm believer in designing as much as possible on "paper" in advance of everything else. This would then define the engine, interface, art style and tools required for the game. This is probably necessary when you're creating games using 30 staff and outsourcing some work.

However, now that I'm working on my own game using a ready made engine and tools I find that I'm taking a much more "organic" approach and from the feedback I'm getting it's paying dividends. While I defined the broad story and gameplay goals to nail down some objectives for the development, the detials of the ongoing gameplay are created from all the thoughts running through my head as I think about this high level structure. The real beauty of this approach is that I'm having fun developing the game and this comes through to the player.

[djdolber]

When developing feature xyz in an engine i always build easy ways of manipulating the level in the game so i can test all possible scenarios with that particular feature before moving on. I think the best way is to build the editor straight into the game, if the game fits this approach, 2D tilebased games for example...

[vjvj]

Your code/tools/editors need to be mature enough so that you don't have to go back and redo content. So getting to that point is important.

That said, content takes a lot longer to produce than code, so you definitely want to start producing content ASAP.

I do tools first, then have the content guy start working on content while I do technology code.

[RWgames]

I would do it in this order. It's what I'm doing for my current project:
1) Engine and Tilemap (together because they can both 'communicate' with each other which is VERY useful depending on the type of game you've got).
2)Make test levels that use all types of events that will be present in the final game, to make sure it works on all leves (ie gameplay wise and functionality wise). Events such as levers opening doors etc.. (All made with placeholders)
3)Fix anything that doesnt work
4)Recheck and make real content
5)Test final game

Your engine and tilemap should be capable of whatever is in your plan, so make sure you have a design document as it will prove very very helpful later on.

[NothingLikeit]

No no no ;)

1. Don't create engine code
2. Don't build your level editor
3. Grap an engine WITH an level editor :)
4. Make "fake" level
5. Make code
6. Make *stuff*
7. Make level


very good advice all. I can't wait till i have time to read it all.

I have an engine which saves me, the newbie programer the headache of learning high level stuff. They both have level editors.

I was at the point where I could either use the scripts that were in each already. But I've deiced that although it could save me time, I should code the scripts myself. It's not necessarily reinventing the wheel. It's more of learning. So I've grabbed some scripting tutorials and I'm off the the races.