First and foremost, I’ve been putting ideas down on paper for the game. I’ve now got a pretty good idea of how it’ll play, what the setting is, what the player’s goal is, and so on. There’s a whole update I need to put together on this, but that’s for a later date.

I’ve also been tweaking the coding, and also reporting some bugs in the platform movement in the software I’m using – one of the big downsides of any game creation software over proper coding is that some bugs are inherent to the program rather than your own project. While I’ve got workarounds for most of the issues, a program update would obviously be preferable. Which does mean waiting on an update, but there are other things I can get on with in the mean time.

On that note, working some more on sprites. Settled on what’ll roughly be the main character design:

The goggles do nothing. For now, anyway.

I’ve also got fully animated walk and run cycles, which I’ll get up as soon as I find a decent free animated GIF maker.

Finally, I’ve spent a lot of time pouring over the Procedural Content Generation Wiki. The idea of the game building its own levels is attractive on two fronts – If done well it adds a lot of replay value, and makes my life easier. I want to get a PCG example file out for people to test in the not too distant future.

None of the above really warranted its own post, least not until I’ve got work done to show along their lines. But it’s still going. Anyone fancying making suggestions or lending a hand is still more than welcome to do so :p

I can't promise that it's any more interesting at full size, but feel free to look.

Boxes! Words! Confusion!

So, here’s an event sheet. I’ve cropped off the rest of the UI and just left the events themselves, which I’ll go through in a moment. Event sheets are essentially reusable chunks of code – we set each of our layouts (levels) up to include any necessary event sheets. This saves us duplicating code for every new level, and means we only call code that’s needed for each layout – no point putting a load of enemy AI code onto our title screen, for instance.

The above image is the entire code for grabbing at the edge of a platform. It’s contained in the “Player Movement” event sheet, where we’ll store most of the code for player movement beyond the default stuff that the Platform Behaviour does for us anyway. It’s also in its own Event Group called “Edge Grab” – Event groups are useful because they can be switched on and off at runtime. If we ever want to take away the player’s ability to edge grab, we can simply turn this off. It also keeps the events sheets much neater and tidier to work with.

Let’s run through this line by line. The first event sets two new objects to always follow our PlayerBox – one ‘tick’ is one pass of the event sheet, so every time the playerbox is updated, so to are our new detectors. In order to be nice and clear, they’re called PlayerEdgeDetectLeft and PlayerEdgeDetectRight. This way, I’ll hopefully not forget that these are important.

The next two lines are a series of conditions used to check if the player should grab a ledge. The first condition reads “is falling”. This is a check to make sure that the player object is in the air and is falling downwards. The next condition checks to see if one of our detectors is overlapping an object with the “solid” attribute. If it is, the game knows the player is next to a wall, but does not yet know the extent of that wall.

We’re only interested in seeing if the player is at the top of a wall or solid object, and this is where our third condition comes in. “Overlapping at offset” is a simple check run by the game to see if a collision would be triggered at a certain point from an object. In this case, the game checks to see if PlayerEdgeDetect would trigger a collision three pixels above itself (0,-3). If this did trigger a collision, then we know the player is not at the top of the “solid” object. So in order to run this event when this condition is false, we’ve inverted the condition (note the =/= symbol).

So now, if the EdgeDetect is in a wall, but the offset above it is not, the game registers this as the top of a solid object and responds accordingly by setting one of PlayerBox’s private variable, “grabbing edge”, to 1. Private Variables are stored numbers or strings you specify within an object. In this case, we’re using a number – When “grabbing edge” is 1, the player is holding an edge. When “grabbing edge” is 0, he isn’t.

This may help explain the edge detection process better than words. Or it might not.

The final condition, “trigger once” means that the actions, or outcomes, of the event, are only run once while these conditions remain true. Once one of these conditions is false, the event can be run again. This simply prevents us getting stuck on the wall when we try to dismount.

We’ll now use our “grabbing edge” variable as a condition in event 4. When “grabbing edge” is 1, we do not want the player to fall to the ground or be able to move freely – so we’ve forced his x and y speed (a value measured in pixels per second) to 0. Our PlayerBox now hangs from a ledge when the necessary conditions are met. Our final two events deal with dismounting the wall. For now, there are two ways to do this – By jumping off or dropping down.

And that’s pretty much it. I suspect there will be updates to this code in the future – we might want more ways to get off the wall, for example. We might also want to make some ledges impossible to grab, so we’d need an extra condition check in events 2 and 3 for that. But it works nicely for now, and it’ll be easy enough to expand when we need to.

Don’t expect me to do this with all the code, as we’d probably die of boredom before then, but I’ll probably post up examples like this from time to time. Who knows, someone may even find them useful tutorials or something. Feel free to make use of any events I post up here, by the by.

Next time, I talk about the necessity of having at least two jetpacks in the game.

Don’t expect this to be a comprehensive guide to Construct; the Construct site has plenty of documentation up on its wiki. But essentially, this is the sort of thing you’ll usually be looking at while building a layout:

Click for the larger image. You know you want to.

In the middle is the layout itself. Most of its contents at the moment are sprites. The “Ground” is actually a tiled object – a resizable object with a repeated pattern which is perfect for quickly laying down tiled areas. Also making my life easier is the grid which I have switched on, marked by the small dots across the screen. I can choose to show or hide this, as well as force objects to snap to it when I move them or resize them.

The “Objects” toolbar lists everything on this layout, and if we wanted to add another slope, for instance, it’s as easy as dragging from the objects list and dropping it somewhere on the layout. We can also make use of layers, as seen on the right. This is especially useful for making sure HUD elements, like our crosshair, are always drawn in front of other objects.

On the far left is the properties dialogue. This changes depending on what we’ve selected. At the moment we’re seeing the properties of the layout itself, where we can change the size. Each object has its own properties – to add movement to an object, for example, we’d add a new behaviour using the properties dialogue. Setting our PlayerBox (the player’s collision mask) with a Platform Behaviour does all the basic collisions for us; all the various pieces of the floor have been given the “Solid” attribute, and the platform engine responds accordingly to ensure the player doesn’t fall through the floor or walk through walls. It really is that simple.

We’ve not even started coding, and we’ve already got:

• a basic platform movement set up
• a test area built
• a camera that focusses on the player (though we’ll be making this more complicated later), and
• a crosshair which is aimed with the mouse

Chances of it remaining this simple? Nil

Coming up next: A whole six lines of code! with at least three comments!

Early sprite mockups for the game

So, here’s a first stab at getting the size and style of the sprites down. They’re loosely based on some older stuff I had sat around on my hard drive, and I’m rather fond of them.

In order, these are a generic female and male sprite, a small child, and an old man. There’s four variations on a theme here, which are as follows:

1. No outline
2. Outline around the edge of each sprite
3. As 2, but the line also goes round each hand to mark the forground arm out more clearly
4. As 3, but with the background arm seperated from the body by a line
Personally, I’m torn between numbers 2 and 3, but I don’t really need to decide right now. Colours and shades certainly aren’t finalised, and there’s also some other things I would need to correct (The legs on the child are a little off, for example). The point about this style is that it’s relatively easy to make new characters. The old man, for example, is just the male sprite with no hair and the head dipped forward a bit. The shading is also delibrately simple. It makes things easier for me, but too much detail could overwhelm tiny fellows like this. I like the “less is more” approach.

Finally, a quick game window test is below. I’ve gone with 512×320. It’s a slightly odd size at first glance, but I do want quite a bit of window space around the player (We’ll see why when I talk about the engine in more detail). 512 will scale up nicely to 1024, which will mean those on a 1024×768 or 1024×640 resolution should be able to get a nice fullscreen or maximised window with everything scaled up to x2 pixels.

The grey cuboids are purely decorative

I’ll be building it in Construct – A free, open source piece of Game Creation software. You’ve probably heard of Game Maker or Multimedia Fusion, or at least played some games made with them. Construct works in a similar way to MMF. You drag objects onto a frame to lay out the level, and use a mouse-driven interface to set up event sheets which represent the actual game code. Given that my actual coding skills are dodgy at best, this works for me.

Task one is to get the basics of the engine up and running, which I’ll do over the next few days. After that, I’ll start talking more about the game as a whole, the key features, and a bit about story.

I’ll also take bets on how long I actually keep this going for.