Top-down scrolling shooter - Map/Level design?

[Addictman]

Hey.

I'm looking for tips on how to design a level for a top-down scrolling shooter game.

Basic premises are:

1) Level scrolls at a constant (although may differ from level to level) speed.
2) Player(s) are always constrained by the boundaries of the screen (Cannot reverse to make level scroll slower, or push forward to make it scroll faster. Neither can you move to the left/right beyond what's visible on the screen. These are pretty common rules for top-down scrollers that automatically move the player forward at a predetermined pace. Think 1942 etc.
3) Enemies appear at a given time, with given points to move through, at coordinates in the range of 0 - screenwidth/screenheight. (As opposed to enemy appearing at y=24000, and having to care how far the level has scrolled).

What I could use input on is how to store leveldata. What do I need to have on file, how would you store it? How would you go forth to avoid making level-creation a massive manual job with editing files. What's your story, - how do you do it, and are you happy with your approach?

Up to now I've used xml, - and although it's working, it's extremely tedious writing huge amounts of xml to create levels.

[Cero]

I write have a map editor I wrote myself, and for every serious project I would derive that and make it specific to that project.
seems like a lot of effort, but later, it's a grand tool.

[Eli Delventhal]

I think I've made it clear on this forum already how much I hate XML, but I'll say again... I hate it. What crap XML is. If you want to use something like it, at least go with JSON because it's much more compact and legible. XML is just a bloody mess.

For something like your game I will usually do one of the following:

1) Make a 2D grid in a text file. Each letter is something else, like "L" might be laser cannon, " " is nothing, "S" is starting point, etc. You can just eyeball it to see what looks like, it's very quick and easy to edit, and it's also quick and easy to implement. The one downside is adding meta data of any kind to each element - you obviously can't do that easily. When I get to this level of complexity, I generally just do:
2) Make a simple grid-based level editor. If you understand Swing or some other UI system well, you can easily make one of these in a few days. Just have a palette of tiles, click on a given space and change its value with whatever tile. Then add right-click support to add metadata or whatever. I've made plenty of these and they're always fun to do.

If you don't feel up to #2, you could still figure out ways of putting metadata into #1, like having a range of special characters (0-9 are good choices, or all lowercase characters) that represent metadata entities, then if you put that in it loads a template specified below the level data or something. Or you could just have the option below of specifying what a certain letter means and then have that override its default behavior. Like this:

1   2   3   4   5   6   7   8   9   10   11

WWWWWWW W  B  W W 0 0 W WG   GW WG   GW WG   GW W  S  W WWWWWWW / B:{class:Boss, hp:500, damage:10, pattern:spinny} 0:{class:Ship, hp:10, damage:3, pattern:swoop}

I'm obviously using pseudo-JSON there (see how legible that is?), but you could do whatever you want. I often just use spaces to separate values, and know which value is what (first value is the letter, second is the class, third is hp, etc.). That's super easy but then of course it's more difficult to know exactly what means what - it's the equivalent of a method with a ton of parameters.

The key is: don't confine yourself to XML, because it sucks. Do whatever fits your needs best.

Games published by our own members! Check 'em out!

[Addictman]

This a basic example of a ship doesn't have much behaviour, and I agree with you, with hundreds of these pr. level, xml quickly gets really bloated.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23

<Entity entityType="org.addictman.game.content.ships.Bat">       <Constructor>         <Curve preDefined="CURVE_FROM_CENTEREDRIGHT_TO_LEFT" stepTime="10" totalTime="15000" />         <Parameter type="float">64.0f</Parameter>         <Parameter type="float">64.0f</Parameter>       </Constructor>       <LevelInfo entryTimeMs="75000" />       <Method name="setX">         <Parameter type="double">0.0</Parameter>       </Method>       <Method name="setY">         <Parameter type="double">0.0</Parameter>       </Method>       <Method name="setFireDelay">         <Parameter type="int">300</Parameter>       </Method>       <Method name="setMaxHealth">         <Parameter type="int">3000</Parameter>       </Method>       <Method name="addHealth">         <Parameter type="int">3000</Parameter>       </Method>     </Entity>

A JSON-like structure seems like a good idea. The funny thing is that it'll most likely turn out easier to read and parse as well.

When it comes to an editor, I made that for my previous game. I might have gone overboard, as it turned into a photoshop look-alike tilemap editor. I spent months on it, trying to make it a general-purpose editor, but in the end I had top stop. I could have gone on and on, and never finished it. And that's my problem; I know myself, once I start writing an editor, I'm going to be thinking miles ahead, and I'll never get anything done on the game itself

But maybe I'll just try something simple this time.

Going for the JSON, - but keeping reflection in there

Thanks.

[Eli Delventhal]

A good idea is to just make the editor spit out whatever text/XML/JSON format you were originally doing manually, that way you're constrained to the format you had and it's merely a nice GUI.

I had one project I worked on for a couple years that underwent some evolution, so it went like this:
1) Made simple text files for every level, like above.
2) It started getting unwieldy, so I made a level editor that spit out the same text format (and could read it).
3) The text format became limited, so I made the level editor start spitting out actual objects with ObjectOutputStream (careful with this, though, you don't want to directly use serialized objects in your game, instead make a clone or something). The level editor maintained the ability to read text files to support legacy stuff.

[SmokeNWrite]

Use view following I have figured out it is awesome.

Basically the whole world moves when your moving opposite though
So basically it follows you when you move.

This solved having any small games now all you need is a Tile map builder and build the whole level and I can walk around a seemingly endless world

I'm working on a 2d game engine of my own, but I will have a top-down, side scroller and shooter in one, so I can switch between.

[SmokeNWrite]

A good idea is to just make the editor spit out whatever text/XML/JSON format you were originally doing manually, that way you're constrained to the format you had and it's merely a nice GUI.

I had one project I worked on for a couple years that underwent some evolution, so it went like this:
1) Made simple text files for every level, like above.
2) It started getting unwieldy, so I made a level editor that spit out the same text format (and could read it).
3) The text format became limited, so I made the level editor start spitting out actual objects with ObjectOutputStream (careful with this, though, you don't want to directly use serialized objects in your game, instead make a clone or something). The level editor maintained the ability to read text files to support legacy stuff.

And yes map editor / level editor is a great idea, I am meaning to make one myself.
Sorry for double post.