I saw someone suggest for an MMO that the world should evolve in Real Time. Great. Everybody has been dying for that for the last ten years, since EverGrind first appeared. But then I noticed that the general consensus idea was that "a simple 80s AI" was to take control of things in the background, while the player played his own life, and that could modify the world enough to make things interesting. Well, given the new trend of multiplying the cores on the processors, instead of trying to rise the clock to insane speeds, would you say that there is a possibility that in the next installment of things like Elder Scrolls series, the multi-core processor will be a pre-requisite, and that one of the cores will be entirely devoted to modifying the world in real time around yourself? Let's take a quad-core exemple. Still top technology today, but probably line entry tomorrow. Let's assume that one core is occupied with the "simple 80s AI" thingy, trying to create a believable war around the player character, and maybe a second core for creating believable social interactions between NPCs, like having them have real needs (a dampened version of radiant AI, maybe, or something...) Would you say such a design is likely to occur? If you can take advantage of the multi-core architecture to leisurely rip a DVD while toying with your photo editor, then surely, you can have this kind of architecture take care of more than one aspect of a game at a time, right? Are we going to see multi-core specs games in the following years? What would be the next trend? The destructible worlds everybody has been dying to see, but applied to a new scale? Red Faction destruction engine in Morrowind's world? Seamlessly? The same thing but in an MMO? Why? Why not?

single player, not a problem, the problem is when you try to make it multi player, where transfering the data and making sure people don't do stuff in lag time. You don't want to have a crater appearing inside a crater for one people, and then have them reversed for the other. (which creates two totally different landscape changes) Not a good thing to deal with.

I've personally been working on a system to generate a false massive AI, interactions between the player and millions (maybe even billions) of 'unique' AI agents. I'm still in early prototyping stages, but it is looking like I can run it in the background of just about any common RPG (barring things like Oblivion).

Basically, when the player is in an area, the system generates the people around them, and updates the local events (things like, what items AI agents have exchanged, people murdered/stolen from. random things like new births, deaths, etc, these would be rather limited) from there is will make a quick update of regional things, major economic and political things, on a fairly small scale. (families engaging in disputes, large sales of land, death of mayors and minor nobles. Trade problems, lack of whatever type of good, surplus, etc) Now and then it can update the largest, international relations, breakdown of trade routes, new ones, wars started and ended, major battles, things like that. Some of these might be caused because of actions of the player. Maybe the player could gather an army and capture a city, shifting things by a lot throughout the whole world.

The AI would be made up of many different levels of agents, each belonging to a faction. Each faction would have a few key names and personalities that are stored, the rest generated as needed. Factions are then grouped into alliances, hard and soft. The top of an alliance might be the king's family, with hard alliances to the nobles of the kingdom, all would have hard alliances to the different factions filling up the parts of middle and lower class groups of families in the cities, and the farmer families in the country side. The farmers would have soft alliances to the farmers of other countries. Some thief factions might have hard alliances to similar factions in other kingdoms, while having very soft alliances to the king of the country they are in, and be enemies of the guards and upper/middle class peoples.

In all, I end up with a web with a few hundred entries, while 'controlling' tens of thousands of AI persons to the player's view.

Quote:

Red Faction destruction engine in Morrowind's world? Seamlessly?

I have actually been working on some ideas along this line. The system i am thinking of uses "virtual" voxel nodes as a network to control the surface of a mesh. The voxels are only invoked if that mesh needs to be modified.

The basic system will also allow these Virtual Voxels to be created and destroyed as needed (as they don't need to be tied directly into a physical location).

If you think of a series of voxels or arbitrary size and dimension, 1 layer thick, just under the surface of a mesh, then this is what it would look like conceptually.

If a voxel undergoes changes (that is the mesh it represents is changed), then it would notify nearby voxels of the changes to it's associated mesh and also of any changes that the recipient voxel needs to make.

So a missile would hit a section of ground. This section would have a voxel assigned to it (either at that point or pre-calculated to save processor time). This voxel would then have a displacement (how large the crater is supposed to be) sent to it from the missile impact event and the voxel would make the nessesary changes to it's mesh.

It would then send this information along with a new displacement factor to the surrounding voxels, which would then apply this same process.

To prevent this having to spread to all the voxels in the network, if a voxel is not effected by this event, it would not send any thing on (unless instructed to do so). So once a minimum displacement is reached (say 0), the voxel send that on to the next voxel, but as this last voxel has nothing to do, it does not send any message onto the next ones and the cascade ends.

Of course smarter handling would be in the actual implementation, but that is the basics.

If, due to the displacement, a large area is created, the voxels could "split" and create new voxels in its place. This means that the results of this displacement cascade could create any 3d structure you like. It effectively makes the mesh act like clay.

Also by only having the voxel code execute when it is needed, you don't have massive amounts of processor speed tied up in its maintenance. In fact you could have a voxel only execute if and when it is signalled. The actual voxel that sends the information might be able to run the new voxel as a recursive function call. Events that trigger a voxel could also be likewise handled.

Quote:

Original post by Fournicolas Are we going to see multi-core specs games in the following years?

No. You seem to be one of these people that has been a little taken in by the marketing. If a processor has 2 x 2GHz processors, it will be performing approximately the same number of actions as a single 4 GHz processor. There's no (ok, very little) magic that is going to make these dual cores any better than an incremental improvement in CPU speed, the likes of which we've seen for decades. On the contrary, making the most use out of a multi core processor requires different programming approaches that are at worst, not suited to games, or at best, not very well employed by game developers. That's why many games out there will run better on single core processors than a similarly priced dual core cpu.

Don't expect any major changes. Or to put it another way, if there are any major changes, it'll be nothing to do with the processor being split in two.

Quote:

Original post by Kylotan Quote: Original post by Fournicolas Are we going to see multi-core specs games in the following years? No. You seem to be one of these people that has been a little taken in by the marketing. If a processor has 2 x 2GHz processors, it will be performing approximately the same number of actions as a single 4 GHz processor. There's no (ok, very little) magic that is going to make these dual cores any better than an incremental improvement in CPU speed, the likes of which we've seen for decades. On the contrary, making the most use out of a multi core processor requires different programming approaches that are at worst, not suited to games, or at best, not very well employed by game developers. That's why many games out there will run better on single core processors than a similarly priced dual core cpu. Don't expect any major changes. Or to put it another way, if there are any major changes, it'll be nothing to do with the processor being split in two.

?
What about massively-multicore applications for server side processing?

Quote:

Original post by Kylotan Quote: Original post by Fournicolas Are we going to see multi-core specs games in the following years? No. You seem to be one of these people that has been a little taken in by the marketing. If a processor has 2 x 2GHz processors, it will be performing approximately the same number of actions as a single 4 GHz processor. There's no (ok, very little) magic that is going to make these dual cores any better than an incremental improvement in CPU speed, the likes of which we've seen for decades. On the contrary, making the most use out of a multi core processor requires different programming approaches that are at worst, not suited to games, or at best, not very well employed by game developers. That's why many games out there will run better on single core processors than a similarly priced dual core cpu. Don't expect any major changes. Or to put it another way, if there are any major changes, it'll be nothing to do with the processor being split in two.

That might be a poor example if you consider a Quad Core (coming out quite soon and later will be affordable..) 4 X 2Ghz (and with much larger caches as Intel has been doing). Current games might not be particularly well designed to run efficiently on multi-cores, but future ones likely will be. Deformable scenery may be one of the new operations/processing that can be relatively independant of other game aspects and thus well suited to multi-core increases in total processing power (we arent likely to get 8Ghz mono-cores..). That goes double for AI which has a great potential for more interesting games, and for Physics etc...

Just because the current games have not had to use new techniques to take advantage of multicores does not mean that capacity wont be used in the future.
Its a matter of splitting up tasks to run in parallel and doing smarter scheduling and eating some inefficiency in the places that things are too interdependant.

Quote:

Original post by Kylotan If a processor has 2 x 2GHz processors, it will be performing approximately the same number of actions as a single 4 GHz processor.

This is true, however, as far as getting calculations done very rarely will they be anything near similar. For a single threaded, and non parallel algorithm the single 4GHz core will ALWAYS be far faster than any multicore.

However, if you can split something into parts, and run them, storing results needed for later calculations, then the multicore is going to beat the snot out of a single core. Also GHz doesn't mean nearly as much as some think it does. Compare how 'fast' a P4 is to a Pentium Mobile of the same clock speed, the mobile is going to win.

I could use 32 cores, considering that program was written for 250 cores.

However the current problem is with uneducation of programmers. It takes just a few test programs to learn all important stuff. For example how to do it without synchronization, or with two asynchronous rendering threads. The greatest problem is windoze, because it isn't a preemptive multithreaded OS. This means a programs that worked on Linux might have big problems under windoze. (and this isn't problem that could be solvable by some library)

With high amount of cores, you'd fall into problem of bandwidth. Considering majority of data would fall out of L2 cache, this problem isn't exactly negligible.

Quote:

Original post by Raghar For example how to do it without synchronization, or with two asynchronous rendering threads.

2 rendering threads? I thought that rendering in threads was a bad idea as most rendering routines are not thread safe, and graphics processors aren't designed for muliththreaded rendering. Isn't this the reason why the newly released java 6 has adopted a single threaded drawing system?

Quote:

The greatest problem is windoze, because it isn't a preemptive multi threaded OS.

What?

1. These are not thread safe as in a function a(b) would always return predicted result for b. However it doesn't matter.
2. These are not thread safe as in you could use one space for data.

So obviously mutithreaded rendering is plausible. However there are features that needs multithreading more than rendering, thus majority of people wouldn't bother with multithreaded rendering.
It's true things might be messy with OpenGL, however not impossible to solve.

IIRC when he compared single threading engine with multithreading version, on single core CPU he had 2 FPS drop for multithreaded version, and on multi CPU system he has a nice increase in FPS.
Of course these things need to be done sensibly, majority of applications are doing larger amount of graphics processing on the GFX card, so multithreaded rendering just to do multithreading is bit silly.

As to your second question. Have you tried to close application that hanged up? "Preemption" under that system is working a little differently than it should.