But short of writing up a new ("true AI") system from the ground up (which would be rather time consuming... and would quite likely require knowledge at the Post-Graduate level in Computer Science... although I'm probably over-thinking this), some sort of fuzzy-logic into a "meh, good enough" result may be what's most feasible.
The innate flavor & modification based on strategies system does work in theory.... except to become effective there would need to be many, many more "strategies" to be checked & evaluated each turn, to the point where you might as well toss all those out and have weights modified directly anyway for each AI.
Going into 'ECONOMICAISTRATEGY_NEED_HAPPINESS' (for example), how would we know whether we should multiply our happiness value by 250%, or increase it by a flat amount of 10? What would be 'enough', what its effect on 'crowding out' the other flavors would be, what happens when the happiness flavor for players/techs/buildings/policies/etc are modified, what happens when happiness/unhappiness sources are changed? The math/statistics that would need to be crunched out to calibrate the system would be extremely complicated (e.g. a lot harder to assess changes across the system when tweaking input parameters, which is not exactly a good thing in a moddable game).
A goal-oriented AI is nowhere near a "real" AI, it's just an extension to an existing AI design. In the pure flavor-based approach, the AI scores all of its possible actions through a variety of scoring functions, then picks the one with the highest score. In the goal-oriented extension of a flavor-based approach, this scoring mechanism is used only to determine the AI's goals. Once it has a goal picked out, the AI then constructs an A* "path" to its goal: instead of tiles between a unit's starting position and a target tile, the goal-oriented A*'s "path" has world states between the AI's current world state and a set of world states where the AI's goal is complete (which doesn't need to be explicitly defined, it just needs to be some world state that passes a set of conditions). These world states are connected by actions the AI can take, which are the only things that need to be explicitly defined in this system (eg. buy a unit, make deal with player, get ideological tenet, etc.). Using these actions, the AI navigates possible world states, constructing an A* path until it finally reaches a world state that satisfies its goal. Personalities can be implemented by having the AI weigh different actions differently: a culture-oriented AI would assign lower costs to actions associated with getting culture, an aggressive AI would assign lower costs to actions that directly harm another player, etc. Basically, the idea is that instead of defining all possible pre-set behaviors for the AI, you only define the actions that an AI can take and you let the AI construct a path to its goal using those actions. This goal-oriented extension was popularized by F.E.A.R. (which uses a real-time variation of it) and is used in quite a few FPS's since, but I can see it being adapted quite well to a TBS environment.
The biggest issue with a goal-oriented AI in Civ5 is the complexity of world states: for the highest degree of accuracy, AIs would have to consider pathfinding and moving units around in tiles for even the most seemingly unrelated of goals. An approach that would split the goal-orientation into two versions would definitely help, ie. one goal-oriented AI would look only at actions that do not involve unit maneuvers (diplomacy, spending gold, spending faith, choosing production, choosing policies, etc.), and the other AI would look only at actions that involve unit maneuvers (eg. moving a unit to a tile to ZOC an enemy to save another unit near death, attacking units near an enemy city to clear the area before trying to actually take the city, etc.). This would remove the possibility for some actions (eg. buying a specific unit at a city to counter an offensive of a certain unit composition against that city) and there would still need to be some communication between the two systems (eg. moving a military unit to upgrade it, moving a settler to found a city, moving a missionary to convert a city so to give benefits to whatever goal the AI has planned, etc.).
The fact that multiple goals can have overlapping routes means that a strict approach of flavor-based goal selection followed by planning to that goal would omit weighing AI actions based on the ability of those actions to satisfy multiple goals. This could be solved by using the flavor system to apply base costs to actions depending on the change in distance to each goal from the action (instead of ignoring any changes that do not help with the main goal), but since this would greatly increase the amount of world states the AI would have to navigate, it would come at a huge cost in performance.
There is also the problem of Lua scripting: goal-oriented AI systems would need to constantly check for Lua code added in by mods that affect the world state, and not only are calls to the Lua script engine fairly expensive, but the actual Lua scripts can affect a wide variety of stuff, so Lua checks would need to be called constantly. Although the upside is that the AI would be able to take advantage of any mod's changes without any input from the modder (maybe if the mod adds new actions, the modder can just add in a new AI action via a Lua script, and the AI would be able to integrate it into its regular pool of actions without any problems), it would be at a huge performance cost, even more so than the pathfinder I think.
Question: when a player "dies" (i.e. a city state having its city captured), does the game remove all the extant attributes of the CvPlayer object instance (i.e. destroys the object and de-allocates memory)?
The player object shouldn't be destructed, seeing the existence of CvPlayer::isAlive(). If it were destructed, these lines in CvPlayer:
oLiberatePlayer() would crash the game:
Code:
if (!GET_PLAYER(ePlayer).isAlive())
{
GET_PLAYER(ePlayer).setBeingResurrected(true);
If the player object were destructed, GET_PLAYER(ePlayer) would be a null reference.
Hey Delnar, sorry for the walls of text
:
- Some irregularities/issues regarding your code & pre-processor-defines
- This is your v10 experimental code, and just for the stuff your CvReligionClasses.cpp changes.
----------------------------------------------------------
Line 5812 in CvReligionClasses.cpp
Code:
pLoopCity->GetCityStrategyAI()->ConstructRushList(YIELD_FAITH);
needs
Code:
AUI_ECONOMIC_FIX_DO_HURRY_REENABLED_AND_REWORKED
Fixed by adding in the necessary define in front of ConstructRushList().
Line 5876 of CvReligionClasses.cpp
Code:
dRtnValue *= 1 + pow((double)GC.getGame().getJonRandNumBinom(257, "Belief score randomizer.") / 128.0 - 1.0, 3.0);
needs
Fixed by adding in a version that doesn't use the binomial RNG (no idea why I forgot to do that).
Lines 6017 * 6018 in CvReligionClasses.cpp
Code:
int iNewPlotValue = pForCity->GetCityCitizens()->GetPlotValue(pPlot, true, adExtraYields);
double dRtnValue = iNewPlotValue - pForCity->GetCityCitizens()->GetPlotValue(pPlot, true);
appears to need one of
Code:
AUI_CITIZENS_GET_VALUE_FROM_STATS
AUI_CITIZENS_IGNORE_FOOD_FOR_CITIZEN_ASSIGN_AFTER_GROW
Fixed by adding AUI_CITIZENS_GET_VALUE_FROM_STATS as a prerequisite for the function (there was a similar thing in the AUI_RELIGION_SCORE_BELIEF_AT_CITY_REMADE section).
Line 6149 in CvReligionClasses.cpp
Code:
if (pLoopPlot && m_pPlayer->IsPlotUnderImmediateThreat(*pLoopPlot, pCity->getOwner()))
seems to need
Fixed by changing the DangerPlots Remade code's PlayerTypes version of IsPlotUnderImmediateThreat() to accept one-argument calls (in which case the player being checked is m_pPlayer), which means the call will function with or without the remade DangerPlots.
With a couple of your for loops, some of your uints, such as
Code:
for (uint jJ = 0; jJ < GC.getNumBuildingClassInfos(); jJ++)
will provoke
Code:
warning C4018: '<' : signed/unsigned mismatch
If using uint, you'll need to cast them back into regular integers (or whatever the relevant ______Types pseudo-integer is being used) before passing it as an index argument.
Ah, you haven't enabled AUI_WARNING_FIXES. I didn't add compiler conditionals for AUI_WARNING_FIXES at those lines because I assumed AUI_WARNING_FIXES would always be enabled if you're using the "big" fixes. Among other things, all the GC.getNum<thingy>Infos() functions return uints with AUI_WARNING_FIXES enabled (like they should, because they're returning array sizes).
Line 6212 in CvReligionClasses.cpp
Code:
if (m_pPlayer->canConstruct(eBuilding, false, true, true, NULL, true, &iEras)
needs
Code:
AUI_PLAYER_CAN_CONSTRUCT_AI_HELPERS
Fixed by adding in an alternate version that does not rely on AUI_PLAYER_CAN_CONSTRUCT_AI_HELPERS.
Thanks for pointing those out, I'll have the commit uploaded as soon as my computer stops freezing up.
