Gaming Your Way

May contain nuts.

Vector Bobs

Another quick break down of an effect in 651.

651_vectorBallGrab2.jpg

On paper this is quite impressive, 500 3D objects with depth of field running over a skybox. In real life, it's not exactly rocket science.

Although we used Papervision in 651, we didn't for the effect itself ( Just for the skybox, which uses the background from Orbs as it's texture ).

We start by creating the 3D objects and giving them random x,y,z coords ( For the very best introduction to 3D movement in Flash check these excellent tuts on Kirupa, everything you need for an effect like this is there ).

Right, we're spinning some objects around in 3D space, what about the depth sorting ?
This is just between us right ? It's not going any further ?
Ok then. We just don't bother. It's a very old trick ( I remember doing it back on the Amiga ). If the vector bobs are translucent enough, it's pretty hard to tell if they're not being z-sorted correctly. Looking at that grab above quickly I can't see anything too wrong in terms of sorting, and even if there was, the bobs would all have moved in the demo before you really notice it.
By dropping the sorting we've got more cpu power for more objects, and the more the merrier.

Next up, depth of field. Such a buzzy thing in Flash atm. We all know it's only a blur filter, but depth of field sounds so much cooler. To avoid an extra hit we pre-calculate each blur frame, we're not blurring in real time. Or even using the blur filter itself as it's all done in PaintShop Pro ( And each frame is imported into Flash ).
Each bob is a movieclip ( Which feels very old school already ) and when we're calculating the scale ( Based on it's z property, ie how close or far away from the camera it is ) we can also gotoAndStop() to the correct level of bluriness.

So to recap, the 3D code can be found in some great tuts, there's no z sorting, the depth of field is gotoAndStop and the skybox was done in about 10 lines of code. Drop a nice image over the top of some scanlines and it's all done.

It may seem like I'm talking the effect down quite a bit. I'm not really, it looks sweet, I just don't like people acting like their code is l33t and they're so clever for doing it. Smoke and mirrors is as good a technique as clever code, and there's not always a need to mystify everything.

Squize.

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.

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

A [ Voxel ] trip to Mars

I had an idea last week on how to code a voxel landscape, so a couple of nights after work later, here's my little...

Trip to Mars

( No preloader, but it's only just under 400k )

Just to caveat it, it's not the quickest routine ever and may chug if you've got a slower machine, this is more looks rather than speed.

I'm really pleased with how it turned out. It uses a real image of Mars for it's height map, so it's a lot more rocky than the usual perlin noise generated maps.

That's about it really. I was going to save it up for a demo I have in mind, but I've got no time for it for the foreseeable future, and if I do re-use it as part of a bigger production I've got some ideas to improve it anyway.

Squize.

Kaleidoscope effect ( Plasma revisited )

I needed a bit of a break from all things gamey this evening, so I looked back over my old plasma source.

By stripping the maths down to the bare minimum and using a for...each loop along with other bits and bobs ( Double buffering the screen helped too ) I managed to increase the fps from the 31/32 mark to 42/43.
Pretty sweet.

I thought I could either post it like that, smug in the knowledge that I've speeded up a pretty intensive routine by ( In real terms ) quite a lot, or do something slightly different.

I opted for a bit of a play, and was really surprised ( And pleased ) to see you can attach the same bitmap to multiple sprites and it still updates. From there it was a no brainer what to do with it. In real terms this is plotting less pixels than the plasma effect ( That was 150x150 doubled ), this is a 120x120, but it's a much bigger effect in terms of screen size.

Kaleidoscope

Squize.


Never say quick when it comes to coding ...

So I had a long night yesterday, finishing off some unloved project that I've been delaying for some time now and as some sort of personal reward for being so brave I played a bit with my "play media on the wii" idea...

I had written the service for getting drives, dirs and files a few days ago (don't try this on real a webserver :) ), so I *just* had to do some flash frontend ...

Oh well, I should have known better ....

To give you a basic idea of what I was thinking of, here's a (sized) image:

wiicenter_00.jpg
(icons are just temporary)


I thought that fiddling with scrollbars would be a no-go on the Wii, so I came up with the idea of a dragable "canvas".
So you can click on a drive, which opens the folder list for it, clicking on a folder... you get the point.

Now here starts the tricky part ...
Once I had the drive list done, I noticed that it lists floppy disks and CD/DVD drives, too. I either had to give the drive type when getting the list from the service or don't show them (in both cases this means to mess with the service's code - that for quick and easy).
The next thing I noticed that the service currently doesn't care if a directory is hidden or not (and if it is hidden, I might need to know in my flash file).

Well, it doesn't end there (of course not), because I might need to know some more about the files inside a folder (size is obvious) - oh and what is if there are some more files/folders (say you have a folder with 1000 images or mp3s) ...

That clearly killed my idea of a quick solution, I'll have to heavily modify the service (although I had to do that anyway) and there are some quite important things to consider for the swf (I may have to drop the drag idea).

We will see.

nGFX


Playing media on the Wii

It's so long ago I've posted something that it's untrue. It may be because there was nothing much to say during that time, that is projects not really game related or so absurdly NDA protected that even to mention the general direction would be ... well expensive.

You surely remember my last (!) post where I have a bit of a rant about the media capabilities of the Wii (still no games on it for me, though). Right now this neat piece of hardware sits beneath the TV left of it's bigger and way more often used brother the xbox 360. All I do with it (you remember: playing Wii Sports after a lot of coding) is using it as TV based web browser.

Webbrowser ... well that brought the idea.

(OK, that and the fact that we had some friends here and wanted to look at some photos from the last party. One of them (a "no gamer") asked if there would be some music to play along and I had to admit that it's not working anymore (due to the glorious photo chanel update))

So inspired be the fact that I got the 360 playing my mp3/fotos/movies from my pc in no time, I started to set up a small test environment webpage on my local IIS to see if I could use the browser to browse my pc's hdd. And of course it works.

So I wrapped the output with some XML and viola I had a flash 7 swf that I could use to browse the directories on my pc. Well done.

The only drawback atm is the fact that there has to be a webserver running ... I guess you can't convince most people to install an IIS on their PC to get some media on the Wii. After a few minutes of thinking it came to me that I could write my own - or better integrate cassini (an open source micro webserver) - to host the services for the Wii ...

Well, let's see where that leads to ...

nGFX

[edit] just found this while hunting for informations about the Wii browser flashplayer ...
http://my.opera.com/[..]flash-7-and-not-8-or-9

I know I promised...

But I found a sweet article about making a textured tunnel, and before I knew it this bad boy was up and running...

Tunnel.swf (16.1 KB)

( No displacement maps, just pure pixel plotting. as3, I'm loving you )

I've really got an urge to do a full blown demo. I know I've got far too much on, but it's gnawing away at me.

Squize.