Gaming Your Way

May contain nuts.

Procedurally generated backgrounds ?

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 ?


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,


BitmapData.copyChannel(), you're a sexy minx aren't you

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.


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.


Xtreme Coding [ Hardly ]

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.