Will project eternity have multi-core support?

[nipsen]

 

Probably will have to be coming along with less d&d dice-roll abstractions in rpgs, at least.

 

Just for the record, I do not see this is an inevitable consequences of animination improvement -- and, more to the point, I don't see this as a good thing.  If you see this as progress, then I'd suggest that you should be looking at a different company.

 

well.. imo... maybe it's a bit easy to let the game-mechanics mimic d&d dice-rolls. Which is an abstraction in the first place. Of people moving around seamlessly. Not of people running from square to square block, having their spells or actions interrupted by artificial constraints. 

 

I mean, there's no reason to remove turn-based gameplay, or letting actions play in time-slots. But maybe it shouldn't be a goal in itself to create a d&d paper ruleset, just with better graphics. I don't know.. but whenever I played rpgs, we always bent the ruleset a little bit. And what I imagined in my head wasn't characters running around actually obeying the ruleset in the first place.

[MReed]

You raise two separate issues here:

 

1) "Games should attempt to implement the rules of P&P gaming systems or rules that could be implemented in P&P".  This I don't see as particularly desirable, as there are abstractions required for P&P that can be eliminated in a CRPG.  One obvious item is range increments -- in P&P, ranged weapons "to hit" chance is generally modified by whether or not the range to the target is "short", "medium", "long", or "extreme".  In a CRPG, however, the modifiers should be applied at a much finer grain (say, every foot) and may take into account factors that aren't feasible in P&P (elevation, determining whether or not partial cover applies between the shooter and the target, and so forth).

2) "Games should attempt to eliminate abstractions that would require die rolls altogether, replacing them with realistic physics and collision detection."  This is what I believe you were proposing, and I disagree strongly that this represent "progress".  The idea here is that "If the player shoots a bow, they should indicate what direction they shoot in and how far back the pull the bow.  The result should be determine by simulation the effects of physics to the arrow (air resistance and gravity being the two most obvious) and collision detection will determine if the arrow does any damage.

 

For an example of the effects of the #2 philosophy, compare and contrast the mechanics of DA:O v. DA2 or ME1 -> ME2.

 

#2 inevitably has the result of reducing the impact of character skills and replacing it with player skills -- whether or not the arrow hits depends on how accurately the player led the target rather than reflecting the skills of your character.  This renders the concept of character skills largely irrelevant, and game play rapidly degenerates into standard action-based shooter / brawler type of gameplay.  It also tends to eliminate active pause gameplay (as it makes it to easy -- Fallout 3 ran into this problem, based on what I've heard) and party-based gameplay (the value of multiple party members is dramatically reduced if their abilities are primarily determined by player skill).

 

TL;DR: Removing abstractions that exist in P&P to save time can be a good thing -- removing abstractions that allow characters skill to be the primary factor in determining the results of individual actions is not a good thing.

[ravenshrike]

AMD's "top of the line" processors tend to be 6 cores or more cores stuck together. Sure, they get the job done if you're just surfing the net or playing an ancient game, but they're not exactly as well-suited for playing most newer games. I imagine the only reason they're even able to compete with Intel right now is because people probably jump to the conclusion that more cores = better. Which is usually the inverse.

 

No... just no. There is very, VERY little difference in most gaming between AMD/Intel. Games, especially modern ones, are much, much more graphics bound than proc bound.  The only time that Intel really beats AMD noticably while actually playing a game is when you are running multiple monitors and at least 3 high end graphics cards. Where Intel is genuinely more useful currently is if you do a lot of video/audio processing. Which has jack all to do with gaming and you almost certainly wouldn't be using a gaming-oriented graphics card if that was your focus anyway.

[Valsuelm]

 

AMD's "top of the line" processors tend to be 6 cores or more cores stuck together. Sure, they get the job done if you're just surfing the net or playing an ancient game, but they're not exactly as well-suited for playing most newer games. I imagine the only reason they're even able to compete with Intel right now is because people probably jump to the conclusion that more cores = better. Which is usually the inverse.

 

No... just no. There is very, VERY little difference in most gaming between AMD/Intel. Games, especially modern ones, are much, much more graphics bound than proc bound.  The only time that Intel really beats AMD noticably while actually playing a game is when you are running multiple monitors and at least 3 high end graphics cards. Where Intel is genuinely more useful currently is if you do a lot of video/audio processing. Which has jack all to do with gaming and you almost certainly wouldn't be using a gaming-oriented graphics card if that was your focus anyway.

 

 

This is a function of what processor you have under the hood. Both Intel's and AMD's mid-high end processors will be fine for any current game. A couple years down the road and assuming games keep using more and more processor power? Well.. Intel has the better high end chips right now and the foreseeable future.

 

Whether a game is CPU or GPU heavy really depends on the game. For example, one of the most popular games out there, WoW, is much more CPU heavy than it is GPU heavy. Another example would be the Paradox strategy games. Not enough CPU oomph will likely manifest itself first in the graphics which can give someone a misleading impression that their GPU isn't good enough, when the CPU is really the problem. Of course how much GPU power you need not only depends on the game but what resolution you play at.

[ravenshrike]

 

 

AMD's "top of the line" processors tend to be 6 cores or more cores stuck together. Sure, they get the job done if you're just surfing the net or playing an ancient game, but they're not exactly as well-suited for playing most newer games. I imagine the only reason they're even able to compete with Intel right now is because people probably jump to the conclusion that more cores = better. Which is usually the inverse.

 

No... just no. There is very, VERY little difference in most gaming between AMD/Intel. Games, especially modern ones, are much, much more graphics bound than proc bound.  The only time that Intel really beats AMD noticably while actually playing a game is when you are running multiple monitors and at least 3 high end graphics cards. Where Intel is genuinely more useful currently is if you do a lot of video/audio processing. Which has jack all to do with gaming and you almost certainly wouldn't be using a gaming-oriented graphics card if that was your focus anyway.

 

 

This is a function of what processor you have under the hood. Both Intel's and AMD's mid-high end processors will be fine for any current game. A couple years down the road and assuming games keep using more and more processor power? Well.. Intel has the better high end chips right now and the foreseeable future.

 

Whether a game is CPU or GPU heavy really depends on the game. For example, one of the most popular games out there, WoW, is much more CPU heavy than it is GPU heavy. Another example would be the Paradox strategy games. Not enough CPU oomph will likely manifest itself first in the graphics which can give someone a misleading impression that their GPU isn't good enough, when the CPU is really the problem. Of course how much GPU power you need not only depends on the game but what resolution you play at.

 

WoW is far enough behind the curve that at the same price point there's no difference in performance. Unless you're again trying to run the game itself on multiple monitors which TBH except for immersive driving/piloting sims is worthless. Otherwise, even using a second monitor for all of your stat tools, there's no major reason to go for any of Intel's offerings that truly outperform their AMD price equivalents. I imagine that the paradox games are similar. 

[nipsen]

That too is a good point. That because of the way "multicore" implementation is actually done, 99% of the time, on current hardware - we might be better off without it. See often that automatically threaded runs in games cause locks, even when executing optimally on extremely fast hardware, because one application has to wait for a critical point in another. Or the governing thread needs to wait longer than expected with no fallback, so the framerate and response drops.

 

Maybe the real question could be whether they can add opencl runs or not for hit-detection, node-generation, ai-runs, animation correction, and so on. Where you're sort of forced to account for execution times from the beginning.

[MReed]

Locking and blocking (in all but the most extreme cases) doesn't hurt performance, but it is the reason that two cores doesn't double the execution speed.  Only in the very worst cases will the overhead associated with grabbing, releasing, and checking locks (all very fast operations) cause a multi-threaded solution to perform worse than a single-threaded solution.

 

Even with a single core/thread solution, the types of glitches that you refer to can and will occur, but it may be easier for the developers to predict (at code time) and detect (at run time) when problems will occur and implement alternate code paths to minimize the impact.

[PrimeJunta]

Coding for multiple threads is a lot harder than for a single thread though. Harder means longer development time, more and harder-to-catch bugs. Race conditions can be real bästards to pin down.

 

Bottom line: don't do it unless there's a real, concrete need, and a real, tangible benefit. As far as P:E is concerned, from what we know about it I doubt that's going to be the case.

[Zwiebelchen]

Considering that all the graphics in the game are very very basic fixed animation procedures and 2.5D environments making advantage of texture mapping processes, I doubt that there will be any significant CPU load at all.

 

The gameplay mechanics with rolling dices certainly won't. RPG games mostly aren't very CPU intense. The most critical thing is - as was mentioned before - the pathfinding.

 

But then just take a look at for example Starcraft II. The pathfinding algorithm is imho a masterpiece and it handles literally hundreds of units at the same time even in multiplayer scenarios. And I have never run into a situation where I could blame the pathfinding for anything yet.

 

A classic RPG like PoE will likely have no more than 10-15 units to handle at the same time. I highly doubt that even as a single thread application, more than what a single core can do would ever be required.

 

 

As long as they make sure not to introduce a bottleneck by a sloppy design of the combat system, I'm positive that it perfectly doesn't matter if the game supports multi-threading or not.

 

I recently played a F2P MMORPG (Tera Online), which made an extremely bad design decision by making the whole UI flash based. This resulted in a severe CPU bottleneck causing the game to have low FPS even on high performance Graphics cards with loads of RAM. If you disabled the UI temporarily (for example for taking a screenshot), you will notice the FPS going up by 20-30 FPS.

Edited May 14, 2014 by Zwiebelchen

[Sensuki]

In my experience, Unity isn't necessarily the best at handling lots of things going on at once - even a game like Shadowrun Returns which was also done with 2D backgrounds and 3D characters, lagged sometimes.

[Roby Atadero]

The majority of AAA games use threading in some way shape or form. It doesn't necessarily need to be used for the core systems (AI, pathfinding, detection) but, you can always use threads to start a load of something (like data for a new level for example) and then let the main thread continue running the primary portion of the game. Most games also have one thread handling the rendering side of the game while the main thread handles all the computation for everything else.

 

If done in the right places and the right way, threads can be be pretty helpful without adding much programming time or effort. Yes, threads can cause bugs and locks, but, the way we typically use them they aren't that much of a problem given the benefits.

 

Because of the scope of Eternity, this game won't require threads as much as other games. But just as a tidbit of info, one thing in Eternity that uses another thread is the fog of war processing (determining if a given spot is revealed [clear], explored [transparent black], or unexplored [black]). All that can be done while updating everything else in the game and keep it running smooth. Doesn't require much thread management either since that system works on its own for the most part from the rest of the game logic.

[Sensuki]

Did you guys end up investigating that multi-threaded rendering bug in Unity at all ? (since it seems like you're using single-threaded rendering instead).

[anubite]

Coding for multiple threads is a lot harder than for a single thread though. Harder means longer development time, more and harder-to-catch bugs. Race conditions can be real bästards to pin down.

 

Bottom line: don't do it unless there's a real, concrete need, and a real, tangible benefit. As far as P:E is concerned, from what we know about it I doubt that's going to be the case.

 

This is exactly correct.

 

Even if Unity "supports" multithreading, they will not write all of their code to be multi-threaded. They will write groups of code to accept multiple threads where performance is critical and many threads can get the job done faster. Pathfinding is one of those areas. Even doing this much, however, is costly.

 

PoE does not do any dynamic terrain deformation, any dynamic simulation of ecomplex economic/physics elements (like DF or a simulation game), or even have massively complex pathfinding (DF has 3-tier path finding, finding the quickest path on an X,Y,Z grid that is as big as 256^3); I don't think multithreaded calculation is strictly necessary - unless there is something wrong and they realize they need that kind of optimization, but I honestly doubt it.