Demo 8 final planning

[Mark_Everson]

Hi all:

It seemed worthwhile to start a new thread for the final push for demo 8. I actually have some time to work on Clash over the next few weeks, and thought I would start with a bit of organization. I'm doing this on the forum rather than by e-mail so that anyone can comment on the decisions we're making.

In order to get the demo out in a reasonable amount of time, I propose that we pretty much stopped doing new things, and concentrate on making sure that what we have works. I view the social test scenario as the big new thing in this demo. It seems to work pretty well, and shows at least one major aspect (dependence of rioting probability upon government policies) of the social and government models. Another big improvement is in the AI! It has come a long way from what we had before. Kudos to Laurent.

Alms has also done a lot of work on the scenarios, and I think that the social scenario will be a lot more positively received because of his introductory comments to it. He and I have discussed the ACME scenario, and decided that having it for demo eight would result in too much delay. We could possibly include it as-is on a "coming attractions" basis. We will have to see what the pre-demo play testers think.

Assuming that there is buy-in for my proposed approach , I have a few suggestions. Everyone that is willing and is not fixing bugs in the code should join in on testing the scenarios and suggesting any changes that seemed critical to their success. The more people we have pre-testing the better, since different playing styles will undoubtedly expose more bugs. We have alms, me, possibly Vovan, and potentially Manu, to push this forward. The bugs and feature lists are quite out of date, and I will try to update them and post them immediately below. However, as I said, we really shouldn't try much in the way of new features at this point. The critical thing is to get out a reasonable-quality demo as soon as practical.

There is one exception to my proposed new feature prohibition that I would like to put forward to see what people think. Numerous people have complained, and still do, about the "whack-a-mole" nature of having to chase down by hand small enemy units. These enemy units can be generated either by units of another civ sneaking by your main forces, or appearing due to rioting. If we can come up with a quick and dirty fix for this problem before the release of demo eight, I think it would be well worth it. I'm going to start a new thread on this issue, since it will require some brainstorming that would detract from the higher-level discussion here.

So, first of all, do people agree with my proposed way of doing this? If not, what is your counter proposal? Secondly, if there are any further play testers available for the pre-demo eight code, please volunteer here, or shoot me an e-mail. Finally, are there any other critical small things other than bug fixes that we need to consider that would make the demo a success? I think that a few brief discussions of what critical next steps are for demo 8.1 would not be inappropriate here. But we need to keep the focus on what we can get out as demo eight soon.

Thanks, especially to Laurent, and more recently alms, for all the hard work that made this new demo a possibility! And, of course this demo builds on the hard work in the past by many others including Gary, Laurent, Vovan , and about ten more.

Let's get this baby out!

[Mark_Everson]

This is the Bug List - current as of Dec 19, 2004 (v38)

I have assigned priorities to all bug and small feature requsts they are noted in square brackets at the end of each item. Feel free to question my priorities. If there is enough clamor that something I rate low is of high importance, I'll change it...

Most outstanding bugs are minor and will be addressed within the next few releases. I have eliminated many old bug reports that I personally haven’t seen in a long time. If someone sees a previous bug that I’ve gotten rid of, please let me know. All bugs have a ‘-‘ prefix to distinguish them from the small feature requests, which have a ‘f’ prefix.

An 'X' in front of an item means it has been fixed/addressed. Usually the X items are left for a while in case the same issue comes up (the implementation may not have worked completely).

I have put the newer bugs at the top of the file, and relegated the older ones to the bottom. Note that there is also now a web-based bug reporting system. I will try and transcribed the bugs reported there to here also, so that we can have one-stop shopping. The web site is at http://www.vovan.net/bugzilla/. I will usually omit stack traces and such for the errors already reported at bugzilla

Numerous bugs have been found by alms and others, and many of them have already been fixed by Laurent. If you see a bug reported in one of the demo eight or scenario threads that is not here and seems important, please report it to me, ideally in the format below.

[D8 Medium priority]

-170 (bugzilla bug 4) - mini map
In playing around with the testbed today, trying to find the map size that would fill the entire minimap screen, I discovered that generating a map larger than:
width=67
height=134
causes a problem with the minimap as seen in the attatched image. I didn't go further to test whether it was the width or the height because, as you may have noticed, I was trying to keep the map square.
[low priority]

-171 Econ bug - social
java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification( AbstractList.java:444)
at java.util.AbstractList$Itr.next(AbstractList.java: 417)
at game.economics.Economics.allEconomicsTurns(Economi cs.java:98)
at game.economics.EconomicsTurn.(EconomicsTurn.java:23)
at game.manager.Turn.run(Turn.java:79)
at java.lang.Thread.run(Thread.java:536)
[low priority]

-172 In the process of looking through the code, I discovered another problem In SquareClass summarized below:

* @todo this method assumes kapital level per population is 1 and hat
* population in the new square will equal average for the civ. Both of
* these assumptions can produce very inaccurate results. (Mark)
*/
public float getPotentialEconomicValue(Civilization civ)


X172 Delenda EncounterManager bug – during active combat and units moving through each other.

java.lang.NullPointerException
at game.military.EncounterManager.meet(EncounterManag er.java:152)
at game.ai.FightSimulation.simulate(FightSimulation.j ava:88)
at game.movement.orders.MovementOrder$SingleMovement. checkImmediateDestination(MovementOrder.java:434)
at game.movement.orders.MovementOrder$SingleMovement. carryOut(MovementOrder.java:268)
at game.movement.CollisionManager.execute(CollisionMa nager.java:209)
at game.movement.CollisionManager.mediate(CollisionMa nager.java:128)
at game.movement.MovementTurn.(MovementTurn.java:46)
at game.manager.Turn.run(Turn.java:78)
at java.lang.Thread.run(Thread.java:536)
Laurent: I don't really understand how this can happen, apparently I'm passed an empty list of units somewhere but that seems checked. I made a quick fix to return before because if there is no opponent civ, then the attacker should be victor.
So this shouldn't happen again, but it is a bit strange.

X174 (Mark) I haven't been able to get the victory message for either the Delenda or Attila scenarios. Something must be wrong in either the XML or code on extermination victories.

X175 (Mark) there appears to be a bug when a province changes hands due to the capital being conquered. In the new conquered province, the capital ends up being moved to some little square off to the side somewhere, rather than the former capital city. I had a case in the social scenario where the Persians conquered some little side square in Asia minor and flipped the whole province because it had become the capital unbeknownst to me. It was also a bit odd because I had troops in the former capital, and I thought the whole province wouldn't flipped if there were still defending units.

First square conquered in an existing province becomes the new capital. Unless conqueror switches it back to the original capital, it will remain in the first square conquered.

X176 ACME bug (Mark) 20+ turns in, a lot was happening, no idea what special happened that turn.
java.lang.NullPointerException
at game.economics.SquareEconomy.calculateProductionIn AllSectors(SquareEconomy.java:265)
at game.economics.SquareEconomy.economicsTurn(SquareE conomy.java:213)
at game.geography.SquareClass.economicsTurn(SquareCla ss.java:255)
at game.population.Migration.colonize(Migration.java: 286)
at game.population.Migration.carryOut(Migration.java: 251)
at game.population.PopulationTurn.migration(Populatio nTurn.java:78)
at game.population.PopulationTurn.(PopulationTurn.java:30)
at game.manager.Turn.run(Turn.java:80)
at java.lang.Thread.run(Thread.java:536)

It was caused by a SquareEconomy without a PrivateSector. Maybe due to initial population of 0, which results in no creation of PrivateSector. Seemed from the code that this shouldn’t happen though. I put in a patch and diagnostic message to try and figure out why this happened.

-177 (Mark) Attila scenario -- the Huns can't build military units (even as player). They can't build anything, even warriors. Huns can build other stuff like roads, so it is something in the isBuildable chain of stuff for military units at a guess.


OLDER BUGS

-55. When there are too many enemy TFs on a square, right-click does not produce a pop-up window with the details. I noticed this when I let the AI grow huge armies (by turn 80). By that time also the power circle of those mega-concentrations vanishes, cause it's too large and it gets buried under tiles further away which are probably refreshed after that. [don’t know if this is still a problem, low priority, D8]

-116 When econ orders frame comes up first the many little text areas appear with no frame around them then the rest appears. Not critical, but any ideas how to fix this? It didn’t happen in D5. [low priority, that interface will hopefully be completely replaced for D8]

X159 (MacHatter on a Mac)Buttons in population transfer dialog are too narrow (text on the "transfer xxxx" button is truncated) [D8]

-160 (MacHatter on a Mac) Path finding problems-units don't use roads, even if it would be quicker
TF at 11,12 goal is 5,8
Road from 7,14-5,11-5,9
Default path (5 turn)
11,12-9,8-5,8
better path(4 turn)
11,12-10,14-7,14-5,11-5,9-5,8

TF at 3,12, goal is 7,14
Road from 4,12-5,12-5,11-7,14 (arrives 2 (first))
Default path (arrives 2 (2 turn 2 markers))
3,12-5,12-6,14-7,14
Better path (2 turn, (1 turn 2 marker))
4,12-5,12-5,11-7,14

(Mark says) not sure if this one is really a movement bug. There is a bug, but it may be in the little red circles that show turn numbers. I duplicated the results posted by Andy, and verified by pgrignon, but they Don't Match actual movement times, which are 5 turns in either case. [med D8]

-163 (Mark) Triremes not on build list in Delenda, neither is the cavalry unit Hannibal has [med D7.3]

X164 (Mark) When population of a square is taken away so that square pop is now 0, square doesn’t change possession when conquered. At least it appears to take special circumstances for it to be conquered, although it can happen eventually. It appears the code to change square possession is ignored if pop = 0, suggest the test become if the square has an administration it can change hands. I looked for the code, but couldn’t find it after about 15 min of looking around, so I quit. [Med D7.3]
Workaround: never remove all population from a square, just leave a few and its ok.

-166 (Heffalump/Mark) It looks like a bug has crept into the unloading menu code. Below is the way it usually works.

To unload:
1. put the ship on a coastal square
2. left-click on either a ship in the carrying TF or the carried TF and select the unload option.
That's it.

It looks like the bug is making those unload options not appear at first. This results in a very short set of options. A work-around is to select the transporting TF with a mouse click. This makes at least the unload option for the ship appear. Selecting the carried TF seems to make the unload option appear for those.

X167 (Heffalump) - In the Rome/Carthage scenario I retreated to Rome, made a stand and defeated Hannibal, then counterattacked north. I recaptured my northern city and pushed on. Then Carthage had it's greatest victory. I divided my 8 or 9 unit army up into multiple units, then tried to re-form it into 2 separate armys .... and it just disappeared. Gone. Oh well, that put a serious crimp in my invasion plans! (The bug seems related to one of those assign unit to TF commands).

I've played around with it a few times and as best I can tell, here's what I think happened:

In the Carthage/Rome scenario
1. Pick Carthage
2. Goto the big stack at 2,4
3. Split the big TF into seperate TFs using the respective command
4. Right click on Hannibal (which is probably the default selected unit) and click Assign Unit to New TF
We're now in a situation where none of the Units are "selected" but the commands to do things like Add Unit to Selected TF are still visible. Use that command on a unit (without "selecting" any units) and you'll see it disappear into space.
Similarly, right click on a unit and do "Merge units into selected TF" and they will all disappear.


Command line switches (Must be in command line mode (FE batch file) to use):
-ef = error logging to a file
-noAI = no AI movement
-seed = random numbers use constant seed for reproducible behavior
-800x600 = start in 800 x 600 res mode to simulate 800x600 screen
-allecon = allows access to economic orders/info for non-player civs
-nopatrol switches off patrolling in addition to militia. “Patrolling” lets militia be formed for defenders even if a square is empty of friendy units, and militia will help in the order: Those who discriminate less against them, those whose preferred ethnicity they are, the defenders.

Full information on command line switch usage is in the testbed readme file

[edit, some new bugs and bug fixes]

[Mark_Everson]

Consistent with my initial post above, we will not be trying to add much in the way of new features before getting out demo eight.

-Mark

This is the Feature List current as of Dec 19, 2004 (v33)

Feature Requests. Frequently it is a judgment call what’s a bug and what’s a small feature, please just accept what I call it… All feature requests will have the prefix 'f' to make it easy to distinguish if it’s a bug or a feature ;-)

I have assigned priorities to all feature requests - they are noted in square brackets at the end of each item. Feel free to question my priorities. If there is enough clamor that something I rate low is of high importance, I'll change it... All bugs have a ‘-‘ prefix to distinguish them from the small feature requests, which have a ‘f’ prefix.

An 'X' in front of an item means it has been fixed/addressed. Usually the X items are left for a while in case the same issue comes up (the implementation may not have worked completely).

Starting with recent requests at top -- I (mark) will only add a priority to these if it seems needed for D8. Feel free to vote

F174 (Alms) Need to add the ability to select multiple units and combine them into a TF, which currently isn't possible

F175(Alms) Need to add "Center on Selected Tile" in the right click menu when over the main map

f176 Shouldn't desert have some sort of farm or resource site so people colonize desert? After all, the earliest civilizations grew up in deserts (granted they had river valleys, so this may be moot).
Mark said: Desert already has farm sites, and you can colonize it. FE in Dawn you can plunk a thousand people down in the desert and they do ok, even if they don't thrive. People tend not to auto-colonize desert, because, while you can live there, it sucks.

f177 (Alms) Need to add some indication of when the next unit will be built (Edit: Noticed this is on the feature list as f69). Same for next tech discovery, road segment built (Edit: See f155), and wall built. For the road segments and walls, a graphical overlay could be displayed showing that it is "under construction." For the tech, I'm not sure without having to rebuild the entire interface, that there is an easy way to do it. And for units, again I have no ideas on this one, other than a progress bar on the current econ interface.

F178 (Alms) Add ‘actual’ numbers next to percentages in the social panel. For example, if 59% of your population is Roman display:
Roman 59% (53,054)

F179 (Alms) ( continued from previous) It would also be nice to have a hyperlink rather than text. The hyperlink would open a new panel giving breakdown by the other two categories (of the three – social class, ethnic group, religion). So, to continue the example above, when “Roman 59% (53,054)” is clicked, a panel detailing Social Class and Religion for Romans is displayed, and looks something like the following:

Roman 59% (53,054)
Social Class: Religion:
Aristocracy 5% (2,652) Roman Paganism 85% (45,096)
Warriors 20% (10,611) Greek Paganism 10% (5,305)
Workers 75% (39,791) Celtic Paganism 5% (2,653)

f180 (Alms) Roads - These should not automatically begin on the tile selected, you should select start and finish. Even though it involves that dreadful "extra" click, it somehow seems more "right" to me.

f181 (Alms) When rebel units form & I “repair” the cause that brought them forth (I'm assuming the cause is that listed under the riots entry in the events panel on the turn the unit was created), I expect to see the units disband back into the population eventually, though I never have.

f182 (Alms) Hyperlinks
Add Hyperlinks as in the Events Panel to the following:
-Civ/Province Econ Panel (military elements) - link to info on strength and such here, currently can't tell which is the stronger unit to build.
-Tech Panel - link to tech info showing new applications available and obsolete ones also.

F183 (Mark) in scenarios like Delenda it is far too easy to flash-build walls. There probably should be a delay, or larger costs associated with city walls. The way it is now Wall-building speed is vastly different from Army unit movement rate timing. This gives the defenders a big advantage. We don't necessarily have to do anything about this for demo eight , since people can always put in their own delay "by hand" for testing purposes. It's just that if you flash build walls it makes it very easy to win some of the scenarios.

F184 (Alms) Transitions. Clash should have 3 types of transitions, normal, cluster and coastal. Normal transitions are those which extend from the tile into an adjacent tile (about 1/4 of the tile), and are the most widely used and known.

Cluster transitions, rather than extending out into an adjacent tile, occur within the last tile itself, leaving about 1/4 of the tile as “flat”. These flat areas can be transitioned into by normal transitions. Cluster transitions are the type used by woods (forests and jungle), hills and mountains in the Civilizations series, and should be used for the same purpose in Clash.
Further info and Discussion at: http://apolyton.net/forums/showthrea...81#post3511781

F185 (Mark) Should have an indicator on the map that shows where provincial and civ capitals are. Maybe a star in the civ color, or a flag or something. Also put in a target flag in the AI so that provincial capitals can be targeted specifically.

- - - - - - - - - - - - - - --
OLDER Requests

f63 The units are shown jumping from initial to final state, without me seeing their pacing. [actually there is an update by tick, but its fast on some machines] This is crucial for gameplay, so sliding of units (like in civ2) has to be introduced. [IMO sliding speed of units should be selectable by player, with the choice included of no sliding (or very little), low priority]

f69 One thing that is needed is some way to know what units are projected to be created in each square and when. Put this in the details frame or the econ info window. Or rather make a city screen, like in the ole civ2! Integration is the key. [D8+ nice to have, but not essential, wait for new econ gui to do it]

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 D8 feature, need to discuss implementation]

f74 One thing we could use when there are multiple TFs in a square is whether they have movement orders or not. Perhaps you could just put the same red circles you put on the path. So a circled 2 in a TFs box would indicate that it has moves for two more turns registered. This is not urgent, just thought I'd mention it.
[Click on the details in the popup menu to get this.]
[If I have to click on every TF to see which has orders it is just about a useless capability. I should be able to See from the TF box which ones have orders. This is not urgent, but needs to be handled in some way to avoid player (read ‘Mark’) frustration. [eventually need, medium priority, D8?]

f108 Unit details issue. With two TFs in a square right-clicking always gives details for the one selected to move (white outline on box), not the one you rt.-click on. [Very counter-intuitive, but it is the spec for now. Selected TF is one right-click gives info for.] I (Mark) would like to make it a feature that the one you right-click on is the one you get move orders for. If the click is not identifiable as pertaining to a given TF or unit, only then would I have it apply to the selected (white box) one.

Gary Commented: The reason it works the way it does is that a right click selects a UNIT, not a task force. It has the function of allowing a single unit to be moved to the selected TF. Mark's problem is that he does not appreciate the difference between a right click and a left click (which changes the TF selected).

(Laurent comment) Maybe highlighting the selected unit (instead of TF) would help understand what right click does. This is particularly interesting when you move units from one TF to another. A multiselection could even be useful.

(Alms) For the units box, rather than showing the hundreds of icons of each unit type present in the square as now, we should show a single icon for each TF present within the square, with the relevant combat info besides each (attack / defense / Health / Personnel/ Transport Capacity). If the player wants to manage the TFs/units in that square, have an army management screen where the player can combine units, split units, ditto for TFs, disband units, etc. Doing this, I would hope, could allow the units box to get smaller (or eliminate it entirely, preferably), while showing more useful info, and allow us to add more info to the detail frame. Things that come to mind for the Detail Frame are the general happiness level of the square’s population, Specials present, trade route present, or growth rate of the square. I'm sure there are lots of other things we can think to include here.

What do others think? [no priority until we get more input]

f118 “hide events” should also hide the detailed description boxes associated with events. Actually closing them would be best so that we don’t end up with hundreds of little event boxes accumulated and hidden from view by the end of the game. [medium priority, D8]

Xf135 Events suggestion from Laurent -- Events should appear in reverse order. Currently most recent is on top. I had an army fight 4 times in one turn (poor they). The display should have shown events: Health
9->1.5, 1.5->0.8,0.8->0.6,0.6->0.4, but it was the other way round. [medium priority, D7.3]

Xf135b (Mark) Related issue, looks really silly to be notified 10 times that identical units are being built. When more than one of a given unit is built in the same province the events should say FE "3 Legions built in [1,1]". To do this all that is needed is to make a pass through the events and count any identically-named ones. Then re-name the first and cull the others.
(Alms, related to f135b) It looks silly to have riots[x,y] listed 20+ times in the events box, and it sometimes makes the box too long to fit on screen, if there are lots of riots. Would be better to have a single "The people are rioting!" entry, and the player clicks that for more info. The reason this is related to f135b is the same would happen if you built that many units in a single turn. IMO this extra 'click' is justified.
[low D8+]

f136 Combat Reports -- At some point there should probably be a breakdown of number of units of each type on each side, but its not urgent. Also unit power, health, etc should probably just be reported as integers. Health 23.4857392 is a bit disconcerting. [mostly fixed, but sometimes a long string of numbers seen]

f138. (Axi) The movement path of the units is drawn on a layer below the units and the power circles, resulting into it being hard to see sometimes. It should be always drawn on top.
Gary Commented: Absolutely not. Please believe me, it would look awful.
Mark supports Axi’s original desire since when moving a TF, That is the focus, not the graphics for other units, cities, etc. What do others think?
(Alms) I vote over... not a high priority though, since I can figure out how long the trip will take myself.
[medium, D8+]

Xf140. (Axi) For players that do not use the same colors as the windows default appearance, the area where you can toggle between traditional and market economy bears the color of the window, while the surrounding area bears the color of the windows default appearance. (I am using a blue-gray tone which makes the thing rather ugly). [ignore, that interface will be history soon anyway]

f142. (Axi) The TF box does not need to have a gray background. In demo 4 it had the flat ground for background. Please bring that back and make it so that the background copies the tile which is currently selected.
Gary Commented: The tile does not have the same shape. Anybody wanting this is cordially invited to provide the images. I won't.
Mark thinks we could at least tile with a nondescript green background as in D4 easily (I still have that tile, and we could just use it). I agree with Gary that trying to put the correct terrain behind would require a lot of artwork effort, and is of very low priority, especially since we have No Artists at this point on the team. [Low, D8]

f144. (Axi) Since we can save window settings now, how about adding the general settings (fog of war, hidden map, TF selection and whatever is added next) into that file?
Gary Commented: They are not intended for that purpose, they are really a debugging aid, not a feature of the game.
Mark says: TF selection should be at player option, and why not the others? I think Axi’s request would be useful during the remaining year or more of debugging we have. [Low, D8]

f145. (Axi) Shouldn't there be "back" buttons in all the launch screens, along with the "exit" ones? [Low, D7+, some back buttons would be difficult to implement due to program load sequence]

Xf146. (Axi) The [econ orders] reorder button seems to be reordering infraclasses by groups. Perhaps the expandable list idea mentioned somewhere above should be implemented, providing us with a much nicer representation of expenses. [ignore, econ interface will be completely replaced soon]

f147. (Axi) I feel that it would be ergonomically better if we could have a merged window for both civ, province and square orders, where we could give orders side by side. Also an option to clear all orders on each level would be swell.
Gary Commented: In my view this is the most critical improvement required after D7. The present system gives a horrendous amount of micromanagement, since the panels must be checked and modified every turn. [High D8 replace the existing econ gui]

X 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. [This has been addressed by Militia in D7.2, walls in D7.2 also help, will revisit if needed].

F151 (Laurent) road-building is pretty fast for me (again, I always put LOTS of kapital in it but even then, 12 squares including 2 hills and a mountain in one turn, it seems a lot).
Mark said: But part of the reason its so fast at 30% road building and above is that 30% is an Enormous amount of resources to put in roads.
What real 'civ' spends more than a few percent of revenues on road-building? There are so many other competing demands...
Laurent said: Yes, but in the game, which is not a simulation, it seems weird. There are so many things the player doesn't see, that roads, which are something he sees (and not in a lost menu but on the map), should have more importance than in real-life.
Anyway, players need feedback on how much money to put in the road-building (so I don't put 30% where 5% is needed), and they can stage it over several turns.
My suggestion, maybe put in an arbitrary delay for road building so it happens over time. This would also prevent flash-building of roads during an invasion. Maybe an automatic 2-turn delay between order and building? [low D7.1]

F152 (Blakis) Why can't I just use the arrow keys to move a unit one tile at a time? This was implemented by Gary, but seems to have become broken, probably fixable with relatively little effort [med D7.3]
Boomer/Aaron fixed this. The only issue was his fix requires use of CTRL+ARROW because the ARROW keys were being eaten in some component before we even see
them. Need to track down problem so CTRL not needed [low d8].

F155 (axi) Roadbuilding could use the same code as pathfinding to show on the map the number of turns in which each road segment will be built, with priority based on the order with which the orders were given. [Low D8?]

F156 (Axi) There should be an option to make visible all friendy TF paths on the map. It would also be nice to have a preview of where each unit should be next turn, if nothing intervenes. This is in anticipation of future major wars. [med D8]

F157 Make it so pathfinding into the black doesn’t give away terrain info [med D8]

f161 (twinge) Another irksome style you use is how the menus work. When you click on a menu that has more than one option associated with it (IE, almost every single menu) they pop up somewhere else on the screen. I find that pretty annoying; If it was done similar to standard windows submenus (where you move the mouse down to the menu target, and the submenus pop out--like the start menU) that would be ideal. Something close would be good too; right now it's quite odd =) Perhaps having that fixed by D8 would be good.[thoughts on this?]

f163 I (Mark) think the new event-driven bulletins work great, thanks for doing it Gary! Some of the bulletins were designed by me to fill "down time" when nothing else was happening. Unfortunately now they can occur when other event-driven bulletins come up. One thing that might be good is to have an event class that says "show on turn 10 or thereafter, but only when no other bulletin is being shown" How hard would that be? If two or more of this type would come up on the same turn, the one with the earliest turn number would be the one shown. Seems to me it would really help in streamlining the tutorial. Also some things I had listed as showing at "event X + 1 turn" seem to show at the same time as event X. [low, D8?] How much does the multiple-bulletins in the dawn tutorial bother people?
(Alms)Multiple events popping up isn't really a big issue for me, though some scenario designers might demand the "fix" suggested by Mark here, so I vote yes.

F164. Horses is listed as active even before you discover the horses resource, doesn't seem right. [leave pending discussion in tech thread on this topic]

F165 (Richard) I am constantly splitting off armies to retake the squares they walked through as they slipped by my armies. More micromanagement. I want to set up a border patrol, but the only way to do this now is to station an army in every square. That would be hideous micromanagement, especially with my civ expanding.
(Laurent comment) This one is quite serious in Jericho in particular. Automatic taking of a whole province under some conditions would help too (like controlling capital + opponent having no troops in the province). That would force AI to target capital and be a bit easier to intercept. Maybe it doesn't solve the problem. A "border patrol" order could also be implemented so that a TF with this order would move to reclaim territory lost in its protected province, or would move to a square of it sprotected province if there is an enemy in a neighbouring square. Note this is crude AI and is prone to abuse, but it seems feasible and could help reduce MM. Longer term, the TF(command) should be able to split so as to send only that number of units is needed to do the task so it can better react if someone attacks from somewhere else. Priority as far as reclaiming territory would have to be set to either eliminate opponent units first or reclaim territory first. I think the former is better in order to avoid armies running around one another in circles.
[we need something like this eventually, probably needs to wait for the real AI, D9?]

F166 (Richard) I have discovered an abusive strategy. It allows one small army to plunder an entire enemy civ. What I'll do is march one warrior into the outskirts of their civ, claiming the square. Then I have the warrior pick up all the people and move to another square. I then pick up all the people in the second square. Since the first square is empty, they will send about a thousand people to colonize it. I then march my warrior back to the first square and pick up those new colonists, leaving the empty second square which will also be colonized again.

This can continue until their population is too low to colonize anymore. At the end of this process, their entire civilization had about 4000 people and my lone warrior was escorting over 11,000 of their people. They had a big task force on their capital, but those armies just sat back and watch me steal all of their people.

Often, they would colonize a square that my armies were actually standing on. That seems wrong. [we need a fix for these issues, ideas?, medium D8]

F168 (Kull) Task Forces: How do you take units in a single tile and group them into multiple task forces? It would be nice if you could use something like "Shift-click" to highlight multiple units and group only those selected. [D9?]

F169 (PGrignon) After re-playing several time the Dawn Scenario on my small machine (iBook, 128Mb, 800x600) here are some features that would be great to introduce.

Features:
- Ability to choose a different font.
- Hot Keys and shortcuts for switching windows
- Contextual menu on Units in Overall map.
- Using keyboard arrows to scroll/pan.
- Settings for not storing traces ?
- Overall view of all the units/task forces. (maybe organized in a tree view).
Civ:
- Province1
-- U1,
-- TF2 (#Units)
- Prov2
-- TF4
-- TF3
- Is it necessary to get all the econ indicators ? Hide show some of them ?

F170 (Martin) It is unrealistic and quite anoying that you can claim a number of tiles by simply passing through them. This is OK as long as there is no (and in some cases very few) inhabitants, but generally you should have to remain some time in an area populated by a different nationality than the invading army. One solution could be to add an occupy/conquer order. The time used to cary out this order should then be calculated based on the atackers strength and the population. A note here is that liberating accupied tretory should be easier. A nice touch would be to make provinces have a chance of revolting if owner is not native.
Naval units should not be able to conquer land tiles. Land there yes, but hold forein terrain no. And they should be penalized for fighting while docked/beached.
[need to discuss exactly what to do, but these are clear issues]

F171 (Mark) If build location has a name I would like to see it in the Events list rather than just [5,8] or whatever the location is. I would go further and say that if there is a name, there's no need for the coordinates. [low D7.3]

F173 (Mark) We should label ports somehow so the player knows where they are, but that's a bit less urgent. Maybe an anchor graphic? [low D8]

---------------- Requests for manual / tutorial topics -----------------------

(Alms) Unload option from naval units (also don't know how many units naval units can hold - see suggestion for the unit box reworking above for a temporary solution.) I saw this mentioned while going over the bug list, though I never knew it existed.

(Alms) Disband Unit/TF settles the current square if unsettled/adds back to population otherwise (we should probably tell people about this in the demo)

And the graphical features I’d (Alms) like:
Larger Tile Support:
http://apolyton.net/forums/showthrea...59#post3483459
Varieties:
http://apolyton.net/forums/showthrea...55#post3485155
Transitions (I’ll be posting something in detail later).


---------------- Keep this at bottom due to its large size -----------------------
F158 LARGE number of detailed suggestions by stickdude on the interface. Not high priority but useful to go over, maybe for D8. Some of the nonfunctional things he specifies should probably be taken out before D7.

---
First, I double-click the ClashD6_12.jar file, and I see the ...

"Select the option" screen
1. No splash screen, or opening movie... That's ok. The opening screen looks pretty good, and it works.
2. I know this is picky, but "Select an option" sounds better to me than "the" option.
3. The logo is a button, which seems odd.

I click on "Select a scenario" and up comes the ...

"Select the scenario" screen
1. Should this be resizable, or a fixed size? I vote for fixed, since it's acting like a dialog box.
2. Again, the logo on the left size is a button. Should something happen when I click it (right now nothing does happen)?
3. "Carthago delenda est" is the title of the first scenario. What does that mean?
4. I can delete all the text from the scenario descriptions. Should they be read-only, or better yet, not text boxes at all (see below)?

Here's what I'd expect to see on this screen:
1. All the scenarios are listed, but in a bigger font, and without descriptions. They aren't buttons, either.
2. The logo is still on here somewhere.
3. As the user moves the cursor over the scenario name, the scenario name is highlighted somehow, or a box drawn around it, or something to indicate which scenario you're about to select; and the description is displayed in a different part of the dialog.

4. If the user moves the cursor off the scenario name, the description disappears (basic mouse-over behaviour).
5. If the user clicks on the name of a scenario, that scenario is selected.

Ok, I click "Select" next to the first scenario, and I see the ...

"Select the civilization" screen:
1. Logo = button...
2. While typing this, I forgot which scenario I chose. It would be nice to have the selected scenario and the description displayed here so I can make an informed civilization choice.
3. It would also be nice to have a short description of the differing goals of each civilization in the scenario. Again, this should be a roll-over type effect.
4. If I selected the wrong scenario, there's no way to go back and choose something different. I have to exit and restart.

I click on "Computer Only", and after a little while, up comes the ...

"Clash Demo 6.1" screen
Impressions:
1. The map itself looks very cool. It's not a cool as, say, Age Of Kings, but I can live with that.
2. I'm not sure I like having everything in different frames, like it's set up now. That could be because I'm used to having one main window partitioned into different setions, instead of different windows.
3. On the menu bar, "Options" and "Econ Options" don't have any options below them. They should be grayed out if there's nothing to select.
4. Since the toolbar simply presents the exact options as the menus do, one of them feels redundant.
5. I have to click on a square/unit for them to show up in the Units/Detail Frame windows. It would be really cool for this to happen automatically as the mouse moves over a unit/square.
6. When I click on a unit and it appears in the "Units" window, it's nearly impossible to read the text above the units. Yellow and Green on a grey background doesn't work too well.
7. Also on the "Units" window, scrollbars keep appearing when they aren't necessary.
8. It would be nice to have more information about the units in that window. Simply knowing that the horse icon on the map is really two horse icons doesn't tell me very much. What are the capabilities of the individual units, how healthy are they?
9. Ok, I just right-clicked on one of the units and saw the little pop-up box that lists what I was wondering in the previous comment. It's not intuitive, though.
10. I restarted the game and am playing as a human player, so now I can see how to create/disband Task Forces.
11. I just disbanded a group of 4 units into separate armies. The last unit is halfway out of the "Units" window, but there's no horizontal scrollbar so I can scroll over to that unit; only a vertical scrollbar, which I don't need.
12. I'm getting the hang of giving orders. Pretty cool, once you get the hang of it. I like the "nearest friend/enemy" idea.
13. If I have a number of different units in a square, and I want to form them into two different task forces, is there a way to do that, other than move half the units to a different square?
14. Can we rename the armies?
15. Can we change the "martial attitude"? Does everybody just attack for now?

I clicked on "Economics" and "Civ Econ Orders"
1. Gasp! What is this? Text boxes everywhere!!
2. I can delete/change any of the text anywhere. I don't think I'm supposed to be able to do that.
3. I've read some of the discussion about completely re-doing these screen to make them more user-friendly, so I'll just wait to see the new and improved econ screens before commenting further.
Other thoughts:
1. 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.
2. When I click "Next" in the Events window that pops up, it just disappears. I don't think it's supposed to do that.
3. I'd probably just use round numbers for the army attack/defence/health stats in the "Information frame". It looks kinda odd to see that my armies health is down to 5.2000003. Or better yet, why not just display them as percentages - i.e. "Health: down to 52%"
Ok, I've played 20 turns now, and the bad guys keep capturing my cities, so I'll probably end up losing. That's ok, though, because it's just a demo.
Overall, I'm quite impressed. The game clearly has a ways to go, but I can definitely see the potential.
---

[ edit: update list]

[alms66]

My only big comment at the moment is that I won't be helping with any more playtesting of existing scenarios. I'm far too sick of playing them (Dawn and the Social Test especially, since those two I played the most), which is actually the reason I started ACME in the first place, I wanted to play something new. Other than that, I agree with what you've said above.

Now, I guess I'll have to move my comments and requests from other threads here then? Or is this already being taken care of?

[Mark_Everson]

Originally posted by alms66
Now, I guess I'll have to move my comments and requests from other threads here then? Or is this already being taken care of?

If you could at least get together the top five unresolved bugs/issues or so that would be helpful. You can just email the text to me if you prefer.

Thanks,

Mark

[LDiCesare]

I agree that a feature-freeze is needed.

-168 (Bugzilla Bug 7) : crash involving movement - best guess when opposing TFs move through each other. Seen only in social test near the end.

Don't go where this stems from It looks the unit had no target destination and that produced the crash. I can't see how that managed to happen...
What's the Bugzilla thing you're referring to? Looks like a bug resources tracking thing but I don't know it/how to use it?

-169 (bugzilla Bug 5) : AI Planning Crash - this is a critical bug that Laurent already knows about, caused by commit 32 in code

Fixed, delivered code today.

-170 (bugzilla bug 4) - mini map
In playing around with the testbed today, trying to find the map size that would fill the entire minimap screen, I discovered that generating a map larger than:
width=67
height=134
causes a problem with the minimap as seen in the attatched image. I didn't go further to test whether it was the width or the height because, as you may have noticed, I was trying to keep the map square.

I don't think this is critical. There is some rewriting of the minimap that could be done, since it currently computes the size of the minimap once and doesn't recompute it if you resize the window. If you want that changed, I can try to allow the minimap resizing to recompute the image it shows, so it would fit the map at best (for D8 keeping a straight number of pixels for each tile - 1,2,3...- later we could do some blending in order to have a really good fit).

-163 (Mark) Triremes not on build list in Delenda, neither is the cavalry unit Hannibal has [med D7.3]

Vaguely related to that: The econ interface hides some orders which are otherwise available, for instance in the military frame. The causes have surely nothing in common, however. I'll look into that one.

-160 (...)pathfinding

The figures aren't refreshed correctly. I don't like it but don't feel compelled to correct it either to be frank as I believe the time taken is correct.

[Mark_Everson]

I agree with your evaluations, Laurent. Thanks for the fixed code, which I'm going to check out shortly.

On bugzilla... Vovan has set up a web-based bug entry and tracking system. Just go to http://www.vovan.net/bugzilla/ to start an account.

[alms66]

A question for pondering:

Shouldn't desert have some sort of farm or resource sites so that people colonize desert? After all, the earliest civilizations grew up in deserts (granted they had river valleys, so this may be moot).

If we decide not to adjust the sites, then we should provide some way for a civilization to claim these tiles.

[Mark_Everson]

Originally posted by alms66
A question for pondering:

Shouldn't desert have some sort of farm or resource sites so that people colonize desert?

Hey Alms:

Desert already has farm sites, and you can colonize it. FE in Dawn you can plunk a thousand people down in the desert and they do ok, even if they don't thrive. People tend not to auto-colonize desert, because, while you can live there, it sucks. The people are usually better off staying where they are.

[alms66]

So, were the map fully controlled by one civ or another, except for a desert tile or two, would those desert tiles be auto-settled?

[Mark_Everson]

Originally posted by alms66
So, were the map fully controlled by one civ or another, except for a desert tile or two, would those desert tiles be auto-settled?

I expect that desert will be colonized under certain circumstances. A target colonization square has to be economically better by a certain amount to stimulate colonization. If squares were very overpopulated for the tech level, and abutted on to desert then the desert would be colonized. The parameters could be tweaked to make desert more likely to be colonized. Just doesn't seem worth the trip to me at the moment.

[Brandomas]

I would love to play test the game, and maybe even do some work on the game. I have skills in web site design, writing, and coding.

[Mark_Everson]

Hi Brandomas:

Great we could use more playtesters. After that you could see where you're interested in other work. If you're set up for Java we can get you access to the repository. Otherwise I'll need to email you a zip of the files. First check and if you can run demo 7.2. If that works, then email me to get the latest.

Cya,

Mark

[LDiCesare]

I ran Dawn again after my latest changes, which are supposed to affect only combat. Chariots become available far too fast (before the first northern barbs attack) and are much weaker but the scenario is still winnable. It's just coming too fast.
I think we reached a point where all changes should be xml and the code is OK unless there's a big bug.

[Mark_Everson]

Originally posted by LDiCesare
I think we reached a point where all changes should be xml and the code is OK unless there's a big bug.

I pretty much agree, but there are two things that are problems with the scenarios that I think will bother the play testers. These are my candidates for potential modification:

The first is that there appears to be a bug when a province changes hands due to the capital being conquered. In the new conquered province, the capital ends up being moved to some little square off to the side somewhere, rather than the former capital city. I had a case in the social scenario where the Persians conquered some little side square in Asia minor and flipped the whole province because it had become the capital unbeknownst to me. It was also a bit odd because I had troops in the former capital, and I thought the whole province wouldn't flipped if there were still defending units.

The second issue is that in scenarios like Delenda it is far too easy to flash-build walls. There probably should be a delay, or larger costs associated with city walls. The way it is now Wall-building speed is vastly different from Army unit movement rate timing. This gives the defenders a big advantage. We don't necessarily have to do anything about this for demo eight , since people can always put in their own delay "by hand" for testing purposes. It's just that if you flash build walls, at least before your most recent changes, it makes it very easy to win some of the scenarios.

On the Dawn scenario... the timing of the appearance of chariots has been earlier since I increased the population and did other things to make the scenario winnable. I think if we reduce the contribution of the horses icon to domestication tech it can put the timing back about where it was before. I'll look into this if you don't get to it first.

[Mark_Everson]

One more bug...

I haven't been able to get the victory message for either the Delenda or Attila scenarios. Something must be wrong in either the XML or code on extermination victories.

I am going to update the bug list with recent fixes, and the new additions.

[LDiCesare]

The first is that there appears to be a bug when a province changes hands due to the capital being conquered. In the new conquered province, the capital ends up being moved to some little square off to the side somewhere, rather than the former capital city. I had a case in the social scenario where the Persians conquered some little side square in Asia minor and flipped the whole province because it had become the capital unbeknownst to me. It was also a bit odd because I had troops in the former capital, and I thought the whole province wouldn't flipped if there were still defending units.

Well, you should have checked where the capital was... The capital is always the first square that's been invaded, and you can see it in the information window. We could decide the new capital should be the former capital of the conquered province. I don't think it's that important, since you can check what the capital is.

The second issue is that in scenarios like Delenda it is far too easy to flash-build walls. There probably should be a delay, or larger costs associated with city walls. The way it is now Wall-building speed is vastly different from Army unit movement rate timing. This gives the defenders a big advantage. We don't necessarily have to do anything about this for demo eight , since people can always put in their own delay "by hand" for testing purposes. It's just that if you flash build walls, at least before your most recent changes, it makes it very easy to win some of the scenarios.

We should just increase the cost of walls. I built some in 2 turns in Delenda, which is far too fast I agree, so what would be a good timing? *3? *5? *10?

Victory messages tend to be clunky in these scenarios. As far as I remember, they have been that way for a long while. Jericho suffers from the same bug.

[Mark_Everson]

Originally posted by LDiCesare
Well, you should have checked where the capital was... The capital is always the first square that's been invaded, and you can see it in the information window. We could decide the new capital should be the former capital of the conquered province. I don't think it's that important, since you can check what the capital is.

Thanks for explaining it, I should have thought of that!

We should just increase the cost of walls. I built some in 2 turns in Delenda, which is far too fast I agree, so what would be a good timing? *3? *5? *10?

How about five times?

[alms66]

Mark,

1. Here's the link for my Transition Request, which you can add in your post above.

2. Why are all the graphical feature requests listed under manual/tutorial requests?

[alms66]

Originally posted by Mark_Everson
I expect that desert will be colonized under certain circumstances. A target colonization square has to be economically better by a certain amount to stimulate colonization. If squares were very overpopulated for the tech level, and abutted on to desert then the desert would be colonized. The parameters could be tweaked to make desert more likely to be colonized. Just doesn't seem worth the trip to me at the moment.

This still doesn't solve the problem of Egypt. They were surrounded by desert, which was for our purposes uninhabited, yet still controlled by them. I think it wouldn't be a bad idea to add a new unit order 'Conquer' or 'Control' which changes the ownership of a tile, even if no population exists on it.

-Edit-
It's probably best if this order consumes all movement points for at least one turn.

[LDiCesare]

First: Controlling uninhabited squares will not be in demo 8 because it would require changing quite a bit of economic code.
Now for later: A "claim" order can be done, but what would it be useful for? The only thing I think it is worth for is if you want to do some negotiation. You could in diplomacy have rights of passage, forbid people from crossing some territory, etc. Otherwise, what good does it do? If there's noone there, you can hardly pretend to see the surrounding squares, unless you put some units there. I'd rather have diplomacy allow orders like "don't cross squares XYZ even if they are controlled by a third party or by noone".
As for desert uninhabited and controlled by egyptians, I believe there were nomads in the desert, and egyptians either traded or fought them depending on the times. I'm not sure they "controlled".

[Mark_Everson]

I think that claiming territory as Alms says is a worthy goal just for maps looking good etc. But I would put this one off for a bit since Laurent has solid reasons for his objections. If we can find a way around the econ problems of having uninhabited squares in provinces I'd be in favor of barren squares just being included in provinces.

[alms66]

Originally posted by LDiCesare
Otherwise, what good does it do?

This was intended to be an order given to a unit. So, you move the unit in, 'control' the square (which adds it to your empire), then it's yours like normal, just nobody lives there... yet.

I've actually got a better way of handling this, though I was hoping for a quick-fix for demo 8. Since, this was just the quick-fix idea, I'll drop it and bring up the better way for 8.1 or later.

[Mark_Everson]

I cleaned up and tweaked the dawn scenario, and it runs quite well now, with Chariot building attainable at the correct point. The game runs pretty cleanly on all the scenarios that I have tried. I am going to start writing up release documents for demo eight as I finish testing the rest of the scenarios. I probably won't get much further along before Christmas, but we should be able to release shortly after that.

Thanks for all the hard work everybody, especially Laurent!

[Mark_Everson]

I have just committed to the code base a modified Attila scenario and some code fixes to get it to work properly.

Please, those that can, try out the new Attila (primarily as the Romans) and do whatever testing you can stand!

I am going to do a writeup for D8 and publish it probably about this time tomorrow unless we find something major that is worth holding up for.


I'll send Alms a zip shortly so he can run the testbed version.

It's been a long time coming. . . Woohoo!