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

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

teamavocado.co

Post reply on HN
Print view View original

21–30 of 45 posts

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

#21

Post by jfkebwjsbx »

mojuba wrote: post #17
popotamonga wrote: post #16

Earlier quoted context omitted.

I did some big game dev for some years 10 years ago. The loop was (there was only 1 loop): delta_t = time between last frame and now fetch input status for each entity: entity.think(delta_t) (for example, if a monster is in the state of moving towards me, it will move speed*delta_t units) Render() Never saw loops with real threads, that looks like asking for trouble. If it was a multiplayer game then the think part w…

Interesting. Something suggests a loop that does entities.forEach { $0.think(delta_t) } is essentially cooperative multitasking, whose efficiency is questionable in general and especially on multicore hardware - but I don't know about games. Let alone programming think(delta_t) adds complexity and introduces more states within each entity, compared to real threads with their own stacks.

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.

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

#23

Post by mojuba »

jfkebwjsbx wrote: post #21
mojuba wrote: post #17

Earlier quoted context omitted.

Interesting. Something suggests a loop that does entities.forEach { $0.think(delta_t) } is essentially cooperative multitasking, whose efficiency is questionable in general and especially on multicore hardware - but I don't know about games. Let alone programming think(delta_t) adds complexity and introduces more states within each entity, compared to real threads with their own stacks.

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 immutable blocks of data with minimal synchronization. So should be possible to do in games, too.

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

#24

Post by meheleventyone »

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…

The evolution has been from single threaded engines to different core elements being on seperate threads (e.g. renderer and io) to task based scheduling.

Typically though the updating the game itself is a relatively small part of the frame time and can be reasonably tricky to get real gains through parallelisation.

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

#25

Post by dan00 »

mojuba wrote: post #19
popotamonga wrote: post #18

Earlier quoted context omitted.

Also you can check games like quake, doom etc which have opened their source, they are all done like that.

Doom and Quake were created in the single-core era. I was just wondering if modern game design is different.

Here is a talk from the developer Naughty Dog - making big games on the Playstation - about the parallelization of their engine: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug....

Having a system thread for every entity in a game doesn’t scale. Also having to synchronise the threads of entities by hand would be quite a nightmare.

It scales a lot better to have a thread pool, with a thread for each core, and then running lightweight jobs on them. So pretty much the same idea like e.g. the goroutines in Go or the green threads of Erlang.

Having such a job system you also have a lot less hassle with thread synchronisations. I’m working on an interactive 3d application and the job system we’ve have works like a charm for parallelization.

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

#26

Post by mojuba »

dan00 wrote: post #25
mojuba wrote: post #19

Earlier quoted context omitted.

Doom and Quake were created in the single-core era. I was just wondering if modern game design is different.

Here is a talk from the developer Naughty Dog - making big games on the Playstation - about the parallelization of their engine: https://www.gdcvault.com/play/1022186/Parallelizing-the-Naug... . Having a system thread for every entity in a game doesn’t scale. Also having to synchronise the threads of entities by hand would be quite a nightmare. It scales a lot better to have a thread pool, with a thread for each core…

Thanks, that's very interesting.

The benefit of threads - green or not - is also that you can maintain the state in the stack and benefit from functional style programming, which is generally more robust and easier to write compared to state machines.

Parallelism has many forms and from my experience you can always find ways of minimizing synchronization in particular tasks. For example, you can sometimes replace a whole queue with a single atomic pointer when you know messages override previous ones semantically, i.e. the consumer is only ever interested in the most recent one.

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

#29

Post by mysterydip »

If you're interested on a more visual/animated explanation for this and other gamedev topics, I highly recommend Yahtzee's Dev Diary series (starting with episode 1 and going forward chronologically): https://www.escapistmagazine.com/v2/category/yahtzees-dev-di... He sets out to make 12 games in 12 months, so he experiments with many different themes and mechanics, while showing what makes a game a game.

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

#30

Post by kungtotte »

jfkebwjsbx wrote: post #21
mojuba wrote: post #17

Earlier quoted context omitted.

Interesting. Something suggests a loop that does entities.forEach { $0.think(delta_t) } is essentially cooperative multitasking, whose efficiency is questionable in general and especially on multicore hardware - but I don't know about games. Let alone programming think(delta_t) adds complexity and introduces more states within each entity, compared to real threads with their own stacks.

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
Post reply on HN