Planning for Demos 7 & 8

[Mark_Everson]

Next steps on Tutorial

My plan for the weekend is to get the Dawn1 tutorial as far along as possible. Thanks for the good suggestions everyone! I hope to release a version of the testbed with a mostly-functional tutorial in it by the end of the weekend (my time). There is a lot of writing I can do before I see any code improvements, and I'm starting on that as soon as this small list is done. But to actually have the writing do anything in the game there are some features I need, mostly involving bulletins.

I think I can get far with bulletins that just pop up at specified turns. I don't think we need all the other trigger stuff we discussed before for the first run-through of the tutorial. Here are my requests for bulletins, Gary. The sooner the better on these...

1. Bulletins that pop up on a specified turn, as mentioned above. If their turn has come and gone, can we have them automatically dispel themselves, or is that too much work to be worth it at this point?
2. A way to specify the upper left position of a bulletin, and perhaps its size
3. When several bulletins come up in a turn, the current method where earlier ones are offset and on top of others is fine, but each turn that position counter for where the bulletins appear by default should be reset. That avoids the current issue of the bulletins slowly working their way off the screen as more and more are presented.

Other than these, I guess the highest priorities are:

fixing the bugs reported by e-mail 6/20/02
getting barb incursions working (#8 in the list)
fixing bug 141 where roads aren't used for movement properly
getting the military costs rebalanced, which Laurent is working on now.

My putting in of education having an effect on tech somehow got lost in the code updates. I will put it back in sometime this weekend.

What else do we need? I think most of it is in the list above, and great strides have been made on much of it, thanks especially to Gary.

It's great to see this getting close!

Mark

[Gary Thomas]

1. Bulletins that pop up on a specified turn, as mentioned above. If their turn has come and gone, can we have them automatically dispel themselves, or is that too much work to be worth it at this point?

This should happen now. Since every turn must happen, they should appear on that turn then vanish thereafter (when you click the little x in the to left corner...)

However, at present the turnevent is triggered by year, not turn number. If you are agreeable I will change it to be triggered by turn number and add another event, yearevent, triggered by the game year (-419, for example).

2. A way to specify the upper left position of a bulletin, and perhaps its size

I will also do this immediately.

3. When several bulletins come up in a turn, the current method where earlier ones are offset and on top of others is fine, but each turn that position counter for where the bulletins appear by default should be reset. That avoids the current issue of the bulletins slowly working their way off the screen as more and more are presented.

That is a bug which I will fix. I might try and get them working properly (that is, one after another) as well. I loathe the way they show now. That should teach me not to allow hacks in my code...

After that I am having the rest of the day off - I have my favourite granddaughter with me, and that is a full-time job...

All done now.

Cheers

[Mark_Everson]

Hi Gary:

Thanks for the attempted quick turnaround on these!

Originally posted by Gary Thomas
This should happen now. Since every turn must happen, they should appear on that turn then vanish thereafter (when you click the little x in the to left corner...)

Hmmm, well the BeginningEvents not only don't automatically disappear, they come up every turn. I didn't even know the turn events were working!

However, at present the turnevent is triggered by year, not turn number. If you are agreeable I will change it to be triggered by turn number and add another event, yearevent, triggered by the game year (-419, for example).

That sounds good. Can you give me an xml example of each when you send the code?

After that I am having the rest of the day off - I have my favourite granddaughter with me, and that is a full-time job...

Hope you have a Great time!

[Gary Thomas]

Fixed the beginning event (sent the new file - just changed a false to true!).

Could you post a consolidated list of the xml examples you want me to do? Thanks.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
Fixed the beginning event (sent the new file - just changed a false to true!).

Could you post a consolidated list of the xml examples you want me to do? Thanks.

Thanks!

Here's the list:

XML Examples needed... numbers from list, letters new(ish) ones.

8. Use events to put barb incursions into Dawn1 (Gary)
Code done, waiting for xml example

X 9. use discovery of the horses tile plus generation of horse technology research points (say once you settle the horse square, or given as a big blob of RPs upon discovery (Gary)
Need an example of how to give some RPs when this or wheat are discovered.

X 11. Victory Conditions Dawn1 - add achieving building of a chariot unit (Gary)
Done in code (need xml)

A. Example of turnevent with screen location and bulletin size specified
B. Example of dateevent

AFAIK that's it.

Thanks again for being willing to do these!

Mark

[Mark_Everson]

Delenda is somewhat more challenging with the new econ orders. At least as the Romans if you don't mount a reasonable defense you can get overpowered.

I played one game as the Romans for about 20 min, and it was some fun! The biggest problem I had was the enemy being able to pass through my substantial pickets without much damage. I guess what happened is a brief battle got fought, and then the enemy moved on to the square beyond that was in their movement orders. I was wondering if we need a rule to the extent that unless you win the battle, you can't continue your movement. A unit that did not win (and these were so outnumbered I'm sure they couldn't have won) would be prevented from continuing its movement, and either have to stay and fight, or retreat back along its path of advance.

I realize this is more a military matter, but I was concerned about it in the specific context of D7, so I put it here. If the passing through of opponents bothers only me, I'll just deal with it. But if it makes the game for others less pleasurable also, it would be worth addressing.

[Gary Thomas]

I realize this is more a military matter, but I was concerned about it in the specific context of D7, so I put it here. If the passing through of opponents bothers only me, I'll just deal with it. But if it makes the game for others less pleasurable also, it would be worth addressing.

It bothers me. Any combat should cancel all orders.

Do you want me to do this?

Cheers

[Mark_Everson]

Yeah, that sounds good Gary, but we should wait first to hear what Laurent thinks.

So if the orders are canceled when the battle begins, I assume when the battle is over and the smoke clears that new orders for whatever seems appropriate will be issued? The problem is for the players' armies it could be irritating to have the orders canceled. That always used to bug me in civ2. Or do you mean that the orders are just ignored until the battle is over? The last one seems the simplest to me for now. We can certainly better refine things in the future beyond D7.

[Gary Thomas]

I think that computer controlled orders should be completely cancelled, and replaced on the following game turn. Player controlled ones could remain. However, their execution will wait until the next turn. At some stage we might allow an overrun - if the enemy force is tiny, it will not slow down the troops.

On another topic, I believe quite strongly that each province should have a capital, and all troops should be raised there. The thought of ordering troops and having them show up in a random square leads to a strategic and logistic nightmare. The capital does not have to be a city, it can be any square, and providing the means to shift the capital requires very little coding.

Cheers

[LDiCesare]

I don't like orders cancelled for the player. I also don't like the idea that we check if that is the player so we must cancel or not, because the player could pass thru a picket and the AI not. I should look at the result of the fight, and, if lost, cancel orders and give a retreat order instead, if drawn, cancel all orders or (better) delay them.
(edit)
I will cancel orders until I get a method that allows delaying them. The retreat decision can be based on the result of the fight (did the army flee or was wiped), but I think after the fight I will check the odds to attack/defend and decide whether to flee or not based on that. It will be more accurate. The question remains for units which have been created in a square, are then attacked and want to flee: Where do they go? For now, they will stand their ground.

[Mark_Everson]

Originally posted by Gary Thomas
I think that computer controlled orders should be completely cancelled, and replaced on the following game turn.

Seems we're all agreed on this one!

Player controlled ones could remain. However, their execution will wait until the next turn. At some stage we might allow an overrun - if the enemy force is tiny, it will not slow down the troops.

OK by me. Laurent, Because player order execution is held up, there is IMO no big asymmetry between player and AI. Player's troops can't shoot through, because if there is still a fight in the square, the move orders get delayed. Is this ok with you Laurent?

On another topic, I believe quite strongly that each province should have a capital, and all troops should be raised there. The thought of ordering troops and having them show up in a random square leads to a strategic and logistic nightmare. The capital does not have to be a city, it can be any square, and providing the means to shift the capital requires very little coding.

The reason I did the by-square was anticipating low-centralization cultures where every square is largely on their own. For now, and in the long run for centralized states, I agree with your changes. If you go ahead and implement, I'll rejigger the econ code to do the right thing.

Laurent said:

I will cancel orders until I get a method that allows delaying them.

I guess canceling is ok as a temp thing, but I think players will dislike it. So I hope a fix that can preserve player orders will be available soon!

The question remains for units which have been created in a square, are then attacked and want to flee: Where do they go? For now, they will stand their ground.

For now I think these units should plot a course to the nearest friendly city, and retrieat into the first square of that path.

Since we're getting down to a lot of details, we should IMO move this discussion to the military thread. Since it was my fault we kicked it off here, I'll do the busy-work of copying it over.

[Gary Thomas]

14. Even though Hannibal is a large task force/command with phalanx and light horse components, the light horse always outruns the phalanx, giving Hannibal much less odds than would be the case if the TF moved together. I think that's a bug it's important to change to give the AI some punch. Another confusing feature of this behavior is that when you click on a square with any component of the Hannibal force, you see the whole thing. (Mark or Gary if I can't figure it out!)

This, I am afraid, has turned out to be a VERY major job which may require rewriting the movement orders system as the only good way to fix it. It arises from the fact that the movement orders work per unit, and don't hold units back for slower units. Probably as much as a week's work.

Cheers

[Gary Thomas]

There is nothing in the rules that says units in a task force have to be in the same square, although the current gui forces this for the human player. The intention was to eventually have a gui that allowed separated units to be added to a task force, then the task force sent to a square. This would, eventually, bring all the units together.

The reason that the units travel separately in the present code is that the quickest path for cavalry may not be the same as the quickest path for infantry, for example, cavalry might find it quicker to take a round about road route, while infantry cut across mountains.

We could have a rule that, once together, all units in the same task force will stay together. This will considerably complicate the path-finding algorithm.

Nevertheless, I think it should be done.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
We could have a rule that, once together, all units in the same task force will stay together. This will considerably complicate the path-finding algorithm.

Nevertheless, I think it should be done.

Yeah Gary, that sounds best to me for now too. As the game development progresses I agree with you that we should do things like short-term splitting up of TFs. But that should wait till the real AI IMO.

[Gary Thomas]

Damned if I can find a reference to it, but I fixed the problem in which the path was shown on the map from the start rather than from where the unit is now, in D7.

Cheers