Tossing some scoring ideas around, input appreciated.

[Drum]

First one I know is kind of goofy but could still be fun. The framecounter is displayed - usually the game runs at 60fps. When you get slowdown from a lot of bullets/enemies onscreen, there is slowdown and the difference between the current framerate and the max framerate is added to the point value of each kill. If the framerate hits zero the game crashes and no score is saved.
Pros: Smartass jab at framerate creeps.
Cons: Possibly gamewrecking if you play for score, may be possible to rig by having a crappy computer.
The game plays out a little like Bangaio in that it's free-roaming and enemies follow you, but enemies will be able to clusterfuck you pretty bad, and there is a fixed maximum of enemies that can spawn per level, which would disinsentivise/disable abuse.

Second one:
Customiseable point-based difficulty system. In the options you have a bunch of boxes you can check, each one increasing point values by a certain percentage
- player takes more damage
- enemies take more damage
- 2x enemies
- no power-ups spawn
etc.
Checking all the boxes results in the hardest difficultly, and there will be a few specially-balanced 'pre-sets' for players who don't want to fiddle around too much with the knobs.

This may only be available in score attack/endless mode.

The second idea at least has probably already been done and I may be setting myself up for a 'how have you not played ___???' post.

[BPzeBanshee]

One thing I noticed about at least one game I've played recently is that even on a bad PC the game appears to run at 60 FPS, but some variable called BLT (which is normally equal to the FPS) is at something more like 20 or 30. This seems to make the game still run at the same speed through some kind of strange form of frameskipping. The frameskipping seems to be done well since while every isnt exactly smooth flowing its all happening at same speed.

That's what came to my head when looking at your first idea, second one is (as you predicted) not totally unique but I don't know any shmup-genred games that do it. Halo:Reach does (though its a FPS), you play on Firefight mode and you get more or less credits depending on how you change the settings. Certainly seems plausible to me for an endless-like mode.

When the "How have you not played ____???" posts roll in I'll be right beside you on this one, since I'm still in concept stages for my game and need discussions like these to make up my mind.

[Drum]

One thing I noticed about at least one game I've played recently is that even on a bad PC the game appears to run at 60 FPS, but some variable called BLT (which is normally equal to the FPS) is at something more like 20 or 30. This seems to make the game still run at the same speed through some kind of strange form of frameskipping. The frameskipping seems to be done well since while every isnt exactly smooth flowing its all happening at same speed.

Thanks a lot for this - this sounds like it could be very, very useful.

That's what came to my head when looking at your first idea, second one is (as you predicted) not totally unique but I don't know any shmup-genred games that do it. Halo:Reach does (though its a FPS), you play on Firefight mode and you get more or less credits depending on how you change the settings. Certainly seems plausible to me for an endless-like mode.

When the "How have you not played ____???" posts roll in I'll be right beside you on this one, since I'm still in concept stages for my game and need discussions like these to make up my mind.

Good to know. I like Halo (by and large) but I haven't picked up Reach yet - looks like I have to now! Maybe I could do something like the Firefight system combined with a rank system. Like, you choose which difficulty adjustments you want and they are introduced in the order you want based on how well you are doing. Sounds messy, but maybe something like that could work.

Right now I'm struggling to think of a fun system that would work well in a procedurally-generated game. I've thought a bit about chaining, but that sounds like it would be tough to balance. It can be annoying enough in pattern-based games, but with random levels and enemy placement ... I dunno. Even with ways the player can freeze the combo meter it sounds like it could be a chore. If you or anyone can think of a good alternative to chain-based scoring that would work well, please chime in.

[RNGmaster]

I find the system in Ibara Kuro actually very similar to the first idea - jack the rank up, then wait until the screen is full of bullets, then bomb. I think that using the first in conjunction with rank is probably the best idea, otherwise there are just a few set "lag" areas. And concentrating scoring on one or two little places in a stage is not a very good idea.

[Ixmucane2]

First one I know is kind of goofy but could still be fun. The framecounter is displayed - usually the game runs at 60fps. When you get slowdown from a lot of bullets/enemies onscreen, there is slowdown and the difference between the current framerate and the max framerate is added to the point value of each kill. If the framerate hits zero the game crashes and no score is saved.

You can tie score to the number, age and type of bullets and enemies directly, without involving the frame rate: there is no reason to let different platforms and configuration options or insufficient computer performance affect score, and on the other hand intentional slowdown and scoring should be separate concerns (slowdown should adjust feeling and difficulty without throwing the scoring system out of balance).

Second one:
Customiseable point-based difficulty system. In the options you have a bunch of boxes you can check, each one increasing point values by a certain percentage
- player takes more damage
- enemies take more damage
- 2x enemies
- no power-ups spaw

A brutal combinatorial explosion of game modes. Some of those modes will be boring, not winnable, etc.: they should be forbidden, at which point you are back to normal selectable modes with a misplaced effort at being orthogonal rather than making every mode well-tuned and (possibly) unique.

On the other hand, some things could be customizable without much trouble:

• length of "time attack" stages (with some thought on which section of the full-length stage should be offered)
• removing and arranging bosses (or intervening levels)
• scaling up speed, hit points, enemy density etc. in successive loops of a short game (which are intended to ramp to superhuman difficulty)

[BPzeBanshee]

Oh boy oh boy that's some complex stuff. I'm sticking to Technosoft's basic difficulty via options menu selection and predefined enemies for my simple head. :/

[Drum]

First one I know is kind of goofy but could still be fun. The framecounter is displayed - usually the game runs at 60fps. When you get slowdown from a lot of bullets/enemies onscreen, there is slowdown and the difference between the current framerate and the max framerate is added to the point value of each kill. If the framerate hits zero the game crashes and no score is saved.

You can tie score to the number, age and type of bullets and enemies directly, without involving the frame rate: there is no reason to let different platforms and configuration options or insufficient computer performance affect score, and on the other hand intentional slowdown and scoring should be separate concerns (slowdown should adjust feeling and difficulty without throwing the scoring system out of balance).

Well, the reason was that I thought it was kind of funny. Not haha funny but still ...
I don't wanna sound too defensive, because I did post the idea to be critiqued but what I liked about it is that the problems sort of solve themselves - you risk not having your score saved at all if the game crashes because the framerate got too low. Getting killed is bad enough, but I liked the brutality of incorporating the bugginess into the gameplay. The real issue is the problems of different setups. If it was for a console this would be moot, but if I couldn't figure out a way to make it work in a variety of setups I'd just drop the idea as it's hardly a core part of the game.

A brutal combinatorial explosion of game modes. Some of those modes will be boring, not winnable, etc.: they should be forbidden, at which point you are back to normal selectable modes with a misplaced effort at being orthogonal rather than making every mode well-tuned and (possibly) unique.

Well, the game would be tested with all the boxes checked at once so I don't really see that as an issue. Also, being unwinnable is aok for an endless mode - so long as it's balanced correctly and the difficulty ramps up gradually.

scaling up speed, hit points, enemy density etc. in successive loops of a short game (which are intended to ramp to superhuman difficulty)

Well, the loop part is moot - it's an endless mode. That is intended to ramp up to superhuman difficulty.

[BPzeBanshee]

Endless modes will get boring quickly though, so while the points may be 'moot' it may still be a good idea to have an optional limit to the mode.
Taking a hint from Halo:Reach again, standard Firefight mode only goes for 1 set, which consists of three rounds and in turn five waves plus another 3 for the boss wave and 1 for the bonus wave. I like this format.

[Drum]

Well, maybe. The way I'm planning it right now there will be a main game with a set number of procedurally generated levels cut with about 7 boss stages. The pattern is two stages -> boss -> two stages -> boss. Each stage will probably take about two minutes on average, more if you're trying to meet all the requirements for the best ending/extra stages, and *much* shorter if you're speed running. The only real difference between endless mode and the main mode is, uh, the end - though I probably won't try to incorporate the bosses into endless, as they are quite the bottleneck.
Main mode will probably just have a single difficulty mode and no loops, though maybe you could unlock a hard mode upon completion (it will be plenty hard as it is). There may also be a mode where I design all the levels myself, but I'm not sure at this stage.

[BPzeBanshee]

Sounds like a good idea to me. My project is going really simple for scoring (ala Thunder Force V if there has to be any multiplier bonus) and stage progression like Raiden.

[Ixmucane2]

brutal combinatorial explosion of game modes. Some of those modes will be boring, not winnable, etc.: they should be forbidden, at which point you are back to normal selectable modes with a misplaced effort at being orthogonal rather than making every mode well-tuned and (possibly) unique.

Well, the game would be tested with all the boxes checked at once so I don't really see that as an issue. Also, being unwinnable is aok for an endless mode - so long as it's balanced correctly and the difficulty ramps up gradually.

The issue is making all different game modes fun. By "testing with all the boxes checked" I assume you mean that the game is going to be hard, but not unfair or impossible, using the most punishing difficulty settings: a one-size-fits-all design is likely to err on the side of being too easy and/or boring rather than being impossibly hard. It's the better alternative, but clearly not enough.

Many sorts of emerging behaviour could make some variants easier or harder than intended for some player: for example, increasing enemies could reward the player with extra powerups and/or more score-based bonus lives and bombs over the course of the game (thanks to a good performance in the easiest sections), making the more intense sections easier than with less enemies because of the increased firepower and durability.

We seem to agree completely about allowing the player to tighten the noose in endless modes; on the other hand all four items in your first post are exactly the sort of deep mechanical modification that requires detailed playtesting and pervasive changes to level design, both in endless or level+boss games. I don't think there are good reasons to design 16 modes, most of which bad and/or hard to tell apart, instead of the usual 3 or 4 (or 1...) balanced and understandable ones.

[Drum]

brutal combinatorial explosion of game modes. Some of those modes will be boring, not winnable, etc.: they should be forbidden, at which point you are back to normal selectable modes with a misplaced effort at being orthogonal rather than making every mode well-tuned and (possibly) unique.

Well, the game would be tested with all the boxes checked at once so I don't really see that as an issue. Also, being unwinnable is aok for an endless mode - so long as it's balanced correctly and the difficulty ramps up gradually.

The issue is making all different game modes fun. By "testing with all the boxes checked" I assume you mean that the game is going to be hard, but not unfair or impossible, using the most punishing difficulty settings: a one-size-fits-all design is likely to err on the side of being too easy and/or boring rather than being impossibly hard. It's the better alternative, but clearly not enough.

Many sorts of emerging behaviour could make some variants easier or harder than intended for some player: for example, increasing enemies could reward the player with extra powerups and/or more score-based bonus lives and bombs over the course of the game (thanks to a good performance in the easiest sections), making the more intense sections easier than with less enemies because of the increased firepower and durability.

We seem to agree completely about allowing the player to tighten the noose in endless modes; on the other hand all four items in your first post are exactly the sort of deep mechanical modification that requires detailed playtesting and pervasive changes to level design, both in endless or level+boss games. I don't think there are good reasons to design 16 modes, most of which bad and/or hard to tell apart, instead of the usual 3 or 4 (or 1...) balanced and understandable ones.

I thought hard about what you're saying and I guess I agree somewhat - in terms of balancing, this is a non-trivial operation. But the concept was that the player could balance it to their own playstyle, so if they make a combination that they find boring ... well, they should make a different combination, or pick one of the pre-mades. On the easiest setting, it's basically a practice mode - I can't bring myself to agree that the possibility practice mode will be boring is a problem. With all the boxes checked, the game absolutely will be impossible in the sense that death will be inevitable - and soon - but you'll also be able to rack up a decent score before you are overwhelmed. Score is where the balancing will come in, not in making sure every combination is enjoyable. Even on easier settings the game will be impossible eventually, as with each stage you pass the difficulty will also increase in terms of the types and numbers of enemies that are introduced. How many boxes are checked basically indicates how long the game is likely to last. With all of them checked, a skilled player will be hard-pressed to get even three stages in, whereas easier settings might last as long as an hour before you die. That's the plan, anyway.

[BPzeBanshee]

Kinda like Communism eh? Perfect in theory but in practice has yet to have succeeded.

[Drum]

Communism is terrible in theory!

Also, and I realise I am just being a smartass here, the build-your-own-difficulty system is basically the opposite of communism. But that is neither here nor there.

[BPzeBanshee]

Well you get my point you smartass.

My point is, the key to getting the plan right is obviously going to be tedious to say the least. But I think you know this already.

[Drum]

Hokay, bumping this topic to toss out another idea.

My game is procedurally generated, so I don't really want a chaining system - I thought of some ways to pull it off but all of them are kind of silly.
How do people like the idea of a system that adds the current hit ratio to the value of each kill (or something like that). Does anybody know of a game with a similar system I could crib ideas off? Or anything else you can think of that wouldn't make a procedurally generated game frustrating to play for score?

[Ixmucane2]

Hokay, bumping this topic to toss out another idea.

My game is procedurally generated, so I don't really want a chaining system - I thought of some ways to pull it off but all of them are kind of silly.
How do people like the idea of a system that adds the current hit ratio to the value of each kill (or something like that).

But what you suggest is a chaining system: you still score better if you killed all recent enemies. The ratio of killed enemies to total enemies is a very appropriate skill measure that isn't significantly affected by random gaps in enemy timing.
There can be some variation in two aspects: what ratio to use and how to turn a kill ratio between 0 and 1 into score.

• Enemies can be weighed evenly, or by point value (do you want errors with major enemies to ruin the chain and popcorn enemies to be almost negligible?), or ad-hoc according to how easy to miss they are.
• You can measure since the start of the level (reducing the importance of later enemies) or consider only a recent window: the last N enemies, the enemies from the last T seconds of play (requiring predictable average numbers of enemies), or something fancier like the last P points of nominal enemy value (forgetting faster when enemies are bigger).
• Instead of computing a simple ratio from all enemies in a given window, you can use exponential decay: with an enemy of weight W, 0<=W<=1, the updated ratio r would be r*(1-W) (missed) or r*(1-W)+W (hit). Weights can be uniform, vary by level section, vary by individual enemy, and so on.
• When you hit an enemy with kill ratio r, the adjusted point value could be P+r*Q, with P being the guaranteed minimum score (possibly very small or zero) and Q a secondary score value that adjusts the important of chaining. P and Q can, of course, vary by enemy type.

The interesting issue of such a system is making the player optimize his strategy for something more sophisticated than hitting absolutely everything since the start of the level. Insufficient firepower, forcing a choice of the most valuable targets, might be a partial answer.

[BPzeBanshee]

But what you suggest is a chaining system: you still score better if you killed all recent enemies. The ratio of killed enemies to total enemies is a very appropriate skill measure that isn't significantly affected by random gaps in enemy timing.
There can be some variation in two aspects: what ratio to use and how to turn a kill ratio between 0 and 1 into score.

• Enemies can be weighed evenly, or by point value (do you want errors with major enemies to ruin the chain and popcorn enemies to be almost negligible?), or ad-hoc according to how easy to miss they are.
• You can measure since the start of the level (reducing the importance of later enemies) or consider only a recent window: the last N enemies, the enemies from the last T seconds of play (requiring predictable average numbers of enemies), or something fancier like the last P points of nominal enemy value (forgetting faster when enemies are bigger).
• Instead of computing a simple ratio from all enemies in a given window, you can use exponential decay: with an enemy of weight W, 0<=W<=1, the updated ratio r would be r*(1-W) (missed) or r*(1-W)+W (hit). Weights can be uniform, vary by level section, vary by individual enemy, and so on.
• When you hit an enemy with kill ratio r, the adjusted point value could be P+r*Q, with P being the guaranteed minimum score (possibly very small or zero) and Q a secondary score value that adjusts the important of chaining. P and Q can, of course, vary by enemy type.

The interesting issue of such a system is making the player optimize his strategy for something more sophisticated than hitting absolutely everything since the start of the level. Insufficient firepower, forcing a choice of the most valuable targets, might be a partial answer.

That actually sounds like Raiden III's scoring system in one way - everything that's on the screen starts with a x2.0 bonus which declines based on the enemy (if its a quick little ship it'll go down quickly, whereas a boss would last a while).

[snafusan]

First one I know is kind of goofy but could still be fun. The framecounter is displayed - usually the game runs at 60fps. When you get slowdown from a lot of bullets/enemies onscreen, there is slowdown and the difference between the current framerate and the max framerate is added to the point value of each kill. If the framerate hits zero the game crashes and no score is saved.
Pros: Smartass jab at framerate creeps.
Cons: Possibly gamewrecking if you play for score, may be possible to rig by having a crappy computer.
The game plays out a little like Bangaio in that it's free-roaming and enemies follow you, but enemies will be able to clusterfuck you pretty bad, and there is a fixed maximum of enemies that can spawn per level, which would disinsentivise/disable abuse.

This is mad - but brilliant. I was doing something similar as I'm a big fan of mushihimesama futari and the slowdown during large bullet hell segments really worked well there - I also ran in to performance problems with certain attack patterns that spammed a high number of bullets. So I exerted some control over the speed of the game. But then I'm developing primarily for consoles with a PC release after - platform fragmentation will destroy your mind when you're dealing with a scoring system like this that is based around hardware performance.

As such, I wouldn't recommend using your games graphical performance as a scoring mechanic ever. What you might want to consider - as this sounds like a great idea - if you haven't done so already, try this.

Timestep your game (as you should be doing..) and then use a formula to divide your timestep based on the amount of bullets on screen.

That way, if your bullet (and everything else in the game) moves like so:

void move (float lrTimeStep)
{
mPos += (mDirection * mVelocity) * lrTimeStep;
}

everything else will slow down the same amount and any decrease in framerate becomes irrelevant. For what it's worth though, I did manage to keep the game playable using this technique when the bullet count got over 2k as the slower your game runs, the less jumpy it appears when you're actually framing out. A trained eye will see that you're actually framing out of course, but that doesn't matter - your game is playable.

[Drum]

Hokay, bumping this topic to toss out another idea.

My game is procedurally generated, so I don't really want a chaining system - I thought of some ways to pull it off but all of them are kind of silly.
How do people like the idea of a system that adds the current hit ratio to the value of each kill (or something like that).

But what you suggest is a chaining system: you still score better if you killed all recent enemies. The ratio of killed enemies to total enemies is a very appropriate skill measure that isn't significantly affected by random gaps in enemy timing.
There can be some variation in two aspects: what ratio to use and how to turn a kill ratio between 0 and 1 into score.

• Enemies can be weighed evenly, or by point value (do you want errors with major enemies to ruin the chain and popcorn enemies to be almost negligible?), or ad-hoc according to how easy to miss they are.
• You can measure since the start of the level (reducing the importance of later enemies) or consider only a recent window: the last N enemies, the enemies from the last T seconds of play (requiring predictable average numbers of enemies), or something fancier like the last P points of nominal enemy value (forgetting faster when enemies are bigger).
• Instead of computing a simple ratio from all enemies in a given window, you can use exponential decay: with an enemy of weight W, 0<=W<=1, the updated ratio r would be r*(1-W) (missed) or r*(1-W)+W (hit). Weights can be uniform, vary by level section, vary by individual enemy, and so on.
• When you hit an enemy with kill ratio r, the adjusted point value could be P+r*Q, with P being the guaranteed minimum score (possibly very small or zero) and Q a secondary score value that adjusts the important of chaining. P and Q can, of course, vary by enemy type.

The interesting issue of such a system is making the player optimize his strategy for something more sophisticated than hitting absolutely everything since the start of the level. Insufficient firepower, forcing a choice of the most valuable targets, might be a partial answer.

Thanks a lot for the feedback - it looks like I really screwed up my explanation horribly though, so I should clarify a couple of things: The player won't be docked for failing to shoot an enemy, at least not in the current plan. The game is free-roaming and enemies pursue the player so there won't really be any situations where the player can miss an opportunity for a kill (I guess I could have enemies retreat and self destruct/disappear if they take damage but aren't destroyed, which could be an interesting twist). Probably a better word for me to use instead of hit ratio is 'efficiency'. The player has an auto-targeting beam that will only fail to hit anything if A) there's nothing left to shoot or B) something gets in the way of the target. It's only in those situations that the efficiency rating would be docked. Some enemies are armoured and can't be destroyed by the standard beam, so I guess hitting them with the beam would also count as inefficient.
If you go through a level and only kill one enemy with one shot, you will have a 100% efficiency bonus (but a very low score of course). The player being hit could take away from the efficiency bonus as well - the beam is actually powered by the player's life bar (like Thexder) so that would make sense.
Further, now that I think of it, there are actually opportunities to be extra-efficient: The beam will instantaneously hit the nearest enemy and stream continuously until that enemy is destroyed (though you can manually switch targets while shooting), but any enemies caught in the beam will be captured in it and treated like a node in the beam's path - maybe destroying enemies this way could increase the efficiency ratio or something like that.

[Drum]

First one I know is kind of goofy but could still be fun. The framecounter is displayed - usually the game runs at 60fps. When you get slowdown from a lot of bullets/enemies onscreen, there is slowdown and the difference between the current framerate and the max framerate is added to the point value of each kill. If the framerate hits zero the game crashes and no score is saved.
Pros: Smartass jab at framerate creeps.
Cons: Possibly gamewrecking if you play for score, may be possible to rig by having a crappy computer.
The game plays out a little like Bangaio in that it's free-roaming and enemies follow you, but enemies will be able to clusterfuck you pretty bad, and there is a fixed maximum of enemies that can spawn per level, which would disinsentivise/disable abuse.

This is mad - but brilliant. I was doing something similar as I'm a big fan of mushihimesama futari and the slowdown during large bullet hell segments really worked well there - I also ran in to performance problems with certain attack patterns that spammed a high number of bullets. So I exerted some control over the speed of the game. But then I'm developing primarily for consoles with a PC release after - platform fragmentation will destroy your mind when you're dealing with a scoring system like this that is based around hardware performance.

As such, I wouldn't recommend using your games graphical performance as a scoring mechanic ever. What you might want to consider - as this sounds like a great idea - if you haven't done so already, try this.

Timestep your game (as you should be doing..) and then use a formula to divide your timestep based on the amount of bullets on screen.

That way, if your bullet (and everything else in the game) moves like so:

void move (float lrTimeStep)
{
mPos += (mDirection * mVelocity) * lrTimeStep;
}

everything else will slow down the same amount and any decrease in framerate becomes irrelevant. For what it's worth though, I did manage to keep the game playable using this technique when the bullet count got over 2k as the slower your game runs, the less jumpy it appears when you're actually framing out. A trained eye will see that you're actually framing out of course, but that doesn't matter - your game is playable.

Thankyou, thankyou - this is fantastic. So I would still have the frame rate counter on-screen to show the bonus value, but it wouldn't be showing the true framerate? I was kind of dismissive of artificial-slowdown solutions to the problem before, but when you put it this way I see that something like this is really the only thing that would not totally suck.

[snafusan]

Thankyou, thankyou - this is fantastic. So I would still have the frame rate counter on-screen to show the bonus value, but it wouldn't be showing the true framerate? I was kind of dismissive of artificial-slowdown solutions to the problem before, but when you put it this way I see that something like this is really the only thing that would not totally suck.

Precisely. Though you probably wouldn't want to call it framerate and if possible display it in some sort of arcadey looking gauge - like a thermometer that fills and then explodes when it's game over.

Definately go through and timestep your code. I'm not sure what you're using - I'm writing for XNA at the moment so my method is as follows:

Code: Select all

timeStep = (float)gameTime.ElapsedGameTime.TotalMilliseconds / 1000.0f;
timeStep /= 100;
timeStep *= mGameSpeedPercent;

This then gets passed down to all my other methods to keep everything moving at the same speed, so if we do get a hitch between updates - everything continues to move at the same speed as opposed to suddenly jumping - since its all based on time elapsed and not number of update cycles - like so:

Code: Select all

EnemyObjManager.Update(timeStep);
ProjectileObjManager.Update(timeStep);

and in those they all refer to lrStep.. Sorry if I'm being overly verbose - I'm new here so don't know what peoples approaches are yet


So if you want the game to go slower as there are more bullets and then have the player lose at say 75% of maxbullets (Brainfail: MaxBullets then becomes misleading..) then you could do:

Code: Select all

mrGameSpeedPercent = 100 - ((mnLevelCurrentBullets / mnLevelMaxBullets)*100);
timeStep = mrGameSpeedPercent;
if (mrGameSpeedPercent <= 25) { GameOverDude(); }

I'm dividing and multiplying by 100 for readability - I tend to work in values I'm used to (degrees over radians, percentages over decimals) unless it gets in the way of performance, which in this case it doesn't as it's not inside a loop!

HTH
- Steve