C64 :: Mayhem 15th intros

After Kenz spotted a couple of small cosmetic bugs and i went delving around, the final menus for Mayhem In Monsterland 15th Anniversary with their loaders in place have (hopefully at least) been sent off for mastering; here's a video of the code written for the B side, which contains the two MC Mayhem music demos:

C64 :: Utter Mayhem

Over the last couple of days i've been quiet because i was coding a new disk menu for the 15th anniversary edition of Mayhem In Monsterland... i was asked to an' stuff, i didn't just decide i was going to do it out of the blue or anything! It's been a while since i thought about presentation programming like this to be honest, it's closer to demo coding than games so takes a little getting my head around. Still, i think it works pretty well and the client [ahem =-] is happy with it. Anyway, here's a video of the thing actually moving (i've just noticed a problem but it'll be fixed before the final release)...

C64 :: Sidetracked... again!

i'm rather good at sidetracking myself these days... i spent most of the day working on graphics but not for Ax 2189... and, after a little late night wandering around i returned invigorated (well, partially awake at least and that's better going than most days) and for reasons i might never be able to explain decided to convert the code for my first PET game Blok Copy to run on the C64. Actually, i can explain the reasoning... i think. i wanted to strip the code back to it's absolute basics (there were a lot of PET-specific hardware detections and work-arounds for frame sync or control in there because it runs on just about any 40 column machine) with the intention being to then convert it over to a number of other 6502-based platforms.

This has been on the cards for a while to be honest (and one day i'll retrofit the new title into the Atari 2600 version of the code and perhaps the music driver too) but there were issues that had previously prevented things from progressing from the theoretical stages (in particular the number of colours per line on some of the potential targets) which have now been pretty much sussed during that walk to Asda and back... i haven't decided yet if Blok Copy - C64 ROM Font Edition (snappy title... but accurate since it uses all the PET screen data) will "escape" yet, it depends on if the design work-arounds i came up with can be applied to a full-blown C64 version or not really.

C64 :: Some progress at last!

Things have been a little quiet of late because, despite my "best" efforts, i've been utterly unable to get a fourth level for Co-Axis 2189 started; finally that deadlock was broken today and i seem to have the beginnings of a tile set for it although if i'm honest i've deviated a little from what i originally intended - but that's fine because the various attempts at what i had in mind to begin with were stalling the bloody project! So now i've got that going there will hopefully be some screenshots of the new level to look at in the (relatively) near future [Crosses fingers and looks hopeful!

C64 :: Armour Storm video

Since i'm going to try breaking the "block" and start working on Co-Axis 2189 again, my thoughts have of course drifted to the next project; ironically, it's going to see me restarting work on a previous project, a sci-fi themed platformer called Armour Storm. What makes it rather special is the graphics, the majority are taken from Cyberdyne Systems' unreleased game Deadlock with full permission from Robin Levy and Dan Phillips themselves - what is far more exciting (well, for me at least) is that Robin also drew the player sprite especially for Armour Storm!



What has been holding it up (for several years in fact, the last build was in 2005 according to the change log i kept at the start of the source code) was the issue of guns; i had always planned to allow Martin (the player's walker droid... Martin Walker, get it? Please y'selves...) but at the same time it does have some quite complex issues such as what happens to shot nasties, do they respawn and how or just frozen or how often should there be guns in operation. That needs a fair bit of thought, discussion and indeed experimentation before its worked out and hopefully i'll be able to find a little more time now.

But anyway, enjoy the video because those graphics are pretty friggin' stunning...

PC :: Wire Fighter released

Although the Bullet Mechanics website hasn't been updated to reflect it yet (that'll happen on Wednesday) yesterday saw the release of the now christened Wire Fighter over on the ShmupDev forums.

The game itself is quite simple to get into, the player has two energy bars for the ship itself and the "laser wire" grappling system (above and below the score respectively); along with the ship, there is also the laser wire's cursor, when the system is charged, it will lock onto attackers (the usually red cursor will turn green if there is power for it or orange if not) and a swift right click will take control of the enemy and see it tethered to the ship as a support weapon. It is possible to play the game without using the laser wire but it's difficult and the best scores will be achieved by constantly grappling new support craft.

PC :: Grappling with spaceships

The new rapid prototype has been receiving a little care and attention yesterday and as far as the code is concerned it's pretty much complete now; i want to spend some time getting the graphics and sound up to spec, there need to be attack waves created and probably couple more nasty types and at this point i haven't actually settled on a [i]name[/i] but the progress is good and i'm happy with the way it feels to play so hopefully it'll be well received on the ShmupDev forum when i'm done.

PC :: More rapid prototyping

i haven't actually given the thing a name yet and it didn't end up using the OpenGL rendering code i was talking about previously... but after a day and a bit of slaving away i've got something together for the fourth ShmupDev competition! The idea is quite simple, the player has the option to lock onto attackers and take over their ships, slaving the craft itself and the weapons for their own use. There are some restrictions placed on the use of course (otherwise it'd be way too easy) such as the enslaved craft not moving as fast as they would otherwise and the bullets taking between two and eight hits to destroy attackers depending on the weapon grabbed, but generally it works pretty well.

All it really needs to "complete" it for the competition is some movement code for the nasties, a bigger selection of attackers with their own weapons that can be taken control of, a proper attack wave initialisation system (it's currently just slinging nasties in at random once every sixty or so refreshes) and then some pretties like a title page, a few more sprite designs, sound effects and so forth.

PC :: Shiny, happy spaceships

i've had a weekend of getting my head around the basics behind OpenGL; my programming language of choice, the rather spiffy Blitz Max, is essentially a 2D language (which was one of the main reasons i leant towards it in the first place, having previously used Blitz BASIC 2D to the point i was trying to simulate some of the more rudimentary lighting effects that Max can handle by rendering objects manually) but there is support included for rendering with OpenGL and, theoretically at least, that means i could build a 2.5D shooter of some kind. So far i've managed to position, plot, scale and rotate some vertexes and then some low poly shapes, although i suspect that a lot of my code so far is somewhat fudged...

As to what i'll actually do with this test code i haven't decided yet, but the idea of stylised, untextured shoot 'em up is rather appealing right now and, assuming the theme doesn't preclude it in some way, might be my "look" for the next ShmupDev rapid prototyping session since i really enjoyed the last one and the next one starts on Monday. Certainly one of my thrown together test objects will look quite good tumbling onto screen, disgorging some bullets and then spinning away again (or being blown to smithereens - that does raise a question of how to blow up a 3D object but i've just had a thought as i was writing this so i'll have to give that a little more consideration) and with a bit of modification will make the basis for a nice player ship as well. Strapping the Alien Release Scheduling Engine into this environment should prove quite... interesting though, the co-ordinates are based on 0,0 (thinking in two dimensions and ignoring Z) being the centre of the play area!

PC :: Boom bang a bang!

Yay! i didn't really get around to documenting any more of the process, but Vinculum has been released in it's "competition form" and i'm in the process of setting up a website for a new "venture"; to paraphrase the old bank advert where the businessman asks people at work, friends and everyone else apart from his wife before making a life-changing decision, i'm "going it alone" or more accurately i'm going to have a go at setting m'self up as an indie developer with this project in a greatly expanded form as a first product if all goes to plan. Anyway, my new website isn't actually there as such but the domain is working and theres a temporary page on it already for Vinculum with the instructions and a download link so off you go for a likkle look. And here's a screen of that latest revision:

PC :: i'm in the middle of a...

As usual, my sidetrack has become sidetracked... there's been a series of rapid prototyping sessions on the ShmupDev forums, each lasting a couple of weeks and with a theme set by the previous winner and i've been putting something together over the last day or so for the third of these sessions which has a theme based around chain reactions. The game in question is called Vinculum for a couple of reasons; partly because it's nice and spacey-sounding and that's a Good Thing for a shoot 'em up... but mostly its because "vinculum" means "that which unites or binds", like a chain and that's what the game is about.

The objective is simple, the player is assigned three standard issue spaceships with forward-firing lasers and nothing else, then sent into battle; blazing away works quite happily but is absolutely guaranteed to result in appalling scores. The secret to racking up the points lies in using the parting shots fired by the enemies against them, when a nasty is shot it explodes rather prettily and disgorges a ring of bullets and, whilst fatal to the player, they'll also blow up any other nasty they rip into. Since that's how chains are created, the true skill is to fire as little as possible and figure out the best ways to create chain reactions that do the rest of the work for you. Every shot the player fires decreases the chain multiplier, every nasty destroyed by a chain reaction adds to it and losing a life with reset the thing entirely. Here's how it looks, running in windowed mode:



Yeah... it's a little hectic, what has happened is a row of seven nasties all stacked up across the screen and i've shot the one on the left; that's blown up, peppered the nasty to it's right and so on until the second to last has just detonated and is about to blow the remaining nasty to kingdom come, all whilst i dodge like a lunatic between the bullets. Even at this stage of development with just five attack waves installed, Vinculum has been proving pretty good fun to play and i've been enjoying the testing, in part because i've been placing the waves in ways that i hope will require a little thought. All it really needs to be complete is a soundtrack (which i'm pretty sure i can sort out, i've been listening to the second level tune from Patriot Dark whilst testing things out) a little more presentation work and then i have to arrange lots of fairly intricate attack wave data... perhaps i need to think about an XML processor for the Alien Release Scheduling Engine's attack waves?

A8 :: Blending into the picture

Whoops, forgot to update the dev blog... i've had a bit of a "coders block" as Kenz put it, so there hasn't been any progress on the remaining couple of levels for Co-Axis 2189 - i know a few people are "champing at the bit" to play the thing (and everybody who had a go at Fusion seemed to enjoy themselves) but i'm fairly adamant that i'll get the bugger right before releasing the final version... that will be this year and hopefully next month at the latest, but in the meantime i've taken a few steps away from it to try clearing my head; to that end, i've been doing an Atari 8-bit puzzle game.

At the moment, it doesn't have an official name but it's pretty much based on the old MSN game Blender where pictures are displayed, then shuffled around and the player is tasked with chosing pairs of blocks to swap in order to get the original image back; right now i have the core of the code running, so single games can be played and the game knows when a picture has been restored and, since i'm not using a common or garden resolution for the pictures (more on that later when i have examples) there was a day of writing a converter in Blitz Max that takes bitmap files that adhere to certain rules and converts them into something my code can display. The "to do" list right now is getting a couple of pictures arranged (preferably three, i'm not sure why but two seems too little but three is enough... odd that), working on some compression to get everything wedged into the Atari and then building the presentation code around what is already there so that games go from title page to main game and back.

C64 :: Then there were three

There are now three levels all populated and playable; the "plan" involves attempting to get a fourth installed before Fusion and sending along a "Competition Edition" version of the game, then addding a stage or two more and releasing the final version.

C64 :: Two levels up!

Once more things are happening and i've now got two completely populated levels up and running (although they'll probably need a little more tuning for difficulty) and i've made a bit of a start on the third... but after spending most of the day naffing around with just shy of 600 lines of attack wave data (the combined length of all source files has passed the 5,200 line mark) it was pretty difficult to continue working on it without feeling the need to bounce my head off the monitor, so i took a "break" and wrote the end of level bonus screen instead and that third level will be started in earnest tomorrow. Here's all of the first level and the beginning of the second as a little bit of a teaser:



Now that there's a reasonable amount of level data in the game to test things properly, i'm quite surprised that nothing has turned out to be seriously broken! In fact, the only issue found is with the scoring system because, as it stands at least, there's absolutely no way it'll ever need an eight digit score! So i'm going to trim it down to six digits (which are just about being used if i turn off the collisions and try to trash everything within the existing levels) and that'll mean redesigning the status bar a little to make the boxes a bit smaller... so whilst i'm there, i might as well add a few other little cosmetic tweaks i wanted to do in the process...

C64 :: Making new worlds

Things are moving onwards... the first level of Co-Axis 2189 is now populated; i need to draw more nasties and change which objects are doing what, but the actual movements are all in and the shield strengths at least roughly tested to make sure the player has a reasonable chance of hitting about eighty or ninety percent of what's passing through with a bit of practice. i've started working on the second level and have some of the background graphics and tiles drawn - it still needs a lot more work and a fair bit of detail adding as well but i'm hoping to have something close to ready tomorrow and possibly even get a start on the attack patterns as well.

My plan is to have three levels done by the weekend and i'll put aside a copy of that version for release in case everything goes pear shaped and i run out of time; i'd like to try for five or six in total if there's enough time but the release date is a week on Saturday which means i need to be done and dusted around a week from Wednesday i reckon... [gulp]

C64 :: Presentation... its what you need

The last couple of days have seen a lot of small details that, whilst not blog-worthy in themselves have finally become something worth talking about; i've just finished integrating the titles and end screens into the game's source code - hat means it's starting to actually feel like a game now and, fingers crossed, there aren't any bugs in there that'll crop up as I begin to build and then populate the levels.

There are quite a few cosmetic details installed such as the status box on the score bar flashing up messages and having the name entry for the top score on the title page all in and working (although i'll be honest and admit the code driving that part of things is somewhat spaghetti-like in nature) and the fantastic music that was done for the iteration before last of this project by Matt Simmonds (nearly ten years ago now, the original Co-Axis 2189 was started eleven years after the original!) has been bolted into place along with volume fades as the code transitions from titles to game to completion and back.

In fact, if the entire thing is really working as well as it currently seems to be, that's the bulk of the code written so tomorrow should see the introduction of a few new tiles and characters for the first level and a start made on the look for the second which I already have a couple of ideas for. At the time of writing, the source code (including white space and comments) is just a fraction shy of 3,800 lines...

C64 :: Breaking down the walls

Well, it's been a week and although quite a few cosmetic jobs have been done including the bolting in of the new status bar, sprites and some level data, there wasn't really a "milestone" to report until today when i got some proper time in front of the assembler; Co-Axis 2189 has a nearly complete game framework running, can initialise levels (although there's no data for anything past the first map and block of aliens) and run through them, detects death events and reacts accordingly, can spot when the lives are all out (but can't act on it just yet since there's no title page to return to) and knows when the end of a level has been reached and if it should move to the next or get ready for the completion sequence.



The next job is getting some of the cosmetics sorted so that the titles page can hand control to the game, then the game back to the titles or the completion screen; that really needs to be sorted now so that i can test it thoroughly before the levels start going in and getting through the entire game takes a lot longer!

The level name "Babylon And On" is a reference to the stone blocks as well as an album by Squeeze - most of the level names in the original Co-Axis were musically inspired and i want to continue that for this "re-imagining" as much as possible - the second level (which is partially planned graphically) is going to be called "Blue Monday".

Spectrum :: Steel Force released

A little development sidetrack this time; Steel Force was developed with Jonathan Cauldwell's Shoot 'Em Up Designer whilst i was writing a review of it for Retro Gamer issue 52; it's a single level, horizontally scrolling shoot 'em up and i've tarted it up with a surround and a simple (in other words, BASIC) title page. It's on my personal site for download and here are a couple of screenshots for good measure; hopefully someone'll enjoy the thing even if it's pretty simple... =-)

C64 :: A spot of rebranding

So i was thinking, y'see, that Boom Zone was familiar... well okay, it's not exactly the most original game going but it does bear a striking resemblance to a project i've had on the back burner since time began; Co-Axis 2189 to be precise. So, rather than writing a totally new game and probably re-coding Ax2189 (as it's referred to on it's source files) from scratch for yet another time next year at some point, the project formerly known as Boom Zone is now officially (wait for it!) Co-Axis 2189!

So the game now has full collisions, a nice attack wave manager that works fairly well and handles up to ten objects (five free floating, the other five produced by recycling one sprite every 32 raster lines), the ship and bullet with their collisions all up and running, the status bar partially activated and it looks pretty nice all told even before i've started importing the tile graphics. The Boom Zone name has, incidentally, been inherited by another project... because despite my saying i wouldn't get sidetracked, i have. Twice. Bum...

C64 :: Whoops, sidetracked...!

Okay, so a little background might be needed here; over on the CSDb message boards a little thread [ahem] ran for a few days regarding coding games in a monitor; during that thread there's a slight possibility i got a teeny bit carried away after several bold claims from an advocate of monitor use that assemblers were "a palava" and that the Action Replay monitor was as good a development environment and... well, i sort of challenged him to write a scrolling shoot 'em up in the same time i could build one with my trusty cross assembler. He didn't even start and suddenly he's the sort of person who takes his time (you wouldn't know it from the bugs he's managed to collect) but i had a fully functioning core to a game running within twenty four hours and video on YouTube to show it off a bit:



So then i've got a small shoot 'em up core that isn't going to be doing anything. Fast forward a couple of days to yesterday and a decision was taken about Charge Armada to move it not so much to a back burner but to one side and let it simmer; the original idea with CA was to get it completed for Fusion '08 but, since it's becoming quite a complex project now, the new game, called Boom Zone, is going to step up for that job and Charge Armada will be given a few more months to simmer on a low heat... or something. i never could cook!


Boom Zone's being upgraded to "full project" has seen it gain a static starfield behind the landscape, bullet to background collisions and a full status bar already but the big jump is trying to come up with level ideas... which is where we're going next, hopefully. There'll be another video over the weekend if all goes to "plan" with some backgrounds in place and a few more attackers tootling around...

C64 :: Catching up

i was doing odds and sods as well as coding over the weekend, so here's a quick update that covers the last three days; the character bullets were tweaked but there's a "ghosting" bug that means a bullet gets decommissioned but left on the screen until it gets filtered out by the buffer copier and the buffers flip, i thought i had it but that needs further investigation it seems. The background starfield went in as well, although it's using it's own routine for speed, again relying on the filters in the buffer copier to remove stars cleanly and a feature of the "colour per tile" colour scroller for speed; the bullets currently inherit the high res colours of the stars as they pass over them, that's on the "to do" list when i go through the bullet code looking for that ghost.

The status bar font was also slapped together and a layout bolted into the code before all the score handling routines were installed; the scoring itself is pretty arbitrary right now since any hit to an active object gives ten points and destroying it another forty but the score itself is displayed correctly and, if it tops the high score, the latter updates as well. The lives and level counters both work as well although the code to decrease the lives hasn't been added for the moment.

The final job was writing up some notes on the object and animation systems for the fluffy bunnies doing the sprites, then passing said notes to the first designer to add some to the pool and whatever specific ones are required for his level; this is, hopefully, where the game starts coming together because it'll be when the first level-specific movement patterns start getting bolted into place... it'll also be the point where my worst fears will be realised and i might start getting raster over-run problems because the damned object system really is too CPU intensive so there might be some re-writes around that area of the code on the way too. Since i'm waiting on data for the moment, i'll give the cosmetic stuff a bit of thought as well; i've had a quick tweak of the backgrounds (we're now using 256 characters of the first font!) and details such as the way the ship arrives and leaves play at the start and end of a level have been improved a bit; the code also spots it's "game complete" state correctly, so the ship zooms off and then it falls into a loop because there's no code for that condition just yet...

C64 :: Out with the old

Well, I finally found some time to code [insert pretentious comment about being a "writer" and deadlines here!] and removed the old single-sprite bullet routine in order to add a shiny new character-based system; it almost worked straight away (which is a minor miracle in itself) and, after just a little tweaking, things seem to be happy... although I did have to re-tune the collisions again now I can actually see where things are in relation to each other! Essentially, the bullets can be used as a guide, if you can fire through a gap it's possible to fly through it as well. There needs to be some work done to add coloured bullets (presently they just inherit the colour of the tile they're over) since I'm hoping that the same plot routine can be co-opted into driving a static starfield behind the action and that'll need high res characters to get it looking the way I want it.

A first draft of the level management routines and some data went in as well; so far it seems to be functioning but I suspect I'll need to keep an eye on the thing because a single, minor typo in that table can utterly bork things up and the attack wave managers or tile readers can suddenly find themselves pulling in totally wrong data. A next step is going to be removing the INC $D021 loop that kicks up when a level is completed and having the thing actually try to leave the level and set up the next.

C64 :: Bump and grind

After a busy day pretending to be a writer, i like to relax and have a quiet evening discussing buffer selection with my collision routines... [Sits with smoking jacket in big leather armchair, with laptop and pipe that, when blown, produces soap bubbles for comic effect]

And after a bit of an altercation which i initially lost, they now take into account which of the two display buffers is in the foreground when attempting to read what is underneath the ship! That's a major plus, the whole thing was pretty unpredictable when, for eight frames out of sixteen, it was reading the damned back buffer during the redraw so it was picking up all sorts of odd ideas! i also spent half an hour tweaking the collision area, getting it lined up closer to the centre of the ship; it's a pretty rough calculation, but if it's good enough for the likes of Armalyte or Io, it's good enough for me too and now it's about as accurate as things get i'm happy.

i've also had the chance for a quick prod around the object decommissioning system and, after a little tweaking to get it working in a way that wouldn't limit the top vertical motion speed of the objects, it can spot something going out of bounds vertically as well as horizontally now; to be honest this isn't really needed for Charge Armada but i have a few other projects that i want to reuse parts of the object system for in the early stages, they could do with that feature so, since it's a fairly minimal overhead, it went in now to save me having to remember later...

C64 :: Testing 1, 2, 27?

Well, had a busy Sunday but at least got a few things done that i wanted to; the first previews of Charge Armada were sent to the people doing level designs so that they can see what their tiles and characters look like in place. i'm a little tired, but hopefully i didn't stuff up any of the colour data during tile conversion! Generally speaking, it's starting to look pretty cool with the backgrounds going past and sprites whizzing around. The code has some documented "features" in the collision system and a few other foibles that i need to iron out, but generally speaking things are going well.

Note to self; when deciding to give a set of routines a silly name like Alien Release Scheduling Engine, it's important to remember that you'll be doing ARSE double entendres for quite a while afterwards...!

PC :: Oops, sidetracked!

Spent part of today working out how to produce something similar to the alien release scheduling engine (or A.R.S.E. for short... you should see some of the comments in my source!) from Charge Armada in Blitz Max and, generally speaking, things went pretty well; i now have a similar scripting language, but with up to thirty two moves per nasty (the C64 version only has eight), each object contains a unique set of commands rather than having the wave data and object move data seperate and all the movement stuff is optimised in that i can terminate a move sequence and wrap to the start early. In fact, the only thing it hasn't either got or improved upon is the death inheritance system that CA has, that's partly because explosions are handled independently to the nasty object system on the PC and partly due to the new format for the object data but i'm considering ways to add it if the need is there...

i haven't entirely decided what to actually do with the engine yet, but there's always the ShmupDev rapid prototyping "compo" perhaps... how to make a shoot 'em up where the ship can't fire, i wonder!

C64 :: Hmm, upgrades

Today (well okay, yesterday to be strictly accurate) saw me taking out a lump of the nasty movement handling code and rewriting it to double the horizontal resolution; usually i just deal with values of $00 to $ff for horizontal sprite positions and multiply everything by two to save having to piddle around with the most significant bit, but this new game was getting to the point where it needed at least some objects to be able to track along with the landscape so a bit of surgery was required... eventually the damned thing worked as well, at least it did after a lot of fairly creative swearing and a second re-write to get the overheads down. Now the only serious bit of CPU grind from the object handling is when it nips off to pull up a new baddie. i'm not sure at the moment why it's got such a large CPU requirement but i can hazard a few guesses; it copies 32 bytes per nasty then re-assigns some of those around to other places... so it might be time to see if i can't consolidate those data tables into one affordable loan place in memory.

The other news is that i'm finally starting to settle on a name; this process usually takes a while, bouncing words around and seeing which sound best when put together. After a little mental juggling, the most probable candidate for this game is Charge Armada.

C64 :: Blam, blam, blam!

Today saw me spending a couple of hours dropping some test data into the new project and it lives! Well okay, it was already living but now the aliens look like aliens, the player's ship looks like the one from my own game Warflame (because that's where it's from!) and it currently fires copies of itself at the aliens because the bullet system is going to be re-written soon to use a different system so there's no point in me adding a sprite definition for the moment. There were a few hiccups where the objects weren't being decommissioned properly and explosions were getting "stuck" on the screen until the management system needed to recycle that particular sprite but after that it looks rather spiffy.

Today's other job is probably going to be getting a character set ready for the status panel and starting to get the splitting system in that masks the sprites if they arrive or leave the play area from the bottom - the object decommissioning checks could do with being expanded to remove objects that get too far out of the screen boundary vertically (this already happens horizontally) so i'll probably add that as well and i've yet to do the cosmetic stuff like make aliens strobe white for a frame when shot. There's still a long way to go, but it's looking pretty solid so far...

C64 :: Ongoing project

i've decided to keep a development blog! i'm not entirely sure why i decided to, but it seemed like a good idea yesterday so here it is! My active projects tend to dot around quite a bit (something i'm attempting to keep under control with a relatively low degree of success), so there's a good chance this blog'll do the same but the more general waffling (at least after this general waffling) will mostly be reserved for my main blog. i'm going to prefix entries with a format and i might do something fun with the syndication to allow filtering for specific machines... if i get time.

So my ongoing C64 shoot 'em up... the name is almost settled and it's current status is that it scrolls 22 lines of the screen with 4x4 character tiles, has colour-per-tile colour scroll and at the moment only uses eight sprites; one for the player, one for a bullet and six for the nasties. The engine is being kept "generic" for the moment because, once i have the attack wave managers absolutely the way i want the things, i plan to "fork" the source off for a couple of other projects. Cheaty i know, but i don't usually rely on library source so it might be a good idea for me to start.

Yesterday saw a fairly major overhaul to the nasty object control stuff; after four or five hours rewriting large blocks of the existing code and swearing (planning ahead... something i've never been much cop at! =-) the objects have eight moves (previously it was just two) which are specified as speeds for X and Y and a duration. They can also be shielded and have the option to "mutate" into another object or simply explode when destroyed, which adds a lot of interesting possibilities... there aren't any real objects defined yet (because there aren't any sprites ready to install) but everything seems to be behaving so that's a small victory!