Showing posts with label shump. Show all posts
Showing posts with label shump. Show all posts
Tuesday, 28 October 2008
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!
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Sunday, 24 August 2008
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:
Labels:
development,
game,
PC,
programming,
shmup,
shooter,
shump
Thursday, 14 August 2008
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?
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?
Labels:
development,
game,
PC,
programming,
shmup,
shooter,
shump
Tuesday, 15 July 2008
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.
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Saturday, 12 July 2008
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...
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...
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Tuesday, 8 July 2008
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]
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]
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Friday, 4 July 2008
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...
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...
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Sunday, 29 June 2008
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".
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".
Labels:
c64,
development,
game,
programming,
scrolling,
shmup,
shooter,
shump
Friday, 20 June 2008
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... =-)

Labels:
engine shmup,
seud,
shoot 'em up,
shooter,
shump,
speccy,
Spectrum
Monday, 16 June 2008
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...
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...
Friday, 13 June 2008
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...
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...
Friday, 6 June 2008
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.
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.
Wednesday, 28 May 2008
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...
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...
Monday, 26 May 2008
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...!
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...!
Saturday, 17 May 2008
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...
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...
Thursday, 15 May 2008
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!
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!
Subscribe to:
Posts (Atom)
