Friday, June 18, 2010

Blitter engine: Benchmarks

Ok, before anyone says "You said you weren't going to do any benchmarks, you said. Wanker" I had a rush of inspiration the other night to improve the blitter engine, so I figured I need to have my own benchmark test to make sure I'm not just wasting my time.

And because I'm a giver rather than a taker, I figured it wouldn't kill me to do a pointless sprite based one just to show how slow they [ Sprites ] are.
Before we go any further, I'm busy working with our new favourite client ( We may even have a game to show next week. Yeah, actually producing something rather than talking about it ), which means I'm knackered, which in turn means the examples are as ugly as you like.
Also it's not a case of getting them all running as fast as possible, it's to show the relative speed between them. We're not trying to break records here, it doesn't matter how high we piss, more how the three approaches compare to each other.

The first test just uses sprites with a bitmap for the scrolling background ( ie, the background isn't wrapped in a sprite, it's just a bitmap added directly to the stage ). For this test we only run a 1000 sprites ( Ha, only. In Flash5 that really would have been a record ).

Test1

Yeah, ugly and not even embedded, but it's only for us to see. All the tests can take a little while, once all the sprites are active you'll see "Finished" and then it's worth checking out the fps.

Next up it's a test using bitmaps, like the scroller they are added straight to the screen. 3000 of the bad boys this time.

Test2

You should roughly be getting the same fps as the sprite test, but with 2000 more objects running ( I get around 31-35, but let's not get too hung up on the actual frame rate, as I'm running snow leopard on a macbook pro and using Firefox as my browser. You more than likely won't be, it's all about the relative speeds ).

Final test, 3000 bobs a blitting, and the scroller background is also being blitted.

Test3

Now for me it runs slightly quicker than test2 in the browser ( I'm not running the debug version in the browser ), but locally the bitmap version ran faster by around 5fps or so.

I'm not overly advocating the blitter approach compared to bitmaps, I'm not trying to sell the blitter engine to you. Bitmaps give you a lot more of everything, you get all the lovely blendmodes, rotation, alpha etc. All the good stuff you don't get in a straight forward copyPixels() engine.
The advantage of the blitter engine is that it's better suited to mobile devices, it will run better on an iPhone than a bitmap approach. Moot point I know, but don't forget we're all going to be writing Android games real soon.
Also the framework for dealing with layers is there and working, if you're using bitmaps then you've got to write your own framework for such things ( And if you do, please post it on your blog so I can get a copy ).

Let's recap as it's late, bitmaps are great, the blitter engine is pretty sweet and sprites are like poking a stick in your eye.

Squize.

coding ideas | experiments | tutorial

Comments [0] |

Thursday, June 10, 2010

Blitter engine

I thought I may as well open source this as it may be useful for some of you.

Let's start with the all important caveats.
I'm not going to be showing you a load [ Or any in fact ] of benchmarks or examples, I can think of nothing more boring to do. Either take it on faith that it's fast, or just use it to look through and nick the bits that may be helpful to you. I'm not trying to prove a point with this that my code is so l33t. I've found it useful, if you do to then cool, we're both winners. If not, well you've not lost anything have you ?

Again another life's too short thing, I really can't be bothered with sorting out a license for this, is it MIT or is it GPL ? I don't really care, it's not something I hold close to my heart, it's a bit of code to do a job. If you do tinker with it and make it better it would be nice to share what you've done, if you make a game using it and you make a ton of money, great. A credit or even a shout about it would be cool, but if not, then I'm not going to hunt you down with an angry mob.
The only thing which would piss me off is people passing it off as they're own, but we've got a wanker free readership here so it's not going to be any of you guys, and there's not a lot you can do about the sort of idiots who would do that anyway.

There may be bugs, there was some experimental iPhone and pixel bender stuff in there which I've just ripped out. If you spot any thing dumb please flag it up, it would be nice to have a fixed version available here for people coming to this further down the line.

Ok, let's go over the usage.

The static Canvas class is the main part of it, it's what makes it tick. To set things up just do a simple,

            Canvas.init(stage,new Rectangle(0,0,600,500),true);
            stage.addChild(Canvas.viewport);

stage is your stage ref ( Surprisingly enough ), next up is the size of the canvas ( The canvas is the bitmap which everything will be blitted into, the viewport property ), and are we going to be transparent or using a background ? You decide with a boolean. You can also pass a fill colour as the final parameter if you don't want to use a bitmap as the background.

Next in our hierarchy is the PlayField. Think of this as your container sprite. I don't know about you, but I miss working with layers in as1 via the timeline, so I've always simulated them with container sprites. PlayFields are pretty much that, eg

            var defRect:Rectangle=new Rectangle(0,0,600,500);
            gridPlayField=new PlayField(defRect);
            baddiePlayField=new PlayField(defRect);
            playerPlayField=new PlayField(defRect);

            Canvas.addChild(gridPlayField);
            Canvas.addChild(baddiePlayField);
            Canvas.addChild(playerPlayField);

From memory I don't think the engine actually does anything with the rectangle we pass to it, I think I was planning to do some simple clipping, but never got round to it, but pass it in anyway it doesn't do any harm.

When it comes to rendering the display, the Canvas class loops through all the PlayFields in the order they are added, so the gridPlayField in that example will be plotted first, then the baddiePlayField and so on. It's a simple way of simulating layers / depth.

Finally we're onto the Bob class. These are your Blitter OBjects, your software sprites. To create one,

            var temp:Bitmap=new playerBM();
            bob=new Bob(temp.bitmapData);
            playerPlayField.addChild(bob);

You just pass it the bitmapData you want, and then add it to your PlayField. The Bob class has all the properties you'd expect, and supports animation too ( So bob.gotoAndStop(bob.currentFrame+1) works, check through the class on how to pass it an animated sprite sheet ).
Where possible I've tried to make things as close to the display list as possible, there's no need to be forcing a new syntax onto yourself.

Like the PlayFields these are plotted in order ( The PlayField is basically just a list of its children ), so add them in the depth order you want, exactly like adding children to a sprite.

As with all blitter engines there are restrictions due to using copyPixels, so forget all about rotation and alpha and blendModes. A pity, and I did start with a ComplexBob class that used Draw() for those things, but to be honest it was a real arse ache, and it's quicker to attach the bitmap directly than to use draw ( The downside to that being the bitmaps have to be above the canvas, there's no way to slide them in there between PlayFields ).

There are quite a lot of properties and methods available to you in these classes, auto-complete is going to be your friend with this.

One last thing, the Canvas uses the RENDER event to refresh the screen, so there's no need to call anything in your mainloop, just by altering a bob's x position it'll refresh for you ( If you're not going to use the actual package, I'd recommend having a look at the Render event stuff, you should find it quite useful if you're doing something similar ).

Guess I should just link to it now, download me here.

As always abuse the comments. Just to sound a grumpy shit for one last time this post, this isn't some big open source project that I plan to expand and maintain, if you find bugs or even better come up with fixes, then yeah they'll be added with a great big bag of thanks from me, but this isn't my life's work. Feature requests are going to be ignored to be honest, it is what it is.

Squize.

coding ideas | tutorial

Comments [0] |

Blitter engine

Wednesday, May 12, 2010

Embedding a text file

I've started work on game 2 for game'88, and it's going to be a tile based scroller. Unbelievably after doing literally dozens of tile based games in as2, I've still not done one in as3.

First up I fired up Mappy, did some an ultra simple test map and then exported it using the lua based exporter I wrote way back. It's a nice simple format, eg

smf!|10|200|0,0|0,0|0,0|0,0|

We've got a bit of a header there, "Stimunation Map Format", now that's going back some years, the width and height of the map ( 10 tiles wide, 200 high ), and then a combination of the tile image|tile attribute.

In the good old days we'd just #include that and hit it up that way, but as3 doesn't give us include, so it's a swanky new byteArray approach for us.

As always reading code on a blog is just boring, so open up another tab and get some filth in there to flick over to when your eyes start to glaze, or maybe a youTube video of a cute cat.

package Classes.Game2.Scroller {
    import flash.utils.ByteArray;

    public class G2_LevelData {

//---------------------------------------------------------------------------------------
// Assets
//---------------------------------------------------------------------------------------
        [Embed("/_assets/G2_level1.txt",mimeType="application/octet-stream")]
        private var level1Data:Class;

//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        public var map1:Array;

        private var mapData:ByteArray;

//---------------------------------------------------------------------------------------
// Constructor
//---------------------------------------------------------------------------------------
        public function G2_LevelData() {
            mapData=new level1Data();
            var mapDataArray:Array=convertToArray(mapData);
        }

//---------------------------------------------------------------------------------------
// Private
//---------------------------------------------------------------------------------------
        private function convertToArray(source:ByteArray):Array{
            var tempString:String=source.toString();
            var tempArray:Array=tempString.split("|");
            return tempArray;
        }

//---------------------------------------------------------------------------------------
    }
}

And that's it, almost too simple to share, but if it saves you a bit of hunting further down the line then it's not a bad thing.

Squize.

Tips | tutorial

Comments [2] |

Embedding a text file

Thursday, October 15, 2009

Simple Star Wars wipe in as3

I've done this effect to death, used it again in the upcoming DAC ( Whose launch has been delayed due to having to add achievements, luckily someone else is doing that ) so I figured it's time to put it out to pasture and share it around.

'cause we've not been posting as often here, I thought I'd treat everyone to some nice grabs to break up the code slightly.

Basically we want to create a simple gradient rectangle movieclip, like so

And we end up with something looking like this,

A simple rectangle that's slightly bigger than your stage, that fades out to one side. It needs to be bigger than your stage 'cause we want all the gradient part with the alpha blending to be off-screen when we first apply it as a mask.

Next up, the boring old code bit.

package Classes {
    import flash.display.Bitmap;
    import flash.display.BitmapData;
    import flash.display.DisplayObject;
    import flash.display.Sprite;
    import flash.display.Stage;

    import gs.TweenLite;

    public class Transition {

//---------------------------------------------------------------------------------------
// Assets
//---------------------------------------------------------------------------------------
        [Embed("../_assets/assets.swf",symbol="transitionMaskMC")]
        private var transitionMaskMC:Class;

//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        private var playField:Sprite;

        private var grabBitmapData:BitmapData;
        private var grabBitmap:Bitmap;

        private var transitionMask:Sprite;

//------------------------------------------------
// System
//------------------------------------------------
        private var main:Main;
        private var mainMovie:DisplayObject;
        private var stage:Stage;

        private var callBack:Function;

//---------------------------------------------------------------------------------------
//Constructor
//---------------------------------------------------------------------------------------
        public function Transition(){
            main=Main.getInstance();
            mainMovie=main.getMainMovie();
            stage=main.getStage();

            grabBitmapData=new BitmapData(640,480,false,0);
            grabBitmap=new Bitmap(grabBitmapData);
            grabBitmap.cacheAsBitmap=true;

            transitionMask=new transitionMaskMC();
            transitionMask.cacheAsBitmap=true;
        }

//---------------------------------------------------------------------------------------
// Public
//---------------------------------------------------------------------------------------
        public function toString():String {
            return "Transition";
        }

//---------------------------------------------------------------------------------------
        public function grabScreen(callBackArg:Function):void{
            callBack=callBackArg;

            if(playField==null){
                playField=main.getInitObj().getPlayField().transition;
            }

            grabBitmapData.draw(stage);
            transitionMask.x=-160;
            grabBitmap.mask=transitionMask;
            playField.addChild(grabBitmap);
            playField.addChild(transitionMask);

            callBackArg();

            TweenLite.to(transitionMask, 1.5, {x:640, delay:0.2,onComplete:houseKeeping});

        }

//---------------------------------------------------------------------------------------
        public function houseKeeping():void{
            playField.removeChild(transitionMask);
            playField.removeChild(grabBitmap);
        }

//---------------------------------------------------------------------------------------
    }
}

There's really no way to make code look interesting in a blog is there ?

            grabBitmapData=new BitmapData(640,480,false,0);
            grabBitmap=new Bitmap(grabBitmapData);
            grabBitmap.cacheAsBitmap=true;

            transitionMask=new transitionMaskMC();
            transitionMask.cacheAsBitmap=true;

Here in our constructor we're just creating a bitmap which we're going to use when we take a snap shot of the whole screen, and create our transisitonMask ( ie, the gradient mc we've just made ) instance.
The key thing is to turn cacheAsBitmap=true on both, otherwise the gradient mask won't work, it'll just be a boring old normal gradient free mask.

            grabBitmapData.draw(stage);
            transitionMask.x=-160;
            grabBitmap.mask=transitionMask;
            playField.addChild(grabBitmap);
            playField.addChild(transitionMask);

            callBackArg();

            TweenLite.to(transitionMask, 1.5, {x:640, delay:0.2,onComplete:houseKeeping});

This is the guts of what we're doing. Firstly use the always sexy draw() to grab the whole screen, then position the mask so our alpha blended bit is off screen. We want the whole snap shot bitmap to be masked normally at first.
We then simply add both the bitmap and mask to the screen. You'll notice the playField reference there. What I do, as I'm a layer loving kinda guy, is create a simple class that creates all the holders for all the things in a game at the depths I want. It's like codey version of using layers that way. So for your transition "layer", that should be on top of everything else ( You could also add it directly to the stage, same thing, I'm just paranoid that I'll need a layer above the transition for some reason ).
We've got the bitmap, the mask, the bitmap is now masked so all we need to do is cheat, and use the very lovely TweenLite. That just slides our mask all the way across the screen, in effect removing our mask, but with the nice alpha blending on the edge it makes it appear soft. Kinda like in Star Wars.

Notice the callback and the slight delay in the tween in there ? What we do is call the transition method, and then jump back to our main code where we're setting up the screen "beneath" the transition, so it wipes away to reveal our next screen.

[Update: Destroy all Cars is now ( Finally ) live, so you can see it action and see if you want to go to the effort of using it yourself ]

Squize.

coding ideas | Tips | tutorial

Comments [0] |

Simple Star Wars wipe in as3

Wednesday, October 07, 2009

Hello Pixel Bender

Played with Pixel Bender yet ? For Ionic ( My TD game which is taking an age to finish ) I wanted to use a similar effect to the transition in cronusX, the rgb split / tv interference thing. In the transition it didn't matter how long it took, but to use it in-game with God knows how many sprites along with collisions running it's got to be a lot lot quicker. Yeah you know where this is going.

After firing up the Pixel Bender toolkit and swearing and looking through docs and examples for an hour or so, I kinda got it, so I thought I'd share what little I know. Just to warn you, this is going to be code heavy and no example to even look at, dry reading ahead. Maybe open up some porn in another tab and just flick between the two when your eyes start glazing over.

<languageVersion : 1.0;>

kernel RGBDistortion
< namespace : "RGB Distort";
vendor : "www.gamingyourway.com";
version : 1;
description : "Pixel Bender version of RGB distort";
>
{
input image3 src;
output pixel3 dst;

parameter float rOffset
<
   minValue:float(-50.0);
   maxValue:float(50.0);
   defaultValue:float(0.0);
>;

parameter float gOffset
<
   minValue:float(-50.0);
   maxValue:float(50.0);
   defaultValue:float(0.0);
>;

parameter float bOffset
<
   minValue:float(-50.0);
   maxValue:float(50.0);
   defaultValue:float(0.0);
>;
void

evaluatePixel()
{
    float2 outCoords=outCoord();

    float2 redPos=outCoords;
redPos[0]+=rOffset;
float3 inputColorR = sample(src,redPos);
dst.r = inputColorR.r;

float2 greenPos=outCoords;
greenPos[0]+=gOffset;
float3 inputColorG = sample(src,greenPos);
dst.g = inputColorG.g;

float2 bluePos=outCoords;
bluePos[0]+=bOffset;
float3 inputColorB = sample(src,bluePos);
dst.b = inputColorB.b;
}
}

I'll try and break it down quickly in my usual lazy not really explaining things style. At the start is simple metadata, nothing you can't figure out there.

   input image3 src;
   output pixel3 dst;

A bit more interesting. input is the image you're going to send to the kernal, image3 being the datatype ( Because we don't want to worry about the alpha channel the datatype is image3 ( RGB ), if you want alpha it would be image4 ( ARGB )), the output is the bitmap we're going to plot the result to, which is a pixel3 datatype ( Which is the same as image3 ).

parameter float rOffset
<
   minValue:float(-50.0);
   maxValue:float(50.0);
   defaultValue:float(0.0);
>;

This how you set up an argument to pass to the kernal. It's a float and refers to the red channel offset when we jiggle things about. The min/max and default values are more for the toolkit itself. When you run it it'll give you a slider to play with, and those are the values for the slider ( It'll make sense when you copy the code into the toolkit. Also you can drop a description in there as more metadata, but this is for Flash so we don't really need it ).

   evaluatePixel()

This is our main loop. Everything in this method is run on each and every pixel in the image.

    float2 outCoords=outCoord();

The outCoord() method returns this pixels x/y as two floating point numbers, in the form of an array ( Kinda ). We just store that in a var out of habit and speed.

    float2 redPos=outCoords;
redPos[0]+=rOffset;
float3 inputColorR = sample(src,redPos);
dst.r = inputColorR.r;

redPos is our x,y position. We then add the new x position to redPos.x ( redPos[0] ), with the new x position being our parameter from above.
inputColorR is quite a chunky little line. sample grabs the pixel data at ( inputSource, position ), in effect we're setting the float3 ( RGB ) variable inputColorR = sourceImage[x+our offset][y]
After doing that, we make this pixel in the r(ed channel ) in our destination this colour. Basically we're doing this:

var rgb=sourceBitmap.getPixel(x+offset,y);
destBitmap.setPixel(x,y,rgb);

( But just on the red channel ).

The rest of the kernal is just more of the same, just for the other two channels.

After that pick the Export Filter for Flash Player option and we're ready to get back to normal coding.

package Classes {
    import flash.display.Bitmap;
    import flash.display.BitmapData;
    import flash.display.DisplayObject;
    import flash.display.MovieClip;
    import flash.display.Shader;
    import flash.display.ShaderJob;
    import flash.display.ShaderParameter;
    import flash.display.Sprite;
    import flash.display.Stage;
    import flash.events.ShaderEvent;
    import flash.filters.ShaderFilter;

    public class Transition {

//---------------------------------------------------------------------------------------
// Assets
//---------------------------------------------------------------------------------------
        [Embed(source="_shaders/distortion.pbj", mimeType="application/octet-stream")]
        private var shader_distortPBJ:Class;

        [Embed("/_assets/assets.swf",symbol="staticMC")]
        private var staticMC:Class;

//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        private var playField:Sprite;

        private var shaderBitmapData:BitmapData;
        private var grabBitmapData:BitmapData;
        private var grabBitmap:Bitmap;

        private var shader_distort:Shader;
        private var shaderFilter_distort:ShaderFilter;

        private var distortCnt:int;
        private var rSin:Number;

        private var staticEffect:Sprite;
        private var staticAnim:MovieClip;

//------------------------------------------------
// System
//------------------------------------------------
        private var main:Main;
        private var mainMovie:DisplayObject;
        private var stage:Stage;

//---------------------------------------------------------------------------------------
//Constructor
//---------------------------------------------------------------------------------------
        public function Transition(){
            main=Main.getInstance();
            mainMovie=main.getMainMovie();
            stage=main.getStage();

//Let's make our bitmaps where we're going to plot our data too
            shaderBitmapData=new BitmapData(700,380,false,0);

            grabBitmapData=new BitmapData(700,380,true,0);
            grabBitmap=new Bitmap(grabBitmapData);
            grabBitmap.alpha=0.4;
//Create our shader, sexy
            shader_distort=new Shader(new shader_distortPBJ());
            shader_distort.data.src.input=shaderBitmapData;

            staticEffect=new staticMC();
            staticAnim=staticEffect["anim"];
            staticAnim.gotoAndStop(1);
        }

//---------------------------------------------------------------------------------------
// Public
//---------------------------------------------------------------------------------------
        public function toString():String {
            return "Transition";
        }

//---------------------------------------------------------------------------------------
        public function init():void{
            playField=main.getInitObj().getPlayfield().transitionPlayField;
            rSin=0;
        }

//---------------------------------------------------------------------------------------
        public function distortInit():void{
            if(grabBitmap.parent!=null){
                return;
            }

            distortCnt=0;
            shaderBitmapData.draw(stage);
            playField.addChild(grabBitmap);

            staticEffect.height=int(Math.random()*100)+10;
            staticEffect.y=int(Math.random()*300)+50;
            staticAnim.gotoAndPlay(1);
            playField.addChild(staticEffect);

            startJob();
        }

//---------------------------------------------------------------------------------------
// Private
//---------------------------------------------------------------------------------------
        private function startJob():void{
            rSin++;
            rSin++;
            ShaderParameter(shader_distort.data.rOffset).value=[Math.sin(rSin)*12];
            ShaderParameter(shader_distort.data.gOffset).value=[Math.cos(rSin)*12];
            ShaderParameter(shader_distort.data.bOffset).value=[Math.sin(-rSin)*12];

            var job:ShaderJob = new ShaderJob(shader_distort,grabBitmapData);
            job.addEventListener(ShaderEvent.COMPLETE,shaderCompleted);
            job.start();
        }

//---------------------------------------------------------------------------------------
        private function shaderCompleted(e:ShaderEvent):void{
            if(++distortCnt==6){
                staticAnim.gotoAndStop(1);
                playField.removeChild(staticEffect);
                playField.removeChild(grabBitmap);
                return;
            }

            staticEffect.height=int(Math.random()*100)+10;
            staticEffect.y=int(Math.random()*300)+50;

            startJob();
        }

//---------------------------------------------------------------------------------------
    }
}

Sigh, that's a ton of boring code to look at, let's just pick out the fun stuff ( Equating as3 to fun, fuck me that's tragic ).

        [Embed(source="_shaders/distortion.pbj", mimeType="application/octet-stream")]
        private var shader_distortPBJ:Class;

That's how to embed the kernal.

//Let's make our bitmaps where we're going to plot our data too
            shaderBitmapData=new BitmapData(700,380,false,0);

            grabBitmapData=new BitmapData(700,380,true,0);
            grabBitmap=new Bitmap(grabBitmapData);
            grabBitmap.alpha=0.4;

What we're going to do is grab the screen when we want to run the effect, but we just want it faint ( alpha=0.4 ). shaderBitmapData is our source, with grabBitmapData being our dest. You can use the same bitmap for both, but Flash has to create a temp working copy, so it's slower.

//Create our shader, sexy
            shader_distort=new Shader(new shader_distortPBJ());
            shader_distort.data.src.input=shaderBitmapData;

Finally we're creating our actual shader, with the second line defining our source bitmap, which can do here as it won't change.

The distortInit() just grabs the screen, resets any vars we need and sends up the static effect ( Which has nothing to do with the pixel bender stuff, so we're going to ignore that ). Once that's all done we call the startJob() method which does the magic.

        private function startJob():void{
            rSin++;
            rSin++;
            ShaderParameter(shader_distort.data.rOffset).value=[Math.sin(rSin)*12];
            ShaderParameter(shader_distort.data.gOffset).value=[Math.cos(rSin)*12];
            ShaderParameter(shader_distort.data.bOffset).value=[Math.sin(-rSin)*12];

            var job:ShaderJob = new ShaderJob(shader_distort,grabBitmapData);
            job.addEventListener(ShaderEvent.COMPLETE,shaderCompleted);
            job.start();
        }

K, so we're using sin and cos to create our r,g and b position offsets, nothing new there. The ShaderParameter is how we change our parameter values in the kernal. You can hit the values directly, and they will be modified, but it doesn't actually do anything. I lost over an hour to that before finding out about ShaderParameter. Hopefully those lines should make sense.

Next up, we create a ShaderJob. We're doing this as opposed to the adding it as a filter approach, as this is the async magic that we've gone to all this effort for ( Runs on it's own thread etc. etc. Let's face it, that's the only thing we all know about PB ). The ShaderJob just wants to know which kernal we're using, and the destination bitmap.
Finally we just add a listener to that, and call the start() method, and it'll go and do it's thing and won't affect our other code. There's no waiting around here.

        private function shaderCompleted(e:ShaderEvent):void{
            if(++distortCnt==6){
                staticAnim.gotoAndStop(1);
                playField.removeChild(staticEffect);
                playField.removeChild(grabBitmap);
                return;
            }

            staticEffect.height=int(Math.random()*100)+10;
            staticEffect.y=int(Math.random()*300)+50;

            startJob();
        }

We're just been recursive bad boys here. Have we run the effect 6 times ? Yes so we're done, clear everything up, nope, so call the startJob() method again.

Hardly an indepth technical breakdown, but hopefully it's a starting point. This was a fair few hours of swearing for me, but I'm old so new things take longer to make sense, so it shouldn't take you more than a couple of hours to get PB doing cool things.

Squize.

Tips | tutorial

Comments [2] |

Hello Pixel Bender

Wednesday, July 22, 2009

Mochibot and BitmapData.draw() issues

Nice descriptive title for a change, mainly 'cause I've spent ages hunting around for a solution myself, so if you're coming here for just this very reason, I understand your pain.

We had issues with mochibot on Invaders Must Die, but by then I'd passed it over to Mousebreaker so they had to deal with it in-house. It's the first time I've hit it face on so to speak.

To set the scene and get you in the mood, I've just finished the viral version of cronusX and wanted to try the version control that mochi offer, as that was one of the best things about gameJacket, plus I've added a twitter option to the game which I know is going to bite me on the arse with people bitching it's spyware etc. etc. so I wanted the option to rip that out if it was becoming too much of a ball ache.
I've also included mochi-bot tracking so Candystand can see how it's doing out in the wild, so I've dropped that in too.

Everything worked first time ( That's where it differs from gameJacket and it's constant security check failures ), gave it a quick test, all good. Ah, not all good, the transition craps out to a black screen.

Testing it locally ( Turns out I've not installed the browsers debug version of FP10 on the pc, how good am I ? ) it spat out an error,

Error # 2121: Sandbox Security Violation: BitmapData.draw

etc.

Joy.

Lots of googling ( To no real avail, hence this post ), seeing the only advice on the mochi forums that I could find was someone copying out some text from the Flash help ( Cheers for that, solves everything ) it turns out that the mochi-bot can't be on your root display object, as you get all the security violations when trying to use draw(); that you would if you tried loading in say an image and using draw(); on that ( It's a cross domain thing. To be honest life is too short to go into it, I could just copy from the as3 docs, but... ).

Basically, long story cut shorter, if you do something like:

MochiBot.track(this,"yourMagicNumber");

In your preloader ( Assuming that "this" is your main preloader class than extends MovieClip ) then you can't use draw(); in your main code.

To get around this, give it a movieclip instead, eg.

mochiBotHolder=new MovieClip();
stage.addChild(mochiBotHolder);
mochiBotHolder.addEventListener(Event.ADDED_TO_STAGE,triggerMochiBotTracking);

private function triggerMochiBotTracking(e:Event):void{
    mochiBotHolder.removeEventListener(Event.ADDED_TO_STAGE,triggerMochiBotTracking);
    Security.allowDomain("http://core.mochibot.com/my/core.swf");
    MochiBot.track(mochiBotHolder,"yourMagicNumber");
}

Now I'm not sure if you need the allowDomain(), but it works with it, and that's good enough for me after losing a good hour and a half to this little gem of a problem.
Because the mochibot code needs to hit loaderInfo.loaderURL via the clip you pass it, you have to add your holder mc to the stage, and then wait until it's actually there before calling MochiBot.track, otherwise you're in the land of null properties.

Now I'm not sure if you can kill that holder mc of after calling the track() method, it's like the allowDomain(), it works as it is, and I'm happy with that.

This has proved to be a fairly techy / geeky post, quite rare from me.

Squize.

Tips | tutorial

Comments [6] |

Mochibot and BitmapData.draw() issues

Tuesday, July 14, 2009

Random Dynamic Levels - Part 3

In the last two articles we made a maze and then destroyed it by adding a lot of free space. In part 3 of this articles I'm going to add some rooms to the empty space and add some doors ...

Part 3 - part 1 - why seperate things and make rooms?

At a first glance it might not be necessary to seperate data into dungeon, room and cell, but thinking ahead a bit it should make sense ...
My idea is that you can have the dungeon which holds the complete map (with the basic room data rendered into it) and the rooms so you access them easier and most important do some magic with them later. One of the neat things is that you could use a different tiling for rooms making them more detailed or use the additional map data for skinning (when rendering the dungeon into a tile based map).

The main difference between a room and a dungeon is that the room consists of empty cells and has walls along it's boundaries. So the first additional method we'd add to the Room class will be the init method, which simply sets all cells so they form a rectangular room.

public function initCells ():void {

    var x:uint;
    var y:uint;
    var cellTmp:Cell;

    for (x = 0; x < this.iWidth; x++) {
        for (y = 0; y < this.iHeight; y++) {

            cellTmp = this.cell2(x, y);
            cellTmp.setWalls(WallType.OPEN);

            if (x == 0) cellTmp.setWall(Dir.WEST, WallType.WALL);
            if (x == (this.iWidth - 1)) cellTmp.setWall(Dir.EAST, WallType.WALL);
            if (y == 0) cellTmp.setWall(Dir.NORTH, WallType.WALL);
            if (y == (this.iHeight - 1)) cellTmp.setWall(Dir.SOUTH, WallType.WALL);
        }
    }
}

We could later add methods to create different rooms (ie. two overlapping rectangles, circular rooms), but for now that will do ...

I also added a getter setter for Offset to the room, so we can modify the x and y pos of the bounding rect that we stored in the map class (you'll see later what's that for).

So we now have a room, but how do we get that sucker into the map, or (as just putting it into the map isn't really an issue) where can we place it *best*.

There are a few things that I want to watch when placing the rooms ...
- a room should not overlap any existing room, we rather don't at it
- placing a room at a place where it doesn't touch anything, is something we don't want, too
- rooms overlapping corridors should be avoided
- rooms touching dead ends is something we want (what's nice than finding a room after a long winded corridor?)
- rooms touching any sort of wall is OK, too

Yet again we (as humans) could just look at the map and say "here, there and there" and done, but that stupic piece of plastic cannot... we need to apply some sort of scoring to the whole placement mess.

Here's a bit of pseudo code ...

start with a VERY high best score, lets say 999999999999 and set current score to 0 ...
Loop over every cell in the dungeon

at any given position check if the new room overlaps any rooms already in there
if so, we add 5000 to our current score, otherwise we add nothing
now loop over every cell in the room and compare it with the current dungeon cell (offsetting the room to the current position)

if the current room cell touches an empty cell (in the dungeon), add 10

if we touch a wall, add 3
if we touch a dead end, add 1

if the final current score is lower than the best score, sreplace the best score and store the current position as the best possible location

if the score is higher than the "room overlaps room" score, assume that it only can be placed overlapping a room and drop it, otherwise add it to the dungeon

Here is the scoring code:

private const TOUCH_DEADEND:int = 1;
private const TOUCH_WALL:int = 3;
private const TOUCH_EMPTY:int = 10;
private const OVERLAP_ROOM:int = 5000;
private const OVERLAP_CORRIDOR:int = 100;

public function fitMazeRoom (myRoom:Room):Boolean {

    var iBestScore:int = 999999999;
    var iScore:int = 0;
    var pBestPos:Point = new Point(0, 0);
    var pOffset:Point = new Point(0, 0);

    var cellDungeon:Cell;
    var cellNext:Cell;

    var rectTmp:Rectangle = myRoom.rectBound.clone();

    var i:uint;

    var x:int;
    var y:int;

    var xx:int;
    var yy:int;

    var iRoomID:uint;

    var bAddRoom:Boolean = false;

    // loop over map (- roomsize)
    for (y = 0; y < (this.iHeight - myRoom.iHeight + 1); y++) {
        for (x = 0; x < (this.iWidth - myRoom.iWidth + 1); x++) {

            // do the scoring ...
            iScore = 0;

            // check room/room overlapping
            rectTmp.x = x;
            rectTmp.y = y;
            for (i = 0; i < this._aRoom.length; i++) {
                if ((this._aRoom[i] as Room).rectBound.intersects(rectTmp)) {
                    iScore += OVERLAP_ROOM;
                }
            }

            // check room/dungeon overlapping
            for (yy = 0; yy < myRoom.iHeight; yy++) {
                for (xx = 0; xx < myRoom.iWidth; xx++) {
                    pOffset.x = (x + xx);
                    pOffset.y = (y + yy);

                    cellDungeon = this.cell(pOffset);
                    if (cellDungeon.iType == RoomType.CORRIDOR) iScore += OVERLAP_CORRIDOR;

                    if (yy == 0) {
                        iScore += this.getCellScore(this.cell(this.getNextPos(pOffset, Dir.NORTH)), Dir.NORTH);
                    }
                    if (xx == (myRoom.iWidth - 1)) {
                        iScore += this.getCellScore(this.cell(this.getNextPos(pOffset, Dir.EAST)), Dir.EAST);
                    }
                    if (yy == (myRoom.iHeight - 1)) {
                        iScore += this.getCellScore(this.cell(this.getNextPos(pOffset, Dir.SOUTH)), Dir.SOUTH);
                    }
                    if (xx == 0) {
                        iScore += this.getCellScore(this.cell(this.getNextPos(pOffset, Dir.WEST)), Dir.WEST);
                    }
                }
            }

            if (iScore < iBestScore) {
                iBestScore = iScore;
                pBestPos = new Point(x, y);
            }

        }
    }

    // add to dungeon if it doesn't overlap any other rooms
    if (iBestScore < OVERLAP_ROOM) {
        myRoom.pOffset = new Point(pBestPos.x, pBestPos.y);
        bAddRoom = true;
    }

    return bAddRoom;

}

private function getCellScore (cellNext:Cell, iDir:int):int {

    var iScore:int = 0;

    if (cellNext.iType == RoomType.CORRIDOR) {
        if (cellNext.isDeadEnd) {
            iScore += TOUCH_DEADEND;
        } else if (cellNext.hasWall(Dir.getOppositeDir(iDir))) {
            iScore += TOUCH_WALL;
        } else {
            iScore += TOUCH_EMPTY;
        }
    } else {
        if (cellNext.iType == RoomType.ROOM) {
            if (cellNext.hasWall(Dir.getOppositeDir(iDir))) {
                iScore += TOUCH_WALL;
            } else {
                iScore += TOUCH_EMPTY;
            }
        } else {
            iScore += TOUCH_EMPTY;
        }
    }

    return iScore;

}

That's ugly and not very fast, but it works.

Some additional info about adding the room to the dungeon: whenever we place a room cell in the dungeon map it's a good idea to check if it overwrites a corridor and if it's a cell on the outer bounds of the room add a new wall to the touching cell (if it's not empty) ...

So far so good, we have rooms in the map, but they cannot yet be reached because we're missing doors ...

Part 3 - part 2 - adding doors and cleaning up

You might ask why I haven't added the doors as soon as I've added the room to the dungeon (and I might just reply that I just didn't mention it), but nope, I didn't add doors - that's the next step.

The reason is quite simple, though. I don't want doors cluttered all over the space and because of that I added another (optional) thing to the room data: hasDoorInDirection ... this way we make sure that there is only one door per wall / room when we add doors ...

Yet again we loop over all rooms and over their outer bounding cells, if we touch another cell, store the current position as possible door location. Then pick a random one per direction and check if it touches another room and if this room might already have a door ...
I guess that's easier to explain with some more code:

private function createDoors (myDungeon:Dungeon, bOneDoorPerRoom:Boolean = true):void {

    var rnd:MersenneTwister = MersenneTwister.getInstance();

    var i:uint;
    var j:uint;

    var x:uint;
    var y:uint;

    var cellTouch:Cell;
    var myRoom:Room;

    var aDoor:Array;
    var pDoor:Point;
    var pNext:Point;

    for (i = 0; i < myDungeon.aRoom.length; i++) {

        myRoom = (myDungeon.aRoom[i] as Room);

        aDoor = [[], [], [], []];

        // collect possible door locations ...
        for (y = 0; y < myRoom.iHeight; y++) {
            for (x = 0; x < myRoom.iWidth; x++) {

                pDoor = new Point(myRoom.pOffset.x + x, myRoom.pOffset.y + y);

                if (y == 0 && pDoor.y > 0) {
                    pNext = myDungeon.getNextPos(pDoor, Dir.NORTH);
                    cellTouch = myDungeon.cell(pNext);
                    if (!cellTouch.isUnused || cellTouch.iType == RoomType.CORRIDOR) {    // the check for a cooridor is needed because they might be just one cell long ...
                        aDoor[Dir.NORTH].push(pDoor);
                        if (cellTouch.isDeadEnd) aDoor[Dir.NORTH].push(pDoor); // double chances for dead ends ...
                    }
                }

                if (x == (myRoom.iWidth - 1) && pDoor.x < (myDungeon.iWidth - 1)) {
                    pNext = myDungeon.getNextPos(pDoor, Dir.EAST);
                    cellTouch = myDungeon.cell(pNext);
                    if (!cellTouch.isUnused || cellTouch.iType == RoomType.CORRIDOR) {
                        aDoor[Dir.EAST].push(pDoor);
                        if (cellTouch.isDeadEnd) aDoor[Dir.EAST].push(pDoor); // double chances for dead ends ...
                    }
                }

                if (y == (myRoom.iHeight - 1) && pDoor.y < (myDungeon.iHeight - 1)) {
                    pNext = myDungeon.getNextPos(pDoor, Dir.SOUTH);
                    cellTouch = myDungeon.cell(pNext);
                    if (!cellTouch.isUnused || cellTouch.iType == RoomType.CORRIDOR) {
                        aDoor[Dir.SOUTH].push(pDoor);
                        if (cellTouch.isDeadEnd) aDoor[Dir.SOUTH].push(pDoor); // double chances for dead ends ...
                    }
                }

                if (x == 0 && pDoor.x > 0) {
                    pNext = myDungeon.getNextPos(pDoor, Dir.WEST);
                    cellTouch = myDungeon.cell(pNext);
                    if (!cellTouch.isUnused || cellTouch.iType == RoomType.CORRIDOR) {
                        aDoor[Dir.WEST].push(pDoor);
                        if (cellTouch.isDeadEnd) aDoor[Dir.WEST].push(pDoor); // double chances for dead ends ...
                    }
                }
            }
        }

        // now just pick one door per side ...
        for (j = 0; j < Dir.NUM_BASEDIR; j++) {

            if (aDoor[j].length > 0) {

                pDoor = aDoor[j][rnd.Range(0, (aDoor[j].length - 1))];
                pNext = myDungeon.getNextPos(pDoor, j);

                if (!myRoom.hasDoor(j)) {
                    myRoom.setDoor(j, pDoor);

                    if (bOneDoorPerRoom && myDungeon.cell(pNext).iType == RoomType.ROOM) {
                        myDungeon.getRoom(myDungeon.cell(pNext).iValue).setDoor(Dir.getOppositeDir(j), pNext);
                    }

                    myDungeon.cell(pDoor).setWall(j, WallType.DOOR);
                    myDungeon.cell(pNext).setWall(Dir.getOppositeDir(j), WallType.DOOR);
                }
            }
        }
    }
}

Viola done ... but wait one more thing, cleaning up ...

The last step might not be needed, but imho it makes some nice dungeons: after we've added all the rooms and doors, we remove all remeaning dead ends. This way there will be no corridors just ending somewhere and the map looks nicer.

So we just run the removeDeadEnds method again, this time with 100% ... now:done.

As with the last parts, the link to a working demo of the whole mess is here or here.

nGFX

coding ideas | Dungeon Creation | experiments | game development | tutorial

Comments [4] |

Random Dynamic Levels - Part 3

Wednesday, July 01, 2009

AS3 OOP, without the bollocks, part 1

I've found myself defending oop recently, and at the same time bemoaning the lack of good oop tutorials with regards game development.

Rather than promising to write a full blown tutorial, as to be honest there's no way I'll stick to it, after around 3 parts at most I'll be bored stupid, I thought I'd try and explain the structure behind an existing game which we've already posted the source to. So it may be an idea to open this link in it's own tab.

Ready ? Ok, let's go.

Look at that, made with a free package so you get the watermark, nothing's too cheap for you dear reader.

This at heart is how I've structured all my games since starting with as2. It only varies in that there are sometimes more classes in there, the actual hierarchy never changes.

Ok lots of code here is never that great to read, but there's no way around it, sorry,

package {
    import Classes.Init;

    import flash.display.DisplayObject;
    import flash.display.Sprite;
    import flash.display.Stage;
    import flash.display.StageQuality;
    import flash.display.StageScaleMode;
    import flash.events.Event;

    [SWF(width="600", height="400", frameRate="35", backgroundColor="#000000")]

    public class Main extends Sprite{

//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        private static var instance:Main;
        private static var __parent:DisplayObject;
        private static var stage:Stage;
        private static var init:Init;

//---------------------------------------------------------------------------------------
// Static ( Singleton )
//---------------------------------------------------------------------------------------
        public function Main(){
            if(instance){
                throw new Error( "Singleton and can only be accessed through Singleton.getInstance()" );
            } else {
                instance=this;
            }

            instance=this;
//When we are running from our preloader, comment this out
            waiting();
        }

//---------------------------------------------------------------------------------------
// Public
//---------------------------------------------------------------------------------------
        public override function toString():String {
            return "Main";
        }

//---------------------------------------------------------------------------------------
        public function waiting():void{
            addEventListener(Event.ADDED_TO_STAGE,mainAddedToStage);
        }

//---------------------------------------------------------------------------------------
// Getters
//---------------------------------------------------------------------------------------
        public static function getInstance():Main {
            return instance;
        }

//----------------------------------------------------------------------
        public function getMainMovie():DisplayObject{
            return __parent;
        }

//----------------------------------------------------------------------
        public function getStage():Stage{
            return stage;
        }

//----------------------------------------------------------------------
        public function getInit():Init{
            return init;
        }

//---------------------------------------------------------------------------------------
// Private
//---------------------------------------------------------------------------------------
        private function mainAddedToStage(e:Event):void{
            stage=this.stage;
            stage.showDefaultContextMenu=false;
            stage.scaleMode = StageScaleMode.NO_SCALE;
            stage.quality=StageQuality.LOW;
            stage.stageFocusRect=false;

            __parent=this.root;

            init=new Init();
        }

//---------------------------------------------------------------------------------------
    }
}

Hopefully this should be fairly straight forward ( I did actually grab it from somewhere else when looking for an as3 version which matched what I was doing in as2, so sorry original author, I can't tell anymore what's yours and what's mine ). We're basically waiting around until this instance is added to the stage ( If you try and read some properties before it's technically been created then you're going to get errors. ) and then running the mainAddedToStage method. Importantly we have some getter methods set up here, as we need them ( More later ). This is our document class, and as such it has a "direct" link with the swf ( For want of a better term ). From now on throughout every other class, any reference to stage or Main is obtained from this class.
The very last line you'll see we create a new instance of the Init class ( init=new Init(); ), so let's check that class out.

package Classes {
    import flash.display.DisplayObject;
    import flash.display.Sprite;
    import flash.display.Stage;

    public class Init {
//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        private var gameController:GameController;
        private var attract:Attract;
        private var soundHandler:SoundHandler;

//------------------------------------------------
// System
//------------------------------------------------
        private var main:Main;
        private var mainMovie:DisplayObject;
        private var stage:Stage;

//---------------------------------------------------------------------------------------
//Constructor
//---------------------------------------------------------------------------------------
        public function Init(){
            main=Main.getInstance();
            mainMovie=main.getMainMovie();
            stage=main.getStage();

            soundHandler=new SoundHandler();

            gameController=new GameController();
            attract=new Attract();
        }

//---------------------------------------------------------------------------------------
// Public
//---------------------------------------------------------------------------------------
        public function toString():String {
            return "Init";
        }

//---------------------------------------------------------------------------------------
// Getters
//---------------------------------------------------------------------------------------
        public function getAttract():Attract{
            return attract;
        }

//---------------------------------------------------------------------------------------
        public function getGameController():GameController{
            return gameController;
        }

//---------------------------------------------------------------------------------------
        public function getSoundHandler():SoundHandler{
            return soundHandler;
        }

//---------------------------------------------------------------------------------------
    }
}

This again is a bit of a nothingy class. In theory it could be shoved into the Main class with no real harm, the reason I don't is pure lazyness. I like being able to copy the Main class to every new project without having to think about it, i.e aside from the [swf] tag I never have to alter it. It just feels cleaner having that first class do very little.

If you look at our Init class you'll see we just create instances of each class we need ( Refer to our cheapo diagram to help clarify ), and set up some getter methods again ( Just to clarify, a method is exactly the same as a Function, it's just that if you use a function in oop it's called a method instead. I don't know why either ), so other classes can get a reference to these instance's if they need to.

How do I decide which classes sit on which row of the hierarchy ? Main is our document class, so he's at the top and doesn't really do much. Init is Main's love child, and doesn't do much either, he's just creating the actual game classes.
The next row is more interesting. Attract is our front-end. It deals with the title screen, the game over screen, hi-score entry if the game supports it, instructions etc. Basically everything that happens before starting the game and after the game has finished.
Let's jump over to SoundHandler. This is just what it says. It's here because it's used by both Attract and GameController, as both need to have sounds. GameController is a simple class like Init, it handles the creation of all the child classes needed for the game ( Check the diagram ).

Let me try and rationalise why Attract, GameController, SoundHandler are all on the same row, in effect why they're equal to each other. We've already established that Attract and GameController need to be aware of the SoundHandler class as both need sounds. In the grand scheme of things, the Attract class doesn't really need to know about GameController ( Remember Attract is everything but the actual game ) and conversely the GameController really doesn't give a crap about Attract. If one of these classes is working, then the other isn't doing anything, so it makes sense to me that they're on the same row.
Does that mean they never need to chat to each other ? No, but it's at very key points. For example, when the player presses the "Play Game" button in Attract, we kill off all the Attract mode things and then call startGame() method in GameController.

Now we come to something cool. Quite a few times I've seen people moving over to oop, and it's all going well, until they need a reference to a different class. How the hell do we get the reference we need ? No one wants to pass a reference to a class via a constructor, as that's just messy and nasty and really easy to screw up, and it's not like we can be old school and use _root.myMethod(); when we're oop gods.

Notice all my constructors are the same, eg,

//------------------------------------------------
// System
//------------------------------------------------
        private var main:Main;
        private var mainMovie:DisplayObject;
        private var stage:Stage;

//---------------------------------------------------------------------------------------
//Constructor
//---------------------------------------------------------------------------------------
        public function GameController(){
            main=Main.getInstance();
            mainMovie=main.getMainMovie();
            stage=main.getStage();
        }

We get a reference to our document class, Main and store it in our local var main. We also store away a reference to our mainMovie ( To be honest I don't think I've used that ref. in as3 yet, it's just a throw back to my as2 code, but I'm a creature of habit so it'll stay there 'til as4 ) and the Stage.

So this is the GameController class, and it's game over, so we want to call the Attract class as he deals with that. This is how we get our reference:

main.getInit().getAttract().gameOver();

Check back with our Main class code up there, see getInit() in the getters section ? It returns a reference to our Init instance. Then look at the Init getters, getAttract() gives us our instance of Attract, and from there we're just calling the method gameOver in the Attract class.
Don't worry if this doesn't make sense straight away, it's quite a bit to get your head around in one go. Basically so long as we have a reference to Main in any class, we can get a reference to any other class no matter how far away from the callee class we are. References aren't a pain in the arse anymore, they're as simple as this.

You may be thinking, how the hell am I going to remember all those getOurInstanceName() method calls. Auto-completion. Flex does all this for you so it's never an issue ( And I'm sure Flash Develop does the same ). I don't know about the Flash IDE, I really don't hold much faith in it doing it, so now may be the time to install Flash Develop and have a play with that.

See we've got the basics of oop hierarchy covered, and I've not had to slip into terms like singleton and composition. Feel free to google both terms, see what they actually mean, and hopefully when you read the flowery descriptions you'll realise that you already get them as we've covered them here.

As always feel free to fire over questions or point out glaring errors in what I've done. Like I said all my games pretty much follow this pattern, which makes sharing code between projects a lot easier plus I'm not having to think about how classes are inter-connected. I'm not suggesting you just blindly copy what I've done, but perhaps plan out your next game using some simple flowchart boxes so you can see where classes should be connected and where it'll be a waste of time to do so.

Squize.

game development | Tips | tutorial

Comments [12] |

AS3 OOP, without the bollocks, part 1

Monday, June 29, 2009

Random Dynamic Levels - Part 2

This is part 2 of my collection of articles that'll deal with the theory (and the actual creation) of random dynamic levels for a (space)game. In part one we created a damn pretty maze and in part two we're going to modify it a good deal.

If you take a look at part one's output you'll notice that the code generates a pretty random maze. And there we got out first drawback: it's pretty darn random, way to random to assemble a man made structure and not quite what we would expect a spacestation / space ship to look like.

So the first modification I'm going to add will be a method that can reduce the randomness of the maze.

Part 2 - part 1 - making something not that random

My idea is to qualify the randomness by a percentage value, so a random factor of 0 will give you long straight passages that only change direction if the need to (random at that), while using a value of 100 the method will never (as far as it possible) return the same direction twice.

Of course that tiny little addition causes a lot of fuzz and requieres to rewrite a part of the core maze generator function. In part 1 I used a method to get all surrounding cells of a given point, but in order to use the direction modifier we need to use directions instead.

//... skipped

          while (iCellCount < iTotalCells) {

                // get neighbor cells ...
                aCellDirections = myDungeon.getPossibleDirections(pCurrentCell);

                // set the cell
                if (aCellDirections.length != 0) {

                    /* old way no direction modification used
                    iRndCell = rnd.Range(0, (aCellNeighbors.length - 1));
                    iRndDir = Dir.getDirFromPoint(pCurrentCell, aCellNeighbors[iRndCell]);
                    */
                    iRndDir = this.getFactoredRandomDir(iLastDir, aCellDirections, iDirChange);
                    pNextCell = myDungeon.getNextPos(pCurrentCell, iRndDir);
                    iLastDir = iRndDir;

                    // remove walls
                    myDungeon.cell(pCurrentCell).setWall (iRndDir, WallType.OPEN);
                    // old way: myDungeon.cell(aCellNeighbors[iRndCell]).setWall(Dir.getOppositeDir(iRndDir), WallType.OPEN);
                    myDungeon.cell(pNextCell).setWall(Dir.getOppositeDir(iRndDir), WallType.OPEN);

                    // store for later use ...
                    aCellStack.push(new Point(pCurrentCell.x, pCurrentCell.y));
                    // old way: pCurrentCell = new Point(aCellNeighbors[iRndCell].x, aCellNeighbors[iRndCell].y);
                    pCurrentCell = new Point(pNextCell.x, pNextCell.y);

                    iCellCount++;
                } else {
                    pPopCell = aCellStack.pop();
                    pCurrentCell = new Point(pPopCell.x, pPopCell.y);
                }

            } // while

Some new variables in there: iLastDir (so we can keep track of the last direction used), pNextCell (a point that stores the next cell, basically just a temp. variable), iRndCell has been removed and aCellNeighbours has been renamed to aCellDirections ...

There are two new methdods: getPossibleDirections and getFactoredRandomDir. The first one returns an array that just contains directions that can be used (ie. cells that have not been visited yet), directions are simply stored as 0=North, 1=East and so one (I've encapsulated them into a Dir class to make it easier to read). The second method is a neat example how to make things overly complicated ...

        private function getFactoredRandomDir (iLastDir:int, aListDir:Array, iFactor:int = 50):int {

            var rnd:MersenneTwister = MersenneTwister.getInstance();
            var bChangeDir:Boolean = (rnd.Range(0, 99) < iFactor);

            var iReturn:int = iLastDir;

            // the last used dir is not in the list of possible new directions, so we need to pick a random one ...
            if (aListDir.toString().lastIndexOf(iLastDir.toString()) == -1) {
                iReturn = aListDir[rnd.Range(0, (aListDir.length -1))];
            } else {

                // we must change direction AND have at least 2 choices
                if (aListDir.length > 1) {

                    if (bChangeDir) {
                        while (iReturn == iLastDir) {
                            iReturn = aListDir[rnd.Range(0, (aListDir.length -1))];
                        }
                    }

                } else {
                    // just pick what's left ...
                    iReturn = aListDir[0];
                }

            }

            return iReturn;


        }

AS3 arrays (in CS3) don't have the nice method I know from c#: contains which would have been oh so easy to use here. I toyed for a fraction of a second with the idea to use a loop to check if a given value would be in an array, but then decided to go ... quick and dirty and use toString and lastIndexOf instead.

The code above is quite easy, so I only do a quick run through it...
- decide if we need to apply a direction change
- if we need to, check if the last dir is in the list of possible dirs, if not just pic a random new (this applies to both states: need to change and keep direction)
- otherwise just pick a random dir until it's not equal the last dir used

That's it.

Running the test app with different values seems to produce the desired results:
0% produces the most possible straight halls,
50% produces somewhat random halls
100% produces a maze with no straight hall at all.

Part 2 - part 2 - still way to much filled space ...

Looking at the maze reveals that there are no free spaces in it, of course we could just paint rooms over it, but I doubt it'll look like what I have in mind.
Randomly removing cells from the map is no option (even if we do check if we would just block a passage), but what about removing cells that just end the passage (ie: dead ends).
Looking at the maze again, it seems that we have (depending on the randomness of direction changes) a lot of them, so our next task would be to find those dead ends and remove them. The first "problem" that comes to me is that each time we remove dead ends, we'd create new ones. In order to clean up the map we only run the "removDeadEnds" methods a couple of times and we're done - right?

Not quite.

If we choose some unlucky values, it might happen that we kill the whole maze and that's something we don't want at all.

I decided to use a percentage of TotalCells that I want to be removed, so if we use 50%, the method should remove half of all available cells.

        public function removeDeadEnds (myDungeon:Dungeon, iRemoveDeadEnd:int = 20):Dungeon {

            var rnd:MersenneTwister = MersenneTwister.getInstance();

            var i:int;
            var j:uint;
            var iDir:int;
            var iRndCell:int;

            var iDeadEndsToRemove:int = Math.ceil((myDungeon.iWidth * myDungeon.iHeight) * iRemoveDeadEnd / 100);
            var iDeadEndCount:int = 0;

            var bExit:Boolean = false;

            var aTmp:Array;

            // the worst case may only return one dead end per run, so
            // to be sure we run it as many times as we may max need
            for (i = 0; i < iDeadEndsToRemove; i++) {

                aTmp = myDungeon.getDeadEnds();

                if (aTmp.length > 0 && !bExit) {

                    while (aTmp.length > 0) {

                        // this is to make sure that the cells are somewhat even
                        // distributed if we do not use the whole lot
                        iRndCell = rnd.Range(0, (aTmp.length - 1));
                        iDir = myDungeon.cell(aTmp[iRndCell]).getDeadEndDir();

                        myDungeon.cell(myDungeon.getNextPos(aTmp[iRndCell], iDir)).setWall(Dir.getOppositeDir(iDir), WallType.WALL);
                        myDungeon.cell(aTmp[iRndCell]).setWalls();

                        aTmp.splice(iRndCell, 1);

                        if (++iDeadEndCount >= iDeadEndsToRemove) {
                            bExit = true;
                            break;
                        }

                    }
                } else {
                    break;
                }

            }

            return myDungeon;

        }

The comments should explain quite well what's going on in there. Only thing to mention is that I pic random dead ends if there are more available dead ends than cells to remove.

Compile and test ... and viola well done for today. :)

(I must admid it took longer to type all that than to code, so I had a bit of spare time left and coded something alse ;) )

I think that is enough for today, you can see the result (and from the upcoming articles, too) Random Dynamic Level Creation Test page (or here if the server is down).

nGFX

coding ideas | Dungeon Creation | experiments | game development | tutorial

Comments [0] |

Random Dynamic Levels - Part 2

Wednesday, June 24, 2009

Random Dynamic Levels - Part 1

After a good while of non-techy pimpings I decided to go the x++ route and describe the process of diving into a new game ...

(CE is again on hold due to some gameplay issues I found during testplays - oh well)

There is no name to the game yet, but I can say as much as it will feature random dynamic level creation (as used in Diablo 1 for example), sci-fi themed, using RPG elements and use Unity (though the levels created will look quite different to Diablo, but the idea is the same).
I want to have random levels because that would add to the replay value of the game. I want a single game to last between 15 and 45 minutes. You should be able to start playing and kill the end-boss in that time. After that you should be able just play again, but with different set of maps ...

But to get things rolling a lot quicker I wanted to rapid prototype my ideas using flash/AS3 and then port it to c#.
The reason for this is quite simple: output. In order to "see" what the level will look like without having to worry about how to display them (ie. place 3d walls, create the assets). With using flash i can just grab the data from the generator classes and use the drawing api to quickly throw out a few lines to show the generated data.

Let's dive straight in.

Part 1 - part 1: To cell or to tile ... and is there anything we need before that?

Before I started I thought that it would be nice to move between maps (in case you thought you forgot something), to do so there needs to be a way to store the maps ... I thought of 2 methods:
a) store all visited maps
b) make them reproduceable

I prefer the later one.

So instead of using some built in random number generator I decided to use my "own" that takes a seed and the produces the same set of random numbers when using that seed - perfect.
I found some old AS1 source of some older rnd gen that I could have ported but a quick search showed that there are some more powerfull ones. After bit of research I decided to go with the Mersenne Twister algorithm. As I was too lazy to see if there was an AS3 port, I wrote my own implementation, though you could use any rnd method you want.

The next one was a bit tricky: cell based or tile based?
Tiles are easy to use and to handle, but they are limited to a single spot and mostly do only have a single "state", ie. you can walk on them or not. This might be ok in most cases but for what I have in mind they are too limited.

A cell in my case is a tile with 4 walls (north, east, south and west), if all 4 walls are set, the cell is "closed" ie. a solid rock in a clasical dungeon. The cell also stors a single integer value (so based on it's useage I could store an index in it.
Here is the code for the cell:

package com.gamingyourway.Dungeon {

    /**
     * Cell datatype
     * @version 2009 06 24
     * @author nGFX
     */
    public class Cell {

        public static const WALL:int = 0;
        public static const OPEN:int = 1;

        private var _aWall:Array;    // array of values ... 0=empty ...
        private var _iValue:int;    // stores a single value, ie. room num
        private var _bVisited:Boolean;    // has cell been visited
        private var _bCorridor:Boolean;    // is cell a corridor


        public function get aWall ():Array { return this._aWall; }
        public function set aWall (value:Array):void { this._aWall = value; }

        public function get iValue ():int { return this._iValue; }
        public function set iValue (value:int):void { this._iValue = value; }

        public function get bVisited ():Boolean { return this._bVisited; }
        public function set bVisited (value:Boolean):void { this._bVisited = value; }

        public function get bCorridor ():Boolean { return this._bCorridor; }
        public function set bCorridor (value:Boolean):void { this._bCorridor = value; }

        public function get wallCount ():int {

            var i:uint;
            var iCount:int = 0;

            for (i = 0; i < this._aWall.length; i++) {
                if (this._aWall[i] == 0) iCount++;
            }

            return iCount;

        }

        public function get isDeadEnd ():Boolean { return (this.wallCount == 3); }
        public function get isUnused ():Boolean { return (this.wallCount == 4); }

        /**
         * Creates a new empty (ie. all walls set) cells
         * @param    iValue    used to stor a single bit of info, ie. room num
         */
        public function Cell (iValue:int = 0) {

            this._aWall = [0, 0, 0, 0];
            this._iValue = iValue;
            this._bVisited = false;
            this._bCorridor = false;

        }

        /**
         * sets a single wall
         * @param    iDir    Direction of the wall
         * @param    iWall    value of the wall, 0 is a solid wall, any other value makes it "open"
         */
        public function setWall (iDir:int, iWall:int = 0):void {

            this._aWall[iDir] = iWall;

        }

        /**
         * return the value if the wall in iDIr
         * @param    iDir    direction of the wall to get
         * @return    value of the wall
         */
        public function getWall (iDir:int):uint {

            return this._aWall[iDir];

        }

        /**
         * shortcut for testing if there is a closed wall in iDir
         * @param    iDir    direction to test
         * @return    true if there is a wall
         */
        public function hasWall (iDir:int):Boolean {

            return (this._aWall[iDir] == 0);

        }

        /**
         * if the cell is a dead end, return the direction of the opening
         * @return    the direction of the opening
         */
        public function getDeadEndDir ():int {

            var iReturn:int = -1; // not a dead end

            if (isDeadEnd) {

                if (this._aWall[Dir.NORTH] != 0) iReturn = Dir.NORTH;
                if (this._aWall[Dir.EAST] != 0) iReturn = Dir.EAST;
                if (this._aWall[Dir.SOUTH] != 0) iReturn = Dir.SOUTH;
                if (this._aWall[Dir.WEST] != 0) iReturn = Dir.WEST;

            }

            return iReturn;

        }

        /**
         * returns a string representation of the cell
         * @return    a string for the falls of this cell
         */
        public function toString ():String {

            var i:uint;
            var strReturn:String = "";

            for (i = 0; i < this._aWall.length; i++) {
                strReturn += this._aWall[i].toString();
            }

            return strReturn;

        }


    }

}

Part 1 - part 2 - Storage and creation

To store the maps generated I wrote a simple Mapa datatype, it'll store a 2d array of cells along with some very basic methods to deal with the data.
The map type also stores width and height in an rectangle, to have an easy way to check if a point lies within the boundaries of the map.
Aditional methods so far:

hasCellInDir (pPos:Point, iDir:uint):Boolean
getNextPos (pPos:Point, iDir:uint):Point
getSurroundingCells (pPos:Point, bUsed:Boolean = false):Array

To create a map (let's call it dungeon for the sake of easiness) I didn't include the methods need to create a dungeon in the map class, instead I wrote a DungeonGenerator class, that returns a filled map class. This way I can mess around with the creation process without messing with the map class.

Part 1 - part 3 - Let's start with a simple maze ...

The most simple representation of a dungeon I can think of is a maze. Mazes are incredibly easy to create and they work oh so well with cells.

The walkthrough to create a maze:
1. create a map of "solid" cells
2. pick a random solid cell as starting point
3. get surrounding solid cells and pick a random one
4. knock the walls between these cells, store the "old" cell in a stack for later use
5. use the cell picked in 3 as new starting point and start over
6. if the current cell has no solid neighbours, pop one from the stack
7. repeat until there are no more solid cells

Easy, eh?

package com.gamingyourway.Dungeon {
    import de.drygoods.Random.MersenneTwister;
    import flash.geom.Point;

    /**
     * Dungeon generator
     * @version 2009 06 24
     * @author nGFX
     */
    public class DungeonGenerator {

        private var _Dungeon:Dungeon;
        private var _rnd:MersenneTwister;

        public function DungeonGenerator(iWidth:int, iHeight:int) {

            this._Dungeon = new Dungeon(iWidth, iHeight);

            this._rnd = MersenneTwister.getInstance();

        }

        public function createMaze (iDirChange:int = 100):Dungeon {

            var aCellStack:Array = new Array();
            var aCellNeighbors:Array;

            var iTotalCells:int = this._Dungeon.iWidth * this._Dungeon.iHeight;
            var iCellCount:int = 1;
            var iRndCell:int;
            var iRndDir:int;

            var pCurrentCell:Point = new Point(this._rnd.Range(0, this._Dungeon.iWidth -1), this._rnd.Range(0, this._Dungeon.iHeight -1));
            var pPopCell:Point;

            while (iCellCount < iTotalCells) {

                // get neighbor cells ...
                aCellNeighbors = this._Dungeon.getSurroundingCells(pCurrentCell);

                // set the cell
                if (aCellNeighbors.length != 0) {

                    iRndCell = this._rnd.Range(0, (aCellNeighbors.length - 1));
                    iRndDir = Dir.getDirFromPoint(pCurrentCell, aCellNeighbors[iRndCell]);

                    // remove walls
                    this._Dungeon.cell(pCurrentCell).setWall (iRndDir, 1);
                    this._Dungeon.cell(aCellNeighbors[iRndCell]).setWall(Dir.getOppositeDir(iRndDir), 1);

                    // store for later use ...
                    aCellStack.push(new Point(pCurrentCell.x, pCurrentCell.y));
                    pCurrentCell = new Point(aCellNeighbors[iRndCell].x, aCellNeighbors[iRndCell].y);

                    iCellCount++;
                } else {
                    pPopCell = aCellStack.pop();
                    pCurrentCell = new Point(pPopCell.x, pPopCell.y);
                }

            } // while


            return this._Dungeon;

        }

    }

}

The code of the dungeon generator ... for now only with the maze creation in it.
Note that the variable iDirChange is currently not used, but I'll go over it in the 2nd part of this article.

I think that is enough for today, you can see the result (and from the upcoming articles, too) Random Dynamic Level Creation Test page (or here).

See you next time when I add some direction modifications and take care of dead ends ...

nGFX

coding ideas | Dungeon Creation | experiments | game development | tutorial

Comments [7] |

Random Dynamic Levels - Part 1

Wednesday, December 03, 2008

States machines in actionscript, nice and easy

December already, it really does fly.

I was chatting with our mate Jeff @ 8bitRocket the other week about function pointers / state machines and I thought it may be useful to quickly write something up about it here, as so much of my code relies on them and they do make life easier.

private var mainFunc:Function;

That's pretty much it.

I'm guessing all your routines have some sort of mainloop. Either you're old school and that's running on an enterFrame on each mc you're moving about or it's a public method in an object which you loop through and call every frame.

Let's take a space invaders mainloop as an example ( Psuedo-code ahead )

That should hopefully be straight forward enough. In real life we wouldn't want to be testing for thisInvaderIsDeadFlag every time, we'd just remove this invader from our array of active ones, but this is just an example.

Now check this out,

mainFunc=mainloop_normal;

function mainloop():void{
    mainFunc();
}

function mainloop_normal():void{
    moveInvader();
    testForShootingAtPlayer();
    testForBeingHitByPlayersBullet();
}

Here we've set up our function pointer to point to mainloop_normal, and then we just call that one method in our mainloop() method. Cool so far ?

Now we're not checking to see if the invader is dead, or if it's exploding. That's good, because by default the vast majority of the time neither of those are going to be true, so it's a waste to check ( It's like waking up every morning and seeing if it's your birthday ).

At the moment it's more of a function pointer than a state machine as such, so next up is why doing it this way is so sexy...

function testForBeingHitByPlayersBullet():void{
    if(playerBullet.hitTest(thisInvaderSprite)){
       thisInvaderSprite.gotoAndPlay("firstExplodingFrame");
       mainFunc=mainloop_waitingToDie;
    }
}

Here's our testForBeingHitByPlayerBullet method from the main loop. Imagine that's just doing a hitTest, the invader to the player bullet. Bang, it's a collision, but instead of having to set our areWeDyingFlag from the original example, we just change the state machine.

function mainloop_waitingToDie():void{
if(sprite.currentframe==endOfExplosionsFrame){
//Kill this invader totally, ie remove the mc
mainFunc=null;
}
}

In effect, no extra checks are needed every frame, we're only running what we need. We've got the advantage of a slight performance boost, but far more useful than that is the flexibility this gives us.

Say for example you want your invader to teleport in now, at the start instead of:

mainFunc=mainloop_normal;

we can now alter it to,

mainFunc=mainloop_waitingForInvaderToTeleportIn;

And run the code there waiting for your cool teleport effect to finish, and then just alter the mainFunc to carry on with our flow.

Running your code this way means you can chop and change states without having to have lots of extra conditionals in your code ( If the player is teleporting in, but that teleport tween isn't at frame 10 yet, then don't test for collisions with the player bullet etc. etc. ).

Any questions just hit that comment button,

Squize.

coding ideas | Tips | tutorial

Comments [8] |

States machines in actionscript, nice and easy

Thursday, November 06, 2008

Jelly cube with an animated plasma texture

Quite a descriptive title for this post for a change.

In this section of 651 we're running two effects, a bog standard RGB plasma effect and then a "Jelly vector" effect.

To create a plasma you're going to have to suck up to Math.sin, he's your daddy for this.

Firstly we pre-calc a colour table, eg.

        public function ColourTable(){
            colourTable=new Array();
            var cnt:Number=-1;
            var col:Number;
            var r:int;
            var g:int;
            var b:int;
            var offset:Number=3.1415;

//To avoid /4 for each pixel every frame, we just make the colour table 4 times as big
            while(++cnt!=256*4){
                r = 128 + 128 * Math.sin(offset * cnt / 32);
                g = 128 + 128 * Math.sin(offset * cnt / 64);
            b = 128 + 128 * Math.sin(offset * cnt / 128);
                col=(r << 16)+(g << 8)+b;
                colourTable.push(col);
                colourTable.push(col);
                colourTable.push(col);
                colourTable.push(col);
            }
        }

Here we're just creating what is in effect a gradient, so we have an array which smoothly goes from one colour to the last one. When it comes to the look-up when we're plotting we'd need to divide the value by 4, so to avoid this we make the colour table 4 times larger than is really needed ( Often it's a balance between memory usage vs speed. An easy way to think of it is with loops. If your game didn't have any loops and you just copy / pasted the same thing over and over it would run quicker, but take a lot more memory, and be pretty insane ).

Right the colour table is done, next up we create instances of our Pixel class,

            activePixelsStorage=new Array();
            var pixelObj:Pixels;
            var j:int=-1;
            var k:int;
            while(++j!=120){
                k=-1;
                while(++k!=120){
                    pixelObj=new Pixels(new Point(j,k),colourTable);
                    activePixelsStorage.push(pixelObj);
                }
            }

It's just like doing a tile based engine, each instance of our Pixel class is passed an x/y position so our plasma is 120 pixels wide by 120 high. That's pretty tiny so we double the scale of the sprite in which we're plotting and add a blur filter just to smooth it out. It's a lot less expensive than plotting a 240x240 plasma.

On to the actual Pixel class:

    public class Pixels{
//---------------------------------------------------------------------------------------
// Properties
//---------------------------------------------------------------------------------------
        private var xPos:int;
        private var yPos:int;

        private var cX:Number;
        private var cY:Number;

        private var jointDist:Number;

        private var offset:int;

        private var cT:Array;

//---------------------------------------------------------------------------------------
//Constructor
//---------------------------------------------------------------------------------------
        public function Pixels(pos:Point,colourTableArg:Array):void{
            cX=xPos=pos.x;
            cY=yPos=pos.y;
            var xDist:int=120-cX;            //Distance from the bottom
            var yDist:int=120-cY;

            cT=colourTableArg;

            var distance:Number=Math.round((Math.sqrt((xDist*xDist)+(yDist*yDist))/2));
            var distX:Number=256 * Math.sin(distance/8);
            var distY:Number=256 * Math.cos(distance/8);

            jointDist=distX+distY;
       }

//---------------------------------------------------------------------------------------
//Public
//---------------------------------------------------------------------------------------
        public function toString():String {
            return "Pixels";
        }

//---------------------------------------------------------------------------------------
        public function pixelmainloop(x:Number,y:Number,plotbm:BitmapData):void{
            offset = (Math.cos((xPos+x)*0.0525) + Math.sin((yPos+y)*0.0255))*256 + jointDist;

            if(offset<0){
                offset=(offset ^ -1) + 1;
            }

            plotbm.setPixel(xPos,yPos,cT[offset]);
        }
    }

I'm not going to go into too much detail with this, as it'll take ages to be honest. The most interesting part is the pixelmainloop, where we pass in the x/y ( As well as the bitmapData we're plotting too, more on that soon ), and from those coords we create an offset into the colour table. To create the smooth curves that makes a plasma look so sexy we use some lovely sin and cos ( That's the bit I'm skipping explaining in any real detail. It takes quite a bit of tweaking to get something looking how you like and different values really give different results, for example:

offset = (Math.cos((xPos+x)*0.0525) + Math.sin((yPos+y)*0.0255))*64 + jointDist;
offset=offset>>3;

That's what's used in the credits plasma / kaleidoscope effect, which uses exactly the same colour table values but looks totally different ).

All that's left for the plasma part is the mainloop that we run on the enterFrame.

            sinOffset++;
            var radian:Number = sinOffset/60;
            paletteShiftX = 128-Math.sin(radian)*255;
            paletteShiftY = 128-Math.cos(radian)*255;

            plotbm.lock();

            var pixelObj:Pixels;
            for each(pixelObj in activePixelsStorage){
                pixelObj.pixelmainloop(paletteShiftX,paletteShiftY,plotbm);
            }

            plotbm.unlock();

            if(plotbm==bm1){
                plotbm=bm2;
            } else {
                plotbm=bm1;
            }

            bmData1.bitmapData=plotbm;

Nothing too tricky here. We just increase the position ( Offset ) into the colour table every frame, and then use for...each ( Much quicker ) to loop through all our Pixel instances calling the pixelmainloop and passing the args.
The part that may be of interest is the plotbm var. To increase speed slightly we double buffer the plasma bitmap, so when one bitmapData is being displayed we're plotting to the other one which is no longer being shown.
To try and explain that a little better, we have two bitmapData objects, bm1 and bm2. bmData1 is our bitmap ( I find the difference between the two confusing as hell in as3. It makes total sense, it just doesn't seem to stay in my brain very well ) which is attached to the our holder sprite for the plasma ( The one we doubled in size and added a blur to as mentioned earlier ).
So lets say we have something like this:
holderSprite.bmData1.bm1;
And that's what you see on screen. If you can see bm1 that means we're plotting to bm2, and visa versa.

This is why we pass the currently hidden bitmapData to each instance of the Pixel class every frame rather than just passing one value in during it's construction.

That's plasmas for you. I've only really given the core concept as hopefully a spring board for your own experiments.

The Jelly cube is going to be much more straight forward, because someone else wrote the clever bit. After x amount of time we run a really quick white up over the whole stage, and that's where we remove the plasma all together and replace it with a papervision cube.

Ultra simple, we just rotate him and scale him. The twister code came from the excellent zupko who kindly open sourced it. Now we've got a twisty cube, what about the texture ?

This is another big fat cheat. At best you can get a plasma running the size we have at around 40fps, so there's no way we could do it realtime and run the cube. One idea I had early on was to use draw() on every frame of the plasma and store those away, then update the texture every frame on the cube using those stored away bitmaps.
I didn't go this route as I was concerned about the amount of memory it would use and I was concerned that using draw() may have had a negative performance hit when actually running the plasma ( I'm possibly paranoid about that and it would more than likely be fine, but it felt like quite a bit of data to be copying every frame when you want everything running as quickly as possible ).

The solution ? flv baby. Unless it's youTube the flv format seems to be badly over looked when it can be used for all types of tricks ( I did quite a bit of video work in games at preloaded long before flv came out so I've learnt what the advantages of using video are early on ).
I just ran the plasma for a little while grabbing the frames, cropped them up, created a copy running backwards and then joined the two together, so runs as A > B > A.
All that was left then was to created a flv texture for each side of the cube, and papervision along with Flash did everything for me.

The only thing left to cover off is the black outline on the cube. Again ultra simple, it's just a glow filter. Set it to black, turn up the strength, turn down the blurring and you've got a sexy outline.

Phew. I think this is going to be last in-depth-ish tut on the 651 effects. Not only does it takes ages, but I think the rest of the effects not touched on so far can be summarised in one post.

Squize.

experiments | Tips | tutorial

Comments [0] |

Jelly cube with an animated plasma texture

Thursday, October 30, 2008

Vector Bobs

Another quick break down of an effect in 651.

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.

coding ideas | experiments | tutorial

Comments [0] |

Vector Bobs

Wednesday, October 29, 2008

The sound of silience ...

Back again!

After a good deal of time I finally have something to post about - or let's face it moan about.

As the headling slightly might suggest I'm dealing with sound today.
I think that sound handling in AS3 is a nightmare compared to the ease of it in AS1/2 and I'm not the only one asking WTF?

So in order to play your sound you have to instanciate it, if it's exported CS3 kindly creates a class for you so you can easily use it ... (loading it from an external source is another story)

This is what the CS3 help gives us for embeded sounds ("working with embeded sounds"):

var drum:DrumSound = new DrumSound();
var channel:SoundChannel = drum.play();

My first question was: what do I need the SoundChannel for if I just want to play the sound?

Well, the rocket scientists at Adobe thought that it would be a good idea to add a play() command to the Sound, but not a stop(), so in order to stop our sound playing we *need* the SoundChannel - so we better store it for later use.

Anyway, to make my life easier I converted my SoundUtil class from AS2, basically it deals with the sounds so I don't have to think about it, it has a few usefull commands like playSFX (plays a sound effect, once), playMusic (which allows fading), crossfade ...
I usually used attached sounds (or from an external swf, but the SoundUtil dealt with it ...)
So in order to play music for the menu I'd just do:

SoundUtil.getInstance().playMusic("musicName", 2); // 2 would do a 2 sec. fade in

The AS3 version should work the same, although it uses static functions which then call the singleton's method.

Oh wait. We need to have a class to start the embeded sound ...

To get over that I wrote the add method, which basically takes the name of the sound (or the classname) and then does it's magic.

        public function add (strSound:String, bIsMusic:Boolean):void {

            var refClass:Class = getDefinitionByName(strSound) as Class;
            var sndTmp:Sound = new refClass();

            var iTmp:int = this._aSound.length;

            this._aSound.push(sndTmp);
            this._objSound[strSound] = { id:iTmp, bIsMusic: bIsMusic };

            if (bIsMusic) {
                this._objSound[strSound].spDummy = new Sprite();
            }

        }

Ha! that was easy ...

As you see the sounds name gets stored in an object (I just use it as dictionairy), I store an Object with some more values along with the name. And you surely might ask WHY on earth I did create a Sprite for music files ...
Well I'm a lamer, I use the Sprite to attach an onEnterFrameTo it for things like fading :)

Fast forward ...

k. Let's say we play some music, and only wont it to play 2 times, after that the sound should be removed from memory. Luckily we have the onSoundComplete Event, it should return (CS3 help): "The Sound object on which a sound has finished playing."

For me it reads like it returns the Sound that is playing. FAIL!

It does however return a SoundChannel, which of course HAS no information (prove me wrong) about the Sound it belongs to ...
So how can I unload/cleanup a Sound when an onSoundComplete occurs, if I don't know which Sound is playing (and don't want to write a seperate Listner for each sound)?

Oh lucky me...

Thank fuck I store a lot of things in my information object (not only what is shown in the add method), for instance I store the SoundChannel I got from Sound's play() command and I store if a Sound is playing ...

After a few hours of using our favorite search engine I came up with something so stupid it might even be brilliant ...

private function onSoundComplete (e:Event):void {

      var strKey:String;

      for (strKey in this._objSound) {
           if (this._objSound[strKey].bIsMusic) {
               if (this._objSound[strKey].chChannel == e.target) {
                   this._objSound[strKey].chChannel.removeEventListener(Event.SOUND_COMPLETE, this.onSoundComplete);
                   this._objSound[strKey].bIsPlaying = false;
                   // do some cleanup
               }
           }
       }

}

Basically I loop over all music "files" that are playing and *compare* their SoundChannel with the one returned by the Event.
That's so insanely stupid! But it works. Sweet.

Maybe it helps some of you ...

nGFX

coding ideas | Tips | tutorial

Comments [2] |

The sound of silience ...

Thursday, October 23, 2008

Infinite bobs

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

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.

experiments | Tips | tutorial

Comments [4] |

Infinite bobs

Tuesday, October 21, 2008

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.

experiments | Tips | tutorial

Comments [0] |

How it does what it does.

Thursday, August 28, 2008

Distance Based Broadphase

Collisions, they're always a part of my games that I'm never happy with. Not so much the actual this sprite has hit that sprite part ( The narrowphase of the check ), but the broadphase, ie deciding which checks are needed and which we can just ignore.

Different genres require different ways to test for collisions. For a long time now I've been using grid based checks ( As far back as this old beauty ) in arena based shoot'em ups. Simple enough, you split the screen up into overlapping sectors, and store each baddie in the sector it's occupying.
So let's say we've split the screen up into quarters, you check each baddie's position, and store it in one of the four arrays you've set aside for each sector. Then you can run through your bullets and see which sector they're in, so in theory you're only testing the baddies which are nearest to the bullet ( There's no point testing a bullet against a baddie which is on the other side of the screen ) which in an ideal world will reduce the checks by 75%. Not bad.

The problem I've always had with this is that it feels costly to maintain. I've always just cleared the sector arrays at the start of the baddie movement routines, I've never been clever enough to come up with a way to maintain it "properly". Therefore I could have baddies that have only moved a pixel or two since the last frame, there's no way they're going to have changed sectors, but I've had to treat them afresh.
That can't be good, but like I've said, I've never been able to come up with a clever way of negating that, so I've always just done it that big dumb way.

Recently quadtrees ( Check here for a great example, and an overview by the always excellent 8bitrocket can be found here ) and octtrees are very in vogue with Flash developers, so being a bandwagon jumper I thought I'd have a bit of that.

Again, I couldn't think of really good way to maintain the structure every frame, and it felt like you'd need a lot of objects to make it worthwhile ( Or just use it as a generic collision system for every game, but I'm not a fan of that. Collisions are a weird beast where very rarely does one hat fit all ).

One aspect that all the collision methods I mentioned above have, is shown below,

I'm going to generalise a bit here, but let's say we've drilled down into the correct sector / node / whatever. Our bullet is travelling along that path ( Pick which ever direction you feel more comfortable with, in my head it's going up and right ). Chances are it's never going to hit that baddie ( I know the baddie could in theory move enough to come into collision with it, but we're generalising for a second ).
So we've gone to quite a bit of effort to narrow down our collision checks, and then we're still running a check per bullet every frame when most of the time it's not going to hit ( Think of your accuracy rating at any game that checks such things. 75% is pretty good in a game. That means that 25% of all the bullets are going to miss, yet we're having to test 100% of the bullets a 100% of the time ).

This all felt a bit sucky in my head. A lot of cpu time spent on something that wouldn't happen.

Let's talks about "Distance Based Broadphase". I made that up, it's more than likely already been around for years with a different name and I've just happened across a similar idea, but it explains what it is pretty well.

I've approached it in a different way than how I normally set up the whole bullets / baddies stuff. Using DBB every baddie has an array of all the player bullets ( Well a linked list for speed ), and every time the player shoots that new bullet is shoved into that array.
During the baddies main loop it runs through all the bullets it has in it's array and checks it's distance to it ( The narrowphase checks are just your bog standard circle to circle collisions ). If it's distance has increased, then the bullet is moving away from the baddie, and it won't hit it.

So looking at that diagram above, lets say the bullet is flying up to the top left. The broadphase will keep checking as the distance from the bullet to the baddie is decreasing every frame, ie it's getting closer. It's possible that it could hit it, so it's worth checking.
Once the bullet goes past the sweet spot, it's moving away from the baddie. It'll never ever hit it, so we just remove it from the array and the baddie won't check for it again.

Whilst there's a possability of a collision it's worth checking, so it's not so costly ( If you're shooting at baddies from a distance then it's going to incur a cost until the bullet goes past the sweet spot, ie 'til the bullet gets to a point where it's not going to hit the baddie. The greater the distance the more the tests as it will take a while to actually get to the sweet spot ).
Going back to the first diagram, the bullet ( If moving to the top right ) is moving away from the baddie right from the start, so it's thrown away.
In effect we're checking the general direction until we get to the point of a hit, or a miss.

Now I've done some generalisation here. In real life your baddie will be flying around throwing some great shapes. For that, you just increase the size of the sweet spot to take it into account. If you have a fixed speed for a baddie you could work out exactly the sweet spot's size ( That is you'd work out if the baddie moving at it's max speed in a straight line to the bullets path how big the area to check would be ), or if you're lazy like me you just increase the size of the sweet spot by subtracting some pixels from the distance and testing it til it stops breaking.

Hopefully I've made some sense, it's proved to be quite a fair bit to explain. As always please feel free to post a comment if you have any questions or if I've got anything wrong. I'm sure I'll be editing this soon enough to clear things up.

Squize.

coding ideas | Tips | tutorial

Comments [7] |

Distance Based Broadphase

Wednesday, July 02, 2008

Game AI for dummies - or making the enemy see.

Sorry folks yet again no image ... but some code :)

The current game (let's call it CC for the sake of it) is getting close to the point where I would declare the main game engine done, most of the events are processed now and the final enemies are going to be done today (hurray!).

As the title suggests (wow it's something post related) I want to write about the dumb ass AI one, nope rather 4 of the enemies in CC use, if you were so bold to call it AI.

While reading up the docs about the original game I read this:

"goes around objects to the left"

And there are 3 more which go around things to the right.

HA!

I first simply ignored the fact of "going around" and just coded a simple "if enemie hits wall turn left".

(ok, I lied, there are some images)

So after noticing my mistake I removed the old code and started to write the one that should allow my enemy to move around things. Sounds easy enough.

Oh, that's easy.

"Go ahead as long as there is something to the left, if not, turn left ..."

After a while I really lost my temper and just coded something that could deal with right turns as well, by checking 3 tiles + one, as you can see in the next image.

Well that is stupid, isn't it?

Jein, it's a dummy approach. (jein is a pseudo German word, combining "ja" and "nein", yes and no).

Some of the common situations, the green arrow shows the next direction
and in "D" shows the use of the 4th check.

In order to simplify (though, yet unoptimised) the checking of the tiles I set up an array of points, holding the offset for each of the checks. To make my life even easier I just numbered the directions (which is used all over the game):
0 = north, 1 = east ...

So the array for 0 (north) looks like this:

this._aTest.push( [new Point(0, -1), new Point( -1, -1), new Point( -1, 0), new Point(1, 0)] );

And because this one should move to the left I added a second array that holds the next direction to go to:

this._aDirNext = [3, 0, 1, 2, 1, 2, 3, 0];

(You might wonder why it has eight entries instead of the needed four, I'll come to that later)
I now could just lookup the next direction I need to face by simply checking with the current direction:

this._iDir = this._aDirNext[this._iDir];

Now, with that in place checking the movement was easy:

private function checkMoveBug ():void {

    var strTest:String = "";
    var i:uint;
    var xx:int;
    var yy:int;

    for (i = 0; i < 4; i++) {

        xx = this._pPos.x + this._aTest[this._iDir][i].x;
        yy = this._pPos.y + this._aTest[this._iDir][i].y;

        if (this._refChipsGame.getTile(this._refChipsGame.aMapGame[xx][yy][0]).objProperties.bMonster && this._refChipsGame.aMapGame[xx][yy][1] == -1) {
            strTest += "0";
        } else {
            strTest += "1";
        }

    }

    switch (strTest.substr(0, 3)) {
        case "000": // "C"
        case "100":
        case "110":
            this._iDir = this._aDirNext[this._iDir]; // turn to the next dir
            break;
        case "111": // "A"
        case "101":
            if (strTest.charAt(3) == "0") {
                this._iDir = this._aDirNext[this._iDir + 4]; // this one uses the second pair for "A"
            } else {
                this._iDir = this.getOppositeDir(this._iDir); // this one is used vor "D"
            }
            break
        /*
        case "011":
        case "001": // "B"
            these are not needed because we can just move ahead
            (there is something to the left)
            break;
        */
    }

}

The final version has the 4th check removed from the loop and just checks it for "111" and "101".

And because we use an array to store the test offsets, we can make the enemy around things to the right by just changing the values (north):

this._aTest.push( [new Point(0, -1), new Point( 1, -1), new Point( 1, 0), new Point(-1, 0)] );

and changing the aDirNext array to face right:

this._aDirNext = [1, 2, 3, 0, 3, 0, 1, 2];

Vioal. Done.

I hope this is quite understandable (the code is, my writing might not)

nGFX

coding ideas | game development | tutorial

Comments [0] |

Game AI for dummies - or making the enemy see.