Gaming Your Way

May contain nuts.

The world in words and pictures

My calendar icon tells me it's Monday  - and July already. This means I've not only missed the start of the summer, but also don't know what happened during the last six month.

All I know is that I started to work on a small scale semi top-down racing game that should be finished in "not more than 3 weeks solid work".


Anyway, the blog needs writing and images.

I've added a new car (see image), coded parts of the backend (for storing tracks "in the cloud" - just to use a buzzword) and a lot less bugs than on my last post. All tiles have been redone, as I needed to split the floor (road) and side (rails) colliders and even a few deco tiles have been added to the editor.

"Right away Michael."

"Look, it's a tree"

What I don't have is solid physics and a working AI. The first is a matter of bending the rules to my favour - which slightly collide with the rules the physics engine believes in. The latter results in parts on the first problem and my stupid idea to control the AI cars using the same principles as the player car, read instead of telling the car to "drive at speed Y" or "turn left X°" I simulate the controller as if a human would be playing. Of course I have a stupid (but perfectly valid) reason for that - playing back things.
Right now I'm brewing a nice mix of waypoint driving, raycasts and player data and it nearly works the way it should, well it works the way it should, but at times it fucks up due to "unforseen" events. 

I'd love to write some more, but just as the weather became fine, there are deadlines to meet ...



The middle of June, so soon ?

I didn't realise I've been neglecting the blog like a prisoner trapped in my basement dungeon for so long ( Best you forget all about that basement dungeon thing ).

So what's new pussy cat ? I've finally added the sentry gun, so all the weapons are complete now.


You can see the area it covers ( Still only placeholder art for now ), and it just rotates between those two points unleashing hell on anything which comes into it's line of fire.

I was concerned it was going to be over powered, but it doesn't seem to be. The real test will be in Swarm mode, so hopefully next week ( I've got some client work which needs killing off, which is partly to explain the lack of updates here ) I'll finally get to add a Swarm level in there which will be good for testing.

We got some great feedback recently, and one of the things which came up was the aliens were seen as being a little too fool hardy, so I've tweaked their AI slightly ( Again Swarm mode would be the best place to test this ), so for the larger "Tank" aliens instead of just moving randomly when they are first triggered [ Off screen ] they start path finding towards the player. Not exactly what was meant by the feedback, but it won't make the game any worse for doing it.

The past week, between html games, I've been working on the new terminal.

Lux has done a great job in redesigning how it works. We've stripped out a lot of the filler from the original one ( No Plan 9 From Outer Space this time ) and it's a lot tighter and easier to use because of that.

Obviously coding it has been a complete bitch, but it's getting there. All the weapons are done, so just the supplies left and a large chunk of in-game UI will be ticked off my list.

Installed the new Flash CC yesterday. It's really good so far, it's like what Flash should be. One of the reasons I've been itching to get hold of it, aside from it making the level design much less painful ( On complicated levels, like the planet based level 3, Flash doesn't work in real time. You move up 10px you get the spinning wheel. Hopefully Flash CC will remove that ) is the LZMA compression it offers.
I had a quick play with using Flash CC to build the game using that, as opposed to Flash Builder, and the release build file size went from 12.3meg to 11.7meg, which is a really good saving.

In terms of a rough road map, I think I'm going to be working on the terminal the rest of this week and then hopefully next week I'll be able to add one Swarm level into the game, which is perfect for testing a lot of things. We've also got loads of exciting news that's just around the corner, in fact it's been just around the corner for weeks now, which is maddening. But we're getting closer, and I can't wait to share. It's pretty fucking cool.


Colliders are mean shits in Unity, let me tell you.

Lots of problems have been revealed since I started to roll my own set of car physics *without* car physics. At first it all seems so easy and logical, get rid of wheels, torque, motor and what not else to get a better control over the car's handling and setup.


(first setup, notice the shitload of settings ...)


I wanted to be able to take the car and set a top-speed from 1 to 10, as well as acceleration, a value I called "handling" and maybe "boost" or something like that.
Normal wheel based setups are a bugger to tune and I've spent a fair time trying to get the values right but still it felt ... wrong.
Anyway, the idea was simple enough: make a rigidbody box (so I can have "easy" collisions) and move it along the track, but you cannot simply move rigidbodies (or it isn't a particulary good idea as physics calculations depend on force). 


(simple box collider setup)


OK, just apply force to the box in the direction I want the car to move, which works (in a way) but then failed after I altered the track's physics material to behave more like a road.
Now the friction killed any movement and the easy solution was to just let the box float (representing the car's body only) and that seemed to work well until I recalled that I have sloped tiles. "Oh no problem", I thought and was wrong again.

[we fast forward here a good deal and stop at a point where I have a semi floating box that is always aligned to the ground, does slopes, accelerates, breaks and what not else]


(new setup, less settings, looks odd, but the
capsule colliders have their purpose...)


Looking at the image you might ask where the difference is, the most obvious are the 4 capsule colliders at the car's corners and you might have noticed that the wheel colliders are back.
There is a simple reason for this setup: it works. Using wheel colliders with no friction is heavy cheating, but it keeps the car's body afloat and always aligned to the ground (esp. on slopes). Reading out their contact points also allows the put the tires on the ground and using the suspension.
The rest of the setup consists of a box collider for the car's body and four capsule colliders (not really needed, but they simplify the handling of some of the collisions).


On to colliders ...

Reading out collisions is easy and Unity offers three events to track these:
- OnCollisionEnter
- OnCollisionStay
- OnCollisionExit

"Oh cool, just listen to OnCollisionEnter and detect when the car crashes into something."

In theory, yes.

In reality it isn't reliably reporting when you collide, and OnCollisionStay is reporting all the time as the wheels nearly always touch the ground (as they are part of the rigidbody setup).

But this is the story for the next post ... 



Let's see if this works

Giving Vine a quick try out, as it may be handy for posting quick clips here.

If it's all gone to plan that should be the flamethrower in all it's too bright to capture well on an iPad glory.


Spot the difference

Work's going really well on level 5, only started it this week and it's coming together already.

This is what you guys will see

This is what I see.

I've managed to speed up a lot of the plotting routines this past week or so ( I've moved over to ASC2.0 which is fantastic, it feels like it's not actually compiled any changes it's so quick and it reduces the file size a bit too ) which means I've been able to drop a parallax layer in level 5.
( Also after my previous post I looked at the level construction times. They've been speeded up like a billion percent. Where the larger levels could take up to 5-10 seconds to plot they now take under 2 ). 

Also we've got this nice lens flare effect which you can kinda see in the top grab. I guess you could call it a HDR effect and really alters the whole lighting of the level. Maybe I'll try and grab a clip of it as it really is one of those effects you need to see in action.

Ok that's it for today, someone's got to do a million white rectangle collision boxes for this level.


Flash FullScreenInteractive and Chrome

Look at that for a SEO type subject title, I hate using them and would rather revert to something stupid / flippant, but this is meant to be an actual useful post, so I guess I shouldn't obscure it too much.

We've been having problems with FullScreenInteractive in Chrome since first adding the feature to Outpost 2, it just scaled up wrongly and was basically broken ( You can't even seen the accept / cancel requestor properly ). Damn you PepperPot player and your added weirdness. So here's a couple of gotcha's for you to hopefully save some pain.

Firstly stage.allowsFullScreenInteractive isn't what you'd think. My idea was I'd hit that value up and if it was false then don't bother displaying a full screen button as an option. That would be too simple. Apparently that only returns true if you're already in full screen interactive mode which makes it totally useless as far as I can see ( You could either read stage.displayState or just set a flag in your own code as you kinda know when you've gone full screen ).

Ok, that wasn't really the bug, just a crushing disappointment connected with the whole mechanic. Here's the actual money shot,

"The fullScreenSourceRect property can only be set when Flash Player or AIR is not in full-screen mode. To use this property correctly, set this property first, then set the displayState property to full-screen mode."


When working in either full screen mode you really need to use the fullScreenSourceRect property to enable hardware acceleration. This is just a rect you set to the size of your normal stage, once done your content flies along ( O2 runs the same full screen as it does normally ).

Turns out this was the problem, when I removed the rect call it scaled up correctly in Chrome, but ran like a dog. Let's try adding the rect setting after going into full screen interactive, yeah we're ignoring Adobe's rules, fuck the man.

Hey presto, it all works. The requestor dialog isn't quite central, but it's the same on Safari and to be honest well down the list of things I care about, as I'm sure that's a Flash quirk that I can do nothing about.

There you go, hope that's some help,


Big restructuring time. Again. *sigh*

Way back in the days of Outpost:Swarm I wrote how we did the Wingman AI ( Here if you're interested ). Well, that's had to change.

The past day or two I've been re-working it so it uses the same pathfinding routines as the baddies. The reason for this ? Hang on, let's liven this post up with a picture of the new C4 weapon first otherwise it's going to be really dull.

It means I don't have to maintain two pathfinding type approaches, one just for the wingman and another for the baddies, which is a bit mental. Plus we're going to be adding human baddies on level 8 ( The one in the grab above ) so "fixing" the wingman AI is a good template for that.

This hasn't been too painful, but a knock on effect from this is needing to update all the bullet classes. Quite a lot of people mentioned in the feedback to Swarm that they'd like it if the wingman changed weapon, so we're going to add that. The game engine was never really designed for that, hence my big re-write of the code for it today. So the wingman will have access to the assault rifle as before, as well as the pulse rifle, the shotgun, the SMG and the flamethrower ( 'Cause it looks so sexy not to let him use it ).

The bigger plus side to all this is that the baddie humans on level 8 will also have access to all these weapon types. Aliens and humans fighting each other, and you and your wingman, all using different weapons. I can't wait.


Level plotting hang

We've got an issue with Outpost 2 with the level construction ( We call it "Loading" in-game but we all know that's a lie, we're just plotting things rather than streaming data ).

On the larger levels it takes forever, and on slower machines it could throw up a script taking too long error. I've always assumed it was creating all the objects in Nape, but I thought I should be good and run a little test. Glad I did.

plotFootMap - Elapsed time: 27
plotWallsIntoMap - Elapsed time: 1
plotPath - Elapsed time: 0
plotBackground - Elapsed time: 4621
plotBumpMap - Elapsed time: 1079
getCollisions - Elapsed time: 63
plotShadows - Elapsed time: 2623
plotBatTriggerMap - Elapsed time: 0
getObjects - Elapsed time: 30
getNodes - Elapsed time: 13

I really wasn't expecting that. Without going into it too much, with the plotBackground method we basically use the draw() command to copy 640x640 parts of a movieclip into bitmaps for the entire level.

Bit of a nothingy post I'm afraid, just thought it'd be interesting to share that you can't really make assumptions about code bottle necks ( The two calls which deal with Nape, getCollisions and getObjects are blindingly fast considering how many objects they have to create ).

Now we've identified the problem properly it's just a case of fixing it. The simple part.


So I've split the plotting routines up, and speeded them up slightly, so now the times taken are:

plotFootMap - Elapsed time: 11
plotWallsIntoMap - Elapsed time: 1
plotPath - Elapsed time: 0
plotBackground - Elapsed time: 792
plotBackground - Elapsed time: 748
plotBackground - Elapsed time: 761
plotBackground - Elapsed time: 748
plotBackground - Elapsed time: 774
plotBackground - Elapsed time: 477
plotBumpMap - Elapsed time: 1015
getCollisions - Elapsed time: 60
plotShadows - Elapsed time: 235
plotShadows - Elapsed time: 230
plotShadows - Elapsed time: 449
plotShadows - Elapsed time: 443
plotShadows - Elapsed time: 417
plotShadows - Elapsed time: 275
plotBatTriggerMap - Elapsed time: 1
getObjects - Elapsed time: 35
getNodes - Elapsed time: 14

By splitting them up like that it spreads the load on the CPU so we can drop a simple progress bar in there. Nothing major I know, but it's important to show some sort of feedback instead of letting the player think the game has crashed.



Entered Ludum Dare for the first time this weekend. I've done 48 hour game jams before, years and years ago on FlashKit ( Actually won one ) and I just fancied the challenge, plus I actually wanted to just complete a game. It's been so long ( The downside to working on Outpost 2 ).

The Game:

The theme was "Minimalism", which when you've got to do your own art isn't a bad theme. I was awake when the theme was posted on Twitter, which was at silly o'clock UK time ( 4 am ? ) and I just went to sleep thinking about it.
What I came up with was a world that was going to be very clean and sterile in iso. Lots of cubes, cube particles, cube sprites. It was inspired partly by Marble Madness and an old Spectrum game ( Which my mate Bas mentioned when we were chatting about it, which was strange, as it's quite an obscure reference ) Quazatron.

Which in itself was an iso remake of Paradroid ( My favourite game ever ). The clean visual style I had in my head was of an unreleased official remake of Paradroid that just looked stunning.

So lots of clean white iso lines.
That was the look & feel sorted, next, the game play. I figured with the theme the player should be making the game area minimalistic, bringing some order to the chaos. Another one of my favourite games is WizBall, where you have to collect colour and paint a drab world.

So let's do the opposite of that, lets position the player as almost a baddie, turning a beautifully coloured world to a nasty plain drab one.

It just needed a name. R.G.B was an early thought ( I'm glad I didn't go with that, ) but felt a little obvious.
It was all about Colour, and keeping with the theme I stripped that right down so it was just C... ( Written in game as C [Dot][Dot][Dot] ).

What went right ?

Let's do this one first, save the nasty 'til last.

The look & feel turned out really well. I knew I couldn't spend too much time on the assets. I can do pixel art to a degree, but it takes me forever.
I lost a ton of time trying to get the colours plotted correctly. I had this vision of undulating hills with stunning shades of pastel colours all overlapping creating lots of different hues ( I was thinking of a pretty version of the Red Weed stuff from War of the Worlds ).
Instead what I got was this:

It took ages on the last day to actually mix the colours as I wanted, and even then I never really nailed the shades I wanted ( Remember, this is the stuff I thought went well ! ).


The level generation worked so much better than I could have ever hoped. I used Perlin Noise to generate the height map,

It took a couple of attempts to gauge the height of each tile sprite correctly so they appeared like a solid wall, but aside from that it went really smoothly, and once I could scroll over it it looked great, I'm so happy with that.


The colour bomb mechanic was a late addition. I realised that if I was going to have lots of baddies milling around I had to either make them slow, zombie like and you'd die just to their weight of numbers, or speed them up but give the player a weapon.
I couldn't have directional shooting, it would have been a massive pain to do with the different heights of the map ( There's no depth sorting going on ) so it had to be a smart bomb type weapon.
I couldn't just give the player three to start with and I didn't have the time to add collectables. But hang on, don't we technically collect the colour emitters ? ( Well we don't, we just destroy them, but it's just a game kids, I'm allowed to break the rules a little ). There's also a certain nice irony that the colour emitters can be turned on their defenders.

For the visual effect it was an obvious thing, let the whole level wobble like a giant water drop. I left the player's tile untouched, partly to keep that slow motion water drop effect and partly because it would have been a real ball ache to move it too.
I abused TweenLite a lot to create the effect and it came out pretty much how I pictured it in my head, which is a rare treat.


And that's all I can think of that went well. The particles the colour emitters ( And the sprites themselves ) look ok.

What went wrong ?

Less grabs this time, I don't want to draw too much attention to all the bad things.

The lack of sprite images. I'm kinda lucky with the theme that it's a slight way out, but I planned to have the player as a metal ball and show reflections in it to create a sense of movement ( I've written a similar routine for Outpost 2 just the other week so it was still fresh in my head ).
But then I realised that it may look weird the player being this detailed sprite in a world where he was trying to make everything drab, so I would need to give the baddies some love and... just out of time with it all, hence the baddies being the same sprite just tinted, which was a crap cop out.


Speaking of the baddies, the AI was the very last thing finished. I had massive issues with it, which I wasn't expecting, as they're ultra simple ( Is the player to the right of this baddie ? Yes, move right. That's it! ).
I had pre-calculated all the possible positions on the map and I was using a simple tweening code to move them, but they'd go mental after a little while. Turns out I was accidentally over-writing my coord values so their movement was getting more broken as the level went on.
By the time I'd discovered that ( On day 3 ) I'd ripped out my tween code assuming that was wrong and replaced it with TweenLite. Now TweenLite is fantastic, but you don't want it running in-game, it's for title screens and other transitions.
The performance is ok on my machine, but it's a beast when it comes to Flash for some reason, it's probably going to be dog shit on a lot of peoples machines.
I also wanted different baddie types. The one really clear image I had when I nodded off on Friday [ Saturday morning ] thinking about the game was having these sand worms type baddies. They'd burst out of tile with a shower of cube particles and arch there way across the screen. Picture Loch Ness style humps, like a snake where you'd see it's arches / humps. Even thinking about it now makes me want to do it.

The chunk scroll came back to haunt me. What looked so nice with just the static objects, looked fucking dreadful when I had moving baddies in there. A combination of them smooth moving whilst the player moved a tile at a time just didn't work. It's my least favourite part of the game and in hindsight I would have smooth scrolled the whole thing and added fogging to edge tiles to try and soften that out.

Lack of time / planning. I always just wing things. If I don't know how to do something I just put it on the back burner as there's always a million things to do when writing a game anyway, and then normally my brain just works it out for me in a bolt of inspiration.
You can't rely on that when pressed for time. Every little thing seemed to come back to haunt me, an added complication I wasn't expecting, and that's partly why I missed the comp deadline and it slipped into day 3 making it a jam submission. Which annoyed the shit out of me, I hate missing deadlines.


There are other things, I'm not overly loving the gameplay itself, it's very basic. Also the map was a late addition, then I realised you actually see the colour splat before the emitter shows up on it, so that was pretty pointless ( When I first did the map I did it with each emitter just being a pixel, turns out a pixel on a map is very very tiny and pointless ).
I'm not overly happy with the sounds, they were very last minute and pretty much the first things BFXR spat out at me. Outpost 2 has 212 sounds in it's library, I just couldn't face spending a ton of time on these ones. Again minimalism was a blessing.
One last thing, I decided to give Starling a try as I've been meaning to use it for ages and this seemed a good chance. Ripped it all out Sunday as I wasn't happy with the colour shading on the tiles, so that was a bit of a waste of time. 

Conclusion ( Or the bit you skipped to )

I really enjoyed doing the comp, the team spirit within the community is great. I can't express how annoyed I am with myself for missing the comp deadline, but overall the game's ok. Well rather, there's a good game in there somewhere, I just didn't manage to extract it.
At least it's a playable game and I've got a real taste for LD, hopefully I'll be entering future ones.

If you'd like to play the game / grab the source / vote / comment here's the link:


Hot, hot, hot

Just a pretty minor thing to share really, but I'm really pleased with it.

With doing the inventory I can now unlock all the weapons, so I've been going through giving them a tweak here and there. The flamethrower in Outpost:Haven was always a bit crap. It didn't look good and ran really slowly, so I've been giving that some love today.

It's 90% more glowy and runs a lot smoother. With the original one we were actually firing out 3 "bullets" at a time and scaling them up, together with the ADD blendMode it was just a combination of ugly scaling and not bright enough. It just didn't look good to be honest, and caused a noticeable slow down.

With this update I've dropped it down to just one flame bullet coming out a time, reduced the amount it scales up by so no jaggy bitmaps on display. Then I've added a red glow bitmap, the one we use on fires now, and put that over the floor layer to create a real sense of light coming off that thing.
To finish it off I've re-used the red smoke effect we use on the flares ( Such as on level 3, and the outdoor levels in Outpost:Swarm ) so it has a slight blurry / smokey ambient feel to it.

If you spin around shooting it still doesn't look the best, as we're having to use bitmaps rather than a zillion particles to create the effect, but in a real game situation I doubt very much people will be doing that beyond their initial play with it when they've first bought it. Straight line shooting like in the grab above works really well.