Last Fighter D [WIP]

[AlexMdle]

(Current Demo Version 1.1: http://www.mediafire.com/download.php?v6u5lynnnrcl2a5)

I am not a fan of fancy long introductions and whatnot and usually like to contain the information to brief and punctual.

Also I'm a terrible liar.



Last Fighter D is a collaborative effort between me, PureQuestion and Oskar Alex. (Artist, Programmer and Awesome Music Guy respectively) The idea was to go ahead and make a fun, challenging shmup, pretty much because we have some ideas, some ambitions and GM just seems to be willing enough to play as a sort of canvas I guess. Hmmm, I guess I should break up the pointless chatter with some pictures to keep it, mmm, spicy.



The game is still pretty much in early alpha stages where we refine the engine, design and gameplay choices. At the moment there are 2 completed stages and 3 different weapons to use. The game is planned to have branching stages, many unlockable weapons and different styles of enemy attacks.



I hope the end result will please the audience and that the feedback will help us improve if we may ask you to accompany us through the different stages of the game's creation?



Stay tuned

[drei :3]

Good to start early with asking for feedback!

About paths that branch out: The developers put so much stuff into a game and yet it gets dull quick, because whether players make it far or not, they always see the same first stage. I prefer the tree upside-down, so you have choice at the beginning and move towards the same final stage. (That way around, you can also have different beginnings for all stages after the one you start in based on from where you enter.)

Either way, I hope the stage choice isn't just a choice between different paint jobs or that there is one path which is the best for any player. I hope that there is a genuine choice, with some paths that are harder to survive, but also offer better scoring opportunities. (Btw. because I like this kind of trade-off in game design in general, I'm against handing out health or extra lifes based on score.)

What's the control scheme?

[PureQuestion]

Lives are based on score, but lives are also dropped by certain enemies.

Arrow keys move, Z is basic shot, X is extra function (Be it alt weapon, mode change, etc), and Z is Bomb/Power Attack/Super

As for Branching paths:
There is one starting stage. So I guess we already fucked up. From there, you head to stage 2, from there you have the choice of stages 3a and 3b. These lead to stages 4a and 4b respectively.

From stage 4a, you have the choice of stage 5a and 5b, from 4b, you can head to 5b or 5c; In other words, the paths slightly rejoin in the form of 5b.

The various 5's all lead to the matching 6, which, naturally, is the final stage.

And of course there might be a couple other stages for those determined enough to find them...

That said, the paths all follow unique gimmicks. Stage 1 and 2 are all about getting you into the game. Stage 1 is a fairly stand shmup ordeal, stage 2 adds more varied enemies and challenges, but remains unnotable (aside from having awesome music ).

From stages 3 onwards, each pair of stages (3a+4a, 3b+4b, 5a+6a, 5b+6b, 5c+6c) shares a unified 'theme'. 3 and 4a, for example, take place in an enemy base. 3 and 4b, conversely, are above and under the surface of a river, respectively.

All in all, a ton of ideas, hopefully the kind that will keep players coming back to see what the game throws at them next.

And once all is said and done, you've always got a few extra stages on your hands.

[Udderdude]

The background in the last screenshot needs to be darker and not the same color as the player ship, IMO.

[AlexMdle]

The background in the last screenshot needs to be darker and not the same color as the player ship, IMO.

It is quite significantly darker than the player, plus most of the stage actually have colored buildings around the main road. Last few months of testing showed no color-based complaints.

Hope it serves to assuage any rising feelings of panic

[AlexMdle]

ATTENTION

I may now at last humor your person with a demo release. It's quite basic and lacks many features that we had not time to add due to an outbreak of bugs to fix and in fact, yet to fix, but I hope it will suffice to showcase the core gameplay.

Without further ado, http://www.mediafire.com/download.php?v6u5lynnnrcl2a5

Feedback and any significant (or insignificant) glitch reports are very appreciated

[PureQuestion]

http://www.mediafire.com/download.php?v6u5lynnnrcl2a5

If you prefer your giant tanks without the ability to teleport across the screen when near death, this is the version for you.

Read: Fixed major bug.

[Udderdude]

General:

Player ship moves way too slow in non-focus mode.

The toggle option cycling through to back shot is pretty annoying, seeing as you only need to use back shot once per level, and most of the time you're using wide or straight.

The pixelation effect is ruined when you see something rotating and can clearly see it breaking the pixel effect. Ex. the rotating shots in level 1.

Level 1:

When the guys show up from behind you get assraped by surprise pretty heavily.

One of the first boss's pattern reminds me a lot of the helicopters in st.1 of Batrider.

Level 2:

The tanks move in a very un-tank like way. They might as well be planes. They also seem to have way too much health.

The Enemies that suddenly surround you (not the stealth bombers) move just like the bees from the TLB in Donpachi and are just as annoying, you should change them.

[PureQuestion]

Player ship moves way too slow in non-focus mode.[/qoute]

Can change this.

The toggle option cycling through to back shot is pretty annoying, seeing as you only need to use back shot once per level, and most of the time you're using wide or straight.

While this is true, its not something I can really think of a(n efficient) solution for.

The pixelation effect is ruined when you see something rotating and can clearly see it breaking the pixel effect. Ex. the rotating shots in level 1.

See above.

When the guys show up from behind you get assraped by surprise pretty heavily.

*makes note to add warning sign*

One of the first boss's pattern reminds me a lot of the helicopters in st.1 of Batrider.

Is that a problem or just a comment? And which attack for that matter o_o

The tanks move in a very un-tank like way. They might as well be planes. They also seem to have way too much health.

I thought the movement was pretty convincing, myself :S

As for HP, if you're referring to the openers, yeah, they need a bit less.

The Enemies that suddenly surround you (not the stealth bombers) move just like the bees from the TLB in Donpachi and are just as annoying, you should change them.

Do they just need to be slowed down, or what?

[Udderdude]

The Enemies that suddenly surround you (not the stealth bombers) move just like the bees from the TLB in Donpachi and are just as annoying, you should change them.

Do they just need to be slowed down, or what?

If I were you I'd remove them entirely.

[PureQuestion]

I'm hesitant to solely due to the variety they add...

But perhaps.

[Ebbo]

The toggle option cycling through to back shot is pretty annoying, seeing as you only need to use back shot once per level, and most of the time you're using wide or straight.

While this is true, its not something I can really think of a(n efficient) solution for.

Just add another button for changing weapons back and forth? ; )

Tried your latest demo and besides new weapons much hasn't really changed. I can pretty much relate to all Udder's comments. Just like the tanks, the copters during stage 2 are still a bit too durable and overpowered - they shoot more bullets than the actual miniboss.

Talking about overpowered: Variable weapon system is pretty much broken when compared to others. As long I just tap the weapon button, I can keep the charge at maximum all times and the overall performance still easily outdoes Standard and Beam... On the other hand the game is much more fun with Variable. Standard is okay while Beam is just boring to use.

[S20-TBL]

I died by colliding with a dead boss...not good. Since this is Game Maker, try changing the boss object to a different, harmless one that handles all the explosion effects instead of retaining the same object that can kill the player.

EDIT: Some bullets in stage 1 are hard to see, notably the transparent bullets with thin outlines. It's made worse by the fact that they pulsate between red and dark red. If you want to retain it, please change them to pulsate between white and red, or just solidify the bullets. It's hard to get a feel for hazards and lethal projectiles if they look like translucent bubbles, unless they're solid obstacles like the ones in Gradius 3.

Also, I died colliding with a dead boss tank in Stage 2. And the tank rammed into my ship. What the? That must be some sick vertical clearance. Usually in verts you can "ride" or fly over tanks without any harm done. In this game, even the normal tanks can ram into you. Please fix that.

[Rozyrg]

I died by colliding with a dead boss...not good. Since this is Game Maker, try changing the boss object to a different, harmless one that handles all the explosion effects instead of retaining the same object that can kill the player.

You can also do this with a variable, all I use is ones like no_hit, so that when there is a collision between your ship and an enemy or bullet, it basically will skip those events. Something like:

Code: Select all

if no_hit=1 {} else
{
//collision events here
}

[AlexMdle]

Issues like dead boss ramming and variable weapon being overpowered have been mentioned before, we just sort of neglected those due to the overpowering amount of more serious bugs to fix.

Some bullets in stage 1 are hard to see, notably the transparent bullets with thin outlines. It's made worse by the fact that they pulsate between red and dark red. If you want to retain it, please change them to pulsate between white and red, or just solidify the bullets. It's hard to get a feel for hazards and lethal projectiles if they look like translucent bubbles, unless they're solid obstacles like the ones in Gradius 3.

Those are actually my favourite enemy projectile sprites. Guess making the rims thicker wouldnt hurt.
Good feedback sofar

[Sumez]

Don't change the stuff you like, but take people's feedback into account. I think it's fair to keep the bullets translucent if that's what you like about them, just find another way to make them more visible, like you said.

I haven't tried your game, so I don't know how those enemies that surround you work, but to me it sounds like a good idea for the variation. So if people find them too annoying, adjust them in some way that you create a trick to potentially easily escape them, that always works without risk.

One of the best comments on good game design that I've ever seen - I think it was actually Shigeru Miyamoto who said it, or someone else at Nintendo - is that that challenges in your game should primarily be built around a combination of little obstacles that are all simple to comprehend and "easy" to overcome on their own. And then, only by combining these properly at the same time, you can increase the challenge by forcing the player to multitask in order to maintain an overview of the situation.
Even though this was a comment on the first Mario game, I think it's even more true for shoot'em ups which constantly force you to dodge one bullet pattern while keeping one or more other patterns in mind to avoid messing up.

What this means is that even though the enemies in question feel annoying as they are used now, I'm sure you can tweak them and, if necessary, place them somewhere else, to make them less of a nuisance while still posing a challenge.

[S20-TBL]

I died by colliding with a dead boss...not good. Since this is Game Maker, try changing the boss object to a different, harmless one that handles all the explosion effects instead of retaining the same object that can kill the player.

You can also do this with a variable, all I use is ones like no_hit, so that when there is a collision between your ship and an enemy or bullet, it basically will skip those events. Something like:

Code: Select all

if no_hit=1 {} else
{
//collision events here
}

D'oh! I forgot, you can also do the above to make the player ship invulnerable during end of level flourishes.

I haven't tried your game, so I don't know how those enemies that surround you work, but to me it sounds like a good idea for the variation. So if people find them too annoying, adjust them in some way that you create a trick to potentially easily escape them, that always works without risk.

The issue with the circular enemies is that very early in the game, when the player is just beginning to warm up, swarms of them (probably numbering around 12-15) appear in very tight circles around your ship. Judging from the game resolution I'd estimate they close in on you in a very small 50-pixel radius, which makes it hard to dodge the bullets. What's worse is they appear near-spontaneously while a few enemies are ganging up on you from the front with bullet spreads, making for an early-game difficulty spike. There is a later circle formation which is slightly easier, due to its larger radius.

My suggestion is to isolate the instances when the circling ships appear, then expand the ring formation's diameter a bit more. Say around 200 pixels max. Then reduce the number of ships formed during early-game versions of the circle. You can have tighter and more numerous circles of these enemies form in later levels, like the ones from Stage 5 in Ikaruga, or implement what is present in the game now--but for later levels.

[Rozyrg]

D'oh! I forgot, you can also do the above to make the player ship invulnerable during end of level flourishes.

Funny, I just recently realized the usefulness of changing objects ..mostly for minor optimizations, ie. such as swapping out 'dead' enemies so they don't run all the collision and complex movement/reaction instructions while they just sit there waiting to scroll off the screen.

I use the variables for lots of different things, though. I have ones for all the basic collision variations:

1. intercepts shots,takes damage, does not collide with player (ie. ground objects/enemies)
2. does not intercept shots,takes no damage, does not collide with player (dying enemies, special objects that might take advantage of an enemy's behavior/movement code; but don't necessarily attack you.)
3. intercepts shots,takes no damage, does not collide with player (ie. starting invincibility for a boss, barrier, shot-blocking boss sub-sections)
4. does not intercept shots, takes no damage, collides with player (rarely used since you tend to assume since your bullets pass over it, it won't hurt you; but you might need this eventually anyways)

Obviously, this means the player's ship object, the bullet object and the enemy parent object all will have similar instructions; but that's all pretty easy to work out.

I tend to leave out the variation where the bullet passes over the enemy but still damages it, because I personally find it a pain in the neck and potentially wasteful to make an enemy have to remember the instance id of every last bullet that's hit it. You could also have a certain time before it can inflict damage again; but you'd still have to keep track of that per bullet. I don't doubt there's a better way; but just with what I know now, it's something I'd save for a really powerful special weapon that simply can't be used non-stop as you're playing.

[Udderdude]

The pixelation effect is ruined when you see something rotating and can clearly see it breaking the pixel effect. Ex. the rotating shots in level 1.

See above.

I am not really familiar with GameMaker, but you could make an array of pre-rotated sprites created before the game starts, and use those based on the rotation instead of rotating it. As a bonus, it's faster this way, too :P

[S20-TBL]

Rozyrg: Type 4 would probably be the kind used for powerups, point items and the like if I'm correct, but then again those aren't enemies... But you just gave me a good idea for collisions. I have the same setup for my player characters, but I didn't think of doing it for enemies.

Back to Last Fighter D: I noticed that the sound folder contained two versions of the same BGM, a loopable and non-looped segment. However, since SuperSound's ability to check WAV and OGG length data is very precise, why don't you instead try to use SS_GetSoundLength(), SS_GetSoundPosition() and SS_SetSoundPosition() in tandem to simply detect the music file's current position, then loop from the desired starting position once you reach the end? This would cut down on the number of sound files.

Here's some SuperSound code I've been working on for my own project. This is meant to make getting a song's position in bytes much easier than it would be if you used SS System's default method (which is getting the raw WAV file size in bytes), and because of this I can just plop in some optimized OGGs. I use an object which loads the music I would need for a single level, though technically this same object can be used to load all the music at the start of the game (possible, but would need some more complicated code structure).

CREATE EVENT:

Code: Select all

var_bgm = SS_LoadSound("<sound file path>", 0);
var_bgmtime = ( SS_GetSoundLength(bgm) / <total track duration, in seconds> );
SS_PlaySound(bgm);

The key variable here is bgm_time. SuperSound returns the track length as the number of uncompressed bytes in the file, which can be retrieved if you were using the WAV. But since it's time- and space-consuming to export WAVs of your songs just to find this out, you can just use the native SS_GetSoundLength() script.

Here's where it gets tricky. You have to know when you want the track to start looping and at what point it should loop back to. I figured out that if you divide the total track length in bytes by the track's total duration (measured in seconds), you can approximate the correct positions in the song which you want to loop down to the exact second in which they take place, and then dictate it to SuperSound.

I had to do some trial and error during this phase because my tracks had instruments with reverb, but since you're using emulated chiptunes this shouldn't be too much of a problem. You can use decimals if you're unsure.

STEP EVENT:

Code: Select all

if(SS_GetSoundPosition(var_bgm) > var_bgmtime*<point in track where you want it to end, in seconds>)
{
      SS_SetSoundPosition(var_bgm, var_bgmtime*<point in track where you want it to loop back to, in seconds>);
}

Hope that helps. The code itself is pretty simple, but the really tricky part is getting the song's measure.

[PureQuestion]

:O

That is very useful indeed, and would solve some bugs with the current system. I may have to attempt to add that.

The pixelation effect is ruined when you see something rotating and can clearly see it breaking the pixel effect. Ex. the rotating shots in level 1.

See above.

I am not really familiar with GameMaker, but you could make an array of pre-rotated sprites created before the game starts, and use those based on the rotation instead of rotating it. As a bonus, it's faster this way, too

I'm not sure how on earth it would be faster o_o

I could program the bullets only to rotate at specific angles (ie: multiples of 15, 30, or 45 degrees), but eh. It tends to bug me when the angle of the bullet isn't equal to its trajectory (and, more importantly, it makes it harder to determine trajectory)

[S20-TBL]

I could program the bullets only to rotate at specific angles (ie: multiples of 15, 30, or 45 degrees), but eh. It tends to bug me when the angle of the bullet isn't equal to its trajectory (and, more importantly, it makes it harder to determine trajectory)

I notice I keep posting in here, sorry. I've hit a snag with my own project and need to stretch a bit.

Technically, yes; rotating the bullet in specific angles is the way to go if you want to avoid your pixels breaking up. To handle trajectory checking, though, you can check for the bullet's hspeed and use variables to handle the direction and rotation.

Here's a sample, using dir_x to handle the sprite's xscale and rot to handle rotation. In the bullet's Step event:

Code: Select all

if hspeed < 0
   {
        dir_x=-1;
        rot+=30;
   }
else if hspeed >0
   {
        dir_x = 1;
        rot-=30;
   }

Then in the draw event, use draw_sprite_ext so you can set xscale to dir_x and image_angle to rot.

Draw Event:

Code: Select all

draw_sprite_ext(sprite_index,image_index,x,y,dir_x,1,rot,c_white,0.9);
image_speed=1;

That should cause your bullet to rotate to the right when its horizontal speed is greater than 0, and to the left when less than 0. The dir_x is for when your bullet is assymetrical, for example a sickle shape, and you need the sprite to face the right direction. You can also modify it to use yscale and vspeed if you need to.

[AlexMdle]

Honestly, I never dwelled much on pixelation breaking up.
Hell, some of the enemies have less pixelated logo emblazioned on them.

[PureQuestion]

Sorry, by saying it's difficult to determine trajectory, I mean in game. I have trouble dodging bullets that are pointing differently than they are moving. It drives me absolutely crazy, in fact.

Also, I've no issues with your posting at all. Feedback and help are always appreciated!

Plus you're keeping us at the top of the page.

[Udderdude]

I am not really familiar with GameMaker, but you could make an array of pre-rotated sprites created before the game starts, and use those based on the rotation instead of rotating it. As a bonus, it's faster this way, too :P

I'm not sure how on earth it would be faster o_o

I could program the bullets only to rotate at specific angles (ie: multiples of 15, 30, or 45 degrees), but eh. It tends to bug me when the angle of the bullet isn't equal to its trajectory (and, more importantly, it makes it harder to determine trajectory)

Drawing pre-rotated sprite is faster than rotating the sprite each time it's drawn.

I guess if you don't want to, oh well.

I'm an old fogey for even caring about speed in a 2D sprite based game in 2011 anyway :P

[Sumez]

Even a lo-res 2D shooter will run like crap if you don't write your collision detection routines etc. with the system's memory pointers and crazy crap like that in mind. I don't know how much of that Game Maker does for you

[PureQuestion]

Most of it. Game maker is rather excessively intuitive. The price paid for that, of course, is limitations.

[AlexMdle]

Alright, the work on stage 3a continues.

The level will feature shenanigans based on side-walls.

These to be exact.


Also a small teaser for the boss (Just an seembly of boss parts done, not the actual form of the boss as of yet)












See you next time!

[AlexMdle]

And here's the assembled look for Stage 3a.



Well, except that larger distracting pillar is going to take a trip to the background.
The pink wall segments on either side can slide forth in various formations, it remains to be seen how we utilize that.

Also worked on the HUD some more.

[BPzeBanshee]

The HUD does look significantly improved.

You're right about the pillar too - but it doesn't even look fitting with the rest of everything on the screen, as well as being obtrusive.

Really I'm just being picky. The rest of it looks good and I haven't been able to test the gameplay yet - too many breaking developments with Game Maker material.