# how to design and develop game level(stages) [closed]

I need some expert opinion about game level design. I've been developing android game(2D) using LibGDX framework inspired from below sample game.

LibGDX sample Drop game

I've customized this game and made several changes as I am novice in gaming industry. Now, I need some help related to level(stages) design. I've just implemented level-1. As level increases , complexity increases. Should I'll have to implement new screen for each and every level and write separate code related to that screen. Or, there is some better approach? I want there should be single game play screen(except splash, menu and help screen etc) that should override sprite as level changes. I've searched a lot but didn't find useful article. Looking for useful links, article or online tool anything.

what should be the best design approach as performance is really matters. Should file reading is good approach or use sqllite ? What should be the best practices while designing these things as I am the one man army. Is there any level editor that will help.

## closed as too broad by bummzack, Anko, Nicol Bolas, Sean Middleditch, MichaelHouse♦Sep 4 '13 at 16:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

You want a "Data Driven" system. This means that you have one game screen used over and over for every level.

When you want to load a level, read a file to decide what to do, the code should not know in advance because you might want to send out new level files later (ala DLC).

For this drop game, it would be pretty simple, your level file would probably just be numbers for how often and fast to send drops, and a list of your sprites for that level.

P.S. How to design is subjective, good luck with having that in your question. Artists usually hate having to mess with code though, so really get on that Data Driven system.

EDIT: To clear up the definition of "Data Driven", there's a topic right here on SO: What is data-driven programming?

Which has a great link in the comments section of the question: http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch09s01.html , which features a sweet and simple explanation:

...in data-driven programming, the data is not merely the state of some object, but actually defines the control flow of the program.

• good call !!! if he gets his data structure right then the game levels should fall in to place a treat :) – War Sep 2 '13 at 6:51
• @MickLH separating the code from the content is always a good idea, but this is not called data-driven design. DDD is a programming technique where you plan the program around the data-structures it operates on focusing on performance considerations. – Philipp Sep 2 '13 at 10:43
• The only reasonable explanation is that you must be referring to exactly "Data Driven Design", a web app development topic about dense user interfaces.I am referring to Data Driven programming, a much older concept which very simply means that the function of the code is determined by the data it receives at runtime. Please read Data-driven programming over at wiki :) – MickLH Sep 2 '13 at 16:39
• @MickLH regardless of the semantics, yes, it's always better to define your data needs first, be it in a database or object/stucture, or both. Then build on top of that. @ ved - think of it this way: how will you know what to do, if you don't know exactly what you have to work with ? – Howard Pautz Sep 3 '13 at 19:53

The best way that I've personally seen this done is to build a few things:

## Level Importer

Essentially you could build a parser that looks for specific things. A way I've done this is I've started the line with a key word, and added data corresponding to it afterwards. So an overly simple example would be:

Level: 1
Bots: 2
BotLevel: 3
BotLevel: 6
Map:
1 0 1
1 0 1
1 1 1


So when it hits Level it expects the next token to be an integer. When it hits Bots it expects an integer and then that many lines corresponding to the levels. When it hits Map then it parses till the end of file. You can just add Keys and some sort of expected values. Of course it's very important to handle if the expected value, say an integer, is a string.

## Levels

After you finish how your importer should look, you start building a few levels. You can go back and add things to the importer that fit your needs.

## Level Editor (Extra)

An extra feature for yourself or your team would then to build an independent program to create the levels for you. This could be pretty simple, or could turn into a rather complex program depending on how advanced your game is. It will especially help if you have people helping you that aren't programmers.