Re: On the cusp...
 

Background processing would be difficult for a game that is built on PbEM. Turn processing is often done on a different machine than the person is playing on.

MODERATOR WARNING
Discuss the SUBJECT and not each other!
Otherwise you endanger this thread.

Re: On the cusp...
 

Actually this is not a bad idea. It is usually not a good idea to put something like the AI in a seperate thread, but in a TBS it should work fine. I am not sure how cpu intensive playing the background music is, but I think it would be a good candidate to receive it's own thread as well since it only changes during combat it seems..

Using a method like you describe, all that would have to processed between turns is the battles. You could even process most of the battles before the end of the turn as well, and reprocess the battles that include the human player/players during the space between turns.

Re: On the cusp...
 

Now there's an excellent idea (though it indeed might be a bit hard to program). As for the PbEM issues, perhaps it could be done the old way in PbEM games (since the turns last so long anyway)? Of course, if the majority of people play PbEM, it might not be worthwhile to spend too much time on this matter (though I doubt that is the case http://forum.shrapnelgames.com/images/smilies/smirk.gif)

Re: On the cusp...
 

Well, it's not an issue in MP in the first place. He was proposing the change specifically for SP.

But I bet it wouldn't help very much in SP anyway. GalCiv 1 and 2 are suited for background processing because most of the work is in the AI and it's igo-yougo, so it can "think" during the player's turn. Dom3 is wego and most of the turn processing seems to be spent in battles, which can't be calculated until you know whether or not the player's orders will disrupt or change them in some way, so it's very ill-suited to background processing.

Re: On the cusp...
 

Not so much that the majority of games are multiplayer, but that the majority of the developer's interest is.

This would require a very different model for turn processing and probably use up a lot of memory, since so many things would have to be done conditionally.

About the only thing that could be done ahead of time is planning the AI orders. Once mages start casting spells, pretty much anything may change based on the results of ritual attack spells, new globals etc. Everything preprocessed would have to be held in memory waiting it's turn to actually happen. I doubt you'd get much time savings in any moderately complicated game, which is where you'd want it.
Nor would it be a simple programming task.

Re: On the cusp...
 

Yeah, I think making this kind of change would be a major reworking of the code - and from what I've understood, the skills in the mammoth "Illwinter development team" may not be that specialized in multithreading an AI (time to get Brad Wardell on the team http://forum.shrapnelgames.com/images/smilies/wink.gif )

Re: On the cusp...
 

A couple of comments -

Yes, I know the programming is complex. A plan - which doesn't require changing the basic model - is for "turn end" procressing to go in the background. The catch would be allowing changes to turn orders - the background process would have to figure out what to back out and redo for each change. Because of "wego" AI choices could be precomputed as is but that seems a relatively trivial amount of time. A crude start would be to precompute and cache each possible battle and redo if anything would change the battle setup. When the background thread finishes, it jumps back to the beginning and reruns the whole turn (if the player has changed anything), consulting its cache of prerun battles. In the most complicated games I suspect there's a lot of AI-AI interaction which would not be affected by most player action - so the turn processing would shorten dramatically. If the player's last action is to pitch a global, oh well, that turn may last a while.

Obviously the change is only relevant and possible for SP.

Re: On the cusp...
 

Exactly.

Re: On the cusp...
 

Er, "every possible battle" would be insanely numerous.

Think about 800 units neighboring 800 units. *Any combination* of those 1600 units could be involved... AND summons and fliers, AND the gems could be changed, AND commanders may or may not have been killed through earlier spells...

Re: On the cusp...
 

I think that background processing is fantastic. Many games use it. But I dont think it will work here. Personally I feel it would be moving in the wrong direction.

In a way, we are background processing. The game allows you to do your turns and send them to a server. The server processes everyones turns and sends them back. This allows for larger maps, larger armies, more nations, more events. I would rather see it move farther in that direction. Make MORE use of basically unlimited processing time. Id be fine even it took turn processing up to an hour or more.

And thats with me bing a solo player. I easily play Dom games where doing one turn a day is fine with me. Taking months to finish a game is fine with me. It allows me to do other things and makes dominions the game that lasts forever on my machine. Changing it into something that plays faster might be ok but its not anything I will push too hard for.

Re: On the cusp...
 

Well it sounds like there's something wrong with your system. The first few turns on a very similar system my brother owns typically takes about a dozen seconds to process the early game stage turns and this is with 500+ provinces and 10+ AI opponents.
The more complex a game becomes the longer it will take to process a turn within a TBS game. Honestly the issue is definitely your system running the game slow.

Dominions_3 is vastly more complex than 99% of the TBS games which currently exist. I suggest you try fixing your system since that's the main issue. I figure you deserve to know that.

Re: On the cusp...
 

Every possible battle that gets set up that turn by the AI orders and the current state of the player's orders. No, not the factorial abstract possibilities.

Re: On the cusp...
 

Which again leads me to suspect that Illwinter needs to look at filtering how often they update the graphics during turn processing. The graphics queue can wind up taking more time (and CPU time) than the actual processing - I looked at something by a professional colleague of mine (he'd been doing graphics programming for 15+ years, X-Windows for 5+), and in less than half a day (counting debugging & profiling) had the program doing in 30 seconds what used to take 15-25 minutes. All because of the way he implemented a visual progress bar.

On my machine (64-bit Athlon, 3500+ Mhz, 2 gigs ram), turn 2 for a 6 player game with 45 provinces takes two seconds. A turn for year 5 of another game takes 32 seconds. I'm guessing that my Radeon 800GT video card is slowing things down a bit, but not nearly as much as a slower card (possibly with worse OpenGL drivers) would do.

IMO, 2 seconds to process turn 2 with 5 normal AIs and 45 provinces is excessive. Not that I can't live with 2 seconds - it's the way the turns keep taking longer and longer, and _either_ it's the graphical status chewing up the time, or (my favorite gripe/peeve) calculating the age on each troop (including independent troops) and its fleas is.

Similarly, getting to view battles takes way too long now - 7 seconds for the black screen to go away, province fades in, fades to battlefield, etc. Since there doesn't seem to be any way to skip the graphical fade in, that's 7 seconds wasted _every_ battle, or worse - multiple viewings of the same battle waste 7 seconds every viewing.

And since you can't pause the battle until _after_ that fade-in is complete, even trying to watch a scout scripted to retreat to spy out indy strength can take 2 or 3 viewings. *mutter*

Re: On the cusp...
 

Cainehill's got it on both issues; I cranked down my graphics settings, and turn processing massively improved. They shouldn't be related. My understanding is that this is the sort of thing which is commonly fixed in patches; optimization issues often don't come out in playtesting.

Certainly, Civ4 was unplayable on most machines before its patches. I'm hoping Dom3 follows the same pattern -- slow on release, followed by patches which take advantage of player notation of bottlenecks.

Re: On the cusp...
 

Ok, so if high graphical setting caused slow turn process time then it needs to be reported in bug forum. It may not be noticed in this thread by devs.

Re: On the cusp...
 

Press ESCAPE to skip fade in.

Re: On the cusp...
 

You can press escape while it's fading in.

Re: On the cusp...
 

Its also in the options?
At least its in the switches. I have music, fades, animated backgrounds all turned off on the icon that I click to go into Dom3. And on the special icons I have to take me directly into blitz games I also include switches for no sound effects and fast graphics.

Here is part of the switches list....

-w --window Run Dominions 3 in a window
-u --fullscreen Use the entire screen
--bitplanes X Try to use a color depth of X bits per pixel
--zbuffer X Try to use a depth buffer of X bits per pixel (default=16)
-T --textonly Use this with --tcpserver to get graphicless server
--gamma X Set gamma function (brightness) 0.1 - 5.0 (default=1.0)
--opacity X Set gui opacity 0 - 100
-r --res X Y Set screen resolution / window size (default=800 600)
--animback Use animated backgrounds
-a --noanimback Don't use animated backgrounds
--fade Use fade effects
-f --nofade No fade effects
--nopopups No helpful popups
--fps X Aim for this nbr of frames per second (default=20)
--maxfps X Maximum nbr of frames per second (default=50)
--filtering X Quality of OpenGL filtering 0-3 (default=2)
--maxtexsize X Max texture size in pixels 32-4096 (default=unlimited)
--treequal X Tree quality 1-5 (default=3)
--texqual X Texture quality 1-5 (default=3)
--nolightfx No light effects in battles
--partamount X Max nbr of particles 0-8 (0=none, 4=default, 8=max)
--nograss Don't draw the grass
--noarcade Don't draw floating damage numbers
--noglext Don't use any OpenGL extensions
--vsync Enable vsync
-V --novsync Disable vsync
--renderpath X Use different optimizations 0-1 (0=good for low mem cards)
-x --fastgrx Faster graphics (use 3 times for best performance (-xxx))
-p --perftest Run a performance test and exit
******* Audio Options *******
-s --nosound No sound effects or music
-m --nomusic No music

Turning off any features that you dont want is bound to improve the results. I know that Windows people arent used to looking at the command switches but it is a linux-created game so I tend to look there first.

Re: On the cusp...
 

As a *nix and Windoze programmer, I am used to looking at the command line switches. Unfortunately, I'm also used to those switches not doing anything - which is exactly what "-f", "--nofade", "-nofade", and "-f --nofade" all do, at least on the Windoze version.

Similarly, hitting "Esc" is still a PITA, because on Windoze it doesn't accept the keypress until _after_ it's already zooming / fading in : during the 1.5 - 2 seconds of blackscreen, Escape does nothing.