http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=1947

Making a game in 48 hours is never easy, but thankfully it was less hard this time. Mainly because I decided to use tools I was more familiar with, instead of using the weekend to learn a new tool or framework.

I started the weekend with the idea of making a super-hero canabalt. Something that lends a bit of variety to the one-button run genre. A constant threat from the rear, a path that makes it difficult to stay out in front and some kind of upgrade system.

I structured my development a lot more than usual, with index cards and a vague agile methodology (and the entire living floor). I tried to sleep well during the weekend, getting 6 hours on Friday night, and 9(!) on Saturday. I also ate well, cooking rather than the usual takeaways, and only drinking one energy drink the whole weekend. (I did manage to polish off 5 pots of coffee though, which was around 25+ cups.)

What Went Right™

Organisation – I didn’t feel stressed much at all during the weekend. I managed time for music and even some graphics polishing at the end (not much mind, I’m not an artist and it’s hard to make faeces shine). All in all, I always felt like I knew what I was doing, what I had done, and what I would have to do.

Tools – I normally take a sackcloth-and-ashes approach to development: “If it can’t be done on the command line, then… you’re lying, because everything can be done on the command line. Fiend!” – But this weekend, I used FlashDevelop and worked on windows most of the time. FlashDevelop really is unparalleled when it comes to Actionscript coding.

K.I.S.S. (Keep It Simple, Stupid) – I nailed down the initial mechanics early. Platformer with tilemaps, jumping, double jumping. I did it all with multi-coloured squares too, sprites were an afterthought. I didn’t try to invent a new genre, and I didn’t try to rewrite the entirety of FlashPunk’s BitmapData handling (see: LD #19). I took a simple idea, and made it.

Asset Pipeline – I learned the workings of D.A.M.E. very early on in the weekend. Got familiar with its output format, its awkward, awkward tools, and it’s habit of refusing to write to CSV on occasion because it believes MXMLC is still holding on to the files (although this is more likely Adobe’s fault). I got much better at using Graphics Gale for initial pixel pushing and animating, and then using Photoshop to touch up and bake in some vague lighting.

Emitters! – Who doesn’t love little objects that fire random things in random directions? More Emitters, I say. More. I wish I could have Emitters every day of the week. My next game might be made entirely out of Emitters.

Guinness – Thanks to my first point, Organisation, I afforded myself an hour on Sunday for a few relaxing pints of Black. Boom.

What Went Wrong™

Tilemaps – I spent a lot of time trying different ideas on how to procedural generate the maps. I had never made a platformer before, nor any game that made use of tilemaps. My first 30+ hours, I simply used a very very large tilemap, ~10000 tiles wide. This allowed me the ability to continue working and come back to this issue.
Eventually I decided upon much smaller (200 wide) tilemap segments. These were manually arranged in sets within the Level class, with each set corresponding to the players current powerup progression, and then randomly appended to the scene when the player was < 1600 pixels from nothingness.
This worked fine for a while, until I realised that these tilemaps were persisting, and even being called in collision routines LONG AFTER THE PLAYER HAD MOVED PAST…. Some rewriting here, and some destroy()’s there and we gained a little bit of performance back.

(It’s worth noting however that I didn’t infinite-ize ALL of the tilemaps in the game, and getting more than 2000m will cause the world to end in a dramatic, double-buffer kind of way, go-on, I dare you.)

Helicopters – See those bombs that keep dropping? Aye, they’re coming from a helicopter. Do you know why you can’t see the helicopter? Because I suck at drawing helicopters.

Wall Jump – Not as easy as I first thought, I had it working early on, but it didn’t feel right and it looked weird. Definitely a brick for the post-compo window.

Communicating with the player – Even in a relatively simple game (perhaps more so if its a well establish genre, actually), its hard to communicate certain ideas, goals and hazards to the player.
My intention for this game was for the player to only lose if they got caught (or, more accurately, blown up). This meant you didn’t lose any health if you fell down a hole.The holes served simply as a setback, in order to close the distance between you and the doom of fiery sky-bombs.
Seemingly, people missed this, and thought it either odd that health wasn’t removed by falling down, or that it was cruel that health wasn’t restored when returned to the last checkpoint. In the post-compo version, I will address this with 2 changes.

First, I will record player position AND bomb position at each checkpoint, and restore on death, as opposed to just the player position being restored as it is now (and then the bombs being teleported to a nearby threatening location).

Second, when a player dies, I will animate the scrolling of the screen back to the checkpoint position, display both player character and distance from danger. I will then visually display a reduction in this distance, to reinforce the punishment.

What’s Next?

Aside from the aforementioned changes, I have a few other ideas I’m going to be implementing in the near future, including, but not limited to:

Story mode, with a number of discrete, designed levels, catered to the current unlocked DNA.
New DNA’s, including Spider-Monkey, Electric Eel and Mole.
Highscores, self explanatory!
Better graphics, self revelatory!
High Definition Jazz Kittens, only at participating stores.

Crazy Idea?

Passive Multiplayer

After a playthrough, a replay of the players run, along with the generated map of their run would be saved with their highscore. Next time someone plays, instead of getting a freshly generated map, they would retrieve one from a server, along with the “ghosts” of everyone else who played that map. Allowing for an indirect, asynchronous level of multiplayer competition.

Conclusion

What a bloody great way to spend a weekend. I always enjoy it too much. This time I feel more accomplished and I’m looking forward to working on this game for quite a while to come. Hope you all had a great time too!

Timelapse

Anyone heading up to Glasgowbury this fine weekend? Looks set to be a great one.

Any Android folks heading up the mountain can grab the little app I put together with acts, stages and times. Haven’t had time to get it cleared for the Market so you’ll have to download it yourself here.

http://ryangrieve.com/glasgowbury

If you’ve never installed an app manually before, you will have to check the “Unknown Sources” box in “Settings >> Applications”.

Enjoy!

My new class “CorruptedSector” should allow me to be much more sensible about this generation malarkey. Firstly, it is the only class used for corruption, as opposed to my previous implementations of “CorruptedTile” and “CorruptedTilemap”, and secondly, each instance retains references to only its neighbours, its parent, and its children, those it will directly affect.

With regards to efficiency, we will only go as deep into the tree as necessary to update and draw changes. This is logically quite simple, when calling the update function for a CorruptedSector, if none of the sector’s children have been flagged as changed, then we run this sector’s update and we’re done. Else we call each of the children’s update functions in turn, which will then check their own children and so on.

This means the actual generation logic is now inherent in each sector. I had avoided this before, as it had been more efficient for the tilemap to handle this logic, but the tree nature of the structure now puts an end to that. When a sector is “spreading” it will call the generation functions of its neighbours, which will be able to determine whether it should to apply the affect to itself, or to individual children.

If a Sector interacts with one of its neighbours, we flag that neighbour for update. This flagging process will then bubble up the tree, marking each parent, in order, as flagged. The same happens if a sector is affected in any other way, such as being hit by the player’s weapons. This selective processing will obviously help performance in a great way, but I can also implement accuracy variations on the generation algorithm as well, as mentioned in a previous post. Hopefully my world size will not be limited by anything other than design choices after this.

I’m excited to get interfacing these changes with the current game logic, it will make a lot of future developments easier too, such as weapon collision detection and A.I. pathfinding.

This works quite well at current settings, and a world size of 1024×768 pixels, (each corruption tile is 8×8). The framerate starts to drop when the world size is increased beyond this. I want my game world to be considerably (+10x) larger than this.

My viewport is currently 800×600, so obviously not every tile is on the screen at once, so the next conclusion is that I don’t need to be generating the spread of corruption in realtime for non-visible areas. This seems trivial, but for one thing. I want the spread of corruption in the game to be a constant threat for the player. If the player leaves an area, where their buildings/resources/assets are, and travels a great distance away, I want the spread to be in their mind the whole time. When they return I want the shape, size and spread of the area to be in accordance with their expectations.

So, using the above statement I can say I regenerate the area as the player approaches it. However, what if I want the player to received alerts when their base of operations is being overrun? This will mean I need to keep the generation going in at least a semi realtime fashion.

The solution that currently has prime position in my mind is as follows…

First I drop the game’s viewport to 640×480 (a much more acceptable geometry for a flash game anyway). This will decrease the number of tiles on the screen at any given instant. Next, I break the world map down into viewport sized areas. Each of these areas themselves a tilemap of 8×8 corruption squares, essentially the same as my current single 1024×768 corruption class.

Now I take this new area class and I make some changes to its generation procedures. Lets, for the sake of argument, say we have 4 levels of generation.

1) Real-time. As the player views it, same as all generation is currently.

2) Semi-real-time. This will have the full generation procedure operating at a reduced rate, but using increased values. This will take less grunt to run, but will look jerky and horrible.

3) Deferred. These areas do not generate at all, they simply store the time elapsed since last time generation ran and run an efficient, less accurate, “catch-up” generation, regularly. (or when the player approaches them).

4) None. These areas have not yet been approached or witnessed by the player, they will be randomly created and pushed to one of the above modes when the player approaches them.

So, each 640×480 tilemap, will be pushed into one of these generation modes based upon the players position and current velocity. There will only ever be a max of 4 of these areas on-screen. So these 4 will be in mode 1, real-time. A player heading towards a corner will be approaching, at max, 3 other areas, these areas will be in mode 2, semi-real-time. All other tiles that the player has witnessed at least once will be in mode 3, deferred, with the remainder in mode 4.

It may be useful to actually insert another mode after semi-real-time, semi-demi-real-time if you will. This would be the areas just outside the real time areas, but not being approached by the player. That way we could handle sudden changes in direction smoothly.

Erm… yeah so that the idea, as fuzzy as it is.

Does it make sense?

Taking a break from my current FlashPunk based project to get back to some real programming. I’ll be using C++ with SFML, with sfxr likely providing my audio. I’ll be developing on Ubuntu Linux 11.04 and targeting Linux, Windows and OSX.

The idea I’m running with will be a cousin of the Tower Defense genre, loosely connected to my first LD48 entry “Planetfall“. The player will be a single ship on the frontier of colonized space charged with defending the territories on a budget. (Space bureaucracy makes life hard for everyone).

I’ll be perfectly honest the idea isn’t very fleshed out atm. I have about 30 pages of scribbled notes and terrible diagrams that point the game in 8 different directions. These will get refined hopefully at some point tonight/tomorrow and I can update this post with some actual details.

Currently I’m refactoring a lot of the code used in Planetfall and expanding upon the shambles of a game framework that I’m calling “Stile”. This might take a while…

What I am sure of, however, is that this game will suffer from a massive case of Programmer’s Art, at least initially.

Grieve