Gaming Your Way

May contain nuts.

It's game over man!

That's such a lazy title isn't it ( I bet I've used it before )

Ok adding the Game Over stuff may not seem such a big deal, but it's an essential part of the flow. It's almost a complete ( Rather than finished ) game now, we only need the game complete sequence, which I've not really thought about yet, and that'll be it, the flow from start to finish, which is a great milestone to get out of the way.

The other part of doing the Game Over sequence is that it's a way to test that all your house keeping routines are working, that sprites and particles are being properly killed and put back into their pools etc. I know that happens between levels, but it's still important that the game can transition from title screen > game > title screen again with nothing breaking and everything nice and clean.

You'll notice the blurred baddies. I did try Starlings blur filter in a vain hope that may just be powerful enough, but it gave me 20fps on desktop, and as I keep the level playing in the background it just wasn't going to work. I did find a good looking alternative on the Starling forums ( http://forum.starling-framework.org/topic/code-much-faster-gaussian-blur-implementation ) but by that stage I realised it just wasn't going to be practical to perform a real time blur on a ton of objects.
So I cheated, and just exported all the baddie sprites and bullets with a blur, and adding them to the sprite sheet. We're doing fine in terms of GPU memory, so although it's a little extravagant we're no where near to hitting any hardware boundaries.

That's it, game over man.

Squize. 

That one day of the year...

...where the whole internet seems to competing with itself to be as unfunny as possible.

Fucking April Fools Day, a vacuum of humour.

Anyway we've not posted anything for a while, sorry, I've been a little under the weather, so not been as communicative as normal.

Lot's to update you about, I'm sure I'll repeat myself and / or forget some things, so let's just plough headlong into it.

I had a weird bug where the game broke and baddies just kept exploding, and it looked awesome, so I've actually altered the explosions to emulate that bug and they look much better.
Yesterday I altered the particle effects slightly so they slow down and that looks better too ( Had a play of Geometry Wars for inspiration ).

I've started adding in the player weapons, I think I'm roughly half way through that, the "Pods" are pretty cool.

Adding these meant updating the baddie bullets / baddies themselves so they have collision checks against them which doesn't seem to have hurt performance.

So we've got more weapons in there, the first 5 levels are done ( I discovered Flash' BezierSegment which has improved the paths a lot, both in terms of how they look ( As I was only using one control point ) and the speed it's all calculated ), but the big thing was...

I redesigned the level select system. What a massive fucking pain in the arse that was to do in Starling, I think 3 whole days was spent on that.

Yesterday I had a bit of a break and played with getting the game running on Android. It's almost there, but there are some issues with the FLV playback. Because I'm using the normal display list to show it I just can't get it to position correctly on the different sized screens ( The game is 1024 x 768 for iPad, whereas the Nexus7 is 1280x736 and there are a couple of other oddities you have to take into account ), I even tried using percentages like in html, but no joy. So I'm going to have to re-do that. Joy.

So for now it's just a case of throwing data at the game, I need to finish the player power-ups and adding the levels, then it's sound, remaining UI and Game Center / ads integration.
I want this gold in two weeks time, so I'm in two minds about adding the challenges, they may be a post launch update just so I can hit the deadline ( It may be a case of skipping the challenges for iOS, putting them into the Ouya version to give some added value as we'll be charging for that, and then retro-fit them back into the iPad game. I'm not sure yet, we'll have to see how we're doing for time ).

Squize.

Hitting the boring wall head on

Well the past couple of days have been literally too boring to write about, so I've condensed them up.

The game needs analytics and after trying with Google and having no joy I went with Flurry. Something I've wanted to do for ages ( Way back to the CronusX days ) was to have a 3D globe showing the geographic positions of players, so the past couple of days has been spent playing with that.

Check out this pitiful screen shot.

Yeah, that's me right there.

I'm hoping me adding comma's to large numbers doesn't prove to be a waste of time. So the display side of it is in place, next up is handling load errors and giving the player some feedback whilst it pulls the data in, and then the rest of the stats ( Which I've not really thought about yet, in a shoot 'em up like this there aren't too many available ).

After this is finished I'm going to tackle more of the UI stuff, it's the part I like least ( And isn't the most fun in Starling ) so once all that is out of the way it's a case of dropping in the levels and the fun stuff.

Squize.

Flash is for video, apparently

Today was the start of the big UI push, which I've been putting off. One thing I really wanted in the game was video clips to show the different power-ups so the player could select which one they preferred and could see it in action.

As we're using a combination of Away3D and Starling, I can't use stageVideo. Because it's always displayed beneath everything means trying to cut a mask out would just be a nightmare and not even worth thinking about.

My first thought was to use a sprite sheet, just load it in on demand and update a sprites texture every frame to make a cheap and cheerful video clip.

I made my grab ( Using Screenflow, OSX only I'm afraid, but the best there is ), imported it into Flash and spat out the png frames. Nope, even with it just being 256x256 it blew the 2048x2048 texture size and it was only a short clip.

Ok, let's try FLV using the native display list. It's probably going to run like a pig but best to test these things. Unbelievably it performs well, the clip is really high quality albeit small, but it worked much better than I thought.

Cool, problem solved. Let's just get it looping and... hang on, what now ? Looping it ( Check for it to be finished via an event and then tell it to seek(0) ) makes it glitch really badly, there's a delay, sometimes a fraction of a second, sometimes a whole second. It's a 68k clip loading from a SSD, and it's not streaming quickly enough at the start. For fucks sake.

The solution I came up with was to make a feature of it ( As I'm not going to be able to fix it ).

I grabbed the last frame and used the excellent ImageGlitcher to make it look distorted on purpose. Not ideal I know, and I'm going to have to screw around doing this for every different clip and manage all that, but the best I can come up with.

I should really comment about what a fiddly pain using Flash's own perspective is and trying to align that with an image in Away3D ( Or just trying to get a grab that's loopable ), but I've been moany enough for one post.

Squize.

Luke, use the force...

The past couple of days haven't been the most productive. Some of my linked list related speed ups came back to haunt me, so lots of time spent looking at Scout and swearing.

Next week I'm going to have to crack and work on the UI, which I'm not really looking forward to as it means both design and boring coding, so today has just been simple things, code speed ups to try and replace the ones I lost due to the above mentioned weirdness and I added the force field in.

Performance wise I'm happy with the game overall, it's not always able to stick to 60fps but that's on an iPad3 so not the end of the world, and there are still some ways to try and eek out some more performance ( It's never really bad to the point of affecting the game play ).
It's going well overall, I'm just spent this week, it's been a long one with lots of bits here and there to deal with ( Fixes to the html5 game, pitches to quote for, Skype chats to have etc. ). 

Squize.

That's a bit more like bullet hell

Just a quick update today, in fact I think this grab will pretty much cover off what was added today

The bullets graze the player ship ( See those grey ones ), but don't actually hurt it yet ( The collision checks are in, they just don't call anything ), so tomorrow we'll get the player ship getting destroyed and we're that bit closer to it being a real game.

Squize.

Let's have some UI in there

The past couple of days I've been working on some of the UI aspects of the game, the level complete sequence in this case.

I thought adding a star rating would be a nice touch, adds a bit of replay ability and enables me to add a simple achievement or two. Little did I know what a complete ball ache it was going to be.

I wanted to use Away3D to display it as I wanted perspective on the panel. In the main game the camera is constantly rotating around, so I thought I'd just figure out where the camera is looking and position the panel relative to that, updating it's position every frame so it appeared static.
Simple in theory, but totally beyond me. I just couldn't figure a way out to work out where the camera was looking ( There's camera.projec()t, which I guess is the way, here's the docs for that ). After dicking around for hours, I cracked and binned that approach, the maths is beyond me.

So let's just add another view and another camera and treat it as a separate entity from the main background. Sweet, all done. Now let's add some love to our texture, a specular map and some nice lighting. Sweet, that looks awesome, I'm really pleased with it, and I dropped some lens flares and moisture effects on top using Starling, looks great. I guess I should test it on the iPad now...

...ah, it runs at less than 30fps. Bollocks.

I've just spent the last hour or so removing all the sexy love I'd added in there, it still looks pretty good ( The grab above is from the cut right back down version ) but it was painful to do.
In my other recent iPad project I found that scaling images seems to cause a real hit on the first time, I don't know why, mipmaps being created on the fly ? Which means that you have to display your meshes scaled up but hide the textures with alpha=0, wait one frame, hide the meshes and restore the textures, that makes it skip that initial performance spike.

All in all a lot more painful than it should have been, but it does look good in motion, those stars fly into it and have a little impact shudder and as you can see a shower of particles. When I get some sound in there the impact should feel nice and weighty.

And that's what my last two days have been.

Squize. 

Numbers Toys

We don't normally pimp things on here, but I think Flash devs need to stick together with the whole world telling us that Flash is dead, so here's a cheeky couple of lines about Roberto's game ( Which I promised to talk about months and months ago ).

It's an educational game for younger players, available for your favourite device:

iOS App Store

Google Play Store

That's it, give it a try and give the guy some feedback.

Squize.

Starling optimising

I was on client work so no progress yesterday. Today I thought I'd have another look at what I could do with Starling to try and save some cycles here and there.

We use sprite pooling like everyone else in the world. Rather than add/removeChild them, I just set visible=false as it should be quicker.

Because we have a ton of possible objects, even if they're not visible, I had a look at DisplayObjectContainer.render(). This loops through all the display objects running a check first to see if they're worth plotting ( i.e if visible=true, alpha>0, scaleX/Y>0 etc. ) and if so calls their render method to actually display them.


Now if we've got 500 particles running, but not displayed, it felt a little redundant still looping through them all just to not plot them, so I altered the visible method to spit the display object into one of two different Vectors, visibleChildren and hiddenChildren. If you change the visibility it's moved from one Vector to the other, which is a little costly and I want to look at that again. But, it means for our render loop we're now only looping through objects we know are visible, so it's a shorter loop and we've removed that extra visibility check which would happen for every object.

Other savings included lots of little things, for example there's a check to see if when you alter a x position has it actually changed. 99 times out of a 100 it will have, so there's no need for a check there every time.
Also because I use alpha a lot for the particles / explosions I had a look what could be saved there too, mainly "inlining" methods ( Not the compiler inline option, as that seems to break the Starling code ), VertexData.setAlpha was a really costly call before I cut it right back.

Just to make it clear, this isn't a criticism of Starling, it's a great piece of code which has to be all things to all people, and anyone can always look at someone else's code and speed it up, there's nothing clever about that.
In a perfect world I'd make my own Stage3D engine from the ground up, but I really don't know how many more Flash projects I'm going to do so I think it would be wasted time and just be a vanity thing.

Squize. 

They explode and everything! Oh and linked lists in AS3

Did some work on the game Saturday and Sunday, which wasn't the plan as I had the html5 game to amend, but I got in the zone and really enjoyed it.

I altered the equaliser effect to the colour you see there, and after taking this grab I added another fainter layer on top to fake some HDR light bleeding.

The main push then was finally adding the explosions / particles / points. This was my big worry with the whole 60fps thing, and I managed to get there with some sly tinkering.

My first attempt was to split the particles up into two arrays ( Well Vectors, but that's such a confusing term when talking about Flash ), and run each particle in the two different arrays every other frame, so even though the game is 60fps, the particles actually only run at 30fps. This kind of load balancing really helps.
I'll be honest, I did notice the difference at first, but only because I was really looking for it, in real life they don't look like I'm cheating.

I'm not running a silly amount for each explosion, only around 60 particles, which doesn't sound much but when you've got 3 or 4 explosions at once they really help fill the screen.

After that I cracked and changed the code over to using linked lists to handle the explosions and particles. Normally I have code like this for my mainloop

var cnt:int=0;
var explosion:Explosion;
	
for each (explosion in activeExplosions){
	if(explosion.mainloop()=="dead"){
		activeExplosions.splice(cnt,1);
		explosionsPool.unshift(explosion);
	}
	cnt++;
}

Where we just loop through all the active explosions, any dead ones are removed and pushed back into their pool.

With a linked list ( I think technically I used a "Double linked list" but really who cares about the proper terms ) you store the first and the last object, your Head and Tail, and then each object has a reference to it's next and previous neighbours.

If the Head isn't null you call it's main loop and when it's finished it looks to see if it has a next neighbour, if so it calls it's main loop and so on. It removes the overhead of running a loop and changing the size of the array by inserting and removing from it. It has a slight cost when you want to remove it as it has to tell it's next and previous neighbours it's not longer there and update their next and previous pointers, but it's a handful of conditional statements.

I'm away from the game for another day or two now, but when I get back to it I'll be looking to change the player bullets to a linked list, I'm not sure if that will be possible as the baddies all expect to know about the player bullets so passing them an array is a nice easy way to do that, then I'll add the baddie shooting routines.

Squize.