<--
-->
Forum | Index
Synopsis
The critique identifies features of Civ Evo which conflict with the expressed aims.
The main aim is to develop optimal AI given that AI players have the same game rules as human players. This can be interpreted to mean design AIs to play against AIs (not necessarily to be playable for humans). The aim can be generalised to "design good AI without cheating" which can be interpreted to include designing AIs to play against humans (ie playable AIs).
Features which are too simple or too complex are identified. Some features which changed from Civ2 are judged worse. AI Interface weaknesses are identified.
Part of the critique is confidential (concerning cheating etc). Civ Evo Administrators and official tournament hosts can request it.
- Combat is discontinuous unlike Civ.
- Too-frantic arms races for every 1 point of advantage which can give 100% success.
- Too much incentive to make the strongest unit.
- 1-point difference in strengths can consistently decide a battle.
- Removing luck tends to make the player with the strongest army stronger which accentuates differences due to initial position making the game result more random. With luck players have more equal opportunities and risks.
This causes an unnecessary cost in slower spatial logic eg pathfinding (movement, road/rail/canal building), exploration, attacking, defending, transport, city siting, fortification and base siting.
Movement is not conserved. Movement is destroyed or created for terminal moves. Admittedly Civ2 isn't very consistent and strict conservation would be novel. A system which allows fast pathfinding is desirable (ie where the actual movecost is more predictable).
- The AI coordinate system is nonlinear.
- Complex spatial logic
- Frequently used routines (eg Remote) require expensive multiplications and divisions for linearisation. Perhaps half the cost of sGetMoveAdvice is due to linearisation.
- Attack=Mobility (ground)
- no light cavalry (scouts with defensive ability cannot be designed).
- no heavy infantry (eg Legions from Civ2 cannot be designed).
- Model design constraints are too strict
- There shouldn't be custom units (eg settlers, engineers). Model features should allow every possible type (Wonders should allow new features not new custom units).
- Defensive constraints tend to be too low.
- There are few paths through the upgrade tree - most later upgrades require the earlier upgrades. The future technologies tend to divert players from arming for a decisive battle in favour of continued research potentially resulting in stalemate for 100s of turns.
- Variance in strength and cost (of upgrades) seems inconsistent. There should be simple trends.
- Various models from Civ2 cannot be designed.
- The Civ2 models are a good set of characteristic types. A design system which cannot generate all of them (or equivalents) is too poor. Strategies from Civ2 cannot be used.
- There is no substitute for the 'scouting in enemy territory' function of caravans
- Glider seems a weak substitute presumably a glider could be expelled if you had a peace/border treaty.
- All game rules are bound at compile-time. (vs bind at run-time with rules.txt)
- Everything (server, AIs) must be recompiled for any change.
- Some game rules are implicit. (ie what isn't specified in protocol.pas/aiclasses.pas)
- Unnecessary dependencies are created between server/AI code and the game rules.
- Changing game rules tends to require updating server code.
- The server doesn't provide an interface to specify/implement implicit rules
- Changing game rules tends to require updating AI code.
- The game rules cannot be proved consistent automatically.
- Cheating cannot be detected automatically. An automatic detector is not complete but is useful for debugging. Some conflicts with the (official) rules are undetectable eg if the server is compiled with different game rules.
- Support for any language
- The development community is fragmented - code can't easily be shared between segments.
- The AI interface must be maintained for each language (it's also highly desirable to maintain a reference AI to verify the interface and to assist developers). This work disappears if there is one official language. Although an AI developer could do this work (for their language) it would take time from developing their AI.
- A third party (eg tournament host) who needs to test if an AI is cheating/erroneous would need to debug in any language - probably impossible.
- No Reference AI. A reference AI is implemented in each supported language. It demonstrates how to use each server command and each data structure provided by Protocol and AIClasses. Developers can see how to use the AI interface. The Protocol and AIClasses implementations for a given language can be verified by running the Reference AI with a known initial random number generator seed and comparing the play to the primary language (Delphi) version.
- Developers do not have official examples of how to use all server commands or how to fully use Protocol or AIClasses.
- Unofficial examples are likely to be out-of-date. (The standard of correctness could be lower than official examples.)
- The AI Interface (Protocol, AIClasses) for other languages cannot be verified.
- Standard AI is the only competitive computer opponent which is guaranteed to be available as soon as a new version of Civ Evo is released. For this reason it should be the first resort for AI developers to test (updates of) their AIs (for a new version of Civ Evo). AI developers will try to make their AIs perform better than Standard AI. This means that if the quality of Standard AI increases with each release (perhaps new server functionality is exploited [with the happy side-effect of verifying that it works and is practical to use]) then the (minimum) quality of all AIs will tend to increase proportionately. Also Standard AI is the main AI available to human players. Many users will associate the (perceived) quality of Standard AI with the quality of the project as a whole.
- The minimum quality of published AIs is very low.
- Given that there is no reference AI, Standard AI could perform this function but because it is not ported to all languages which developers use and it doesn't use all functionality of the AI interface, it is inadequate in that role.
- Users (ie human players) are not offered a long-term challenge.
- The aim of generating good AI is not being met (StdAI could be improving with each release but it is not).
- Restorable saving (with no alternatives) is inadequate.
- Save files are too large.
- Save files take too long to load.
- Saving is too slow when there is a lot of data.
- The save protocol is too limited.
- There is no facility to load/save blocks larger than 60 bytes. A small number of large blocks should be faster to load/save than vice versa.
- Players cannot control the number of contacts they receive per turn.
- When a player runs out of time they are forced to reject all contacts.
- Players can't manage bargaining because they don't know how much time their partner has.
- Items are offered without necessary information to decide the price.
- Eg World map - the value depends how many novel tiles it reveals.
- Without knowing a reasonable price, it's impossible to agree a deal.
- The offer protocol is incomplete - only a small subset of trades can be reprisented.
- Unnecessary additional offers are required - often you can't trade several things in one offer because there aren't enough slots for the price.
- To buy something expensive (eg world map) you must have 11 items valuable enough to exchange.
- Civil and Military Report convey too much information
- The value of chart information is too high to exchange for most other items.
- The diplomacy/trade protocol of client activations/deactivations is awkward and inconvenient.
- To start negotiation at an arbitrary point in the program (eg in a loop) an AI must somehow save it's state and restore it after negotiation. This is a significant constraint on AI design. (In practice AI use of negotiation is crippled.)
- The trade protocol is too simplistic.
- It should be easier to make offers without revealing information. Eg the ability to ask for a random advance.
- Players should be able to make contracts to exchange items they don't currently possess. (And for actions eg attacking a mutual enemy).
- Alliances must use ad-hoc communication for planning.
- AIs can conduct auctions and inverse-auctions over multiple turns. There should be game rule support (or macro management) for human players to run auctions.
- The treaties after Peace pass too much information
- There should be a victory condition which allows alliances to win with no incentive for members to compete eg scenarios with permanent alliances.
RO is the only reprisentation of knowledge you can use with server calls. There is no provision for deduced or uncertain (or hypothetical) knowledge.
- You can't use sGetMoveAdvice despite knowing there is probably a possible path.
- You can't send speculations or use speculations communicated from other players.
- You can't send untrue or speculative messages or distinguish if a received untrue message is speculative or dishonest.
- There is no reason to have cities larger than about size 21 without Tax Collectors or Scientists.
- Improvements to increase food (there are too many) are quickly redundant.
- There is no substitute for "We Love the (X) Day" in the early-to-mid game.
- Lower growth rate (vs Civ2) for the first few hundred turns until Refrigeration.
Borders should not be a compulsory condition of treaties they should be negotiable.
Borders extend beyond the area a player controls or observes. There is no logical basis for this. (If borders should be extended why is ZOC only adjacent tiles? Shouldn't it be at least any tile the unit could attack?)
- Border negotiation.
- If borders have an effect on the game, negotiation will reveal the approximate location of cities.
- (Secret borders during negotiation) if any territory can be claimed (eg the whole map), iterative negotiation will reveal enemy borders. If some areas are marked "disputed" that reveals the enemy borders (presumably all players will claim the whole map nullifying the effect of borders). You could have a small cost for each tile claimed - That would inhibit claiming many unproductive tiles.
- If only territory close to cities can be claimed borders reveal the approximate location of cities.
- If only territory which is land (not sea) can be claimed that reveals the location of islands and the shape of coastlines.
- If only known territory can be claimed that reveals the extent of your map.
- Borders should not be visible/effective until you have negotiated a border treaty (independent of peace/war). Border treaties should be cancellable on a similar basis to peace/neutrality treaties.
- Where multiple players are concerned in a border negotiation how can it be accomplished quickly? (ie if one or more players are human). How can you prevent renegotiations on each player's turn every turn?
- Player-player communication is desirable.
- In games with more than two players all players can gain by communicating (eg sharing battle plans with allies or threatening enemies). In two player games players can gain short-term advantages by communicating. It's important for Civ Evo to define standards so that AIs by different authors can communicate and AI-Human communication is possible.
Infinite Sea of Cities. A decision must be made whether to support large numbers of cities and units or to inhibit it. A positive decision requires a very high level of macro management to make the game playable (Goto is convenient but it would take too long waiting for 100 units to execute it) and simpler AIs to make moves in a reasonable time. A negative decision requires new game rules to enforce it. The problems below refer to the present state where it is implicitly supported but without high-level macro management.
Large maps are unplayable for humans (against expert human/AI players) because with hundreds of cities and thousands of units it would take too long to move. NB a 100% map could be considered large by this definition.
Large maps are impractical for AI competitions because expert AIs will take too long to move (memory requirements could be very large also - 100s of Mbs temporary data during a turn). Presumably expert AIs are close to as fast as possible already but they can be simplified (it's unclear how much reduction in competence would be necessary). Unatteneded games could be played in parallel on a network of machines. A problem with parallel solutions is that most AI developers cannot reproduce the tournament (ie play all games) in a reasonable time so confidence in the fairness of the tournament is reduced.
Because ISC tends to simplify AIs and make the game unplayable I cautiously support rules to inhibit it. I acknowledge that it is entertaining to watch simple AIs having large battles. And it's an interesting programming challenge to approximate slow expert algorithms. But the aim of the project is to produce good AI.
I conservatively estimate that the maximum number of cities a human can micro-manage in a reasonable time is 7. Macro management can extend this by managing cities which don't require micro-management. Presumably if you can have games with 8 players that implies a maximum of 56 cities for one player (40x30 grid with 100% landmass). That could still be too many cities for a human to compete with an expert AI (which can micro-manage all of it's cities). Captured cities could be looted then burned (destroyed) or liberated as free cities (new allied tribe under control of a randomly selected AI - more or less _100% macro management_). Perhaps when you have built the maximum number of cities you can release free settlers. Smaller industrial base implies more reliance on super models. High mobility (eg air) units are stronger on smaller maps.
- Basic server features for AIs designed to play against humans are missing (eg the ability to identify each player, notification of the start and end of each human player's turn [for background processing])
- AI players do not have the same game rules as human players.
- The majority of users will be frustrated because there are no AIs designed to play against humans. (Competitive AI-vs-AI might be unplayable for humans eg taking an hour to make the first move). In practice the aim of generating good AI is not being met.
- Progress is slow (eg StdAI) and uneven (sometimes a release is once per week sometimes less than once per month)
- Unpredictable release schedule is inconvenient for AI developers.
- Third-Party resources (eg AIs and translations) are likely to be out-of-date.
- Having only one developer severely limits the improvements which can be realised for each release.
- Specific components of a release (eg StdAI, documentation [AI,Game Manual], debugging, AI templates) can be neglected. It would be better to assign (at least) one developer to each key component so that improvements are likely for each release. At present it is predictable that at least one component will break (or not be fixed) for a new release.
- Having the project management and development team be (led by) the same person is a possible conflict of interest.
- Features which appear difficult or lengthy to implement but which have significant benefits may be delayed or rejected more than necessary. With more developers it is practical to have some developers work on long-term projects while the others continue scheduled releases.
- Releases are not thoroughly debugged.
- There are often visual glitches.
- No regression testing.
- New features often break existing code. Could be reduced by better structuring of the code (ie isolating common code eg game rule implementations).
- Petty AI interface changes (eg changing variable or method names) require all AI code to be updated (and all ports of the AI interface).
Top