New and Modified Scenarios

[Richard Bruns]

I've been quite busy recently, but when I get a version that works with the new testbed I'll send it to you.

[Gary Thomas]

Has anything else happened in the months since the last post to this thread?

In particular, is there any requirement for different events? I am good at that...

Cheers

[Mark_Everson]

Hi Gary:

Originally posted by Gary Thomas
Has anything else happened in the months since the last post to this thread?

Nope. I checked with Richard a few times to see if he wanted updates, but he always thought he wouldn't be able to get to it.

In particular, is there any requirement for different events? I am good at that...

Not that I know of. I expect the requests will start when serious scenario modification and creation begin again.

[LDiCesare]

I added a few scenarios for testing purposes. In all, I did: a siege scenario, an ai test scenario (very silly), an embryo of a scenario for a test of the social model.
I just coded whatever event I needed, which was not many.

[alms66]

Since the map is nearing completion, and I plan to post it when it's done, I thought I'd mention it here. I have a 50X*100Y middle east map which covers everything from Greece & Egypt in the west to India & Tibet (though barely) in the east. I've titled the scenario "Ancient Middle East." This will just be a blank map for now.

After the map is complete, I'll add in several ethnic groups (I'm thinking at least 12), and twice as many civs (For example, Egyptian EG/ Egyptian Civ & Native Egyptian Civ). The "native" civs are to emulate the aspect of Clash D4 that I miss, where nearly the entire map was populated, but controlled by "minor" civs.

The scenario will start in 5000-7000 BC (copper age), and will be the place where the technology tree I'm developing will make its debut. It will also feature a wide variety of new units (since the tech tree is large, we'll need em). I hope that soon someone will be able to start coding the Diplomacy and Infrastructure models, so those will be in there as well.

I will make a 'standard' version of this scenario, as well as a 'tutorial' version, which will give tutorial advice much as the current Dawn scenario does, but even moreso. It will feature every current (at that time in the future) aspect of clash, including sieges/walls, maritime issues, etc.

[Mark_Everson]

Sounds Great Alms, looking forward to checking it out!

[alms66]

Ok, I've attached the scenario folder and a new 'scenarios.xml' in a single zip file. I've run it on two different computers, and here's the deal:

Comp1
CPU: 2.6 Ghz
RAM: 512 Mb
Video: 128 Mb

Comp2
CPU: 2.0 Ghz
RAM: 512 Mb
Video: 64 Mb

Comp2, ran it fine, though rather slow.
Comp1, ran it fine, and it was still slow, though a good bit faster than Comp2, and is at a speed I can live with (but this is just the map at the moment).

Thus the map alone, is too large for a computer without the minimum specs of Comp2, and is still a bit large for specs of Comp1, which is just plain ridiculous. There's got to be some quick optimization we can do to make this thing run a little faster.

I'll put a quick link here to a page that has good isometric engine related articles, in case they may help with optimizing some of the code. I'd also suggest, for anyone who doesn't have it, "Isometric Game Programming with DirectX 7.0" by Ernest Pazera. It's C++ using DirectX, but it is good info for iso engines nonetheless.

[vovan]

Hi,

Well, I would be willing to look into the performance of this thing. For some reason, all of my university project classes involved writing a game - a couple of them - in Java, so I got pretty good when it comes to efficient graphics in Java, even if I say so myself. Plus, I have a few profiling tools installed on my machine, so finding out what precisely is slowing the game down wouldn't be a problem.

Vovan

PS: And I agree, that book you mentioned is really nice. One of the most useful game programming books I have ever read.

PPS: Incidentally, the programming project for a software engineering class I am taking now, due in two weeks, also involves writing a game, and we went with an isometric view, so I am coming fresh out of coding an isometric map engine. So, hopefully, I'd be able to spot a few optimizations here and there that can be introduced to the code.

[alms66]

Originally posted by vovan
Well, I would be willing to look into the performance of this thing. For some reason, all of my university project classes involved writing a game - a couple of them - in Java, so I got pretty good when it comes to efficient graphics in Java, even if I say so myself. Plus, I have a few profiling tools installed on my machine, so finding out what precisely is slowing the game down wouldn't be a problem.

That would be great. I’d certainly appreciate it, as I’m sure everyone else would too. When you find the problem areas, could you either post them or send them to me via email? Perhaps I can provide some help.

Originally posted by vovan
PS: And I agree, that book you mentioned is really nice. One of the most useful game programming books I have ever read.

It’s extremely useful for this particular game.

Originally posted by vovan
PPS: Incidentally, the programming project for a software engineering class I am taking now, due in two weeks, also involves writing a game, and we went with an isometric view, so I am coming fresh out of coding an isometric map engine. So, hopefully, I'd be able to spot a few optimizations here and there that can be introduced to the code.

If I may suggest something:

Assuming it’s not too much trouble, in addition to the typical primary buffer and back buffer, I’d suggest creating “working pads” to draw the tiles (and all subsequent overlays – roads, cities, units, etc.) on and then draw the entire working pad to the back buffer as a single image, rather than continuously layering onto the back buffer itself. The working pads (three of them) would be in their own thread drawing the next three tiles ahead. These pads should be equal in height and width to the width of a tile (80 currently, but query it - don't hardcode it whatever you do), for a surface area equal to 80*80 pixels (the reason for being square is to draw units and such above the north tip on the iso tile).

I’ve used this method before, though I’ve never actually checked how much of a performance increase it gains, but it sure made working with graphics much less of a headache.

[alms66]

Ancient Middle East Scenario Update

At this point I have the following to do:

To Do List
1. Add 'desert' tile (see comment #2)
2. give one army to all civs
3. give 'native' civ several individual units scattered on the map
4. add tech tree
5. write tutorial

Once I've gotten to step three (which should be by Sunday at the latest), I'll post the alpha version here. Once step 4 is done, I'll repost it (let's call that the 'standard' version), then write the tutorial (for the 'tutorial' version).

Comments on the scenario as it is:

Comments
1. We need a scenario editor....NOW! Seriously, making a large scenario like this is a real pain editing text.
2. Dunes cannot hold population, the economic code gives errors, so I changed them to farm:1 and resource:1 (this is enough to keep the economy from complaining). I'll add a new tile (along with graphic) and call it 'desert' for the alpha version.
3. The scenario takes about 2 minutes to load in the Testbed, mostly due to the running of all the diplomatic states (you watch that on the screen for about a minute and a half).
4. Turns take 4-8 seconds to generate. This may be due to the fact that the 'Native' civ has a province that covers the entire map, except for the 9 tiles that each civ owns (9*25=225 tiles total don't belong to the Natives).
5. I origionally planned on having 25 civs & 25 native (or minor) civs, but due to the initial loading time, and the pain of adding additional civs after the first 25, I opted to add one Native civ that covered the whole map.

[LDiCesare]

(Getting off-topic)
Although I agree that checking the performances is a good idea when the game starts being slow, I would advise running the profiler BEFORE thinking it's due to the graphics (ok, it's likely, considering we draw several overlays, redraw the whole map everytime because the APIs are just that way, etc.). You often find out when optimizing things that there's a quadratic in a place noone ever thought of, and it is a very bad idea to optimize stuff that happen not to be a bottleneck.
If you have profiling tools, I'm interested in the results.

[LDiCesare]

(Slightly more on-topic)
In a mail, alms said:

In addition to 'Rename Province,' 'Set to province capital,' and 'Set to civ
capital,' on the right-click menu, can you add 'Reassign Province' so that
the player can draw his own provincial borders? It would be really nice,
though not necessary to also put a limit on provincial sizes, though I'm not
sure of the best method to do so.

In playing the Ancient Middle East Scenario, which has a single province
called 'Native Land' that nearly covers the entire map, I've discovered that
this feature would be very useful (at least for this particular scenario).

I guess you mean a menu that lists the provinces you currently have and which one you'd want to reassign to?
But then we never decided how provinces are formed (there are some discussons in several old threads that I don't have time to look for right now). Are there limits on these provinces you would like to have (like only reassign if square is neighbour to the province)? Creating new provinces from scratch is another question, would you want to do it? This may require another thread.

[alms66]

Originally posted by LDiCesare
I guess you mean a menu that lists the provinces you currently have and which one you'd want to reassign to?
But then we never decided how provinces are formed (there are some discussons in several old threads that I don't have time to look for right now). Are there limits on these provinces you would like to have (like only reassign if square is neighbour to the province)? Creating new provinces from scratch is another question, would you want to do it? This may require another thread.

I'm not sure exactly what I want here. I just know that we need a way to reassign squares to another province. I guess I'll start or find a thread to discuss the details in.

-Edit-

Moved discussion to Provinces (Management & Size Limitations) thread.

[alms66]

ACME Update (AnCient Middle East)

I've done the desert tile (it was completed Sunday morning actually). I can't complete #2 & #3 (I found the game to be unplayable when they are completed), which is why I haven't posted the scenario yet. Even if I don't give armies to all the civs, the game still becomes unplayable as the AI builds units and takes longer and longer to run its turns.

I've discussed it with Laurent, and come to the conclusion that the only way to make this playable is to modify the Natives somehow (since they see 99.9% of the map, they are causing much of the slow down), which will take a bit of time. I'm going to first try giving them scattered tiles here and there (rather than every tile not owned by one of the other 25 civs), and if that doesn't work, I'll delete them altogether.

If I am forced to delete the natives, I'll most likely bump the number of civilizations, later on, up to 30+, since that's an awful lot of map for just 25 civs.

In addition to the above changes, I've modified the religions, regimes and am working on modifying the social classes to better suit my tastes. I'll also add in anything else I run across that I've neglected to mention thus far.

[LDiCesare]

Let me give you a small update on the performance of this scenario so you don't back uselessly.
There are 2 kinds of performance problems:
-Either the program is slow, but bearably so. This means you should wait for 6 months or 1 year, upgrade your machine, and the problem's gone.
-Or the program doesn't run at all, and it needs fixing.
This second case, however catastrophic it may look like, is actually the best case. It's usually due to some quadratic, that is you are doing the same job over and over for no good reason.
The scenario started with a new turn which never lasted. I checked and saw the pathfinding was taking forever. Actually, it was not the pathfinding, but the nearest neighbour algo which was slow (looking for the nearest square looked for all squares and computed the path instead of using Dijkstra's algo which means it was N2Log(N) instead of NLog(N)). Fixing that reduced the time to about 23 minutes and then 8 minutes after some tweaking on my computer. Still unbearable, thus fixable. I checked and decided that computing a path to reach an invisible capital that I won't choose as a target anyway was a bad idea. Correcting the ai, making it not target unseen squares reduced the time to about 5 minutes. Still unbearable. I profiled a bit, replaced an array access by a hashtable, which reduced again the complexity of the algorithm by O(N). So we went down from O(N3Log(N)) to O(NLog(N)), which means it now runs in about 1 minute. That's enough for me now, considering now the majority of the time spent is in the economics. I'll check other problems, but DON'T WORRY about performance problems. The most catastrophic ones are usually the easiest to fix (at least if you don't have the burden of modifying existing data and data compatibility, but don't get me started on my work). In this case, my estimate is the duration of the ai computation got divided by about 2500 or more thanks to one week of work on this issue. So don't worry if it's slow, just say so, and I'll look for the problems we put in the code.

Now I've said that, I'd like to see Sumerians in addition to Babylonians (when I play the Babs in Civ, I rename the capital Uruk and call myself Gilgamesh ). The map looks really good.