Gaming Your Way

May contain nuts.

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.

And on the 8th day I created a mini-map.

With this title in place, I don't think I have to write much about the technical details, do I?

I read an interview a few days (or is it weeks?) ago (forgot who was interviewed) and one of the things that were said was something like "mini maps are a lazy design choice". Maybe.

I still needed something like that in the prototype game, one reason is that it shows where things are, but I don't want to show a map. In reality it works more like a radar, but honestly who is going to search for "game development" and "radar"?

...

And here ends this post. I got myself a new PC, you see. Seems like I now got most things set up and running again (I could have just migrated my old stuff, but I do like a fresh start now and then).

Well, tomorrow is Monday, so it's time for a new post anyway and I try to push it in between some very serious deadlines.

 

-- Oliver / nGFX

Mr.Peabody and Sherman game

I'm not a 100% sure of our contractual obligations, so we're going to say we had nothing to do with this game.

We didn't make this over the Christmas break with our friends at Producto Studios, actually we weren't even there when whatever happened, happened.

So if you'd like to play this game that we had no hand in at all, it's here: http://www.mrpeabodyandsherman.com/lostintime/

( Also check out the main site, because you know, advertising: http://www.mrpeabodyandsherman.com )

I'm pretty sure that's all legally binding and there's no way we can get into trouble.

Squize.

Work stopped play

A bit of client work has come up this week, so I've not managed to touch DN8 today.

One thing I did mange to do yesterday though was to give the particles some colour, I'm really pleased with them.

They're a lot more colourful than in the original game, they have a nice 8Bit colour wash feel to them. Rather than going the tint route of the original, which is expensive, I just created a 260 frame tween in the Flash IDE and got it to spit all the frames out as pngs, dropped them into Texture Packer and the game just picks the next one in an array every time we need to plot one.

I think unfortunately that's where I'm going to have to leave the game for a couple of days, there's too many other moving parts work wise right now to be able to try and claw some free time back to work on it, which is kind of annoying as next up would be some explosions and all the particles which go with them. Oh well.

Squize.

Thursday I don't care about you...

Quick update today, as it's Friday and I'm sure we've all got places to be.

The first level baddies are in now, and the particles which show their path.

You can shot them to earn points, but no explosions yet ( That's the next big thing ). I noticed the frame rate drops slightly when the path is onscreen, so I'm going to have to look at that as well ( It's not too bad right now, but when we have a silly number of bullets running every little saving helps ).

Basically I'm trying to get all the costly in terms of CPU / GPU stuff in as quickly as possible and then optimise that so we keep as close to the magic 60fps as possible. I'm lucky in a way that I've got an iPad3 to test on, it's the slowest device out there ( iPad 1 doesn't count, that's really not worth targeting ).

Hopefully Mondays update should have more in the way of particles, as they always look good.

Squize.

We have the pow pow pow

Only the 2nd day of trying to update the progress on DN8 iOS and I'm struggling already ( I had fuck all sleep last night and then an early morning, I'm dead on my feet. I always know when I'm working early as everyone I chat to on IM says "Who's that ?" or "Shit the bed ?" or a combination ).

So, basic title screen in place with a play button and rollOver, the majority of the HUD done ( Working scores and everything ) and a player sprite which you can move around and it has the tilt animation in there.

And guess what ? Bullets too.

I don't think I've actually used any of the original code in this yet, which was the plan, but with looking at the baddies I think some copy and pasting is going to happen there as I really can't remember what I did.

Before I go, I got caught out with a couple of Starling things. Adding a blend mode to an image forces a draw call, as does using alpha. I know there's that whole starlingStage.alpha=0.999; work around, but it feels like that will be costly to do it on every child clip, so I've got a few specific container sprites that I add the blend mode to and use that alpha trick, so I've just got to remember not to use alpha in anything outside of those.

That's probably gibberish isn't it, so time to stop.

Squize.

And, back.

It's been ages since I've posted anything, and there are lots of reasons why ( Well, just one reason, work ).

I haven't stopped since Lost Outpost shipped, hence me not being able to go back and fix the bugs on that. I had a large html project to finish around the same time O2 was launching, so I couldn't give it as much attention as usual, and from that straight into an iPad project ( I guess I'll write more about that sometime, hopefully it'll be signed off soon ) and then my planned Christmas break was spent doing a quiz game ( A link as soon as it goes live ).
Then last week I did my first html5 game, which was cool, more on that once it's live. So basically lots of stuff that I can't talk about yet, that makes for a golden blog post.

With the iPad project I had to re-register as an Apple dev, and learn how to use Starling along with Away3D, and that inspired me to look at an old project.

This bad boy is coming to iOS ( And maybe Ouya / Android )

I've only been working on it one day, but I was thinking a blow by blow account of it's development may be interesting ?

Currently there's very little to it, I ripped out the original planet code and got that running ( I had to alter things slightly, the really large planets killed the framerate, I think it was a fill rate issue ) and just today I started on the title screen you can see there, with the graphic equaliser effect I always wanted in the original.

One nice thing I played with yesterday was reading the accelerometer, so as you move the iPad the screen moves ever so slightly, like in iOS7, to create a parallax effect.

I'm really hoping to have this run at 60fps, as it looks so beautiful running at that speed on the iPad. I optimised the crap out of the Starling particle extension the other week, partly for the client iPad project and partly as preparation for this, so I'm hoping we can keep the particle porn we had in the browser version.

I guess that's it for now. I don't really want this slipping into a big project, so we'll have to see what features get kept from the original and if any new ones will be added. I'm not super confident I can make my money back from working on this, so I've got to be a little bit pragmatic in terms of the scope.

Squize.

Decision Style #4: Activity-Focused Design

I'm still awe and wonder about what shit comes up when you search for our post titles. This time it's a tech-talk-bullshit gem.

Anyway, it's time to get going with the prototype game and start piecing together all the little tools written so far. I mentioned it on g+ already, but I reached the point where I needed more than my usual ToDo list to keep track of what I want/need to do next.


Just a small part of my "map helper"

The first map I used for testing was quite big and complex and with some 20 rooms and even more doors a bit - shall we say - shit to keep track of. So I invested 2 hours to make a smaller map, then rendered it out and drew my notes on it (making revisions on paper is a bit messy after a while).

Color coded rooms help to maintain overview and layers in photoshop make it incredibly easy to keep track of items to place and doors to connect. Right now I'm placing these in Unity and wiring things up to be able to do a "play through" with the main objectives: find docs (USB drives), codes and key key cards and avoid being caught.

The next thing on my ToDo list however is the minimap, which wont show you the location but items, guards and cameras (and their "senses"). With that in place it's finally time to add security to the map.

Maybe I should add a trigger for the exit first so I can have a "well done" screen up and running (and make it feel more like a game than a pure game mechanics test bed).

-- Oliver / nGFX

Inheritance is your friend.

Let's talk about items in the game prototype (which is actually a bit more than a prototype if I look at it).

One gameplay element is finding keys / codes to open doors (although you can also hack them, but that's another story). In the first version these items were separated into Doors and searchable Items, both with a lot of duplicated code, on the item and on the player object that had to interact with these items.

After everything worked like expected (ie: walk up to a crate, press the action button and wait, find the key, walk to the door and unlock it), I started the second refactoring pass. First thing added was the ItemData class, which holds most of the vital data and exposes them to the editor. ItemData covers basic items and things in the game, a wardrobe you can search through is using ItemData as well as a bed or a crate.


Basic ItemData in place.

I already mentioned that doors are a bit tricky when it comes to making them work with generic code, so adding ItemData values to a door meant some messing. As you can see ItemData contains two fields for interaction: action and secondary (mapped to different buttons) and this also the trouble with doors. Doors (at least in this game) have more than one action, based on the door's current state (locked, closed, etc) plus different actions for the same state. If you stand in front of a locked door, but don't have the key, the action is "hack door" - if you have the key, the action is "unlock door".

Exposing that to the editor is more than a major ball ache, except you want to write your own editor panel - which I very much don't want to.

This is where inheritance comes into play. So the Door (DoorController Class) is inherited from ItemData. The trick is that the code that manages the door's state also changes the "action" of the underlying ItemData. As doors are always work the same way this doesn't have to be exposed to the editor. So when the state of the door is changed the "action" is updated based on the new state. Quick, simple and clean - not as flexible as going through the editor, but that's a small price to pay.

Another (big) advantage is that items and doors now all run through the same code for displaying button hints, tooltips and message boxes, so no special cases to tackle.


For comparision: the door's editor values.

Now that this is done, I'm going to add guards wandering around the map and I fear I also need to get my head around doing a minimap to guide your around (without being a spoiler).

... and with this, "Hail to the king and his epic saga in search for candy".

-- Oliver / nGFX