Gaming Your Way

May contain nuts.

Nearly there

We're pretty close to Outpost:Swarm being gold, we've just finished working through the amends, so it's just a couple of little bits and pieces dealing with the portal's API to finish off, and we're done.

Should we celebrate with a screen grab of level 2 ? Yeah why not,

I'm sure there will be a couple more screen grabs before it's actually live. Ah pimping, it's what makes the web go around.



As you can see, my imagination for snappy post titles has long gone.

Ok, we're two weeks into DN8:Pulse, what's new ?

Well we've got baddies in there now. They follow patterns and detect the player bullets. In terms of the sprites themselves, I use the same code as in DN8 to generate them, creating 30 random ones every level. These are stored in one bitmap and then converted to a texture which we can then use to batch all the baddies.

As you can see we've got paths in there too. These are again batched sprites just plotted on the curve which we use for the baddies movement. You'll notice they're strangely thicker in places, that's because they pulse to the music ( Yeah, the name makes more sense now doesn't it ).

The baddies move and blow up when shot, the explosions are also connected to the music, and the paths are drawn. That's about it really. Last night I reduced the stage size from 854x480 to 700x480. Not for performance reasons, but to make it more portal friendly.

Also a couple of days were spent playing with Air 3.2. It's mentally impressive ( Even more so when I remember back to struggling with the very first beta Air for iPhone ). The paths affect the performance, but when they're not displayed it's a rock solid 35fps, and that's on my Desire S. It's feeling good that this is going to make it to the Android market.

And I think that's about all. Not the same huge steps that happened in week 1, but that's to be expected. It feels like it's going to be really good and that is more than enough to make me happy. If it turns out to be really good, well we'll have to see.



You've got to do a blog post on leap day haven't you.

Work started on new game a week ago, and somehow I've managed to get a fair bit done. Want to find out what ? Sure you do, because if I ever found out you weren't interested in our games I'd start hurting myself.

Let's start with a screen grab, it's easier to talk around that.

It's a little cut off as it's a big ol' screen, it's not that wonky in real life.

So as you can see it's a sequel to DN8. In saying that, it's going to be more of a 1.5 than a full blown sequel, a directors cut where we give it a visual overhaul and fix all the things which needed fixing.

The major thing with this bad boy is that we're going the stage3D route. And just to complicate matters, its using 2 engines. The background ( So the skybox you see, the planet with nice bump mapping and specular lighting ) is powered by away3D. It's really great to use, I've only ever used the lite version before so it's not as if I knew what I was doing, but I managed to get one planet and the skybox up and running in a couple of hours.

The downside to away3D is that its 2D support is limited, and for particles the general consensus is to use something like Flint. Now Flint produces great results, but packages like that are all singing and all dancing, which means an overhead which you can't really afford in a game ( It's like say Tweenlite, knock the shit out of that on the title screen, but in-game it's a little too costly ). I've being eyeing up ND2D for a while as it seems the best of the 2D GPU powered engines ( Friends who have tried Starling say its a little bit bloated as it's trying to be very transparent and displaylist like. Just to point out, I'm not slagging it or Flint off, I'm just going on hearsay as I'm far too lazy to do lots of tests to find things out ).

Now, how to add ND2D running on top of away3D ? Well I noticed you can have multiple stage3D indexes, I'll drop away3D at [0], ND2D at [1], set the transparency and swallow a little extra overhead as well, shit, we're on the GPU baby, everything is free and runs like liquid gold. Ah. the different stage3D "levels" don't have a transparency setting. Ah.

Plan B, download the away3D source ( I was just using the swc ), shove ND2D into the same package, find the render call in the away3D code and after that call the ND2D mainloop. Fairly simple. Hang on, it's displaying my simple particle test, but for some reason it's above the skybox, but below the planets. That's so close to working I had to pursue it, as if I could get it working we'd be laughing. A whole day of swearing and looking through both engines and I was having no joy. It was making me want to kill.

It takes a big man to admit when he's wrong. I'm far from being a big man, so I just posted on the ND2D forums asking for help. Lars is as good as gold and pointed me in the right direction, one changed line later and it works.

So in the first week we've got the look & feel nailed ( That was actually day 1, a whole day just to sort out a logo, a font and a rollOver style ), got a lovely looking background rotating around, most of the flow from title screen to actual game, the main player sprite moving and shooting ( The bullets using batched calls ), the music from DN8 as a placeholder playing a random mix each time and... I think that's it. I couldn't be more pleased with how its going, I don't have the first clue about 3D so to bluff my way through like this makes me happy.

Should we come back in a week to see if I'm still loving this ? Yes, lets.



One thing we found with Outpost:Haven ( I've got to start using its new full name so I get used to it ) that having the players footsteps generated a lot of atmosphere.
Early in the game we thought it was key that there was only really sound effects as it helps create tension, you know something bad is coming, but there's no real indication of when. By stressing every little noise, including the player themselves, it helps draw that suspense out.

How we did it was really straight forward and really not costly in terms of CPU time.  

So that's the actual map as it's laid out in Flash ( Minus the more ugly things you don't need to see, like collision maps and objects ).

We also have another footmap movieclip which looks like this,

Just simple colour coded floors ( The walls are just there for illustration ). When creating a level that mc is copied into a scaled down bitmap, where 32 pixels in real life equals 1 pixel in our new footmap bitmap.

Then as the player takes a certain number of steps ( From memory it's the equivalent of a tile, so every time you walk 32px ) the game uses a getPixel(playerXpos,playerYPos) to read the pixel colour of the footmap beneath him. From there we pass that to the SoundHandler class which plays one of the different foot step sounds we have ( The green is a normal step, the blue is a metal grill type step etc. ).
To flesh the illusion out we actually have four types of footstep sample for each floor surface type.

Give it a try in your own game, it adds so much and is as simple to do as this.


Unhappy meals - and that's OK

If you come here often you might have seen the screenshots of the "random mine" game, well this one won't make it to a full game.
There's a good reason of course (actually there are a good number of reasons).
I still like the appeal of random created levels, but this one didn't quite work as well as I thought. The early alpha version showed that a jump & run game needs carefully designed levels in order to be fun and you can't fake that by adding elements from other genres.
That was something I discovered pretty early in development and changed the idea from "really random" to "random pieces" or blocks.
This created levels that were playable, but in worst case quite repetitive. The obvious thing to do was to create more variations of the basic tiles (or parts). 

These are the basic blocks the generator used.

A version of the 0101 block.

I create a set of variations for the blocks (each one uses 30*20 ingame tiles) which worked well at a first glance.  But due to the random nature could appear multiple times in a large map. That drained the fun more than I expected. In the end it proved as much work to create varied and fun blocks as to create a whole level.
Tough decission, but I didn't want to design a jump & run game, I wanted to write code that does that for me.

Zipped and stored away for later use.


So while Squize works on an AAA title I'm back at the beginning of a new project.


You've seen Knuckles (I think he might change a bit in the end), the main character in the Unity game I decided to do (that mine game should have been done in Unity in the first place, too - but flash seemed to be make a faster development possible).

The Idea for Nuckle's game evolved from a 2d sidescroller into a 3d game, so using Unity seems the better choice - even though there's the promissing stage3d api around.

Right now I'm focussing on the controls, aiming at a mouse only controlable game, but adding optional keys for movement. I think point 'n' click controls are what I'll use in the end.
But first there's a lot of stuff to code for the first level and I need to find ways to wire things in the game (like alarms and lights) to create an working environment.
If that proves to be "fun", more things can be added for the later levels (guards, cameras, more types of alarms and security).


Night vision effect

I thought it may be interesting to go over how we did the night vision level in Outpost ( Yeah slight spoiler I know, level 3 uses a night vision effect, there I've said it and spoilt it for you. I also spoilt it for you if you saw our halloween post ). 

The way we store the levels is slightly weird, I've touched on it in an earlier post, but to go over it quickly we use the Flash IDE and shove the different layers in movieclips ( Such as the floor, the walls, shadows etc. ). The plus side of this ( There are many to be honest ) is that we can just use the AdjustColor filter and grey scale our tiles.

We already use a vignette in the game, it just creates creepyness and brings focus to the centre of the screen, where the player sprite is. For the night vision level we add another much tighter one to create the impression of a much reduced field of view. This has another cheeky little bonus, which we'll come to.

Next up to enforce the effect is a static animation. Use a noise filter in your usual art package, import it into Flash as a mc. Rotate it around so you have 4 different frames of "Animation" and that's it. On top of that we drop a simple green rectangle and use the Overlay blendMode, and hey presto, our grey scale tiles are now looking pretty damn green.

You may be thinking this is costly CPU wise, but this is where our tighter vignette comes into it, we only have to run these costly items at a reduced size ( Only 320x320 rather than the full screen size of 640x480 ).

Next up, the lights. We have a nice light movieclip which we use on the other levels, I just duplicate this over and over so the intensity is really increased ( BlendMode.ADD is the daddy for things like this, I'd use it on everything if I could. Some past games I have ).

Finally the anamorphic lens flares. They're just so sexy and may be over used in AAA games, but still seem quite rare in Flash. It's just a nice subtle effect and really easy to do.

In Flash just create a straight forward gradient, rather like this one.

In real life you'd alpha out the ends so it fades to nothing on both sides, but I thought it was clearer like this. Convert it to a mc, and blur the crap out of it, with more blur on the x. Convert that to a bitmap and you've got,

It's blurred out to almost nothing, but we're going to use ADD and it'll be on a transparent background ( Plus we're going for subtle ).

In terms of code it's a distance to player check. As the player gets closer we increase the alpha, and when the player moves away we drop it back down.
Again you'd think that running alpha on a 640px wide image would hurt the performance, but Flash seems to be able to cope with it fine, and the lights are spread out where we can, so there's never a silly amount of them running at once.

This new blog software puts the authors name under the heading, but I like to finish off with my name like I'm signing off, so it looks silly doesn't it.


Object Pooling, nice and simple

I promised to write an article for a mate over a year ago now about object pooling. As you can see, I'm a little late ( And with apologies to Michael, I don't mean to be shit, I just am ).

Ok, pooling. To sum it up it's a way of re-using objects. Creating new objects is costly, so rather than killing them off we just store them away until we need them again. Pooling is perfect for things like baddies, bullets, particles etc.

Let's get down to it.

In our baddie class we have the following,

public var type:String="Baddie1";

Just a simple identifier, obviously the number reflects it's ID.

We'll come back to that.

In our BaddieHandler class we have the following,

		private function createBaddie1(data:Array):void{
			var baddie:Baddie;
			} else {
				baddie=new Baddie1();

That's straight forward ? Ignore the data:Array and the init, that's just passing the x,y positions to it.
So we check baddie1Pool ( In this case its a Vector, an array does the same job ). If there's a baddie object in there we grab it and use it. If not we create a new instance.

Let's go back to the baddie class, when we declare it dead we simply do this,

return "dead";

Back again to our BaddieHandler class ( I've structured this well haven't I ), in our mainloop we have,

		private function mainloop_normal():void {
			var baddie:Baddie;
			var cnt:int=0;
			for each (baddie in activeBaddies){
//We can live with defining vars in a loop, as it should only be needed once per loop
					var type:String=baddie["type"];
						var functionCall:Function=this["returnToPool_"+type];

So we loop through the active baddies array, running the mainloop for each baddie. If we get returned "dead" as a string we know we've got to put him back in the pool. This is where that identifier from the start of the post comes back into it.

Finally we have a simple method for putting it back into the pool itself, eg

		private function returnToPool_Baddie1(baddie:Baddie):void{

The nice part is the use of identifier and the dynamic function in the mainloop, see how we create this["returnToPool_"+type] and then just call it, no messing around with any conditionals to see which pool we should
put the object back into.

And that's how simple pooling is. If you want you can pre-populate your pool ( ie create 30 baddies right at the start of the game, so there's no slow down as you slowly fill the pool to its maximum level ), I just find it easier on my brain to create the instances as I go.


More Nuckles


Pretty much where I want it to be now. Not textured yet and only using plain colours.
I guess I'll add bones now and do a simple walk cycle. With that in place it's time to do some environments (and props) for walking around in.



Some JJ loving


Sorry about the lack of posts recently ( And the formatting in the last one, what a nasty wall of words that was ). Still waiting for the two client projects to come out, although they're both pretty much just waiting for sign off now.

Thought I'd show a little love I've added to Outpost today.


Dropped an anamorphic lens flare in the game 'cause they're this years lens flare aren't they. Pleased with how they look, and that's just with my art in place rather than the real final art.

Also added "Swarm" mode. This is basically Firefight / Horde from games I'm sure you've played. The maps are nice and small and I'm really happy with how they play, it's like Geometry Wars / SmashTV and it gives the game some new life. I've done 5 levels of it, and I think that should be enough. I'm hoping to add some new graphical effects to each one, just to try and lift them off from the main story mode, so for example in the first level there's some nice huge fan shadows spinning around.

I wish I could show more of the game and open up a beta as I feel like I've been talking about it forever and it must be wearing thin for you guys. As soon as we get some final assets in there I'll be able to, it's just that ( For example ) just to balance the swarm mode difficulty correctly I need the terminal in there so you can buy weapons / upgrades.
Its one of those projects where it'll all come together in the end, which is frustrating.

This is far and away the best thing I've ever done, and that makes me happy.