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.

It's time for our annual review of what we've managed to achieve over the previous 12 months, so bring that hangover and stale mince pie with you as we go back in time and space...

Jan:

This saw our first birthday, and Olli experimenting with web servers and the Wii. Quiet month, I'm putting it down to hangovers.

Feb:

The most loved up month of the year saw what has got to be one of the most camp games ever,

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.

Merry Christmas everyone!

At this time of year we'd just like to thank you, all our beautiful constant readers and our sexy newer visitors, for helping make this blog what it is. Without you we'd just be talking to ourselves, and I'm no doctor, but that's got to be a bit mental hasn't it ?

So thanks a lot for keeping us sane, it means a lot to us.

Turkey, tv, unwanted gifts, eating until your eyes bleed, visiting relatives when you just want to play on the xbox, something about the little baby Jesus, a big fat man breaking into your house in the middle of the night, paranoia that you can smell burning every time you turn the tree lights on, getting a card from someone at the 11th hour when there's just no way you can get one back to them on time, wrapping presents far too late and making a really bad job of it, having to spend Christmas with relatives and their weird not the way your family does it rules ( "We don't open the presents til after lunch" ), it's just all good isn't it.

Have a great one,

Squize & nGFX
x

(ps. edited by nGFX):
So Squize was done with posting a good deal earlier than me, so instead of having a second post I decided to add to this one...

If you're not quite so much into Christmas (like me, although, only the stress before it spoils it for me as early as November) here's my usual:

Happy Hogswatchday!

"ER...HO. HO. HO."
-- Death makes a career move (Terry Pratchett, Hogfather)

We're really really pleased and proud to present a guest post from our good friend Pany at the oh-so-talented UrbanSquall ( Developers of Battalion:Nemesis amongst other great games ) not to mention the words behind the always essential GamePoetry blog.

Enough of my introduction, on with the show:

---

Zombieland: Bonesnap Boulevard


Intro:

This is a really late post-mortem for Zombieland which was completed at the end of the first quarter 2007. Zombieland is an endless side scrolling shooter written in ActionScript 3.0. The game was written with the Flash IDE 9 Alpha, and was completed before Flash CS3's official release date. The game is still playable at http://www.newgrounds.com/portal/view/378688

Zombieland was essentially a critical flop. It didn't garner enough eyeballs to warrant a sequel, and despite some really creative ideas, and the flawlessly crafted graphics, people who played the game had a hard time coming to grips with the flawed weapon implementations, gameplay experience and jarring audio. It was a fun project that was executed in a very short time period, but a few missteps ultimately damaged the gameplay experience considerably.What Went Wrong:1. Audio. The music in the game is at too high of a volume, and the compression was set too high. The result is that long before you ever see anything approximating a mute button you are assaulted with an overwhelming blast of scratchy static-riddled music. I suspect many potential fans of the game were lost in the onslaught of those first few obnoxious seconds. The great sadness is that the music is actually pretty good. A few minutes could have fixed these problems very easily.

2. Questionable design choices. Random is not fun. The game uses a very basic algorithm for deciding what sort of enemies to spawn and at  that frequency. I think this only barely worked. Static levels would have taken longer to produce, but would have been inherently more interesting. Combined with other design blunders, like the constantly moving forward main character, the weak default weapon, and shoddy collision detection, Zombieland scared off most players long before they could come to appreciate some of the funner aspects of the game.
I'd say our rushed development schedule was partly to blame here, but it was also partly a lack of objective oversight.


3. Syncing gameplay and animations. In Zombieland, the majority of events are queued off animations. Firing, reloading, taking damage are three examples where I let the speed of the action be determined by animations. This could have been fine, except it clashed horribly with the fact that the character is supposed to be constantly moving forward meaning we had to do ugly tricks to maintain the illusion. The result is that most core actions in the game are very unresponsive which multiplied the negative effects of poor collision detection.
This was just a naïve misstep that was avoidable with a very simple design change.


What Went Right:

1. Graphics. Tim Wendorf, the artist for Zombieland, nailed the visual aesthetic. The 2x look, combined with the slick character designs really make the graphics the best thing about this game. There is a distinct possibility the game got away with its crappy core gameplay mechanics during development simply because of Tim's quality graphics.


2. Inventive zombie designs. Again, I have to credit Tim's warped sense of humor for coming up with some of the more memorable moments in the game, like going toe-to-toe with a wheel chair zombie, or having to face a stream of zombie porcupines tossed by an angry zombie cowboy. The Zamboni Wamboni was all mine, though.

3. Quick turn around. The game took less than 5 weeks of near full time development. We didn't hit any snafus along the way and we delivered the final build ahead of schedule, despite the fact that I was still coming to terms with a new programming language (ActionScript 3.0) and a new content pipeline (bitmap tilesheets). We shipped the game with gameplay flaws that only became clear after the dust had settled and it was too late to do anything about it.
Scheduling wise, though, Zombieland was about as good as they come in terms of everything just coming together right.


Conclusion:

The hindsight of almost two years since the game's release has given me some time to reflect on why Zombieland failed to achieve the success I thought it was due.
The most valuable lessons I can take away from Zombieland, at this time, is that I should avoid integrating slick graphics early in the development pipeline, and instead focus on prototyping and nailing the core mechanic and avoid getting seduced by a pretty presentation.
A part of this is getting more feedback on the gameplay mechanic, especially in those earlier stages, which can help identify issues with a poor random level generation algorithm, or crappy engine limitations, like bad collision detection and animation-based timing dependencies.
I'm hoping fate allows me another opportunity to revisit the Zombieland setting, as I think it was under served by a few key bad decisions that spoiled an otherwise solid game.

Panayoti Haritatos / UrbanSquall

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.

So I guess a month or so has passed without a word from me, which either means I haven't got something to say or lost interest or something else.

Well, a bit of everything. This year has been a real let down in terms of games, Squize outnumbered me in terms of finished games by far, so what have I done at all?

First the official conversion I've been doing for gimme 5 still isn't really gold (still waiting for the level swapping stuff), which was or still is quite a letdown and has killed a good deal of the motivation I had put into a game of my own otherwise.

Then there were quite a lot flash based applications (not the stuff to write about here) and some .NET based backend stuff.

Oh and I've been doing a heavy "quick fix" session for Ubisoft (yes, that Ubisoft), which ment 3 weeks of 16h days to fix 3 flash games and write a menu in 3 languages (regular readers might find my post related to this) ... I still have to rewrite the third one, but that's another story.
We haven't been involved in the design, but it was quite a lesson for me to make them work at all (read: I got some half fininshed games and a very tight deadline).
If you're eager to take a look ... do it here: Handigo The Game - Ubisoft (first one on the right).

After all that I decided to have a quite long holiday now and start on a game that has been floating around my mind in varoius designs for quite a while now (I did mention that "unfinished" games like my CC port are big motivation killers?).

I doubt I'll do daily updates like Squize, so for now you just get the name (and static screenie of the menu):

(Oh, and did you notice the "Medals"? While writing on Calisto Eclipse I'm setting up something nice for us all ... more to come later :) )

Back to coding now (finally), nGFX