26th December 2010
Keyhole challenge : Come and get it! - collectables
This is article 6 in my series on developing a tiny-screen game.
I know it's been a while since my last post - I've had little uninterrupted time to work
on the game recently. Things have now progressed a little.
A change of plan
Early on in this series, I mentioned that I wanted the player to be able to take pictures of their environment. I've abandoned that idea, at least for this game. There were two issues with it, both due to the small screen. Firstly, the images won't match those of a larger game. Reviewing photos later and showing them off to your friends loses a lot of its appeal when they're 64x64 stamps. Secondly, working through any sort of menu becomes much more laboured when you can only have about 4 small icons on-screen at once.
I realised that I might as well file the idea away for later, and fall back on the long gaming tradition of collectables. Many, many games have had coins, gems, rings and coloured or sparkly doo-dads of one kind or another. I chose animated stars.
Advert
The current map structure
The important thing is that the extra information can be efficiently incorporated into the level-data build pathway. So far I have:
- The 'playground' - essentially a 2D array of solid or empty tiles
- The foreground - an identically sized array of cosmetic tiles.
I store this information as a bitmap, which is efficient in terms of filespace and access. To create it I process the map editor output textfile using a small Actionscript program - which is where the alternative textures are randomly assigned, too. To this I need to easily add information about where the collectables are. In future I'll also need to add more interesting objects, but I'll go over that later.
The reason to mention this is that I could just add a list of coordinates to my game code. However, that would be stupid, because the map isn't complete - because to do that I'd need to assume things about the stuff I haven't done yet. So that would end up with me hand-editing that list each time the map changed.
I could just add a new layer to the map editor. In many cases that would be the right thing to do. But even with all the other objects I may put in, this would be a very sparse layer.
Of course at some point the information will need to get parsed into arrays held within the game. If I output an additional array as text during pre-processing, I then need to manually transfer that every time I wanted to update the map. Why not add the data to a map layer I already have? The playground array is quite full, and I'd lose the background selection for any collectable tiles if I used it. But using the foreground only costs the ability to put something in front of the collectable - which is probably a foolish thing to do in any case.
So this is what I've done.
Advert
Runtime extraction
When the game loads up, it looks through the foreground for collectables, and records them in a list. Because they're sparsely distributed, this is very quick - I use getColorBoundsRect on
each column, which is a straightforward loop because I decided not to have more than one per column. This also has the advantage of very quick tests for collectables on-screen and pick-up by the player.
As I want to store which items have been found previously, I'm also giving them sequential numbers in the order they're found by this routine. This means they can go in the sharedObject file as a bitstring.
I recommend this strategy of the sparse one-axis array when you have some slack in where things are placed - and the axis is not too ridiculously huge. It's also useful if you need to make minor edits to a large -and otherwise procedurally generated- set of data. If you need a bit more control, you can make each position its own array, but your data-structure parsing code becomes more complex.
Postface
As a game is developed, it often doesn't go quite the way you planned. It's important to keep reviewing what you're doing as time goes on, and not to chase impossible goals.
Advert
Comments