Fuck This Jam!

Whew.

I can honestly say I have spent more hours programming in the last week than I would normally do in three. Thanks to a freak of bad timing (or good timing, depending on how keen I'm feeling), I worked on stuff for three back-to-back jam events in a row, on top of my day job. I can sleep when I'm dead, right?

The first of my triple-threat jam onslaught was Fuck This Jam. Organised by the guys at Vlambeer, Fuck This Jam is a massive online gamejam to create a something in a genre you hate. Strong word, 'hate', and the idea seemed to polarise people from the off. I'm not sure I could say I 'hate' a whole genre, apart from sports games, but I think that's more an aversion to sport rather than an aversion to sport videogames.

I toyed for a while with sports management games, which sounded simple in my head: no graphics, a bunch of numbers, easy peasy. After actually sitting down and sketching ideas out however, it started to sprawl and sound more and more complex, so I canned it. Definitely the right decision. I also toyed with an actual football game, and although I canned that in the end too, it was interesting to note that quite a few people did make similar games in the end... seems like the programmer community hates sports. Who'd have guessed?

In the end I chose to look at the match-three puzzler mechanic: I don't hate puzzle games, and I don't even hate match-three puzzlers, but I do hate inane pointless puzzle games that have no challenge or objective. Puzzle Quest = good, endless none-challenging Bejewelled clones = baaad.

I lucked into meeting a chap in the Fuck This Jam IRC channel, by the name of Kieran Lampert (@CandidKlamp), and after batting some ideas around we decided to form a pan-global tag-team and work on something together. Kieran is a total ninja digital illustrator, who does 2D, 3D, and as I found out later, amazing animations too. A general all-round magician. Check it out:

The game idea came together amazingly quickly. In just one quick conversation on IRC we had a basic design doc down, and we set to work. The time difference worked out great too: I'm in Manchester in the UK, and Kieran is in Seattle, so when one of us was about to go to sleep, the other guy was waking up! This allowed us to keep the momentum going well, and meant we were never waiting on each other.

There was a load of back and forth after that initial conversation, but the basic mechanic we came up with was to swap tiles with army units on (think Advance Wars), that would then fight each other. Stats change depending on the terrain, and the unit type. If a unit is destroyed, it's removed and the tiles slide inwards like a puzzle game, and a new unit is added at the side. In keeping with the match-three idea, having adjacent units together forms a battalion and makes them stronger. Oh, and each player gets a load of turns in a row (say, five each), so they can move tactically and keep units togther, that kind of thing.

We'd pre-decided all the pixel measurements, so I was able to stick placeholder artwork in while Kieran did his thing on the other side of the planet. This is the first tilemap engine I made, with some crappy PNG's laid over the top that I screengrabbed from Kieran's email. Did the trick in a pinch:

These then became proper tiles, which turned out brilliantly. Kieran created a great little tileset with land and water, including normal and inverse transitions, which went in pixel-perfect. I cobbled together a super rough tilemapper, in the name of quickness all the levels are hard-coded arrays of values, but it was enough to get by for the jam!

Kieran also animated the units perfectly, and was even good enough to put everything straight into Flash, which meant life was pretty easy for me at the receiving end. I also managed to get the grouping working, so adjacent units are a bit stronger. This is the first debug version just after getting it working:

Everything went well overall, but as always the time factor was an issue: real life started getting in the way a bit, and before we knew it time was up. We'd managed to get everything moving and fighting, and ran completely out of time before doing any game logic. Here's how far we got:

We submitted it anyway, and we're both massively happy with where we go to: it was a valiant effort, all things considered! As a concept I think it's definitely got legs too, and now we're not frantically panicking about a deadline we've agreed that we really would like to see this made into a full game. The code for this version is horrible (as most jam code is), but the mechanic is straightforward. I'd also like to try and get it onto mobile devices too, we'll have to see how that goes. I reckon I might take Haxe for a spin, see if I can't get it compiling onto devices. Watch this space on that front....

So yes, we had a blast making this even though we didn't *quite* get there, and working with Kieran was awesome too. If this jam rolls around again, I'll definitely be taking part. I might even make a football game.

View the full playable submission here!

Roguelike: room generation sourcecode

A few people (hi, /r/roguelikes!) have asked if I'd share my roguelike source code, or at least some of it. As a Flash dev I know I'd be really excited to see how other Flash devs are handling roguelike development, so I figured it's only fair to get mine out there. I'm hoping some gurus out there will tell me if I'm doing this wrong, and point me in the right direction, it's all a learning process!

OK, so anyway, the first thing I'm posting is a highly simplified version of my room generation code, that shows a random single room being built, and a character dropped on to a valid random square. I've also stuck it on an external Pastebin link rather than an embedded one, as this code has long descriptive comments on that freak out a bit when they're stuffed into a thin blog format.

Feedback would be appreciated!

http://pastebin.com/BBPpGPBz

Making a roguelike, Part 1

I read a great thread on Reddit the other day, asking what exercises an amateur programmer can do to get better at whatever language they're trying to learn. There were some great suggestions (notably Coding Kata, but that's another blog post entirely), but interestingly the highest voted one was "make a rougelike". If you're not familiar with what a roguelike is, check this explanation out before continuing... these games are as geeky as they come, but are some of my favourite games ever (look Mum, no graphics!)

My inital reaction to the suggestion was dismissive, given that roguelike games are usually so mind-bogglingly complicated most players (myself included) haven't even gotten close to the end of one despite years of play. However, I thought some more about it and realised that it's actually a brilliant idea. Think about it for a second, the features of an average roguelike are:

- Mimimal graphics, or no graphics at all (mine will use graphical tiles)
- Randomly generated levels
- Randomly generated monsters/items etc
- Stats, lots of stats.

The structure of a roguelike lends itself perfectly to an OOP project; creating lots and lots of small elements to form a huge, randomly-generated game. So, I'm having a crack at it. I must say at this point that I am using this purely as a learning exercise: I don't intend to try and produce a finished game, nor do I intend to write any stories or any of that crap (leave it to the professionals, I say). What I do want to do is get my head around all of the ideas and concepts that make up a great rougelike, and try and build them.

Who knows, if it works well enough then I might throw it out to someone else to populate it with characters and stuff, but at the moment I'm looking at it purely from a 'technical challenge' standpoint.

The big thing I'm finding interesting right now is getting randomly generated levels working, which is the first thing I've got stuck into. I'm going to put together a proper detailed post about each element I build, as well as how the whole project is taking shape.

For now, here's some of the stuff I've been checking out:
- Brilliant and detailed tile tutorial, slightly outdated (AS2) but super useful
- Tilesets archive from some of the more popular roguelikes
- Nethack, my favourite roguelike ever. It's for research, honest.

Basically, this project is about learning some new stuff (and it's working already!), in the most fun and geeky way possible. Much more later! :D

PV3D - Easy billboards

Billboards in 3D are really useful, they're used in all sorts of ways: from particle systems right up to big pseudo-3D elements (remember how in the Doom videogames everything always faced you? Billboards!). Anyway, I was happy to discover that creating a PV3D billboard is easy.

All you need to do is add this to your rendering functionality (assuming "plane" is your billboard):

// Position billboard in 3D space

var up : Number3D = new Number3D(0, 1, 0);

Matrix3D.rotateAxis(camera.transform, up);
            

// Reorient the billboard in relation to the camera

plane.lookAt(camera, up);

plane.roll(180);

plane.pitch(180);

Which will give you:

Of course this functionality could be applied in a much smarter way; if I had a bunch of billboard shapes I'd probably store them in an array and update them all in a loop, but you get the idea.

One of the best things about this (apart from the fact that billboards are much less processor-intensive than full 3D geometry) is that you can set up multiple cameras, and the billboards will shift to point at the new perspective a different camera is used. Handy!

A day with Seb Lee Delisle('s iPad)

Today me and a few other Creative Lynx developers had a rare opportunity to get out of the studio and spend the day marveling at Seb Lee Delisle's iPad. It was definitely worth the £99 entry fee, and as an added bonus we also got a full day's AS3 training from Seb (in between looking at the iPad, touching the iPad, and talking about the iPad).

(image: @theRushen)

I jest. We were in fact there for some more top-notch training from Seb (courtesy of the awesome guys at Technique), who we'd had some training with at the excellent Technique Retreat in Morcambe a few months back. This time the session was on our home turf; luckily Seb managed to somehow get back here in time after the ash cloud o' doom grounded everyone.

There were a few people on today's session that weren't on the Morcambe one, so it wasn't a continuation of those sessions; instead we went down a Flash games route, starting at relatively simple clones of stuff like Space Invaders and Asteroids. The session level was pitched just right: starting off reasonably simple at the start of the day, getting steadily more complex as we got stuck in. Admittedly it was a lot to get into one day, which is kind of why I'm sat here at the moment blogging and writing up my notes so I can hopefully get some more of this to stick!

Seb's teaching style is ace: his work is fun and interesting, and being able to work with a few rough builds before the final finished piece is a great way to see how decisions we make early on affect stuff later down the line. It was also great to see that he got stuck in straight away instead of pondering the details or over-explaining anything unnecessary.This was definitely reflected in the sound advice that it's more important to get stuff working first, and then begin to refine and optimise it later if required. I really like this approach, mainly because I know/admit that I'm one of those guys who gets fixated on little bits of cool stuff rather than making the bigger project work before getting into the nitty gritty. Seb's advice on getting stuff to 'feel' right was important; on a rough platform game demo (just a cube and some platforms) we experimented with gravity and player movement before adding any graphics at all, to make sure that the game really feels right before getting stuck into any of the other elements. Definitely something to bear in mind next time I think about tackling something complicated and terrifying.

We ended the day looking at some awesome motion tracking experiments, the highlight being a multiplayer webcam Pong game that tracks player movement (in a large group of people) to control the bat. This stuff was an impressive (if slightly daunting) way to close the session, and is something I feel an immediate desire to mess with! From a more practical point of view, the games portion was incredibly useful both for stuff I've got coming up and stuff I really want to experiment with more. Considering we were only here for the day I picked up an amazing amount of stuff: covering Pythagoras and trig properly in relation to actual Flash work was really useful: my previous stabs at it have been guesswork at best, so it was good to get a proper understanding of how to use it. We unexpectedly went on a nerdy tangent at the end to get our collective heads around Hex colours and binary shifting too, argh! It was at this point my brain started to melt slightly, but I think I got it.

So overall it was an excellent day, and by the sounds of it the iPhone and HTML folks had a great time too. Seb and (I think) Brendan Dawes are going to be talking at Northern Digitals in August, which I'll definitely be going to. All I need now is a Flash On The Beach ticket and I'm all set.

PV3D: Crumple primitives up

Here's something awesome that I got my head around recently: how to take a Papervision object and warp it so much that it looks like it's being screwed up into a ball (and, flattened back out again!) Like so:

Like with most Papervision unknown territory, I expected this to be hugely fiddly and difficult: in reality it's easy to accomplish in a few lines of code. All you need to do is apply this to your Papervision object (it will work for anything, but a flat image works best visually so you can really see it screw up). Note that this example uses TweenMax to animate, but once you've got it working you can do whatever you want with the shape. Check it out:

// Create vertex array 

public var vertex_array:Array = new Array();

// Write the vertices of myShape to the array

vertex_array = myShape.geometry.vertices;

// Loop through the array, and animate them (in this case firing them backwards)

for(var i:int = 0; i < vertex_array.length; i++)

{    

     // Cast each array entry explicitly to Vertex3D
     var v:Vertex3D = vertex_array[i] as Vertex3D;

     

     // First crumple

     var target:Number = Math.floor(Math.random()*600);
     TweenMax.to(v, 0.2, {z:target, ease:Back.easeOut});

     // Second crumple
     var target2:Number = Math.floor(Math.random()*400);
     TweenMax.to(v, 0.2, {z:target2, ease:Expo.easeOut, delay:0.1});

}

And that's it! Of course this is a hugely simplified example with hard-coded animation, but the possibilities are endless. I think my next step with this is to start messing with more complicated shapes; this will work great for extruding object faces and generally creating more involved and complex animations. More to come with this, definitely!

PV3D: Rotation around a point

A while ago I was using PV3D to try and create a set of three-tiered shops, that popped up section by section as if they were folding up from the base. Like this:

Straight away I ran into the issue of not being able to change the rotation point of the object; Papervision uses central rotation points that can't be messed with, which obviously wasn't going to help me here.

Handily, the solution is pretty simple, using these steps:

1. Wrap the object up in it's own individual DisplayObject3D
2. Move the object up by half it's own height (that's assuming you want to rotate around the bottom edge, like in this example).
3. Move the holder object back down by the same amount (to offset the difference). 
4. Apply the rotation to the holder instead of the actual object itself.

Check it out:

// Create the object (in this case a flat plane):

public var Plane_Pavement:DisplayObject3D;

// Create the object texture

[Embed (source="/../assets/pavement.png")]

public var Bitmap_Pavement : Class;

// Apply the texture to our shape

Image_Pavement = new BitmapMaterial(new Bitmap_Pavement().bitmapData);     Image_Pavement.smooth = true;

Plane_Pavement = new Plane(Image_Pavement, 737, 87, 5, 5);

// Create the holder

public var Holder_Pavement:DisplayObject3D = new DisplayObject3D();

// Add the holder to the stage, then add the object to the holder:

addChild(Holder_Pavement)

Holder_Pavement.addChild(Plane_Pavement)

// Finally, do the offset (assuming our image is 100px high)

// Also remember that the Y axis in PV3D goes the other way!

Plane_Pavement.y = 50

Holder_Pavement.y = -50

// Now if we rotate the holder, we get rotation around the bottom edge

Holder_Pavement.rotationX = 50