Gaming Your Way

May contain nuts.

I think I want a wall there

Two posts in two days ? I don't know about it being my birthday, it's like Christmas for everyone who likes reading Flash gaming related crap.

I thought I'd go over how we've approached the level design in Outpost, there may be some ideas you can re-purpose for your own stuff.

outpost2.png
I wish we were more like a crap version of cracked.com


Ok, so we're using the IDE. May seem strange for such a tile based game, but it has a ton of advantages which we discovered when working on Knight's Quest.
Perhaps it would make sense to explain how the scroller works first. Basically we've got a holder sprite, and within that we have lots of 640x640 bitmaps. It's done this way so as we scroll around we can turn off the bitmaps which aren't on-screen ( To be honest I've got to code that bit yet, but that's the plan ).

Each level is in a mc, and within that we have 4 more mc's. Background, Walls, Objects and Collisions. Background is literally that, the floor. We can make this totally art based, nothing needs to be pixel aligned if we don't want it to be and we can throw blend modes etc. in there for no cost.
Next up is the walls clip. This has to be tile based, but we can still mess around with it to some extent. The IDE's snap to grid makes life a lot easier with this. The wall tiles are just 32x32 bitmaps dropped directly onto the stage.
Objects are in-game sprites ( Surprisingly enough ), so you can see crates in the above grab, and the yellow squares are baddie start positions. Also the doors are on view as they are technically sprites as we have to open them / run collision checks.
The final layer is the collision one, which is made up of just those red rectangles you can see.

That's the basic nuts and bolts ( Now that's a great name for a game ), the more interesting bit is how we actually use this. Firstly we loop through the background and grab 640x640 pixels at a time, and plot them into our scrollers 640x640 bitmaps. We then grab the walls and do the same. Before we finish with the walls we loop through each tile and store it in a small bitmap ( Where each tile = 1 pixel ) which we then use for path finding / line of sight / displaying the map.
So the data is just burned flat into our bitmaps, hence no extra cost if we add say gradient shadows in there, and we have the luxury of using High settings for filters which you can't really do "real time".
Next up we loop through the Objects, using the instance names to create the relevant item ( Instance name == "Baddie1", ok lets make one of those and position it ).
Finally, we loop through the collision layer. We just need the vectors from the rectangles because we then pass these to Nape. Yep, we're using a physics engine in our game. It started off a little "Fuck it, lets spend a day dropping it in to see what happens", and it worked way better than I thought it would, so it now handles all our collisions, from baddies being able to push crates out of the way to the player bullets hitting walls.

There are some downsides to this approach, the shadows are burned into the background whereas I'd really like them in their own layer so sprites could go into shadow, and it's obviously not as quick to design a level as using something like Mappy, but I think it's going to more than pay off in the long term.

Squize.

Comments (1) -

  • wtfaremypants

    6/8/2011 8:39:02 PM |

    You mention you're using an IDE - what IDE are you using?

Comments are closed