Faster walk speed

[ArtimusBena]

I'm interested in speeding up the 'action' of my game without changing FPS. Is there a way to do that?

[TMC]

Wow, didn't dream of seeing you work on an OHR game again!

Increasing the walk speed is as simple as simple as using the "set hero speed" command...

Code: Select all

plotscript, walk speed 5, begin
  set hero speed(me, 5)
end

I never realised before that changing the leader's walk speed stays in effect even if you add/remove/swap heroes; the speed isn't actually set on the hero, but applies to whoever is in the leader position.
So you only need to run this script as the newgame and loadgame script.

Unfortunately the only valid speeds are 1,2,4,5,10,20. Something I really need to fix, but it's going to be tricky.

Come to think of it, changing the party walk speed is so common that I should just make it an option in Custom.

[ArtimusBena]

Awesome. I'm going to have to re-familiarize myself with OHR customization, but thanks for the tip!

It's probably a feature that will be rarely requested, but might be basic enough to put somewhere

[TMC]

Well it's a glaring omission that you can change NPC speeds but not the hero speed, and now that you can change the FPS it needs to be customisable. That's also why I have to allow a broader range of walk speeds. Even speed 1 is quite fast at 60fps.
Changing the speed during the game (e.g. when you press a Run key) is probably something that should just be scripted, though.

[ArtimusBena]

Run speed! That is a great idea.

In my case, that would drastically improve gameplay dynamics. If, say, you were more likely to get 'caught' because running makes more noise.

Also, games like Chrono Trigger and Pokemon vs. old Final Fantasy show how that tiny feature affects enjoyment. (Pokemon made it interesting by giving you a bike at some point).

[TMC]

Yes, running is always useful in RPGs (especially those innumerable games with outsize maps), and especially interesting if it has implications for other things too! I wish more OHR games had a run key (or the way Axe Cop does it, where you start to run after walking for a while)

[Pepsi Ranger]

Or you could implement the backwards feature that Stardew Valley employs, which is to move in a perpetual state of running until you hit the "walk" key. I never understood why anyone would use that key, but it's there.

Alternatively, analog joystick movement, similar to sandbox 3D movement where you speed up the farther you push the stick, revolutionized in Super Mario 64, would be an interesting feature to include while controller support is being worked on.

I think custom speed would be easier to adjust if we had an option to select pixel-based movement as an alternative to tile movement (in other words, we could select a game to default to one or the other, while allowing scripts to override the function in certain cases where precision is important).

At any rate, I'll be in the same position soon. Once I raise the FPS of my game to 30, I'll want to reduce the hero's move speed by half to keep the original pacing while making ticks a bit faster.

[charbile]

Why not go the full 60, Pepsi? 60 so buttery smooth.

Ultimate level 99 technique: don't use walkabouts or maps, only menus. Fastest possible speed. Faster than airships.

[ArtimusBena]

Menus. Menus all the way down...

[TMC]

Using gamepad joysticks to control movement speed/direction is a fun idea, but it's too bad that other players miss out. Well, I guess a run key and 8 directions is a passable substitute.

Yes, if the engine adjusted all the animation and movement speeds so everything's the same there wouldn't be much point using 30 instead of 60. (Well, I guess you still have to deal with scripts which use waits and timers, and 30 might screw things up less.)

[charbile]

you can always skip ahead and remove frame rate altogether, just unlock it to something extreme like 9999.

yeah, that's right. I'm talking DELTA TIME. save Pepsi Ranger from having to update his game a four hundredth time -and- open up the door for online multiplayer, and game timing independent of frame rate. can you imagine the fun the Q&A forum would become for you

[Pepsi Ranger]

I'm down with that. ;)

[TMC]

I've considered it, if only because the monitor refresh rate isn't always 60Hz, so it's poor to make that assumption. I've also manually scripted a game that way (it did some heavy rendering that meant it didn't consistently hit 60Hz).
But it would be a big complication for many things, and would only be an advanced feature anyway, because you'd have to know what you're doing when writing scripts containing waits.

And anyway, when I unlock fps (--runfast cmdline arg) I couldn't hit 9999. But... drawing 3000 frames per second and only displaying 60 is clearly not optimal.

[Pepsi Ranger]

But it would be a big complication for many things, and would only be an advanced feature anyway, because you'd have to know what you're doing when writing scripts containing waits.

Just to quickly address this point: It's actually pretty easy to adjust script waits to match FPS if you lock in a scripting pattern that does away with hardcoded waits. I've actually scripted a future-proofing element to Entrepreneur that makes adjusting waits to FPS as easy as changing the value of a single function in the starting script:

Code: Select all

set frames per second speed (18)

In the above example, I've written a shell function that stores the current default FPS, which I still have to set manually in CUSTOM (hoping for scripting options soon).

This function is merely the "memorable name" version of setting a variable:

Code: Select all

script, set frames per second speed, spd, begin
fpstimer := spd
end

By using this variable for timers in place of the hardcoded value 18 ticks per second, I can maintain my count of seconds and minutes globally. The following example would run a clock for five minutes no matter the game's frame rate:

Code: Select all

set timer (0, 300, fpstimer, @work clock, 6)

Even if I changed the FPS to 30, as long as I write "set frames per second speed (30)" in the launching script, I can still keep timers running at the same speed.

That way, if scripting FPS is ever possible, which would be great because then we could give players the option to set their own preferred speeds, then control over time elements won't be lost by the changing of the frame rate.

Anyway, I can also harmonize waits regardless of FPS with the following script:

Code: Select all

script,wait equivalent,tick,begin
wait ((tick*fpstimer)/18)
end

wait equivalent (3)

So, in this example, if I want my "wait (3)" at 18 FPS to play at a wait equivalent of three ticks in a 30 FPS game, the script will automatically convert the wait time to five to match the time a wait of three would normally give me.

So, yeah, there are simple ways to keep up with FPS changes on the fly. I'd actually recommend that most people update their waits and timers now to accommodate for any potential shifts in FPS.

Though, it would be really cool if we could simply pass an argument that measures the computer's clock speed and prints the FPS to the controlling function in real time. Then we'd never have to touch this function again, unless we deliberately wanted to slow something down.

[TMC]

Yes, you could use a replacement for 'wait' that counts in seconds instead of frames - I'm going to add a command equivalent to your script as build in..

However, your scripts don't allow what Charbile was talking about, which is adapting to a variable framerate, which eg. might drop from 60 to 45 for a few seconds because something program is running in the background

But if you use a "wait" replacement that counts in actual-seconds-elapsed instead of ticks, that doesn't change the fact that all your scripts and everything else become non-deterministic. So you need to know what you're doing, because you can't just run your scripts once to test them, you'd need to test them under various and also variable framerates, and constantly worry about the framerate as you write them so that you get them correct the first time, because you'll never be able to fully test them.

So I think that for most games (not action games) it's actually preferable that the game logic slows down when the framerate drops, instead of doing more per frame to compensate. That way the game plays deterministically and doesn't get harder/easier as you use projectives. In other words, the "wait equivalent" script should work the way you wrote it, not actual-seconds-elapsed.

Oh, and you can get the framerate set in Custom like this:

Code: Select all

script, target frame rate, begin
  return (1000 / read general(198))
  if (read general(198) == 16) then (return(60))  #Special cased to mean 60fps
end