ship feel: ASDR vs. ASR

[racarate]

i'm at the very early stages of working on 'ship feel' and i have a question:

almost everything i've done with platforming involves an acceleration, deceleration, velocity and a MAX_VELOCITY. the player pressed a button, i fold in acceleration to the current velocity and clamp it off. as far as i can tell this would be -- in synthesizer terms -- an initial attack as we rise to the MAX_VELOCITY, a sustain at the MAX_VELOCITY, and then a release back down to zero movement.

i started thinking about synthesizers though, and they have an extra step, where the value actual goes a little bit higher than the sustain (MAX_VELOCITY) and then drops at a certain rate. in videogame terms this means the ship would exceed MAX_VELOCITY for a split second after moving from a standstill.

does anybody know if this is used in modern shooters? or any other kind of game for that matter.

thanks,
nick

[trap15]

STG should never have any acceleration on player movement. You want precison, not fancy floatiness.

[nasty_wolverine]

STG should never have any acceleration on player movement. You want precison, not fancy floatiness.

In synth terms, 0% attack, 0% decay, 100% sustain, 0% release. So you move when you move and stop when you stop. Precision is more important then trying to simulate real world physics.

[S20-TBL]

Precision is more important than trying to simulate real world physics.

Emphasis mine.

As for examples of inertia-based control: most so-called "Euroshmups" are the ones most guilty of this (several games on Kongregate use it), but there are some arena shooters like Acceleration of Suguri and Senko no Ronde that use it.

Hangeki also uses a variation of inertia and momentum, but according to some devs on here it's done ingeniously. So it's not impossible that your game could have physics, but the end result really needs to be precision in your movements, and more importantly it has to be integral to your core gameplay.

A shmup is basically a precision game with emphasis on precise positioning and dodging. So when we play one, we expect to move at max speed when we move, and fully stop when we stop. most games that try to have some inertia dampening tend to screw up the "positioning and dodging" aspect, so there's hostility whenever movement physics is mentioned.

[Ixmucane2]

To repeat the same advice in a few other ways, the ship doesn't ever start moving as if it's an extended action, it simply goes to a better location as fast as possible. A shooter is not a platformer, movement has a different rhythm and purpose.
Since the player wants to predict what input will yield the desired displacement, exactly and quickly, the relationship between input and movement needs to be as simple as possible: linear to know how long the inputs should be held, without overshooting which would make movement fatally uncontrollable, without velocity fluctuations which would make dodging much harder.
Keep in mind that unlike a platformer there is no second chance: if Mario jumps too high, he risks bouncing back where he started, not putting his head into a laser beam.

[racarate]

wow, thanks for the answers. so not only is the D in ADSR unnecessary but the whole freaking envelope is!

one more question, if you don't mind me asking (i'm eating this up):

it sounds like the predictability and rhythm requirement for STG imply that most people code movement like this:

ship.x += dx;
ship.y += dy;

rather than like this:

ship.x += bigger_dx * dt;
ship.y += bigger_dy *dt;

that is, ASSUMING a constant framerate rather than taking into accout how much time has passed between frames. is that true?

[Udderdude]

If you want to get really fancy you can use analogue movement but nobody takes that seriously.

[S20-TBL]

it sounds like the predictability and rhythm requirement for STG imply that most people code movement like this:

ship.x += dx;
ship.y += dy;

rather than like this:

ship.x += bigger_dx * dt;
ship.y += bigger_dy *dt;

that is, ASSUMING a constant framerate rather than taking into accout how much time has passed between frames. is that true?

Pretty much, yes. Some shmups with speed regulation (Thunderforce, Einhander, most classic Konami shooters with Speed Up items) only bother with flat dx and dy increases themselves in some form or another, rather than adding another interpolating variable into the mix.

Like Udderdude said, you can use analogue movement if you want hat-controlled speed regulation or something, but yes, it's a rarity. Speed regulation is only usually done with single button presses like two of the titles I mentioned above: a one-time flat increase or decrease. That way you don't have to keep track of your own actions as much.

[racarate]

very interesting... so since it's just constant-amount dx/dy per frame, a framerate drop would just give good old-fashioned slowdown instead of your ship jumping half-way across the screen (assuming graphics update and moving-thing update are locked together).

are there any other good readings out there on the nitty gritty of ship feel? or is it just so simple (constant dx/dy) that there's not much to write about?



-nick

[nasty_wolverine]

very interesting... so since it's just constant-amount dx/dy per frame, a framerate drop would just give good old-fashioned slowdown instead of your ship jumping half-way across the screen (assuming graphics update and moving-thing update are locked together).

Yes, framerate drop equals slowdown instead of jumps. graphics and physics dont have to be locked together. graphics can run at its own speed while physics runs at a constant rate. with modern hardware that can easily handle shmups, you will have to manually introduce slowdown. but thats not dropping frames, but rather throttling the physics update rate. something like here http://gafferongames.com/game-physics/f ... -timestep/ but without integration. If you want i can post how my mainloop runs.

are there any other good readings out there on the nitty gritty of ship feel? or is it just so simple (constant dx/dy) that there's not much to write about?

it is that simple. keep adjusting dx/dy (both are should be equal) till you are satisfied. also when moving diagonals you may want to make sure the ship travels unit distance. Just multiply with root over 2 when moving diagonals. or keep it oldschool where you move faster on the diagonals.

[racarate]

that's cool, have to try that sqrt2 diagonal trick! i always assumed that was only an issue in the hex/square strategy games.

i'd love to check out your loop. just to make sure i understand what you wrote, are you suggesting that instead of letting a failure to hit the 16.6ms budget cause a slowdown you script a 'slowdown' event? that's awesome.


-nick

[nasty_wolverine]

just to make sure i understand what you wrote, are you suggesting that instead of letting a failure to hit the 16.6ms budget cause a slowdown you script a 'slowdown' event? that's awesome.

no, you cause manual slowdown when there are too many bullets on screen to give the player a chance. watch some cave game replays to know what i am talking about. mushihimesama would be a good example.

i ll post the loop once i get back home.

[racarate]

sorry one more question!

if movement/slowdown is very all-on/all-off and frame-based rather than time-based... does that imply the auto-fire system is keyed to frames as well?

in other words, i guess the rate-of-fire would need to be constrained to (frameNum % fireRate) if it's to keep working as intended during manually-induced slowdowns. is that correct?


-nick

[nasty_wolverine]

sorry one more question!

if movement/slowdown is very all-on/all-off and frame-based rather than time-based... does that imply the auto-fire system is keyed to frames as well?

in other words, i guess the rate-of-fire would need to be constrained to (frameNum % fireRate) if it's to keep working as intended during manually-induced slowdowns. is that correct?

-nick

Modern shmups are deterministic. Atleast, any shmup that is to be played for score has to be deterministic. Best way to make things deterministic is to tie things down to frames rather than time. This will save you a lot of headache later, like when implementing a replay system.

autofire system will probably be implemented something like, fire every 2nd or 5th frame. Usually this will be a counter, that when reaches a certain value in frames triggers a bullet and gets reset, which is incremented each update.

But obviously there is no hard and fast rule here. you can do whatever you like, as long as there is no rng madness or doing the same things at different times produces different results.

[racarate]

oh wow, the rng gun sounds like the most unsatisfying item of all time!

that all makes sense. i guess if you are making these games for non-deterministic hardware (where frames can drop because of other processes) you just have to accept that the game will have both manually-induced frame-based slowdown and for-real frame-based slowdown.

[nasty_wolverine]

you just have to accept that the game will have both manually-induced frame-based slowdown and for-real frame-based slowdown.

not necessarily, shmups on modern hardware can probably run at 200% speed or something. they not really CPU taxing. for-real slowdown on shmups hardly happen. and induced slowdown is a design choice.

[racarate]

true, but iOS is notoriously shitty with stealing your cycles (especially if the player has 'notifications' enabled)

thanks for all the tips by the way, my quest for the D in ADSR has resulted in a mild STG fever instead

[nasty_wolverine]

Code: Select all

        accumulator = 0;
        deltaIndex = 0;
        deltaTime[0] = 17.0;
        deltaTime[1] = 16.0;
        deltaTime[2] = 17.0;

void  CstateSystem::runnosleep()
{
    int loop = 0;
    timer_->startTimer();

    ////////UPDATE BLOCK/////////
	while(accumulator >= deltaTime[1])
	{
		//16.6667 = 1000 ms / 60 framepersecond;
		//approx 16ms per frame, 62 FPS;
		//Update loop runs at 62 FPS
		accumulator -= deltaTime[1];
			if(loop < 1)  //MAX 1 update per pass
			{
				flushStack();
				inputSystem_.update();
				hashSystem_.flush();
				gameManager_->getTop()->hash();
				gameManager_->getTop()->collide();
				gameManager_->getTop()->update();				
			}
		loop++;
	}

    ////////RENDER BLOCK////////
    renderMode(OFFSCREEN);
    //TODO: add gamestack camera switch here
    gameManager_->getTop()->render();
    gameManager_->getTop()->composite();
    renderMode(ONSCREEN);
    finalizeRender();

    if(!displaySystem_.isvsync() && throttle_)
    {
        glFinish();
        timer_->delaySleepZero(deltaTime[deltaIndex] - timer_->getPassed());
        if(++deltaIndex > 2) deltaIndex = 0;
    }

    displaySystem_.swap_buffers();
    glFlush();

    accumulator += timer_->endTimer();
}

This works for me. Hope it helps.