Announcement

Collapse
No announcement yet.

Regarding Implementation of AI (repost from Suggestions, June)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Regarding Implementation of AI (repost from Suggestions, June)

    REGARDING SPECIFICS OF IMPLEMENTATION OF AI

    While I do understand some of the underlying principals of AI design, I guess what I know in a total way is very minimal indeed. I have nothing but respect for a good AI, and its programmer, for this reason.

    As far as I tell, the CtP1 AI was a form of list processing. The AIP and FLI files were the parsed files that were conditionally processed, producing weighted answers as to what should happen. The results were
    ‘hints’ to the games AI dll, as to what should be done.

    There are two main challenges that the new AI has to meet.

    First is its obligation to pose as an effective threat to the player, by doing three things militarily; first building good stacks, second put those stacks on transport, or many transports (and reconstitute the stack at the other end) and lastly attack with those stacks. The only way that the AI was TRULY effective (at least overseas) was as a nuisance, by employing special unit attacks. The reason for this, is that one special unit can be effective. However, grouping was never a thing it did very well at.

    Secondly, newly created units (created by scenario designers) might have a very tough time, since they, unless some thought is put into AI behavior, will be unused by the computer. This ultimately means that certain scenario units could be unnecessarily unbalancing. The way to solve this, of course, is to have enough groupings of behavior where the new units could fit in. Behavior can generally be defined as movement and attack, since you can ‘preempt’ combat and do something ‘clever’ in SLIC or do something during or after movement.

    There was the concept of grouping units by type and them having behaviors, in CtP1.

    The problem is… that there were not enough groupings for customizing, and the way the units were described was by static tokens… yes?

    The archetypal new custom unit in CtP1, which was employable by the user, but not the AI was the cruise missile. It was one shot, offensive… preferably against towns… or carriers, so it should be grouped for best effect, unlike a nuke. Perhaps carried by subs or ships…(not carriers), and not travelling on its own, except to get into position.

    The defensive version of this, which I would like to have seen, though for technical reasons (lack of size classes,) it was impossible, is the Anti Aircraft Missile. A one-shot ship or land-carried unit, that would be used in response to threats within its range radius. Of course, certain people might say… this is too specific. Civ is all about abstraction. However, scenario designers should be given freedom to express their ideas in a flexible product. That is ultimately what the culmination of “Civ” should be.

    These are two examples, but I can imagine another… a non-attacking, non-settling unit; one that either explores new sea or land territory, or wanders already discovered land or sea, in settled or unsettled regions. With SLIC, these movement patterns could be put to use, in ways that we don’t know now, but I’m certain will have great use later.

    The extra or replacement AI unit classes that I am suggesting are:

    SINGLE_SHOT_LAND_OFF
    SINGLE_SHOT_SEA_OFF
    SINGLE_SHOT_AIR_OFF
    SINGLE_SHOT_TERROR (nuke)
    SINGLE_SHOT_LAND_DEF
    SINGLE_SHOT_SEA_DEF
    SINGLE_SHOT_AIR_DEF
    POWER_PROJECTION_SEA (the carrier, and sub?)
    POWER_PROJECTION_AIR (nuclear strike aircraft)
    POWER_PROJECTION_LAND (for completeness?)
    WANDERER_LAND_EXPLORED_SETTLED
    WANDERER_LAND_EXPLORED_UNSETTLED
    WANDERER_SEA_EXPLORED_SETTLED
    WANDERER_SEA_EXPLORED_UNSETTLED
    WANDERER_AIR_EXPLORED_SETTLED
    WANDERER_AIR_EXPLORED_UNSETTLED
    WANDERER_LAND_UNEXPLORED
    WANDERER_SEA_UNEXPLORED
    WANDERER_AIR_UNEXPLORED

    The problem of the static tokens in the AI file has to be remedied by moving their specification to where the units are defined; units.txt. I understand this is yet another line and flag to be added, and parsed. You could do vertical partitioning of the data, and split the property into another file… something like unitAIdef.txt or whatever. However, its important that if you want to have a customizable game, that you allow specification of a unit as within an AI behavior group.

    The next thing to consider is how you want to define the organization of these units. Ultimately what you want to achieve is , say, a number of stacks; some bombard stacks with, for instance, a couple of attackers, and ranged units, and 5 bombard units (this stack would soften up targets for the assault) and some general purpose stacks with 4 strong and resilient attackers and 5 ranged attackers, to attack or perform defense within the empire, and some appropriate defensive stacks for cities. Sea stacks, air stacks and wanderer escort stacks would be yet another case.

    You could define the proportions that you would like to see for each AI behavior pattern (aggressive, defensive etc.) and those would be scaled up or down as resources permitted into ‘build plans’ which the AI could carry out, still taking into effect ‘social’ building.

    You might set up a text file that was parsed, with ‘descriptions’ of stacks… with incremental sizes and priorities… I.E.

    Stack Defensive_Cities 255(all cities… not literatally 255) 10000 (priority)
    {
    Defensive_Land 1
    Ranged_Land 1
    }

    Stack Offensive_Land_Stack 1 (a single stack to attack is the second priority) 5000 (priority)
    {
    Offensive_Land 1
    Ranged_Land 1
    }

    Stack Defensive_Cities 255 1000 (third priority is a larger defensive force)
    {
    Defensive_Land 2
    Ranged_Land 2
    }

    Stack Offensive_Land_Stack 1 (still single stack) 500
    {
    Offensive_Land 2
    Ranged_Land 3
    Slaver_Special 1
    }

    Stack Bombard_Land_Stack 1 450
    {
    Offensive_Land 2
    Bombard_Land 2
    }

    AND SO ON, AND SO FORTH…


    When a priority is met, you can move down the list

    Lastly, stacks need to be treated as homogeneous entities in their own right, by the AI; they need to be regrouped after being split up to move past a city or across an ocean in small boats, and re-supplied with reinforcements after being damaged in battle. As new cities are added… perhaps parts of the attacking stack should be split off to constitute a new garrison.

  • #2
    Limey,

    This sounds very interesting but I think that if you want to get a discussion going you're going to have to provide some more basic information. Although I have spent many hours pouring over the FLI and AIP files my knowledge of AI theory is undoubtedly more minimal than yours. So, could you begin by expanding on:


    --------------------------------------------------------------------------------


    As far as I tell, the CtP1 AI was a form of list processing. The AIP and FLI files were the parsed files that were conditionally processed, producing weighted answers as to what should happen. The results were
    ‘hints’ to the games AI dll, as to what should be done.


    --------------------------------------------------------------------------------

    Thanks,

    Peter

    Comment


    • #3
      The original posting was in the context as a direct request and/or submission of into from and to the team. The AI guy hadn't shown his face before at Apolyton, and this was a repost that I thought was maybe relevant.

      In many ways, I felt it was a little pointless, what with CtP2 being so far along and all, but maybe that there might be a few ideas in it that could approach the AI issues in a different way.

      Of course, theres no harm in discussing the right way of doing things AI wise, especially since its probably the most important subsystem of a Civ game. What bit of my piece wasn't clear?

      Comment


      • #4
        Although most of your post deals with stacking, I thought that you were trying to stimulate a more general discusion on how CTP's AI works/should work. Perhaps I misunderstood and should have brought this up in either the CTP general or creation forums.

        In that other AI thread you mention, I asked if anyone knew of a good source of information on how the sort of AI that CTP utilizes works, but so far have had no reply. So your general description of CTP's AI - which I quoted above - is intriguing. I was hoping that you could expand it a bit with a view to starting off such a discussion. Like you say, the AI is probably the most important subsystem of a Civ game and so it's a bit surprising how little response there's been in AI threads. I suspect there's more people interested but are maybe put off by the lack of basic information.

        Comment


        • #5
          I certainly don't purport myself to be any kind of AI specialist, although since I have a good understanding of programming, data, and system design, certain things are obvious to me, specifically here, given the situation of the text files, what happens when you change them, and I thus speculate on the method of the changes.

          Back in the relatively early days of CtP mod making, a few of us looked at the AI system, and were mostly baffled by it. A number of us spent a fair amount of time analysing what the identifiers and statements meant, and how we could theoretically lever those concepts to alter the functionality of the AI to our specification.

          Its clear that there are very few direct and absolute correlations to events happening because of settings you make in the AI text files, thus we can postulate that the AI parses these merely as hints in combination with hard coded routines, rather than absolute 'plans of action' spelled out in the text files.

          I do think its a shame that so little real discussion has been made on this important subject.

          I guess the point that I was trying to raise, was that tactically, all Civ games, and pretty much RTS games too for that matter, handle coordinated attacks badly. To do so requires multiple levels of organization of troops, and treating them as entities, and transporting them as such etc.

          This is a low level of AI functionality, but is a large part of what a player sees. Also, this would solve a problem of AI complexity; if you have a system by which you can abstract tactical movement, from strategic battleplans, you can think about both in a clearer and more precise manner. You might want to split the strategic system further into goals and battleplans, which would further isolate the system, and eventually allow you to have an integrated diplomacy-goal-battleplan-strategy-tactics system. Thats the holy grail of civ combat.

          A little bottom-up design is helpful to sort out the wheat from the chaff, when you've such a muddled basis to start with.

          Comment


          • #6
            Limey,

            Sorry I've been so long getting back to you on this. About a week and a half ago my computer packed up and then with last week's local difficulties around here, I had a heck of a time getting it fixed.

            I think I see what you're on about now and basically I aggree with you completely. Don't know if you've ever seen the following review of CTP's AI (from www.gameai.com ) but I think it sums things up pretty well:


            --------------------------------------------------------------------------------

            Details:

            Civilization: Call to Power (CIV:CtP) is the third in the classic series of games. Lead programmer Steve Marrioti had said during the development cycle that the new CIV:CtP would feature a non-cheating AI that would use a "...small number of powerful over-arching potentialities. In situations where there is no clear-cut choice for the AI--if this happens, respond by doing that--we're relying on fuzzy logic".

            Of more interest perhaps was the plan of the development team to provide full and total access to the AI to players. The AI was to be built as a dynamically loadable .DLL file and the interface spec made public, thus allowing budding AI developers to write their own AIs if the ones that ship with the game weren't good enough. Specifically Activision promised:

            The text datafiles that describe units and objects within the game would be open and available for modification; The fuzzy logic text files used by the standard AI .DLL (used to specify the priorities of the AI while it played) would also be opened to modification; The C++ header files for the AI API itself would be published to support user-developed .DLLs.

            Activision actually planned to extend this openness to all of the code and unit data in the game, putting forth the possibility of extensive user built maps, units, and AI modules following the game's release. They had warned that users would be on their own, and that no technical support would be provided. As one of the Civ: CtP developers put it, players unhappy with the game's AI would "...darn well be able to redesign it instead of *****ing and moaning in the newsgroups about it." (Now that's a refreshing bit of honesty!

            Commentary:

            Didn't work out that way, unfortunately. The Extensible AI aspects of the game fell to the pressures of shipping and design complications. Activision was forced to drop the Extensible AI elements (though oddly enough you can still find a .map file listing the various function interfaces on the CD).

            Still, a number of extensible features made their way into the game, enough that while Activision isn't advertising the fact much a number of players have begun making mods and trading them online. Players can modify unit attributes (all maintained in flat text files) and have access to the fuzzy logic rules sets used by the AI to set priorities for the strategic level AI itself. This allows for the creation of new unit types and civilizations in much the same fashion as UnrealScript permits new `bots. In a similar vein, Microsoft's Age of Empires provides much the same level of customization of units and civilizations, though the emphasis is more on customization of the various personalities of each civilization type than on actual modification of their rules sets.

            So far as I know, I've never been defeated by a "powerful over-arching potentiality" before, so that aspect of the design easily wins the Best Box Blurb Award. Upon reflection, I'm guessing that they're implementing a series of Fuzzy State Machines (FuSMs). Most like there will be a series of pre-defined strategies, somewhat overlapping in function, that the AI will try to follow. The AI likley chooses between them (or between alternative internal branches of a given strategy) based on the situation it finds itself in at the moment, most likely using some type of weighted random dice throw.

            It's interesting to note that Steve was also the lead programmer for the first two Close Combat games, and made use of a lot of fuzzy logic in those games.


            --------------------------------------------------------------------------------


            So we never did get the full and total access to the AI that the original development team had intended to provide. Moreover, it's pretty clear that the pressures of shipping resulted in them releasing text files that are frankly a bit of a mess.

            Your comments on the tactical side of the AI bring up a good example. I'm sure that there *is* a tactical componant of the AI; it's just that we don't have any effective access to it. The AI must have some way of choosing targets and then grouping forces and sending them to attack those targets. Presumably, it overlays the grids from strategic_AI_config.txt onto the map and then uses the Priorities, Modifiers, and Max Goals per City data from the operative AIP files, via some hardcoded and incomprehensible algorithm, to send troops to those regions which it has evaluated as containing it's most important current goals. But we have no control over this. I take it that in your initial post you were suggesting, amongst other things, that we should in particular be able to specify how the AI stacks it's forces and I strongly second your motion. But more than that I'd like to have access to the algorithm that determines *where* it sends it's troops. This is where CIV type AI's fall down: they don't seem to be able to cope with water nor with systematically and aggressively taking cities.

            Well, we're promised that the new AI is going to be more of a challenge than the old one. I'm sure it will be but it's disappointing that we're not going to have access to the AI dll. I'd love, "instead of *****ing and moaning about it in the newsgroups", to have a go at designing my own AI.

            BTW, I'm familiar with your 'previous existence'. When I first got interested in CTP's AI one of the first things I did was to search the archives to see if anyone had made any sense out of the text files. Your thread, "The Low Down on Diplomacy" was particularly helpful.


            Comment

            Working...
            X