Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game devs explain the tricks involved with letting you pause a game

kotaku.com

Post reply on HN
Print view View original

231–240 of 273 posts

Re: Game devs explain the tricks involved with letting you pause a game

#231

Post by Grimblewald »

mrob wrote: post #63
Krutonium wrote: post #34

Earlier quoted context omitted.

Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar gets it wrong. (GTA V has several framerate dependent bugs)

It's desirable for arcade games, which have fixed hardware including the display. There's no possibility of upgrading for better framerate, and the game can be designed so slowdown is rare or non-existent. Tying the physics to the framerate gives you very low and very consistent input latency with minimum developer effort.

Right, all valid points, but consider the scale of a game like those coming out of rockstar. I'd understand for indie games and arcade games, but a single player rpg that will likely never be seen in arcade settings? Seems odd to me to see it here. Rockstar has the resources to do it properly, one would think, no?

Re: Game devs explain the tricks involved with letting you pause a game

#232

Post by RobRivera »

netcoyote wrote: post #200
RobRivera wrote: post #180

Earlier quoted context omitted.

Omg I love this! I have been finding excuses to do little animation engine features that arent on the critical path of development for the sake of creative self-indulgence. Such features shipped was alpha channel based fading using the fundamental opengl fade parameter (under the hood its a linear interpolation of alpha values over 256, pieced together over a provided pair of timestamps). I tell you what I'll do toda…

While I don't have the original code, it's something along the lines of this: // for each palette entry: pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)

So I was able to create all the bits necessary to introduce the palette change in a similar manner (3x256 changes) on the triggerz and at the moment of truth instead of grey I got a GREEN and PURPLE fadeout (I wasnt sure if you meant rbg or rgb for the ratios so i tried both).

I also tried 128 across the board for grey, and it just made a dull fade which may be the best I can do with my method.

I think it may simply be because rather than have palletes controlled by rgb, I load predrawn sprites using sfml's sprite and texture classes. So the default rgba is 255,255,255,255 - so I have a sidequest to figure out the RIGHT WAY of applying rgb changes to predrawn sprites.

It may very well be a simple matter of "sfml does it differently" or perhaps having grey variants of all sprites and toggling. I feel there has to be a way to accomplish the fade to grey programmatically. Fun little dive tho! I'll have to post an update when I figure it out.

Re: Game devs explain the tricks involved with letting you pause a game

#233

Post by purple-leafy »

vintermann wrote: post #8

One of the things that impressed me in Quake (the first one) was the demo recording system. The system was deterministic enough that it could record your inputs/the game state and just play them back to get a gameplay video. Especially given that Quake had state of the art graphics at the time, and video playback on computers otherwise was a low-res, resource intensive affair at the time, it was way cool. It always s…

Hey I am actually working on a browser game that is fully-deterministic (except for player inputs) and so I can basically replay games entirely. Think like a chess engine game.

I’ve been obsessing over this determinism and replayability for months, to the point where any game played is fully replay-able to the exact same events as the original game. So you can play, then watch a recording and spectate your played games from different actors perspective (enemy perspective etc).

My rendering and game logic are fully decoupled.

I wrote the “engine” for the game from scratch. I think I only use one third party library currently.

Cool to see this discussion

Re: Game devs explain the tricks involved with letting you pause a game

#234

Post by daemin »

dataflow wrote: post #186
Aurornis wrote: post #148

Earlier quoted context omitted.

Paused game does not equal paused process. It means the gameplay clock has paused. The rendering loop continues to run. The GUI is immediate mode and is still rendered. In some games visual effects continue to be rendered. If it’s a networked game the network code will continue to run.

I think the parent comment still ought to stand. Unless you're saying it's literally infeasible for some reason, which I find hard to believe?

A paused game is not like a paused video where there is no processing going on. A paused game still has all the rendering usually going on (unless the developers got time to implement something custom), audio still needs to continue, the only thing actually paused in the game logic and gameplay elements.

Given this the game needs to slow down and lock its frame rate while paused and in menus otherwise it will run at full speed and burn a lot of CPU & GPU time. Though I would say this is not usually an issue because it gets fixed pretty quickly during development.

Now more work can be done by the developers to make the paused state this efficient, but it is all a matter of priorities, and in all cases the developers would rather spend their time making the gameplay better and fixing crash bugs. If the player wants their game to run more efficiently then they should reduce the processing demands by limiting the frame rate and lowering quality settings.

Re: Game devs explain the tricks involved with letting you pause a game

#235

Post by daemin »

DeathArrow wrote: post #3

Not sure if slowing down time is the right approach. The best approach would be using something like if(game_is_paused) return; in the game loops.

A surprising number of systems break down if you pause time by passing a 0 time delta, hence why slowing down time is usually the thing that gets done. The alternative (which you imply with your suggestion) is to pass the many paused states down to every system which further complicates their implementation and is a major source of bugs.

The added fact is that many systems still need to continue running, such as audio, video, and input otherwise the program doesn't appear to respond to input and so isn't in a useable state any more.

Re: Game devs explain the tricks involved with letting you pause a game

#236

Post by JoshTriplett »

Grimblewald wrote: post #231
mrob wrote: post #63

Earlier quoted context omitted.

It's desirable for arcade games, which have fixed hardware including the display. There's no possibility of upgrading for better framerate, and the game can be designed so slowdown is rare or non-existent. Tying the physics to the framerate gives you very low and very consistent input latency with minimum developer effort.

Right, all valid points, but consider the scale of a game like those coming out of rockstar. I'd understand for indie games and arcade games, but a single player rpg that will likely never be seen in arcade settings? Seems odd to me to see it here. Rockstar has the resources to do it properly, one would think, no?

Suppose you don't care as much about replays, and you're willing to use other tricks to "cheat" on multiplayer sync instead (because most AAA titles seem to have multiplayer these days). Suppose, instead, your top priority is visual fidelity and being perceived as having cutting-edge graphics. You want maximum computational effort going into letting the gamers with a top-of-the-line GPU render on their 360FPS monitor. And you want lots of objects and realistic physics.

If you run physics on a global timer, you could run it at a slower rate and try to fake some of those frames (extrapolating intermediate positions of objects), which is complex. Or you could run it at a faster rate, and every frame has real physics updates, and then it's taking time you could be using for graphics or something else that you think sells better. And there are ways around that, too, but they're complicated and your team is busy and they aren't what your engine gives you for free...

Re: Game devs explain the tricks involved with letting you pause a game

#237

Post by ryanisnan »

acomjean wrote: post #205
ryanisnan wrote: post #189

Earlier quoted context omitted.

This is a great idea, but respectfully, if you're going to get traction you need to be the one instigating getting people to talk to you. Have a pitch, have an explicit ask, and be willing to put effort into making it happen. Fantastic idea though, you should do it.

There are a few of these floating around for older games, but the world needs more: Ara technica has a war stories feature on game development. https://arstechnica.com/video/series/war-stories For apple 2 games John Romero did a podcast. It’s decent but he seems to have stopped doing them. https://appletimewarp.libsyn.com/ Or YouTube Ted dabney experience has a lot of interesting interviews with older arcade game des…

Wow, thank you for sharing. If I could upvote your comment twice, I would. I'm going to enjoy this series.

Re: Game devs explain the tricks involved with letting you pause a game

#238

Post by dataflow »

daemin wrote: post #234
dataflow wrote: post #186

Earlier quoted context omitted.

I think the parent comment still ought to stand. Unless you're saying it's literally infeasible for some reason, which I find hard to believe?

A paused game is not like a paused video where there is no processing going on. A paused game still has all the rendering usually going on (unless the developers got time to implement something custom), audio still needs to continue, the only thing actually paused in the game logic and gameplay elements. Given this the game needs to slow down and lock its frame rate while paused and in menus otherwise it will run at…

Yes, I already understood all that.

> unless the developers got time to implement something custom

As I said: the point nevertheless ought to stand.

Re: Game devs explain the tricks involved with letting you pause a game

#239

Post by Folcon »

insraq wrote: post #108

I am recently working on a "realtime with pause" style grand strategy game using my own engine (think Europa Universalis, Crusader King, Hearts of Iron). The trick is to separate the logic simulation from other game loops (rendering, UI, input, sound, etc). So when a player pauses the game, everything else still more or less works. And the logic simulation should be able to take user "command" while being paused. Mos…

Hey, I'm working on a grand strategy game as well based on a fictional setting, would love to chat and compare notes if you're open to it, my email is in my profile

Re: Game devs explain the tricks involved with letting you pause a game

#240

Post by a_e_k »

netcoyote wrote: post #200
RobRivera wrote: post #180

Earlier quoted context omitted.

Omg I love this! I have been finding excuses to do little animation engine features that arent on the critical path of development for the sake of creative self-indulgence. Such features shipped was alpha channel based fading using the fundamental opengl fade parameter (under the hood its a linear interpolation of alpha values over 256, pieced together over a provided pair of timestamps). I tell you what I'll do toda…

While I don't have the original code, it's something along the lines of this: // for each palette entry: pal.r = pal.b = pal.g = (byte) (0.299 * pal.r + 0.587 * pal.b + 0.114 * pal.b)

From my recollection of doing fun palette stuff back in the DOS VGA days, I'm betting it was more like:

    pal.r = pal.g = pal.b = (77 * pal.r + 150 * pal.g + 29 * pal.b) >> 8;
Hardware floating point was rare before the 486 DX and Pentiums. Not to mention that IntegerFP conversion was slow. And division of any kind has always been slow. So you'd see a lot of fixed-point math approximations with power-of-two divisors so that you can shift-right.
Post reply on HN