Posts Tagged ‘seu’

And finally…

Saturday, August 14th, 2010

I know my memory is getting worse but this is ridiculous… okay, there have been swathes of changes to the Blast Engine’s internal workings over the last couple of days but, because they’re all little incremental things, I haven’t blogged about them – so instead, here’s a round- up of the Blast Engine News [shuffles papers, puts on a pseudo-serious face].

A jump command has been strapped into the timeline that can be unconditional and simply leap from point A to B or be told to only do so if a specific object exists; this means that background movement can be looped and doesn’t have to stop during boss fights unless I actually want it to. There are several firing modes added into the system as well and it happily sprays bullets around in interesting patterns during the test level. This managed to produce bizarre problem (the conditional jump to jammed on because the bullets had somehow inherited the name of the object that fired them) which was subsequently “fixed” by doing the equivalent of stamping all over the little darling’s array entries before assigning it as a bullet. Another firing-related issue that makes one bullet in about eighty spawn just a fraction of a second later than the others being fired during the same frame hasn’t entirely been eradicated yet but I’m beginning to suspect a rounding issue and have no idea at this point if it’s mine or the compiler!

On the cosmetic front, the particle effects for explosions have been tuned a little so that smaller bangs don’t get too energetic and larger ones for bosses have a bit more muscle – objects can also become particle emitters, although that needs a bit more work so that they can specify the ferocity at which they spawn since right now it’s all hard wired to “bonkers”. Enemies strobe red when they take a hit (they were already spitting out some particles on non-terminal hits, but the number has been dialled down to avoid burying things) and will flash repeatedly when they’re close to being destroyed. There’s a proper shadow generation system as well and, if an object specifies a distance away from itself, the engine renders it a drop shadow based on the object’s own shape – the video in the previous post has the bridges already displaying shadows but that was a fudge using a transparent area bolted onto the image itself, this solution is far more elegant and indeed efficient.

So now there are only four major items on my “to do” list; put in some proper object-by-object scoring rather than the fixed values currently being added, get the entire game running actually as a game with titles page, game start, game over sequences and so forth, install smart bomb handling (which in turn means an upgrading of the bullet handling, but that’s been on the cards for ages now) and separating the graphics data from the object arrays so that a proper animation driver can be slotted in. After that, the bludgeoning of any errors that are almost certain to stick their heads above the battlements in the process and a few other cosmetic modifications such as muzzle flashes for the player’s guns, it should be close to the point where I can start thinking about specific game design rather than it being engine work where I’m constantly trying to second guess what features will at some point be needed – that’s a momentous occasion because this’ll be the first iteration of the Blast Engine to get that far!

It’s showtime… sort of

Wednesday, August 4th, 2010

I’ve been working on the Blast Engine again, today saw the text display over the playfield bolted in and I’ve strapped a simple bit of code that bumps the score by five points for every hit on an enemy and twenty five more if it goes bang afterwards.

Today saw me experimenting with CamStudio as well, with mixed results; it can grab footage from my machine but not a large area if a half-decent framerate is wanted… so the code was kludged to display at a quarter of it’s regular scale with the virtual resolution feature in BlitzMax, recorded just shy of a minute of me playing and fed the results to YouTube – it’s pretty rough quality, the background music was just playing in Windows when the video was recorded (it’s from Tempest 2000) and everything on show is “borrowed” from Star Force for test or placeholders knocked up in an hour today, but here it is:

Time to object

Tuesday, August 3rd, 2010

So after strapping a background scroller into the Blast Engine and getting half an editor written for it… I’ve just stripped it all back out again in order to pursue some ridiculous plan of generating the backgrounds using large sprites! Oh the humanity. On the plus side, this does remove the need for the hideous and cobbled-together bespoke editor and has made adding parallax scrolling, horizontal panning and spot details a lot easier so maybe it’s not an entirely mental decision.

A new object expiration feature which removes objects at a specified timeline value means that warning messages for enemies coming in from the bottom of the screen or “boss approaching” alerts can be added – I have one of the latter in as test and it seems to work okay. One thing the object system can’t do just yet is allow spawning objects to request a sound effect; jets arriving in a hurry could “whoosh” into the play area, the end of level boss warning could trigger it’s own klaxon sound or ask for the music to be faded out, the boss itself could request that the boss music start…. all very nice of course, but as it stands there’s no sound handling at all in the engine so these features will have to wait until they’ve been implemented!

But the first job to be done tomorrow (well okay, today) is add text rendering over the rest of the layers of game stuff to put up the status bars; right now the “game” isn’t keeping score and it’s probably time to start. I also need to strap in a temporary titles page and some lives handling just to get a proper game loop going… oh joy of joys, housekeeping jobs!