Posts Tagged ‘game’

Fading away… and back

Wednesday, September 1st, 2010

It’s new Blast Engine functionality time again; objects can now specify an alpha blending level and movement commands are able to set a destination value and speed, so things can materialise and dematerialise at will. A similar set/destination/speed system is going to be added for object scaling at some point, although this is less for the game and more for attract mode and completion animations – the engine should in theory at least be able to handle these events without much extra work so I might as well let it rather than writing bespoke code!

The layering system has had a bit of a rename and, after I had a bright idea whilst hammering away at a side project earlier in the week, object definitions are going to know which layer they want to default to so there’ll be very little need to set values from the script – there is going to be an option to change layers within a move command though, so a shuttle can launch from underneath a larger object and then pass over it as though it’s height has increased. As these changes go in, the overall number of layers for each level will be bumped up to eight to give forty in total.

I’ve also added Tate rendering yesterday so players will be able to select 3:4 ratio (as has appeared in the screenshots and videos so far) or a 4:3 display where everything is rotated 90 degrees clockwise; in the latter mode, players can rotate their monitor to counter the shift so the game looks a bit more like a coin-op. This feature has been a “must have” since day one, even the engine’s default 480 by 600 resolution was selected so that it works on an 800 by 600 display in 3:4 mode and can call up a rotated 640 by 480 full screen display as well.

That’s a bu-ug!

Friday, August 20th, 2010

Some days I wonder if it’s worth getting out of bed… during a bit of routine testing of the Blast Engine a couple of days back a bizarre bug appeared; enemies can be given a name like “level 1 boss” and it’ll get used as reference elsewhere, not only can the timeline jump be set to only happen if an object is still active) allowing it to loop events during a boss battle) but these named objects can have “children” that follow them around or explode when they do. All well and good, but a new routine in a function called ParticleMultiSpawn that slings out fireballs from particularly large explosions (wind the video in the previous post forwards to 0:22 to see them) was trashing the name of any object being destroyed in that way…

So generally speaking that shouldn’t have been an issue since the object is dead anyway by that point and the timeline jump didn’t care less because as far as it was concerned that was how things worked anyway, but the explosion handling was being done before a scan to destroy child objects and by the time that code ran there was no name to look for and they were getting left behind! So a marathon two hour local variable renaming session ensued to make all of the loops use unique, identifiable names for their counters and… the bloody thing still didn’t work and the only fix that helped was to swap the processing order so that the main explosion is handled after the children are toasted… and that feels so damn fudged! Presumably there’s an object name being nuked that shouldn’t be in there still, but now I can’t see an effect to look for the cause but sleep will probably still be lost over it.

More showing off

Tuesday, August 17th, 2010

Righty ho, another test video and there are a few improvements – of the visible changes (there’s quite a few from the last version that literally nobody bar me will ever be aware of or even care about!), there are some newly-created airborne enemies and ground bases and the latter has six frames of animation to make it’s “eye” glow so that, along with the kludged background object that now has flashing lights, I can test the newly-improved graphics code. Objects can now optionally spurt out particles in their wake too, so there’s a test of that during the boss explosion although I’m really not sure about the way that looks yet…

All of these graphics are still to be considered test only (although I quite like the new enemies so they might be staying in at least some form) and that appallingly bad rip-off of the Raiden ship and the… well, box pretending to be a boss will both be long gone before this starts being an actual game rather than just an engine; before that can happen there are a still few more object-based bits and pieces to add before that happens but it’s finally in sight!