To celebrate ( If that's the right word, we'll have to see ) the launch of cronusX at Kongregate we've taken over the Freelance Flash Games news blog for a week. Well, taken over the theme anyway.

Check it out, as Olli has done an excellent job on the background, and we've both been through the hell that is messing with wordpress, and that's got to be worth a click ( And that's without evening mentioning the excellent work Ryan does at the blog with a constant stream of great posts ).

Squize.

Think this is going to be the last in the epic posts that have followed cronusX's little life, from back in the day when he was still called X to today, when the viral version finally goes live.

We've had a plan for a while now for gathering the stats from cronusX and displaying them in widgets on a custom page. We weren't allowed to data mine the version of cronusX on Candystand, we're only go to do it in the viral version, which is good 'cause it actually buys us some time to get them done.

We managed to get some data when we were beta testing the game, so there are some figures for test data ( I did a quick post with some stats here ).

First widget is the number of asteroids destroyed, here's a clipped screeny


Rather than just having a number and that's it, I'm trying to liven these widgets up by hopefully making them interesting. One thing the uk newspapers love doing is when say a new Dinosaur is discovered, they compare it to either black cabs or double decker buses, as apparently if they just put a figure we can't picture it. Shove a bus next to it, and we get it.

So in the spirit of a dumbed down newspaper article, I thought let's compare the weight of the total number of asteroids destroyed to double decker buses.

Figuring out the value is where it gets boring, and as it bored me I'm just passing it on. We're all about sharing. Plus regular readers will know every single time I put any sort of maths on here I get it wrong, so this post is like a sanity check for my calculations.

How big is an asteroid in the game ? Around 96 pixels. The player ship is around 45 pixels, so my train of thought was to set a real life size for the ship, multiply that by 4, and that would be the cubic size of an asteroid. I figured I'd just compare the ship to something in real life, and a F-15 Eagle seemed a good size. They're 63 feet long so let's pretend our ship is 63 feet long and wide too.
That makes our 96 pixel asteroid 252 cubic feet. In meters that's 76. The reason to covert to meters ? 'Cause this page gives us the some nice weight figures which need meters. Apparently we're looking at 3 tons per cubic meter, therefore our rocks weight is 76*3=228 tons. We're nearly there. All we need now is the all important weight of a bus, and the net never lets you down does it ? I went for unladen which is 12 tons. Almost there.

(numberOfRocks*228)/12

That's it. All this effort just for a stat. I think there are going to be another 8 or so widgets, so I'm going to have to come up with more silly things to compare the stats to. Now best you move along otherwise you're going to be asleep soon.

Squize.

"Be as select in those you endeavour to please, as in those whom you endeavor to imitate. Without love of fame you cannot do anything excellent"

Sir Joshua Reynolds 1772.

...tomorrow

Just a quick X++ stat to keep things ticking over on that front.

Since it's been on FGL the total distance flown has been 643 kilometres, which is the equivalent of going from Paris to Milan.

Boring, but true.

Squize.

PS. And 29274 shots have been fired in anger. That's a lot of anger.

Just a minor update about X++

The final version has been posted to FGL, so if you're a registered developer there with a 1+ rating in each of those different categories that I can't remember ( Market place and the like ) feel free to check it out ( It should be verified in a couple of days ).

We were looking to Kong for a sponsorship but we've not heard anything back, so off to FGL she goes.

It's funny how the last 0.5% of it has dragged on quite so long, but we were both tied up with proper work. I think it's worth the delay though, I'm really proud of it.

Anyway the next post about it should be a link to it's final home, and then we can move onto the next one.

Squize.

I have that written on the front of my pants.

The penultimate preview of X is online now and panting for you to play it.

New in this are the options screens, which between you and me I'm really not happy about. I backed myself into a corner with using tweens and bitmaps for the majority of the text / buttons, which take ages to actually get into the game.
Once they were in I realised I'd messed up by not giving appropriate feedback on each selection. I should have re-done them, but it would have taken ages and been really boring, so instead I just dropped in a really cheap way to show the feedback.

If there's going to be a part of the game that really bugs me, it's going to be the options. But the rational part of my brain ( As opposed to the part that makes me want to delete the whole game and start again 'cause those options aren't as good as they should be ) is saying that people will only ever got to the options once or twice ever, that the pay off for the look & feel of the game text is greater than losing out on a bit of feedback, and, well, fuck it.

The main thing in terms of feedback about the options is the alternative control method ( Well two actually, but in a lame lazy way ), which to be honest I really struggle to get to grips with. I coded it a couple of days ago and obviously tested it, and after a while it wasn't too bad ( I'm kinda used to EveryDay Shooter on the psp so it's not a million miles away from that ), but since than I've not used it, and having a quick go today showed that I'd fallen out of the habit of playing X that way, and that I really didn't want to get back into it.
Not really giving it the hard sell am I ? Well it's a case of it's there if you want it, although to me the default method is always going to be better.

Squize.

Only two more updates to go after this one, we're nearly there.

It's actually getting tricky now, as it's so close to being a final game, what I can and can't post. I don't want to give the whole thing away, but then I don't want to shut the door too early on you guys who have followed from the start.

In saying that the roadmap is as follows,
* build 19, the latest one, features the sound and music along with a couple of graphical tweaks and fixes.
* build 20, options so the new control modes can be tested.
* build 21, the global stats ( We've got something really sweet in mind that we're both really excited about. Not excited about the code, but the results should be way sexy ).

And then that should be it in terms of public releases. In my head I want the game to be finished next Friday, and then it'll just be a case of seeing what we're going to do with it.

For this build I've put a watermark in there. I was in two minds what to do, but I opted for the less sweary version ( I was going to put a harsh word onto the background, but figured that could just backfire ).
I'm not overly happy about having to do it, or rather feeling like I have to do it, but if it stops the game being spread in a beta version then all well and good.

Nearly there. It's really mad to think that it's just build 19. I've had some half days on it, and big breaks where real work has got in the way, but I've really not cheated ( ie worked on it for extra days but not said. I've had to "join" half days together rather than post builds after only working a couple of hours on it ) and to do a game like this in 19/20 full working days is pretty cool.
It shows what can be achieved if you have a real joy for the project, as opposed to an extended slog, and having pretty much complete creative control over it makes such a difference in terms of dev time.
We're going to have a really in-depth post mortem about this and see how we can transfer these things to client work to improve turn around.

Squize.

Bit of a minor update for X++ in anticipation of the options settings.

So what does build 18 bring to the party ? Well lots of things behind the scenes ( Such as FlashJoystick support, which is so sweet. I swear a little bit of pee shot out the first time an asteroid hit a ship and the joypad rumbled ).

On the surface though it's not a world apart for build 17, not every new build is a huge step forward. The main ( Only ? ) user facing update is the option screen right at the start allowing the user to set the "quality" of their machine.

We've touched on the play back issues on previous posts in this little mini-series and it's now become the time to address them. Basically if you've got a good enough machine you get to play it looking all super sexy. If on the other hand you're stuck with a less than able machine, picking the reduced visual quality option will turn off some of the love and hopefully enable you to actually play it.

What would be really nice would be if any of you guys have had input problems in the past ( Due to the nature of the time based mainloop, if things over-run too badly then Flash can't keep up with I/O requests, such as reading the keyboard ) could give it a go with the reduced quality settings and give us a shout back in the comments about it ( Including your spec ).

I'm also going to post this over at FK.games for the first time in it's own thread, 'cause it really needs testing on a wide range of machines. I can almost picture the next hour being one of writing caveats in that thread...

[ Update, thread is here ]

Squize.

< I wrote this yesterday, but then my net connection poo'd out on me, so it's a little bit past tense >

It's good to be back. My first free day for as long as I can remember ( This year at least ). It feels pretty damn great to be honest.

The main reason I'm free right now is that the Maths based educational project I was working on got cancelled the other day. There's a neat little story about life imitating art, indulge me a minute,

Story

Basically ( If you don't want to leave us ) an asteroid passed pretty damn close to the earth the other day.
The weird thing was that the concept of the game I was working on was to use maths to target a missile at an earth bound asteroid. So when I was in a meeting hearing how it was canned, we were all just a couple of hours away from starting over again and living in caves.

If you wrote it in a story it just wouldn't fly.

There's another game I'm close to based on the whole asteroids as the bad guys theme, and today I had a good crack at it again.

Where the development has been paused for such a long time, I'm not a 100% sure what's new and what's kinda new. So forgive any repetition.

The final flv is on the title screen now, and it looks great. It's really large in terms of filesize and ideally we'll be able to cut that down somehow and retain the quality, but it is a thing of beauty, nGFX has done some great work there ( It's worth watching all the way through, trust me ).
The player movement is less, well, shit, which is always a plus.
Options are in there now. Well, a button saying Options, I really wouldn't press it as you'll probably have to reload the swf ( Although you'll be able to look at our logo rather than a blank screen again, which is another new thing ).
( Adding that options button was a ton of work due to the curved text and the set in stone way I'd set things up. That'll teach me ).
The "play" options are in. They're all unlocked now so you guys can check them out easily, but in real life you won't see those options if none of those features are unlocked ( ie, pressing Play will just make the game play as you'd expect without an extra click ).
Notes are gone. They weren't that great so sod it, they're dead and buried.
There's a lens flair in the game now, although it's pretty subtle and is based on a "Chroma fan" rather than a usual flare.

I'm sure there must be some other bits and bobs, but those are the main things that spring to mind. As always, the latest build is here, thanks for taking the time to give it a bash.

Squize.

Since I started on X+++++ I've always had it in my head doing it as a d/load game too ( That's why it's 800x600 ), using Zinc to wrap it up in.

So I have rencently finished a bigger update on a client's website, dealing with all the nasty and ugly shit one would rather like to avoid (to name just one: css - what was wrong with the good old table layout? OK, I know what was wrong, but dealing with all the browser's shitty problems to make it look nearly the same is just ... well, shit)

Meanwhile Squize was hammering out post after post so I didn't felt too bad being quiet.

Now today I actually have something to post, so here we go ...



This is a single frame from the X menu/background animation I've been doing. It'll take a while to render so I have to set up the network renderer on Monday to get the 30 seconds movie out to an flv file (which then will be played in the X menu) ...

If you're a fan of that game already, why not use that image as wallpaper? You can grab the 1024x768 version here.
Bigger Versions are rendered tonight and will be posted later this week - and maybe (if rendertimes for hi-res vids aren't that high there might (really just might) be a screensaver ... we'll have to see).

nGFX

Busy busy busy. I'm like a broken record. A busy broken record.

X is on hold for the time being, but it doesn't mean I'm not thinking about it. I think being denied the chance to work on it is making me think about it more, it's like smoking.

Quite a few people are feeding back that the controls stop being responsive on lower end machines. This is due to the main loop it uses. Rather than me go into depth about it, have a check of the great tutorial at the other end of that link.
The only downside to it is that so much of Flash's time is spent actually updating the display that input listeners can be missed, making it feel that the game is being unresponsive ( I'm guessing a listener buffer within the vm is checked every frame, and if the mainloop over-runs due to the sheer amount of data which is being plotted then the listener handler misses it's chance to check the buffer for any triggered events for that frame. That happens 60 times or so and that's two seconds where the game is ignoring you ).

One of the ways I'm looking to fix this is to add an options menu to the game, so people can turn off the eye-candy to suit their set up. The downside to this is, do I default to the game not having everything turned on by so anyone can just come to the game without messing with the options ( As it should be really, a game shouldn't expect or force a user to jump through config hoops before you can play it ), or do I max it out and put some comment in the game telling people that if it's slow to go and mess with the options ?

My current thinking is to run a cpu speed test at the start of a game. So some text explaining what's happening, that the user can go to the options page etc. and a counter runs down whilst it does it's thing ( So we can get an average of say 5 seconds ). This generates it's own problems though ( Doesn't everything ? It'd be so much easier to just be making banner ads for twice as much money ).
The first being, what test do I run exactly ? Should it be a maths formula in a loop and it running some bitmap plotting at the same time ? Is that the best way to judge a machine ? Then, should it be running under a normal enterFrame, or using the timer loop ? Next up, how much can you trust this test ? I don't know where this game will end up, so in theory whilst the test is running something could be happening in the background ( From the user opening a new tab to a nasty chat window to the right of the game doing something ).
Finally where do I get a good spread of test figures from ? I can tell you how quick a quad core pc running FP10 in FireFox 3 with 2 gig of memory will run the test at, but from there we only have so many other test machines. Are there going to be enough of you good readers of this blog willing to give good feedback on such a test ?

Even so, using the figures themselves isn't totally clear cut. To try and explain that, let's say a test on my machine comes back with a value of 10. I know X plays perfectly on my box, nothing I've thrown in there has affected anything at all, so 10 <= is a perfect machine in terms of playback. Great. Say you test it, and you get a rating of 20. What does that mean in real life ? I really doubt it means your machine is twice as slow as mine, 'cause it's just too much of a generalisation. But let's say it means that, what options do I turn off ? Do I kill the particle effects and leave the others running, or can I get away with removing something else.

I'm thinking the way to do it is run the test, output your machines rating, and then turn all the options off. Then when you're playing it, ask you to turn each bit of eye-candy on 1 by 1 until your machines screws up.
Quite a big ask.

I'm really throwing this open to all of you guys, what do you think ( About any of it ? )

Oh the new asteroid images are in the game btw, usual place.

Squize.

Hi,

More in the world of X++

The final power-up, the pulse weapon, is in now. It's a big old powerful shot, slow to move, slow to reload, but two hits from that and anything is dead.
To try and make it bigger and give it a bit more wow, I've used the particles playfield too. The particles are just little images ( Not pixels, they look too small, and it's something a lot of Flash GWars style games do, either that or they add a big ol' blur effect onto them. Neither being very nice ) which are blitted into a canvas bitmap.
Every couple of frames I run a colorMatrixFilter on that bitmap canvas to fade the alpha down, all straight forward stuff we've all been doing since F8 came along.

With the pulse I just draw() it's image into the canvas bitmap so it creates a trail / thickens it up ( For want of a better term ). Draw() is a bit costly, but I'm only ever running at most 10 pulse bullets at once ( They were always going to be slow to reload, that's why I figured I could get away with doing this extra trail effect ).
I'm really happy with it, it's in keeping with the very glowy nature of the game. BlendMode.ADD is the best thing to happen to Flash for a long time.

Once that was all in and working I did even more tweaking to the difficulty curve, the flockers now get nastier as you go, which is based both on the current level and the number of lives you have left ( If you're not doing so well there's no need to make it even harder ).

Then back to the power-ups again, and the space bar now swaps between them, which works a treat.

It's all going to plan so far, and seeing how we're on what, around 12 ( Full days ) development time, it's pretty good. It'll be nice to add the final baddie type ( Did someone say bullet hell ? ) and then the biggest thing should be the sound, which I'm a little concerned about 'cause there's a lot of things going on, and it'll be easy to just overwhelm the player with sound and make it really jar. Some thought is going to need to go into that.
From there we're looking at presentational issues and then bugs, love and play testing.

Squize.

Things didn't work out as planned today, and I've spent most of the day hitting X again.

I think this is going to be pretty brief as it's just gone 2:50 am and I'm pretty dead on my feet. Main changes are the asteroids now use the bitmap technique as mentioned in the last blog ( Not final images, and the way they animate shows up the circle to circle collision checks quite badly, the final images will animate in such a way as to hide that ), the baddies drop an icon which can be shot to select your power-up ( Again placeholders. The final images will be a lot more colour coded to make it much easier ).

I've decided after a long think today, and some great ideas posted in yesterdays comments ( Vex, didn't reply there mate, but I really liked your timer based idea, but I think for a web game I have to strip away complications as much as possible. Too tired to go into depth right now why that idea could be complicated, bug me in the comments if you really want me to justify it  ), I've opted for something quite straight forward.
A power-up icon is dropped after killing 20 baddies. You can shoot it to change it to a power-up you want, and then collect it. Every time you collect one you boost it's power ( Shown by the 3 new indicators at the bottom left ). Tomorrow ( Today ) I'll add the option to press space to change what power-up you're currently using ( Space was being reserved for a possible smart bomb, but I figure the player is going to have enough fire power as it is ).
Also the pulse weapon hasn't been coded yet, so collecting the icon with a little star on will break things. Not every build I post was going to be nice and neat I'm afraid.

I've also played with the difficulty curve a bit, and it's coming together a lot more. I've got at least one more baddie type in mind, maybe two ( And a third has just come to mind, but I've got to draw a line somewhere ), and then I should really be able to have a big push to finalise when things are triggered, how many shots they take to kill, how much energy you lose etc.
Also the asteroids themselves may drop point based collectables, as there's no combo system in this game, and I do want to give the player an incentive to move rather than just spin on the spot.

Despite my bloodshot eyes it's coming together nicely now, I'm finally starting to get a real feel for how I want it to play. A couple more days of giving it a really big push and we should be looking at something a lot more final.

Squize.

I'm starting a reskin of the bowling game I was working on last year ( Working on a reskin of a game which isn't even live yet, that's weird ) tomorrow, the holidays are over so I've spent a good couple of hours this weekend working on X whilst I've still got time / energy.

Some minor things to start with... the credits have been updated slightly to reflect your input, there's a new section on the title screen called "Notes", which is basically just this blog repeated there. In an ideal world there would be a nice audio commentary but that would take an insane amount of bandwidth, so this is the next best thing ( Maybe a youTube clip with developers commentary at a later date ? )
It's a nice touch and isn't hard to do. It needs some love as I'm not a 100% happy with the presentation ( It's annoying that it's height > 2880 pixels, which means I can't cacheAsBitmap, which in turns means I can't use a gradient mask on it ), but I think it adds to the game overall.

Next up, the explosions are in their final state. Shoved into tilesheets and dropped onto the stage by directly adding the bitmap ( Rather than using a sprite or mc as a container for that bitmap ), which is a sweet tip that Pany posted here. They're animated by using scrollRect ( To just show a small "window" of the tilesheet ) and look pretty damn good. I've got to convert the player's explosion frames to a tilesheet ( It's painfully boring ), but I'm still mulling over exactly how to blow the player up, so that can be put on hold for a little while.

Along with doing the explosion tilesheets FireWorks was fired up and a lot of the existing final images were compressed as 8bit pngs, which dropped the filesize down a bit.

The homing missiles have been optimised too, seeing how no one flagged up any issues with them from the other build it wasn't really needed but it all helps.

Finally, the first baddie type is in. Nice and small "Flockers", which strangely enough are exactly the same as the Flockers in Orbs. Weird that.

They teleport in waves of 5 in a circle, and I'm pleased with them. I need to tweak triggering the player's shield if they teleport in on you, but aside from that they're pretty much done. Oh, the images are place holders before anyone asks.
( Also as I've stressed before over and over, the game play balance isn't done yet. So some levels you'll have cleared all the asteroids and just be sitting there waiting for the baddie waves to appear, other times all the waves will have been destroyed long before you manage to kill the remaining asteroids etc. ).

A good productive weekend for me, as you can see on the X Dev page.

Next up a bit of a tricky one, ideas are more than welcome. I need to allow the player to get power-ups one way or another.
My current thought is to just level up the power-up every level ( The power-ups will all max out at level 5 ), but I'm going to have 3 different types ( Spray, missiles and another one I've not quite sorted out in my head yet ). So how would the player pick which power-up to use ( The mouse wheel would be nice, but then Mac owners are left out in the cold ) ? I'm still in two minds about having a smart bomb, which means the space bar would be used for that.
My original thoughts were to have power-up icons dropped like in Polarity, and the player can shoot them to change the type before collecting them ( Think of the old 19xx shooters ). Perhaps that's the way to go, and just level up the weapon every, or every other, level.

I'm loathe to have a shop in there were you can buy upgrades to your power-ups. It's a lot of extra code and design, and will break the flow. This isn't a game of strategy and missions, it's pure score attack. Even with a shop, it would mean the baddies / asteroids dropping credits for the player to collect, and then there would still be the issue of being able to select the power-up you want to use.

The old style collecting tokens and then selecting a power-up from a list is out ( Nemesis and it's sequels ) because there just isn't the real estate on the screen for a list.

I need to play some old shooters and have a think, but really if you have any ideas please comment me up.

Squize.

There's a newly posted update on the XDev page.

This isn't really a "I did all this last night" build, it's what I've squeezed in during the holidays, and is I guess around 8/10 hours work in total, so counts as a 1 day-ish. I'm not trying to be totally anal about how long each build takes.

Now I've actually got to remember what I did. The first main thing I managed to drop in there was the asteroids bouncing off each other. The small ones ignore each other as I think it'll be far too cpu tasking, and too much of a head fuck to be honest ( It'd be like pinball with 30 balls ).
It all seems to work quite nicely, it's pretty subtle, you've got to be watching for it, but I know it's doing it and that's enough for me.

In saying that, I think on later levels ( Level 6 seems to be the first real "kick off" level, around that level it feels pretty sweet ) I may have to drop the checks, or at least test for the number of objects running and skip them when there are too many to test.

Next up I added the "waves". Basically, not all rocks come at you at the same time, there's a trigger point where extra ones will be released. This will need some balancing ( Like all the gameplay, which for me is a long way from being done ) when the baddies are in there.

I guess the biggest thing, in terms of the blog title anyway, is the power-ups. Firstly I added the spray power-up ( I don't think I'm going to stick with that name, it conjures up images of dogs and lamp posts ) which is your standard weapon, plus friends. It looks really good when you've maxed it out at [ Weapon ] level 5.
For all the power-ups there's give and take. For example with the spray power-up, yeah you get 5 shots at once, but the reload time is increased to try and balance that out. It helps me as the coder because it means the games not running as many bullets as it would be if I didn't increase the reload time and will also hopefully bring some balance to the game ( If you max out your power-ups and you're as hard as hell, how do you still make the game fun ? Do you make the baddies that before died with one shot now take 5 shots to keep the challenge going ? If that's the case, you've not actually got a useful power-up, you've just got more sprites on screen. Do you increase the sheer volume of baddies ? Then you could slip into a grind if their easy to kill. It's always a tricky tricky problem ).

The spray PuP didn't take too long, so I moved onto the homing missiles ( Which I knew would ). I've optimised these quite heavily already, but I still think with 4/5 running with a lot of objects there's a performance hit, and that's why I've left them unlocked and maxed out in the current build, so if anyone whose got two mins could give the game a quick play ( 'til around that magic level 6 would be good ) and feedback on their performance and specs that would be great.
If they are generally running crap for everyone ( Fine here, but quad core machine. This baby could run seti@home on it's own, so testing a swf in a realistic enviroment is tricky at times ) then I've still got some ideas to try and claw back some speed whilst still keeping the same look to them.

Squize.

We're back, hurray!

Hope you all had a good Christmas and got lots of new things to play with ( Left 4 Dead was the best thing Santa gave me, it's the best marriage of "proper game" and multi-player I've ever ever seen. Everyone is going to copy that soon and just ditch the single player mode all together ).

I'm still in a holiday frame of mind, so the posts here may be sporadic as I alternate between working, and eating crap food / watching tv ( I think Olli's the same too ).

There's a new update to X. This is more of a "presentation" build, where I just can't be bothered to try and code anything clever.

The pause mode is in, which is always a nice thing to have done. To try and make it less drab, there's a bit of eye-candy in there, which is a Lorenz Attractor and was ported to as3 from the code at the always excellent Levitated ( I had played with this a couple of weeks ago using setPixel, and just wasn't happy with the results. Rather than let it go to waste I used the bubbles from the depth of field vector effect in 651 and a bit of blur and the add blendmode along with the old faithful infinite bob effect, and it looks ok-ish now. One thought that came to me was the code may be handy for running some types of baddies, could be quite a nice movement pattern and wouldn't require me to think of any more code ).
One thing is that I don't kill the animation during pause, so asteroids keep spinning, explosions keep exploding. This is because the use of movieclips is only a temporary measure, I'm going to wait til we've got final assets before ripping that code out and using tilesheets instead.

The other major chunk of work done is the stats / medals. The medals needs some images drawing for them, and then code to actually trigger them in-game, but all the internal guts is in there. The stats I think are done now, which is cool. Just don't get too attached to them, as every new build will reset them.
I've also added some stats to the level complete section ( I've been brainwashed waiting for things to load on the 360, where they display tips / stats to help you forget you're waiting ) which I'm really happy with.

Following on from a comment from Tonypa, the current level is now displayed, and a level progress bar. I've noticed a lot of casual games show the level progress ( Zuma, Luxor2 etc. ) and it's a simple nice thing to have. It's maybe not that useful now, but perhaps if the asteroids were to come in waves later in the game ( That's a clue btw ) ?

Squize.

Always a great milestone, when you can play a game, complete a level, die x number of times, read "Game Over" and start it all again.

This to me is when a game is a game, and X(++) has just reached that sexy milestone. Ok, it's not a great game yet, it needs a lot of balancing, and it needs some fun desperately, but it's a game.

Adding the asteroid to player collisions was pretty straight forward, just simple circle to circle checks. I wanted the player to be forced away from the impact, and it works quite nicely. Seeing how the code was written, I used the same bounce code again for when you're shooting an asteroid ( So your bullets actually push the asteroids away slightly ).
It's a little bit weird shooting an asteroid via the screen wrap, as you kind of suck it back towards you, but hopefully shouldn't be too much of a pain to fix.

Next up was making the energy bar decrease. Simple code. Looks nice. Just how code always should be. After that the next logical step was to blow the player up. It's a movieclip, it doesn't get any more straight forward.
That left me with the issue of what to do with the asteroids still on screen, and as I've done in what feels like far too many games, I've added a heat shimmer / wave to the explosion, which blows up all the rocks as it grows.

Another nice simple solution ( I'm not trying to get a rocket into space here ).

From there, it's not much more than

if(--lives<0){
    gameOver();
}

And we've got a game. Sweet.

I don't know how much work I've got in me before Christmas, a couple of days off eating like it's my last day on earth and sitting in front of the tv sounds just perfect right now. Even if I don't do anything tomorrow, we've got a really great guest article to post up, which we're really excited about.
It's nice and apt for this time of year too, I mean Zombies are good all year around aren't they ?

Squize.

Look at me using a term that'll be a hit with the search engines.

What's been happening in the world of X++ today then ? Very very little.

It's not for the want of trying, it's just been one of those days. Yesterday after posting I ran the game through the profiler as I wasn't happy with the performance, and I wanted to see what was being nasty.

It turned out it was the skybox. Lots and lots of calls to papervision classes, and they were taking the vast majority of the actual game's run time. I've had to remove the planet effect I really loved 'cause of performance, am I going to have to do the same with the skybox ?

Yes.

Annoying as hell, but I can't let the game suffer for the background. If I've made the game good enough you shouldn't even be checking the background anyway, so losing a little bit of love isn't the end of the world. So so annoying though, what the hell can we use 3D in-game for if a couple of spheres make it gag ?

Today was meant to be the asteroids > player collisions, with the plan that you'd lose energy and therefore lose a life, and eventually lead to a game over. Once that's in, the game is a complete game, until then it's just a demo.

First step on this road was designing an energy bar. Firstly I wanted a lcd style display around the lives, where each element would "power-down" as you take a hit. Tried it, and it look toilet. Next was a plan about having some sort of arc around the lives and use a mask to show the energy being reduced. I just couldn't even face starting to design that, as I just knew I didn't have much art in me today. Next up was a simple bar effect, inspired by Wipeout Pulse's speedometer.
Looked crap. All the blend mode effects I tried on the score / lives numbers also looked crap.

Some days you could make Angelina Jolie look bad.

In desperation I ripped the energy bar out of Orbs and tinted it. Looks great. There's nothing especially creative about stealing ideas from yourself, but that's the way it goes some days.

After that, the collisions and all that goodness weren't really going to happen, my spirit has been broken. So instead, it was time to sort out the backgrounds after removing the moving skybox.
Without any movement I figured the way to go was to try and make them look as good as possible, like each one is a bitmap done in an art package, and yet make them random every time ( "Procedurally generated backgrounds" makes a much better heading than "Random backgrounds", and to be fair, I think the backgrounds are slightly more than just random ).

The 3D planet is used from the other day, it's spun on it's axis' so you're always looking at a random part of the planet texture, it's z value is also randomised for scaling, and I move the light source around slightly for the phong shader. Also another smaller planet is created, although it's not always shown.
After that, the skybox is spun around too.

We then grab that skybox and plot it into a bitmap ( ie, draw() ), on top of that is another bitmap with our planet(s) in. Depending on the size of the planet we add a blurFilter, a glowFilter and we tint it.

I really don't know what the odds of having two identical backgrounds are, they must really be vast, and aside from the odd "not as good as I would like" looking levels, for the most part I'm really pleased with how they look.

And... I think that's it til Monday, have a good weekend everyone,

Squize.

The subject title is both the longest, and most perfect, variable I've ever written.

If I could do a whole game using vars like that, it would be like writing a book rather than a game. Bliss.

It seems build 4 was causing more people problems. I'm hoping it's 'cause I was a lazy boy and cut a few corners with the transition, which basically meant it was doing too much at once ( Although on all our test machines, not a single issue. Joy ).
Well that's been tidied up now so hopefully no more problems there.

The score is in, I think that was build 4 and I just forgot to mention it. It uses polling, so every x number of frames the game checks to see if the score actually needs updating.
The reason for this is that I'm using a dynamic text box for the score, which is really costly. Rather than update that more than is needed ( It's not the end of the world waiting a fraction of a second for your score to be updated ) I can just save up a couple of updates and then do them in one hit.
That's the theory, dunno if it makes any difference at all in real life ( ie, I don't know how often the score will increment when playing the game at the moment ).

Also today we've now got levels. Lazy, not tweaked at all levels, but you can complete level 1 and go to level 2 and that's good enough for me today.

One thing I've wanted since the start was a nice sexy rotating 3D planet in the background, that's partly why the skybox is there, so the planet has something to sit against.
Dropped it in today, and wow, it looks so cool. Slightly less cool was the massive hit on the fps. I'd added Gouraud shading because without it, it did look a bit of a pig, but the performance hit was too great.

Shit.

Lots and lots of messing around later, and I had to call it a day on that idea, and look for a compromise. That came in the form of still using papervision to create a 3D planet, but to grab that into a bitmap and then overlay that on the skybox.
It's not as good as true 3D, and it's still not quite there, but it's going in the right direction.

As always, all the builds live here.

Squize.

Time for a recap on X development stories.

I posted a 3rd build the other day, but didn't bother blogging about it, as, well it didn't seem worth while. The main thing added was the player movement ( Arrows or wasd ) and targeting ( Mouse ) and shooting ( Guess ).
The particles from Orbs were re-cycled to show the bullets expiring ( They have a certain range before they expire. This is 'cause in asteroids the bullets wrap around the screen, so in no time you'd be over run [ With your own bullets ]. Also with a limited range it means you've got to go in perhaps a bit closer than you'd like to shoot up an asteroid ).
The effect is no where near as pretty as when it's running in Orbs, and it took a fair bit of tweaking to get it is where it's at now, but I'm ok sticking with it for the time being. Unlike Orbs, I think in terms of eye-candy the particle effects are going to be well down the list, so I don't want to pour over them for too long. Yet.

The movement is not the usual asteroids control system, of rotate and thrust ( tehehe ) as our good friend Mark at Blastone released a great Geometry Wars meets Asteroids game a while back ( The very sexy Vectoroids ) and when getting feedback on FlashKit games I was the sole voice of "Rotate and thrust" ( Still quite funny, but I'm 36, I've got to stop finding vaguely rude words funny ).
Everyone else acted like I was slightly mental, that those controls wouldn't work in a million years.

I could get on my retro defending soap box, but the retro way isn't always right. There were a lot of shit design choices back in the day, we just didn't know it back then because everything was new, and because we didn't have good design to compare things to. So, instead of me bitching at the kids for not understanding that it's the way it should be played, screw it, let's make it actually handle better than the original. That's not a bad thing to be able to put in place.

( Also it's how Orbs plays, and I like it, and I like to be able to copy and paste ).

One last thing about build 3, our old friend Phil @ flashgamemaker.com has been a star and reported some issues with it, including a freeze during the transition and a pretty piss poor framerate. I'm hoping it's 'cause he's using FP9 on an old machine running the new IE beta, but I'm still going to have to look at it, the transition could be done better so a bit of re-coding there.
If anyone else is having similar issues, please pipe up and let me know. I remember the good old days of Flash, where it was only the Mac version that would play differently ( And no one really cared about Mac users back then ), everyone running Windows would get pretty much an identical experience. Now there seems to be a lot of "On my machine this happens..."

Build 4, this is more like it. The asteroids are in now. An asteroids AI isn't the most taxing thing to code ( A bit of atan2 and you're done basically ) so getting them in and moving didn't take long.
The current images are all greyscale, so a bit of colorTransform action is added to them to try and liven them up a little.

Three big asteroids moving around with a colour tint on them. Next up was to add the player bullet > asteroid collision checks. Again, Orbs was raided, and we've got distance based broadphase collisions in there ( Which is a perfect way to do the collisions in a game like this ).

Getting a trace saying "hit" is only so much fun, so next up was the ExplosionHandler class. Worked first time like a charm ( Tell me how rare that is ).
The large asteroids explode now after 5/6 hits, I should really add the medium asteroids. Tore through that too ( Almost the same code really, I'm not doing anything really clever here ) and finished it all off with adding the small asteroids.

After less than 4 whole ( ie, an 8 hour working day ) days working on this bad boy, we've got a ship you can fly around and asteroids to kill. That's pretty sweet, I'm more than happy with the way it's going.
The original X even to this day is one of my very favourite projects in terms of development, it took 2 weeks and I didn't plan a thing and yet it all fell into place. If I could turn this around in 2 weeks I'd be really pleased.

More whenever really, bye for now.

Squize.

There's a very minor update of X on the X Dev page.

Aside from adding some credits ( I have no sense of priority do I ? Credits done before the game, what the hell is wrong with me ) and finally getting the in-game skybox pretty much how I want it ( Although using a placeholder, which I know I'll come to love and hate having to remove come the time ) quite a bit of time ( Read: Far too much ) was spent on the transition.

Keeping with the TV screen theme, which I think I may have done to death now, I wanted the transition to be a nice distortion / break up effect ( I've been heavily inspired by this After Effects plug-in ).
Part of that, aside from the more obvious static and ghosting / blurring, was splitting up the red / green / blue channels so I could offset them.

With that in mind, copyChannel() got some F1 treatment to see how it works. It's all pretty straight forward, to the point that I'm not going to repeat the syntax here.

What isn't straight forward, is how to overlay the images again to get the original image back. Perhaps it's just me, but I couldn't find one example of how to do that ( Well, I found something using papervision which overlaid planes for a similar sort of effect ).
3 bitmaps, 1 red channel, 1 green and 1 blue. I want to shove those all into a sprite on top of each other to get the same image that I started with. To be honest, I can't think of another reason to use copyChannel() off the top of my head, so I thought I'd be tripping over examples.

But no, one PV3D example like I said, and nothing more.

Cosmic.

The solution ? BlendMode.DIFFERENCE. By applying that to each of the 3 bitmaps it works a treat. Hopefully this will help someone out one day when faced with the same problem.
It amazes me at times how some things are still so tricky to find out about in actionscript.

Squize.

I'm starting a little experiment today. It could either prove to be something quite cool, or I'll really fall flat on my face with it. Lucky that I don't mind either way really.

Rather than doing a diary style collection of posts about a specific game's development, I'm going to post daily builds. Every day I work on it, even if it's just to tweak a sprites position quickly 'cause it's bugging me, I'll upload that new build.

Now this doesn't mean I'm going to be working on it every day. There aren't going to be a nice collection of sequential posts here until it's done. This is a personal project + Christmas is coming up, and life just isn't so smooth as to allow that.
If I get an urgent job come in then this is on the back burner straight away.

Also if you stick with this ( Never mind me sticking with it ) you're going to see versions which crash, versions which are buggy, versions with no preloader so you're looking at a blank screen for a while. It's a true game in development. I'm not going to fluff it up for you guys, or put some spin on it and work 8 days on it and then pretend that's just 1 day. It's going to be the same as that game you've got in development on your hd, with all the traces that say "Sprite collision failed, wtf?" and all the nasty things that you'd have to hide from the clients build.

That's the caveat out of the way. What are the good parts to this project after all the negative ? I guess that's down to you guys. If you find it interesting then the blog is doing it's job.

X. That's the game. It's an old asteroids clone that I did years ago ( It was my 2nd ever complete game, 2003 some time ? It was part of the "Majestic Trilogy" of games. I'll dig out a link for a future post ).
I've already done a reskin of it, X+, but for some reason that has never seen the light of day. I was looking at it recently and realised it's just a bit too dated now to use, it's as1 so publishing it for F8 so I can use the blendModes in there is really a lot of trouble, so it's either release something that's not as good as it should be, or re-writing it in as3. X++ it is then.

I'm weird when it comes to coding. I know a lot of developers just like to get in there and get the engine working, and then work back from that. I'm very linear, like a bad fps. I need to start from the beginning, the title screen. It's important to get that look & feel in place to set the tone for the rest of the game.
So that's what we've got, a title screen. There are buttons that rollOver, but don't lead anywhere. The background image is a place holder as we're going to have a flv running there instead ( I did have a flv to test in place, borrowed from here ( Click the video button ) but it bumped the file to 9meg, so it's been reduced to a static image until we get the final render done ).

Enough words, here's the front-page for the xtreme coding experiment

More soon, although I'm going to try avoid saying what's coming, 'cause it usually falls through and I go off and do something else.

Squize.