Dominions 3 on Dual Quad core machines

[Agrajag]

I'm pretty sure it won't work.
IIRC Dominions uses tables of prerandomized numbers, and to show a battle again just means starting at the right place in the right table and recalculating the whole thing all over again.
If you simulate more than one battle at once, you can't tell which random numbers belong to which battle, since they'll all be taking random numbers randomly.

I'm not really explaining this well, but I hope you understand anyway

EDIT: Just to be clear, I'm not saying "impossible!"*, I'm just saying "harder than you think."
*-obviously it is impossible, even if at the worst case scenario it would take rewriting the entire source code from scratch

[Griefor]

Actually, random numbers are a good point. I hadn't considered those.

Unless the reverse engineering I did in my mind is wrong, Dominions relies on the deterministic nature of its code to produce the same battle results on every machine a game is played on. Without prerandomized numbers, a random number generator (one of those pseudorandom generators which produces the same results if you seed it with a static value) would still suffer from the same problem - it's only deterministic if all the calls to it occur in the same order every time.

As you said I'm sure it's still a solvable problem, but it's definitely something that would have to be thought about.

I *still* think it wouldn't be incredibly difficult to implement this, but I also don't think it's really necessary enough to warrant the work anyway. In my big SP game experience loading times were really not all that horrible. Although if it's just for SP, a simple pseudorandom generator that isn't deterministic would probably be sufficient anyway.

[thejeff]

There are no simple non-deterministic pseudorandom generators.
In fact pseudo-random is pretty much equivalent to deterministic.

I believe Dominions does use a pseudo random generator not a pregenerated table.

The simplest implementation that comes to mind for doing the battles in parallel would be for each thread to work with it's own RNG and for the main process to generate the seeds for each battle before spinning off the thread.

[Loren]

Agrajag said:
I'm pretty sure it won't work.
IIRC Dominions uses tables of prerandomized numbers, and to show a battle again just means starting at the right place in the right table and recalculating the whole thing all over again.
If you simulate more than one battle at once, you can't tell which random numbers belong to which battle, since they'll all be taking random numbers randomly.

Non-issue--the generator simply needs to pull it's seed from thread data instead of global data.

[thejeff]

Battle resolution is independent in each phase.
Obviously fortress battles depend on the outcome of regular battles which depend on the outcome of ritual phase battles, but otherwise they don't affect each other.

The outcome of battles will affect where routed troops go, but that's handled after they are all resolved anyway. Troops routed from the first battle don't show up in a later battle in an adjacent province. They're spread out among any neighboring friendly provinces after all battles are resolved.

[JimMorrison]

Seriously, next to the rest of the programming, would it be that hard to simply have 2 tables to go off of? I mean, you just need to copy the first table (if they are pregenerated), and a miniscule amount of additional RAM/HD usage solves the entire problem. Now we just need the game to send some of the battles to core 2 and we're golden.


Damn, forgot there was a page 2..... Stop pissing in our cornflakes, Ich. <3

[thejeff]

The magic phase battles could be hard to handle. Am I right in thinking that assassination spells (and assassinations?) occur along with the normal ritual casting and thus can interrupt, but that Teleport(etc) battles occur after all rituals have been cast? You can't interrupt someone's casting by teleporting onto his lab?

If so, it's not too much harder. Deal with all the assassinations. Spawn a thread for each province's magic phase battles.
Deal with the results and army movement, etc.
Spawn a thread for each province's movement phase battles.
Deal with the results
Spawn a thread for each fortress battle.

It's not even a graph. I think for each phase it's confined to a province. You'd need to resolve everything in a phase before moving on to the next anyway.

[Aezeal]

just PM the programmer himself and ask if he can do it.. it's known the makers don't like others messing in there code so if he can't it won't be done.. if he can there might still be a zillion reasons why he won't do it (busy with other stuff outside dominions being nr 1 I'd figure and if busy with dominions then probably fixing bugs takes priority) .. but you could ask..

[JimMorrison]

Well this discussion is somewhat important (if the facts can be gotten straight). In my experience, programmers tend to HATE being asked to change code unless you actually know what you want. If you just say "hey, can I get fries with that", your response tends to be, "sorry, there are no fries, but I can give you extra ketchup". Now, if you say "if I turn on the fryer and add fresh oil, can we have fries?", sometimes you get a favorable reaction. Of course, sometimes the response is "those fries are frozen, if you put them in hot oil it will practically explode giving us all third degree burns, are you an idiot???". That is when you give thanks that we even have a Dominions 3, single core or otherwise.

[Taqwus]

1- Concurrency control is not something that should be grafted on after, if the code was not designed with it in mind.

There's much more to it than 'could this battle affect the outcome of another', for instance -- or how one seeds PRNG tables. There's also quite likely to be shared data structures (notably, the table of units -- and units get both created and destroyed in battle), for instance. There may be static variables that would need to become thread-local. And so forth.

Grafting on MT-ness is a serious pain. That's true even in languages which are designed for it, unlike ANSI C. It's even more true if you're using libraries, because you can't really assume that the people who coded the libraries made -their- code MT safe, or if they've provided sufficiently fine-grained locking to enable the serialization you need. Yeah, individual operations may be atomic... but if they didn't give you the methods to lock a sequence?

2- Dominions is unusually quite cross-platform. ANSI C does not specify any threading infrastructure, let alone a cross-platform one. Pthreads *might* serve, but the last release on Windows seems to be from 2006, so it wouldn't surprise me too much if it broke on more recent OSes.

Writing MT code for even one OS is enough of a pain.