Gaming Your Way

May contain nuts.

Infinite bobs

Here's another really old trick we used in 651.

651_bobs.jpg

Way back in Amigaland software sprites ( ie, sprites which were plotted by the blitter as opposed to being hardware based, like a mouse pointer ) were called "Bobs" ( Blitter OBjects ). As with everything you could only ever run a certain amount before you started running out of cpu time, so when the first infinite bob effects started appearing in demos every one passed a little bit of involuntary wee.

//------------------------------------------------
// Bob properties
//------------------------------------------------
        private var ball:Sprite;
        
        private var bm1:BitmapData;
        private var bm2:BitmapData;
        private var bm3:BitmapData;
        private var bmData1:Bitmap;
        private var bmData2:Bitmap;
        private var bmData3:Bitmap;

        private var currentBitmapNumber:int;

Just set up 3 bitmaps, and then...

//Set up the sprites
            container=new Sprite();
            stage.addChild(container);
            
            playField=new Sprite();
            container.addChild(playField);

Create a holder sprite + add it to the stage, and then a further sprite within that. Also add your bob to the playField ( Not the container or the stage )

Next up, our mainloop,

//---------------------------------------------------------------------------------------
        private function mainloop(e:Event):void{
            moveBob();
            copyBitmap();
}

moveBob() is however you want to move the bob around the screen, use your nice sin based movement that you've got tucked away. All it's doing is just moving one bob ( ball:Sprite in this case ) around the screen.

The funky bit is the copyBitmap() method,

 

//---------------------------------------------------------------------------------------
        private function copyBitmap():void{
            container.addChild(this["bmData"+currentBitmapNumber]);
            this["bm"+currentBitmapNumber].draw(playField);

            if(++currentBitmapNumber==4){
                currentBitmapNumber=1;
            }
        }

It just simply loops through all our bitmaps, copying what's in our playField ( ie the ball ) to the next bitmap. Just written down like this it's a bit tricky to grasp, think of it like an old flick book. You move the bob, you take a copy of the whole screen and store that in a bitmap and then display that, you then move the bob again, and take another grab of it and so on. We use 3 bitmaps because the image will be slightly different on all of them, creating the sense of movement ( Otherwise it wouldn't animate and would just look like a trail behind the bob ).

I can recommend giving it a quick play, it'll take 5 mins to set yourself up with a working example and once it's running infront of you it'll click into place how it actually does work.

Squize.

 

How it does what it does.

Now 651 is history I thought it may be of interest to go through how some of the parts work.

Let's start with the boring bit for today, the actual structure. To make testing it easier, and to be able to swap and change the order to make sure it felt right, I used a pretty simple yet modular approach,

//------------------------------------------------
// Demo classes
//------------------------------------------------
        private var logo:Logo;
        private var credits:Credits;
        private var twister:Twister;
        private var vectorBalls:VectorBalls;
        private var pimp:Pimp;
        private var showReel:ShowReel;
        private var water:Water;
        private var fin:Fin;
        
        private var sequenceOrder:Array=new Array("logo","twister","vectorBalls","pimp","credits","showReel","water","fin");
        private var sequenceOffset:int;


The sequenceOrder array kinda speaks for itself. The other part of the code is just as straight forward:

//---------------------------------------------------------------------------------------
        public function sequence():void{
            switch (sequenceOrder[sequenceOffset]){
                case "logo":
                    logo=new Logo();
                    break;    
                case "twister":
                    twister=new Twister();
                    break;    
                case "credits":
                    credits=new Credits();
                    break;    
                case "vectorBalls":
                    vectorBalls=new VectorBalls();
                    break;    
                case "pimp":
                    pimp=new Pimp();
                    break;    
                case "showReel":
                    showReel=new ShowReel();
                    break;    
                case "water":
                    water=new Water();
                    break;    
                case "fin":
                    fin=new Fin();
                    break;    
            }
        }

//---------------------------------------------------------------------------------------
        public function finished():void{
            if(++sequenceOffset==sequenceOrder.length){
//Finished            
            } else {
                sequence();
            }
        }


Each segment is totally independent, ie it has it's own init and housekeeping routines, there's no co-dependency at all. To start the demo the sequenceOffset var is set to 0 and then the sequence() method is called.
When a segment has finished, it calls it's houseKeeping() method to dispose of all the bitmaps and removes all the sprites from the stage, and then calls the finished() method ( Hence it being public ).

That's all there is to the underlying structure which runs the demo, it really doesn't get any more straight forward.

Squize.

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 )
http://tv.adobe.com/#vi+f1556v1715

Want something for free ? I know I do. Well here's the link to the FP10 download,
http://www.adobe.com/products/flashplayer/

And seeing how we're a developer blog, here's a direct link to the standalone / debug versions
http://download.macromedia.com/pub/flashplayer/updaters/10/flash_player_update1_flash10.zip

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.

Squize.



651:Soon

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

651_sphereGrab.jpg

Part show-reel / part demo. Coming soon.

Squize.

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.

Squize.

F.H.Mmmmm

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.

Bollocks.

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.

Squize.

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)

test.png

goAway.jpg


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 ...

Ha!

nGFX

Son of SICO

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

soSICO_grab.jpg

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
myLifesWorkRuined..as
But please don't risk it, call the file test..as 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
SonOfSICO.zip 21k

Squize.