Gaming Your Way

May contain nuts.

cs3 ? That's so last week

A couple of days late posting it here, but it gave everyone an extra couple of days to save up.

Flash CS4 is out now, here's the launch video ( Of the whole huge cs4 package )

Want something for free ? I know I do. Well here's the link to the FP10 download,

And seeing how we're a developer blog, here's a direct link to the standalone / debug versions

Early feedback seems to show that FP10 is faster in quite a few areas which is great news ( And credit to Adobe for squeezing even more speed out of as3 ).
Like a virgin, I'm saving myself before I get down and dirty with the new player, but as before when we have some interesting tests to post here we will.



Here's a little grab of what I've been working on during my current down time.


Part show-reel / part demo. Coming soon.


Another 48 hours

Every now and again there's a 48hr game comp on FlashKit games. I've not entered since the 2nd one ( Which I was really pleased to have won, so I wanted to keep my 100% record ) so I felt it was time again, to see if I can still turn it on.

It works by everyone offering up a couple of words and then at kick off two are chosen at random and that's the games theme. This time it was "human brain" and "micro-organisms".

The theme was announced at 1am ( Saturday ) and the obvious thing for me was a shoot'em up over the brain, zapping the invading baddies, so I went to bed. It's what us coders do best.
Saturday afternoon I was mulling it over, an arena shooter would be cool but I'm meant to be finishing Orbs off as it is without trying to do another, plus I knew realistically that I'd have about 16 hours to do this. Ok, a Galaga style shooter. But that means lots of attack waves, plus a scrolling background ( Without the scrolling background it would feel really really old school ). Scratch that then.

I've never written a mouse avoider as I've always found them trite and throwaway. Perfect!

Saturday I didn't get much done, the England match got in the way, mainly the front-end and the overall structure was nailed. The power-crystals ( Or "geoms" as they're actually called in the code 'cause I just couldn't think of a better term ) were in and running which was good 'cause I knew a lot of those routines would be used by the baddies.

Sunday, erm, well I finished it off. I managed to be the first person to post up a final game, as I was sick to death of working to be honest ( It only took around 12 hours in total, but by the end I was glad to see the back of it ).
The sounds were the last thing to be added, I found an old tune from a game I'm not going to finish so re-cycled that and the sfx are also from various old games. I'm not a 100% happy with them, and I wanted to add another baddie type that would explode when killed which would have caused a cool chain reaction with combo's etc. but I felt it was better to have a complete ok-ish game done on time rather than try for more but post a game with a lot of loose ends in there.
For me the comp is as much about finishing by the deadline as the game itself.

If you'd like to see the fruits of my labours, click me

Also I've posted the source, in two flavours:
Just the code ( 16k )
Code with fla's ( 2.5 meg )

It was written in Flex and I very much doubt it'll run out of the box straight away, but it includes the preloader code which may be handy.

Also all the comp entries are here. I can really recommend giving them all a play as there's some great work there in such a short space of time.



Just some news about the FHM game awards.

Teague at the sickeningly talented Hyperlaunch sent us a mail mentioning that they're working on this years awards, and that the awards were about recognising great development and developers, celebrating their efforts and thanking them for allowing so many of us to waste our time playing games when we should be working.
He also mentioned that everyone who entered would be given some cheeky widgets to help promote their games, plus a badge to stick in your game ( "FHM Web Game Awards '09" no less ). The outcome will be decided by user voting and the winner will recieve £3000 ( Or if you're in the land of dollars, enough to buy a house ).

You also have the choice to make a brand spanking and hopefully £3k winning game, or submit one of your existing ones and try and win without any real effort.

But you know what ? We value our integrity here, and we won't just pimp any old thing just 'cause someone wrote us a nice email.


Well now the genie is out of the bottle click [ here ] to find out more. It's well worth a bash, and although I don't know if we'll have anything new to offer up I'm sure we can wipe down some of the old stuff, spray it with some deoderant and just pretend it's new.


PS. Remember the kick back to us if you win. It's only right and fair.

goAway, Nephew of SiCo

What do the following things have in comon?


test.swf (5,87 KB)

goAway.swf (8,07 KB)



After my funny little episode with the hacked version of Law of the West I started wondering how to prevent that little pricks that can use an URL changer or decompiler to mess around with my stuff. Above you see what might be a solution. It will not stop someone who really, really wants to see your code from seeing it in the end but it will make it reasonably hard.

So how can you prevent that someone just grabs a decompiler, changes things and publish it back?

Maybe if there is no game inside the swf, at least not directly visible.

This is a screenshot of the library of the goAway.swf. Nice, eh?

Right now goAway is a neat little console app (so you can batch it), that takes an swf, optional a textfile full of vars (so you can check them later from the game itself) and spits out a png.

This can be included in another swf (to be released) and is unpacked after loading - and viola you have your swf again, though it'll be like a loaded swf, so you loose your "root".

There is a lot more security related portential behind this:
- load the png from a server instead of including it.
- use a key to decrypt the png
- create the png on the fly on the server each time with a new key
- store multiple swfs/files in a single png to pack a multi file game into a single distributable swf without a lot of trouble
- and and and

The above swf is just a proof of concept and there is still alot to do on the goAway app in oder to make it useable (maybe a frontend, new features (like dynamic png dimensions, splitting into multiple png files for more security, different ways of reading writing the data into the png (byte order)) not to mention an AS3 class to easily handle the goAway png.

After all I'm quite pleased with the idea, as it makes it quite hard for script kids to mess around with a published flash file with the available tools. Making hacking a game just that little bit harder that is needed to seperate the users from the coders.

And of course SiCo will be used to obfuscate the goAway code ...



Son of SICO

More tinkering with Air, and SICO now has a front-end


The reason for me firing this old project up again was covered in a comment in the last post. Basically the GYWEncrypt app is only as strong as the code decrypting it, so I wanted to mess the source code up for that process as much as possible.

Now this is beta, and it could break. A couple of things to take note of are:
* It doesn't bother messing with local vars. Unless I'm totally mistaken Flash doesn't save local var names anyway, so
var heresMyUltraSecretPassword:String="fistedNun";
won't show up in the source anyway ( Well, not as literally as that ).
* There are some white space issues I want to sort out, although the messed up file does rip out comments so it should result in a smaller file-size. In theory you'll never be looking at the messed up output, it's just that it's bugging me it not quite doing what I wanted ( It's the design tart in me ).
* It doesn't yet ( If ever ) handle lines like
private const var heresMyUltraSecretPassword:String;
The same may apply for private static vars too.
* Because of oop it can't do anything to public functions, as by default your public function are just that ( It only works on 1 file in isolation not a whole project ). If you want that, shell out for this instead.
* I've really not tested it to death. As with most home grown apps it's a case of "It works for me".
* On the Air installer it shows up as unsigned publisher blah, blah, blah. It doesn't do anything naughty at all, it's not going to format your hd or d/load porn in the background. If you don't trust it / me, then fair enough don't d/load it.
* Never ever ever save over your original code. May sound stupid me saying that, but I feel I need to. The filename is saved with an extra ".", so even if you should screw it up it'll be saved as
But please don't risk it, call the file for peace of mind.

What would be really cool would be if anyone testing it has any problems if they could post the original code snippit and the broken output in the comments. I'm guessing there are going to be issues ( It really depends on how many if this ever gets out of beta or not, if the world and his dog have problems then I'll just open source it and be done with it. If it's only minor stuff then it shouldn't be a problem fixing it up ).

If this all goes well ( It's sweet for me ) then the next couple of days should see GYWEncrypt finished too, although we're not sure what we're going to do with that yet.

Here's the link for the air file, thanks in advance for giving it a bash 21k


Air today, gone...

Air. The future of RIA. Unless you try and actually use it.

I've been wanting to write a swf encryptor for ages and last night I finally cracked ( As I'm working on something that I really don't want decompiling for various reasons ).
It was a toss up between Zinc and Air, but I opted for AIR 'cause in theory it is the future and therefore should have better support than Zinc.

So after all the hype surrounding Air I should just be able to google around, find out how to drag and drop, save a file and some other basics. I develop in Flex rather than cs3 'cause it's a million times better, but any search for Flex and Air just brings up examples using MXML. That's not great.

Eventually I found a hacky way to create an Air project in actionscript in Flex ( It's so convoluted it's untrue. You create a Flex project as opposed to an AS one as usual, tick the Air box, but on the part where you set the document class you alter the mxml extension to .as and it works ).
Getting there. Published the main class and up popped... nothing. More searching and I found out how to set it up ( A big thanks to Toby for blogging about it, without his words I'd have given up all together ).

Cool, got a window in place now. Close it, try publishing it again, and... nothing. Lot's more searching ( And swearing ) and I found out what the problem was, and the cure. If you don't exit your app correctly ( ie call an exit() after adding a listener to the close button ) then it doesn't actually exit correctly ( I found this out myself after a lot of messing about ).
When you publish an air app it runs something called adl.exe ( Adobe Debugging something. I've had enough air googling for a life time so can't face looking it up ) which runs the swf wrapped in the air api.
If you don't call exit() then when you close the app adl.exe keeps running. Ok, that's not the end of the world. What actually is though, is that you can only run one instance of adl.exe. If it's running after you've closed your app incorrectly, then you can't run any more air apps.
The beautiful thing is, it doesn't tell you. Flex doesn't tell you either. It's like they've ganged up to keep us in the dark.

Until I figured out the whole exit() thing, I was working with task manager open closing it down every time. The only solutions I found online were, yep, work with task manager open and...

Ok it kinda makes sense, and if you've got to call exit() then you've got to call it, but c'mon, this is the future of RIA and I've got task manger open to kill it ?
It all feels very beta-ish, from the hacky way to even create an Air project in Flex to that.

Once I got past these hurdles, I must admit it wasn't that bad. The lack of docs ( I only found this after I'd gone through a lot of pain ) has made it a less pleasant exercise than it should have been ( Oh joy, another mxml example for something I want to do with code ).

One weird thing which I'm putting down to me is that when I drag and drop a swf into my sexy little app it runs the app twice. I don't mean it opens another window, it just runs through all the code twice ( In alcon I was getting,
"wtf ?"
"wtf ?"
which was a bit of a give away ). A little kludgy check cleared that up.

At present we've got a simple little app which you can drag a swf onto, it then encrypts that with blowfish via the very nice Crypto library and you can then save that back out.

Next up ( And what I've been swearing at for the past hour or so ) is the decryption routines. Well, the code is being embedded and decrypted, it's just figuring out how to then make that byteArray run as a swf rather than just sitting there annoying me.


74 hours, 33 minutes and 40 seconds

I'm currently touching wood ( tehehe ) that GMM is gold.

Guess how long it's taken ?

This is going to be a two pronged post, I'm going to both wow you with visuals and bore you with stats. Stats first I guess, here's the breakdown of how long the game took blow by blow

Attract Mode: 1hr 9mins
Bots: 13hr 33mins ( I had such a mare with these )
Class Structure: 10mins
Corn Power-Up: 5hr 20mins ( This was re-used for the other power-ups, hence it taking so long )
Display Map: 32mins
Dummy Trap: 2hr 34mins
Game Complete: 58mins
Game Over: 24mins
Golden Ball Power-Up: 49mins
Health Power-Up: 1hr 37mins
Hidden Baddie: 2hr 47mins
HUD: 1hr 38mins
Instructions: 2hr 33mins
Level Complete: 40mins
Level Design: 7hr 38mins
Level Plotter: 7hr 39mins ( What are the odds ? )
Level Structure: 1hr 22min
MiniMap Layout: 1hr 31mins
Mud Power-Up: 1hr 8mins
Pause Mode: 30mins
Player: 7hr 37mins
Points anim: 24mins
Preloader: 34mins
Score: 7mins
Sounds: 3hr 22mins
Tiles: 2h 54mins
Transition: 25mins
TrapDoors: 3hr
WaterTraps: 1hr 23mins

Now this may seem incredibly anal, perhaps to some degree it is, but when working for yourself it's important to keep track of where your time is going. It helps budget for the next game, as you'll see a pattern ( So for example a preloader won't take long, but you know the player and baddie routines will ). A lot of common sense I know, but seeing how long things actually take can be a useful eye opener.

Want to see the map for level 1 ? Go on then seeing how I promised


So from here the clients need to give it the once over, make sure I've fixed what I was meant to, tweaked where things should have been tweaked and sign this bad boy off.

K, time to work on the arkanoid game again...