 |
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
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
|
 |
New Zealand
Mar 2001 time: 17:17
|
|
quote: 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).
quote: 2. A way to specify the upper left position of a bulletin, and perhaps its size | I will also do this immediately.
quote: 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
Last edited by Gary Thomas on 23-06-2002 at 05:10
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
Hi Gary:
Thanks for the attempted quick turnaround on these!
quote: 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! 
quote: 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?
quote: 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!
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
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.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:17
|
|
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.
Last edited by LDiCesare on 25-06-2002 at 14:41
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
quote: 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!
quote: 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?
quote: 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:
quote: 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! 
quote: 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
|
 |
New Zealand
Mar 2001 time: 17:17
|
|
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
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
Good progress, since the last update, a Lot of the items are gone, thanks expecially to Gary. The tutorial is starting to be a bit of fun with the barb incursions, and their being hard to predict!
The list is not in priority order. A preponderance of the items are discussed in posts in the D7&8 thread if the short version doesn't make it clear what needs to be done. X = done. I have eliminated most of the old ones that have been taken care of, and only leave Xs if some small part remains to be done. FE the code may be there to do it, but the scenario file doesn't have it implemented.
Numbering scheme changes after 15 to that in bugs and features lists, any further D7 todos will go in either the bugs (- prefix on number) or feature list (f prefix) and be handled with those numbering schemes.
If anyone wants to sign up for particular bugs, just list the number(s) you want to go after. Some of you new coders could help with this when you finish or want a break from your starting projects.
Comments, criticisms, and suggestions for additions and deletions welcome!
Note because of my vacation schedule (a week, starting July 6), its possible we will move on to the D7.1 stuff before having an official D7 release.
X 2. Ship boarding GUI (Gary) [tentatively leave for D7.1]
3. Small AI improvements per my suggestions in the D7&8 thread (parts waiting for 7.1)
X AI takes over just plain squares once cities taken
More AI stuff detailed below.
7. Dawn tutorial (Mark, a bit more than half done as I write this)
X 11. Victory Conditions Dawn1 - add achieving building of a chariot unit (Gary)
Done in code and xml but not tested
13. Difficulty levels as separate scenarios for now. FE Dawn1 and "Dawn1 Hard". There may need to be two versions of the Hard one in Delenda, since there could be a "hard playing Romans", and similarly for the other side. (Mark, don't know yet if we even need this)
X 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. (Gary, deferred to D7.1)
15. Another AI problem was that sometimes AI forces just sat there even when there were plenty of city targets available. (Mark will fix if can be done in a few hours)
-----------------------------------
Numbering scheme changes here to that in bugs and features lists, any further D7 todos will go in either the bugs (- prefix on number) or feature list (f prefix). Name in parentheses at beginning is person who identified/requested the bug or feature. Name in brackets at end is person who has taken on fixing it. Volunteers needed!
-129 Got message that roads were planned but none set aside even though I did have an order for road building, and was part way through building one. I had other orders that preempted it. [low D7] ***[Mark]
-141. (Axi) Pathfinding doesn't seem to take advantage of roads. [high, D7 or 7.1] ***
-152 either eliminate Ruler button or mark gui as "Don't Touch, for Display Only" or some such [Mark] ***
f72 Economic consequences of battle -- The two armies share the square, fighting every turn. But there seem to be no economic consequences to this raging battle. [medium D7 feature, mark will try to implement] ***[Mark]
f149 (Richard) There should be some kind of home field advantage. Cities fall over way too easily. Maybe in city battles we should generate free horde units to represent militia. When the city is attacked, the units join the defending TF. Then they return to civilian life when the battle is over. [d7.1 or D8, we have talked recently about an auto-mustered militia].
X F151 Road building delay needed, so roads can't be flash-built. Also way to figure out how much resources to use... Too long to duplicate here, see feature list. [delayed per Gary suggestion till D7.1]
f159 (stickdude) I don't know how far along the economic model is, but it would be nice to see some highlights in the "Information frame" at the end of each turn, like income, spending, and current cash balance, units to be produced next turn, etc. [med d7] ***[Mark]
F160 (Mark) Put in a method where I could check if a tech has changed "Significantly"? Say we define significantly as the first time the tech reaches every step of 0.1. During that turn it would say its changed significantly, and then reset so it doesn't come up again till the next step level is achieved. Then I could show the player the info only when those changes occur. What are your thoughts on such a thing? I think it would be useful longer-term also, though with an adjustable step size. [Gary]
-----------------------------------
Small coding projects, for coders new to the project
map editor
xml editor
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:17
|
|
I checked the game today and want to add one feature and make a few comments:
Feature - it is just considering a fight is won if the enemy considers its odds are too low to keep ground. Currently, it is checked in-battle but not after-battle. I must playtest it when it works, but it combines retreat and Mark's odds so I think it should please everyone.
Comments
- I am a bit uneasy about the fixed-turn event messages in Dawn. The first play I made I mistook east for west. Okay that is silly, but I got everything 2 turns late and that was a bit hard to play afterwards. Even following the messages, the horses events are quite puzzling. I am not sure where the horses are, although sometimes I see an icon. I don't understand what happens with them. Only once did I manage to get the domestication tech bonus, and I was quite surprised when I saw it. Probably just checking the horse/late messages would be enough to make the dawn demo real good.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:17
|
|
In think all events should be event-driven, and we should try to avoid as much as possible the appearance of two bulletins on a single turn, as it is disturbing when you have two or more of them. Iconifying them would be a solution to that problem.
I usually avoid fight as much as I can. It is really funnt to get a message that barbarians are fighting themselves in the south. This means that most barbarian events are useless right now as they don't move. However, as the plaer doesn't know that detail, they work quite well. I agree that the penultimate barbarian army is quite useless. The last one is not, however, as it scares you a lot when you discover the huge power circle. Problem is it shrinks after a while probably due to lack of supplies.
To sum it up, three invasions should be enough. The first one to force the player to react to the possibility, the second one to test him lightly, the last one to conclude the game on a grand battle. More is unneeded.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:17
|
|
Hi Laurent:
quote: Originally posted by LDiCesare
It is really funnt to get a message that barbarians are fighting themselves in the south. This means that most barbarian events are useless right now as they don't move. However, as the plaer doesn't know that detail, they work quite well. |
Hmmm, this used to work more or less ok, with some occasional glitches. I'll see what's going on when I playtest the latest in a few minutes!
quote: I agree that the penultimate barbarian army is quite useless. The last one is not, however, as it scares you a lot when you discover the huge power circle. Problem is it shrinks after a while probably due to lack of supplies.
To sum it up, three invasions should be enough. The first one to force the player to react to the possibility, the second one to test him lightly, the last one to conclude the game on a grand battle. More is unneeded. |
I'm comfortable doing it the way you suggest... Have to find out where the supplies are set and increase them to avoid the bug!
|
|
|  |
All times are GMT. The time now is 05:17. Apolyton Time is 00:17. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|