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

Game Loop

gameprogrammingpatterns.com

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Game Loop

#21

Post by dfischer »

allenu wrote: post #12

After playing around with making a simple, somewhat function programming-style engine [1], I came to the conclusion (from other people's work) that the game loop is really just iterating on a pure function call that gives you the next world state given the previous world state: next_world_state = UpdateWorld(inputs, previous_world_state) Where inputs is all external inputs (user inputs and "time"). How the inputs is…

Just read something similar with Urbit: https://urbit.org/docs/introduction/technical-overview/

Taking that concept to an operating system essentially.

> Your urbit is a deterministic computer in the sense that its state is a pure function of its event history. Every event in this history is a transaction; your urbit's state is effectively an ACID database.

> Because each urbit is deterministic we can describe its role appropriately in purely functional terms: it maps an input event and the old urbit state to a list of output actions and the subsequent state. This is the Urbit transition function.

Re: Game Loop

#22

Post by Nition »

khaledh wrote: post #11

While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if y…

Game Programming Patterns actually does that in places! Check out the State chapter for instance.[1]

[1] http://gameprogrammingpatterns.com/state.html

Re: Game Loop

#23

Post by koonsolo »

khaledh wrote: post #11

While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if y…

I also experienced that the most intuitive way of learning things, is to follow the natural evolution that led to it.

For example, you can teach people programming with higher level languages. But if your goal is to fully understand programming (as a professional programmer), you can start with the oldest discoveries and work your way into more recent years. That way you are able to grasp the full scope, know benefits and drawbacks, etc. You are also less likely to make the same mistakes of the past.

Re: Game Loop

#24

Post by koonsolo »

vectorrain wrote: post #18
koonsolo wrote: post #16

Earlier quoted context omitted.

What is the part that is not clear?

The sconed part "Game Speed dependent on Variable FPS". I'm confused about the parameter of function "update_game()". From the code, I think the time length of "curr_frame_tick - prev_frame_tick" would increase at each timestep beacause of function "display_game()".

display_game() doesn't change any of these values.

(curr_frame_tick - prev_frame_tick) is the delta time of each loop. So this value is the time it took to do the previous loop.

It doesn't increase each timestep because prev_game_tick is recalculated each step.

Step1 (initial step):

- prev_frame_tick = 0

- curr_frame_tick = 0

- delta = 0

Step2:

- prev_frame_tick = 0

- curr_frame_tick = 200

- delta = 200

Step3:

- prev_frame_tick = 200

- curr_frame_tick = 356

- delta = 156

...

Re: Game Loop

#25

Post by cjsawyer »

vectorrain wrote: post #18
koonsolo wrote: post #16

Earlier quoted context omitted.

What is the part that is not clear?

The sconed part "Game Speed dependent on Variable FPS". I'm confused about the parameter of function "update_game()". From the code, I think the time length of "curr_frame_tick - prev_frame_tick" would increase at each timestep beacause of function "display_game()".

Every loop, prev_frame_tick is assigned the old value of curr_frame_tick before curr_frame_tick is updated. That means the value of their difference is the time in ticks it took for the last loop to execute. That difference is used to scale things like physics.

As an example, if we want to move something on screen at a constant rate in pixels per second, the number of pixels to move per update (ie frame) at 60 FPS is half as far as when updating at 30 FPS. The result is that the position at any time is the same regardless of how quickly the computer ran the simulation.

Re: Game Loop

#26

Post by mrob »

One example of a problem with variable frame rate physics simulation was Quake 3, which allowed you to make otherwise impossible jumps if your frame rate was 125fps. This value exploited the rounding errors in the jump height calculation to get extra jump height. Some custom maps even assumed you'd be running at 125fps and would be unplayable if your hardware couldn't keep up.

Demonstration and explanation here: https://www.youtube.com/watch?v=P13KmJBNn1c

OpenArena added an option for fixed framerate physics, and an option to disable the rounding.

Re: Game Loop

#27

Post by hazz99 »

khaledh wrote: post #11

While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if y…

Joe Armstrong does this in Programming Erlang: Software for a Concurrent World. Its extremely effective, and pulled me through each chapter by forcing me to continually look at how the solution could be improved.

Re: Game Loop

#28

Post by LoSboccacc »

obl wrote: post #5

Extrapolating up to one physics frame is still not a good solution, it will be noticeable. For example a falling object will clip in the ground for tens of ms of displacement which is definitely visually significant. A better solution is to either only interpolate and live with the additional frames of input latency (fine for a lot of games) or resimulate the next physics frame with the new player input, and live wit…

well this is your basic game loop, and serves as an introduction to the topic. there are lot of things that were just skimped, for example you'd still need an event loop to capture input and store them for the process input method, or you risk losing fast key presses.

Re: Game Loop

#29

Post by vectorrain »

koonsolo wrote: post #24
vectorrain wrote: post #18

Earlier quoted context omitted.

The sconed part "Game Speed dependent on Variable FPS". I'm confused about the parameter of function "update_game()". From the code, I think the time length of "curr_frame_tick - prev_frame_tick" would increase at each timestep beacause of function "display_game()".

display_game() doesn't change any of these values. (curr_frame_tick - prev_frame_tick) is the delta time of each loop. So this value is the time it took to do the previous loop. It doesn't increase each timestep because prev_game_tick is recalculated each step. Step1 (initial step): - prev_frame_tick = 0 - curr_frame_tick = 0 - delta = 0 Step2: - prev_frame_tick = 0 - curr_frame_tick = 200 - delta = 200 Step3: - prev…

Fair enough. I think I didn't understand the difference between game time and real time before. I though the running time of "display_game()" was the game time (curr_frame_tick - prev_frame_tick). Thanks a lot for your detailed explanation.

Re: Game Loop

#30

Post by bartread »

h0l0cube wrote: post #10

Space Invaders exploited the render-dependent timing of it's game loop to increase the speed of movement as the kill count increased. https://en.wikipedia.org/wiki/Space_Invaders#cite_ref-RG-3_1...

Yeah: from careful observation Space Invaders seems to move one alien every frame, hence the fewer aliens the faster it gets. I started playing around building my own version, but it's never got beyond the prototype phase: https://arcade.ly/games/space-invaders. I'd love to be able to use lack of time as an excuse but it's really lack of motivation.
Post reply on HN