Multithreading

[Turbo]

Hello,

I've read in a few posts that when certain things get overpopulated on screen that the game comes to a crawl. (eg fire or map size)

Have you considered multithreading support? I know Introversion did something similar for all their pathing which made their game go from 70 prisoners to over 250 and totally playable.

[GC13]

I'd hope that multithreading was something taken into consideration sooner rather than later, though I am operating under the assumption that it's as (or more) difficult to add multithreading to something you've written already than it is to simply start out with it. Even the weakest computers have two cores (3.87% of people on Steam do not), and a significant chunk have four or more (just under half), and multicore is only getting more prevalent.

[golgy]

A common saying about threading:

A programmer had a problem. He thought, "I know, I'll use threads." Now the programmer has two problems.

Adding multithreading is not trivial - it's not just a matter of saying "oh hey, just use more than one core". It's a matter of having to ensure that all the functions perform thread safe actions on shared memory and designing the internals so that deadlocks/races cant occur.

That being said - I'm sure if its required, it'll be done and/or considered already. Though i'm curious as to whether or not game engines these days can offload graphics stuff onto a dedicated core if one is available/free and branch to allow AI/other computation to occur freely on another.

[Turbo]

No need to be rude golgy.

If you have played PA one almost entire update was dedicated to it and it took a game's playability way up.

[golgy]

No need to be rude golgy.

If you have played PA one almost entire update was dedicated to it and it took a game's playability way up.

My apologies if you thought I was trying to be rude - far from it! The quote is meant to be humorous.

Just stating that there's hurdles to implementing multithreading, and it's not just a simple matter of throwing more available CPU cores at the problem. Actor based systems always suffer from constraints on compute time; actor-based systems ( PA is a good example of this, hundreds of actors ) can lend themselves quite nicely to mutithreading, because you need to do all kinds of interactions between them all at once. As stated by GC13 - it's difficult to retroactively shoehorn it in - it requires a bit of foresight and changes some of the internal design a bit.

As i said though - I'm sure if it's a need, it'll be done if it hasn't already been. I wouldn't particularly be concerned about asking for it, however.

[Hypolite]

RimWorld is based on Unity, which is supposed to do all the heavy-lifting. That makes a programmer life easier building the first stages of the game, but has some limitations, notably technical: if Unity is hardwired to use only one core, Tynan would have to rewrite most or all of his code using a different framework/language to make use of multithreading.

[golgy]

RimWorld is based on Unity, which is supposed to do all the heavy-lifting. That makes a programmer life easier building the first stages of the game, but has some limitations, notably technical: if Unity is hardwired to use only one core, Tynan would have to rewrite most or all of his code using a different framework/language to make use of multithreading.

Ah - I've got extensive experience in HPC, but i'm not a game developer. So i know enough to theorycraft my existing knowledge into gaming Thanks for the clarification, though!

[Turbo]

My apologies if you thought I was trying to be rude - far from it! The quote is meant to be humorous.

In that case, apologies on my behalf too! 

[Ford_Prefect]

Multithreading the game logic is possible in C# (the language you use in unity).

[Tynan]

I could be multithreading the game. I'm just not yet because I'm not at the stage where I'm trying to optimize that hard. I'll probably do it eventually.

[Technical Ben]

You definatly know more than I could ever do. But I remember many saying multithreading later is a pain. But I guess it depends on programming environment and what type of system. I guess offloading graphics/audio to extra threads is easier than say offloading task priorities of settlers.

[Ford_Prefect]

Since the settlers can walk through each other, an easy and large performance enhancement would be the settler's ai/pathfinding.  Especially since the pathfinding is being recalculated every-time the map changes (changing that behavior would greatly enhance speed, but is tricky to implement).

Threading sound isn't too hard, but has doesn't have much performance impact.

Having the game logic in a separate thread from the rendering (so that why the game is rendering the last frame it can figure out what needs to happen in the next), can also boost performance significantly.

[linkxsc]

Heh multithreading. Lets just say that was the single worst project I had to do in my "intermediate programming" class in college. Intermediate my ass.

Though surprisingly, if you're ever in the world of custom electronics, I often find that throwing a extra core in can solve a lot of problems. (especially since most processors for electronics, at least the cheap ones are only 8bit, and they have little seizures every time you tell them to do floating point math. Double precision, don't even bother on a 8bit 16MHz chip)

[Ravine]

One possible solution (depending on how the AI and gameplay subsystems are implemented) could be using Coroutines to slice heavy computations (i'm thinking end-game here, with multiple colonists and raiders and plants and muffalos). I have no idea how the systems currently scales toward end game (my biggest game was around day 30-40, and it was a Friendy AI, so not a lot of baddies to fight against). More infos on coroutines can be found here http://www.altdevblogaday.com/2011/07/07/unity3d-coroutines-in-detail/ and ofc in Unity3d's doc (quick googling : http://docs.unity3d.com/Documentation/Manual/Coroutines.html , http://unity3d.com/learn/tutorials/modules/intermediate/scripting/coroutines and http://unitygems.com/coroutines/ ).

Another easy optim could be implementing some sort of LOD on effects based on camera's distance to the board (all those plants probably dont need to move when you're zoomed out, right ?), but i'm out of subject here. I'm going to create a .txt and list all tech-related suggestion i can come up with. (and i'm going to present myself in the appropriate subject right away)

[Galileus]

Another easy optim could be implementing some sort of LOD on effects based on camera's distance to the board (all those plants probably dont need to move when you're zoomed out, right ?), but i'm out of subject here. I'm going to create a .txt and list all tech-related suggestion i can come up with. (and i'm going to present myself in the appropriate subject right away)

That could lower the stress on drawing engine, and this is not a problem. No matter how much you optimize secondary elements, the game won't speed up if you won't deal with the bottleneck. And in this case, the bottleneck would be CPU.