Check (and rate) the game here:

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.

Read the rest of this entry »

Permalink | 0 Comments »

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!

Permalink | 0 Comments »

After much faffing about last night with my tilemaps, I realized that what I actually was looking for was much more akin to a quad-tree than a tilemap. So that’s what I’ve implemented.

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.

Permalink | 0 Comments »

At the weekend I started a new project, an entry for July’s Experimental Gameplay theme “Disintegrate”. I was quite pleased with the progress I made over the short time so far (show below), but I’ve run into a major problem and I’ve been mulling possible solutions over in my head. Going to sound the problem, and one of the solutions, out here and see what happens, if by the time I’m done it sounds ridiculous then this post will probably never see the light of day. ;)





Currently my class for the spreading corruption keeps 2 arrays, effectively 2 tilemaps. One of these is for its visual representation and the other is a much simpler array of integer values that is used for raycasting, collision detection etc. Currently each tile in the corruption has a “corrupted” value, and when it is high enough it will start increasing the “corrupted” value of its adjacent tiles. This isn’t a straight forward increment, there are some seeded random values, and other considerations to be taken into account, that can speed up or slow down the corruption process.

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?

Permalink | 0 Comments »

Excited to be taking part in #1monthgame or OMG! if you prefer :)

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

Permalink | 0 Comments »