Friday, October 31, 2008
petal.jpg

Meet Petal

As way of a slight added bonus, click here to expand your mind ( Or make yourself feel sick, it'll be one or the other ).

Squize.

Friday, October 31, 2008 4:25:19 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Thursday, October 30, 2008
Another quick break down of an effect in 651.

651_vectorBallGrab2.jpg

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

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

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

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

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

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

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

Squize.

Thursday, October 30, 2008 12:42:37 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Wednesday, October 29, 2008
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

Wednesday, October 29, 2008 5:46:21 PM (W. Europe Standard Time, UTC+01:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Thursday, October 23, 2008
Here's another really old trick we used in 651.

651_bobs.jpg

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

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

        private var currentBitmapNumber:int;

Just set up 3 bitmaps, and then...

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

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

Next up, our mainloop,

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

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

The funky bit is the copyBitmap() method,

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

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

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

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

Squize.

Thursday, October 23, 2008 2:22:11 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [4]  |  Trackback
 Tuesday, October 21, 2008
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.

Tuesday, October 21, 2008 8:37:29 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Monday, October 20, 2008
Monday, October 20, 2008 1:08:54 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [9]  |  Trackback
 Friday, October 17, 2008
All the sections are in now, ready to go live Monday.

651_vectorBallGrab.jpg

Squize.

Friday, October 17, 2008 7:36:48 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Thursday, October 16, 2008
A couple of days late posting it here, but it gave everyone an extra couple of days to save up.

Flash CS4 is out now, here's the launch video ( Of the whole huge cs4 package )
http://tv.adobe.com/#vi+f1556v1715

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

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

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

Squize.



Thursday, October 16, 2008 12:28:30 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Tuesday, October 14, 2008
Here's a little grab of what I've been working on during my current down time.

651_sphereGrab.jpg

Part show-reel / part demo. Coming soon.

Squize.
Tuesday, October 14, 2008 11:15:46 AM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Monday, October 13, 2008
Every now and again there's a 48hr game comp on FlashKit games. I've not entered since the 2nd one ( Which I was really pleased to have won, so I wanted to keep my 100% record ) so I felt it was time again, to see if I can still turn it on.

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

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

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

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

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

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

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

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

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

Squize.

Monday, October 13, 2008 12:33:38 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [2]  |  Trackback
 Thursday, October 09, 2008
Just some news about the FHM game awards.

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

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

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

Bollocks.

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

Squize.

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

Thursday, October 09, 2008 7:52:50 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Wednesday, October 08, 2008
What do the following things have in comon?

test.swf (5,87 KB)

goAway.swf (8,07 KB)

test.png

goAway.jpg


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

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

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

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

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

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

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

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

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

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

Ha!

nGFX

Wednesday, October 08, 2008 11:14:04 AM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [5]  |  Trackback
 Sunday, October 05, 2008
More tinkering with Air, and SICO now has a front-end

soSICO_grab.jpg

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

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


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

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

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

Squize.

Sunday, October 05, 2008 4:26:57 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [0]  |  Trackback
 Thursday, October 02, 2008
Air. The future of RIA. Unless you try and actually use it.

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

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

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

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

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

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

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

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

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

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

Squize.

Thursday, October 02, 2008 9:20:04 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [7]  |  Trackback
 Wednesday, October 01, 2008
I'm currently touching wood ( tehehe ) that GMM is gold.

Guess how long it's taken ?

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

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

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

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

gmmMap.png

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

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

Squize.

Wednesday, October 01, 2008 2:30:47 PM (W. Europe Daylight Time, UTC+02:00)  #    Disclaimer  |  Comments [6]  |  Trackback