Well you basically come up with a framework for the game play and a method for adding the features for a level.
Then the level information is typically stored as some sort of encoded data that makes sense for your program and each level is read from those files.
In my WIP, being done in Tier 2, I have a base game_object class that knows how to read enough information to display a basic sprite at a specific location, with physics type (or not), physics shape, color attributes and size scale. Then I have a bunch of specialty classes derived from that for things that rotate or are animated or move. Things like that.
Then you create a level editor that lets you build the levels. In my case, the level editor uses about 90% of the same code as the game itself and then just adds bits for selecting object type and parameters. It knows how to read existing files (in ascii for human editability) and then write back out both the ascii version and a binary version (non-human readable) for the game itself.
It comes down to your own programming style and what how the game is played.
Tiled plat formers have other ways to do things, but I suspect it is similar.
Look at some of the examples of tiled plat formers posted in these forums. There are also many examples of the level editors for the same or similar apps.
Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master
