How do I design a game from scratch? A primer on core loops • Hacker News Board

Re: How do I design a game from scratch? A primer on core loops

#41

Post by jfkebwjsbx » Sat, Jul 18, 2020, 6:52 PM UTC

mojuba wrote: post #23

jfkebwjsbx wrote: post #21

Earlier quoted context omitted.

That doesn't work as well as you think it does because entities cannot think on their own. They need to refer to global shared state all the time.

In low level audio you have something similar: there's a thread that pulls audio data all the time and it can't stop; at the same time you have potentially lots of things happening in other threads, including the UI one. You can always find ways of minimizing the synchronization overhead by e.g. having a single fast entry point to any changes that happened since the last cycle. With audio you basically end up passing…

Audio is a very different problem that is typically about a chain of streaming buffers. The thread pulling audio data (and all the others processing it) is independent from the UI etc., that is not an issue.

Copying and passing immutable data around is not always fast enough and definitely not trivial to merge the results back.

In summary, it is a hard problem with no general solution. If you could solve it, then you have solved multithreading design for any problem.

Re: How do I design a game from scratch? A primer on core loops

#42

Post by jfkebwjsbx » Sat, Jul 18, 2020, 6:54 PM UTC

kungtotte wrote: post #30

jfkebwjsbx wrote: post #21

Earlier quoted context omitted.

That doesn't work as well as you think it does because entities cannot think on their own. They need to refer to global shared state all the time.

John Carmack has some ideas on how to use immutable copies of the game state and functional programming concepts to create something that's easily parallelized. I saw it in an old QuakeCon keynote: https://youtu.be/Uooh0Y9fC_M

Duplicating state has always been an approach for multithreading, but the problem is that it is not always fast enough and merging back can be hard.

There is no silver bullet. There are decades of academic research and engineering on this and we have yet to reach a good answer.

Re: How do I design a game from scratch? A primer on core loops

#43

Post by jholman » Sat, Jul 18, 2020, 10:11 PM UTC

sunpazed wrote: post #3

I really love this talk by Mary Rose Cook — she illustrates step-by-step how to code a game loop from scratch in 30 minutes. https://youtu.be/hbKN-9o5_Z0

panopticon is correct that this talk is sort of off-topic, because it's about game-dev gameloops, not game-design gameloops, which are not the same thing at all.

And rishav_sharan is correct that it's nonetheless lovely, so thank you for linking it.

It's interesting that, being from 2014, it uses a lot of patterns that would be completely imprudent (though still possible) in modern post-2015 Javascript, so on a line-by-line basis more than half the lines are not how I would recommend doing this today, while the approach is still totally perfect.

Hard to believe, though, that that video has so few views/likes/comments, because she really nails it.

Re: How do I design a game from scratch? A primer on core loops

#44

Post by Kiro » Sat, Jul 18, 2020, 10:35 PM UTC

mojuba wrote: post #40

Kiro wrote: post #33

Earlier quoted context omitted.

I'm curious why you presume thread spawning is needed.

Two reasons like I said elsewhere: (1) using multi-core architecture more efficiently and (2) eliminate state machines and use functional style instead, which is possible when you have threads (green, pseudo, OS threads, whatever) each with an execution stack. Functional code is more robust and is easier to write and maintain too.

Yeah, ok. People are not doing that.

When multicore is utilized it's normally in the line of https://unity.com/dots

Re: How do I design a game from scratch? A primer on core loops

#45

Post by mojuba » Sat, Jul 18, 2020, 11:26 PM UTC

Kiro wrote: post #44

mojuba wrote: post #40

Earlier quoted context omitted.

Two reasons like I said elsewhere: (1) using multi-core architecture more efficiently and (2) eliminate state machines and use functional style instead, which is possible when you have threads (green, pseudo, OS threads, whatever) each with an execution stack. Functional code is more robust and is easier to write and maintain too.

Yeah, ok. People are not doing that. When multicore is utilized it's normally in the line of https://unity.com/dots

DOTS is exactly what I said, as a matter of fact.