The talk was very informative and even presented some new details we had no idea about in the AI modding community, and I think it's worth reading for all modders. In some parts we were writing simultaneously so it might look a little messy, but I'm hoping it won't be too much of a problem ^_^
Nekron: Did you & the AI team write campaign scripts (especially attacks) for all of the missions, or was Scenario Design mostly responsible for that?
If you did, could you tell a little bit about how that process looked like? Did you guys just wing it or was it a little more nuanced than that
Bob Fitch: There was no AI team. I was it.
I coded the systems, designed the strategies, wrote the scripts, etc.Yes, I did all the campaign work except for making the maps. Level designers would use the editor to make the maps and put units on them, and then they'd give the maps to me with some basic ideas like, "We want them to attack down this path, but sometimes go over here. Don't attack expansions. Use air units more than usual." I'd then write campaign scripts for all difficulty levels and strategies. Feel free to add follow-up questions now that you know the basic idea of how I did it.
N: Follow up question: Since I'm working on a campaign rework that encompassess all original campaigns, I do know how much work it is to go through so many missions and come up with working script ideas that are meaningfully different from each other. What is something that would actually be super interesting for me to hear is, did you try to give AIs representing a given faction (for example, Mengsk in xT5 and Mengsk in xZ10) some kind of a personality, where it'd behave in similar ways, or was it not a consideration beyond what you were told by level designers?
BF: The personalities of the different AIs were mainly in what units they built and used, and how aggressive they were in attacking or defending. It was very simple.
N: Regarding your comment about level designers wanting the AI to not attack expansions - I find it a really interesting remark to make, since there is exactly one mission that has an otherwise unused flag set through an opcode called target_expansion - if you remember by any chance, is that related?
BF: Yea, it's probably related. The designers wanted to severely limit the damage done to player expansions, while at the same time in melee I wanted to almost exclusively target expansions.
N: Some of these commands are really obscure, and never used - for example, implode, a command that specifically makes small isolated pockets of pathable terrain defended, or eval_harass, a command that can only be used to bypass enemy defenses (in the simplified way of looking for regions with no enemy strength) - if you remember, can you tell us what were some ideas for how you'd use stuff like this?
BF: I don't really remember the specifics. The term 'eval_harass' is familiar, but I really don't remember why anymore.
I know I did quite a few experiments and didn't always remove the code after deciding I didn't need the opcode yet.
You might find this interesting... I searched the code for 'harass' and found this enum of states I used in my attack routine.
MODE_INACTIVE, // 0
MODE_HARASS_ATTACK, // 1
MODE_HARASS_COMBAT, // 2
MODE_LOST, // 3
MODE_WATCH, // 4
MODE_GUARD, // 5
MODE_DEFEND, // 6
MODE_STAGING, // 7
MODE_HARASS_STAGE1, // 8
MODE_HARASS_STAGE2, // 9
And this is the comment in the code about the enum:
All ep areas begin MODE_INACTIVE. When a zone is acquired it is switched to
MODE_GUARD. From there it goes to MODE_DEFEND if it ever gets attacked. If
attacked and outnumbered then the zone is "lost" so it goes to MODE_LOST.
An adjacent MODE_GUARD zone would switch to MODE_STAGING with the MODE_LOST
zone as the target. MODE_STAGING waits for enough troops to take an enemy
zone and then attacks. The attacked zone goes to MODE_DEFEND and the staging
zone switches back to MODE_GUARD.
The MODE_HARASS_STAGE acts just like MODE_STAGING except that when it's ready
to attack it goes to MODE_HARASS_ATTACK. That mode is like MODE_DEFEND except
that it never retreats when outnumbered and never asks for additional troops.
If a harass attack ends in victory then the new zone goes to MODE_GUARD just
like any other zone.
N: We call those region states now! You can find them described by reverse engineering ( so probably less accurately than here ) on page 16 of the AI doc, under "Region States", it's amazing how different the intentions behind them were compared to what we guessed based on their behaviour lol
BF: I looked. Thanks for the link. Cool info. Almost correct too.
N: AI modding requires a lot of tools that were only more or less finalized in the recent two or three years for the modding community! Did you have any AI-specific debug tools when you worked on the project, or did you just test it with cheats/by playing and only find issues that way?
BF: I programmed lots of cheats and visualization modes. I could look at what the units were thinking about doing, what they wanted to build, and where. I could see what they valued, what they wanted to attack, how much time they were spending on tasks, etc. I don't remember if those cheats are still in there, buried and hidden, or if the code gets compiled out in Release builds.
N: Starcraft AI is now considered the best AI base out there for modding (and I'm not talking about BWAPI), with it's huge flexibility, a plethora of specialised commands and the ease of adding new ones if needed, as well as multiple AI systems (defense, target selection) that are smart enough to feel smart and yet simple enough to not screw up constantly (which alot of modern RTS AIs tend to do, like Starcraft 2 or RA3) - what was it like to develop a toolkit for script-writing that's essentially uncontested 20 years later? Was it ever a major consideration, how many tools you've created for campaign development?
BF: I didn't know it was considered the best AI base/framework.
It feels great.
I was originally writing the StarCraft AI with the intention of having users create their own AIs that could be pit against other people's custom AIs. Time constraints caused me to scale back that plan, though I tried it again in StarCraft 2. (Although I was the AI programmer for only the first 50% of StarCraft 2. It was ultimately written/finished/released by a different programmer, and I did no AI in the expansions. I was the engineering director for Hearthstone when the expansions were being made.)
Honestly, I was just writing the SC and BW AIs on an "as needed" basis by the time I was deep into it. I'd try to make the AI smart, realize I needed a new opcode, add it as simply as I could, and repeat. The same was true for campaigns. I wrote special case opcodes for missions, like "junkyard dog" for example. That opcode was for a specific mission, though after I'd write a new opcode I would then try to find ways to reuse the code in other places.
N: I think that even if the original idea of making it possible for people to make their own custom AIs didn't work out because of time constraints, it definitely lives on now. ASC3 (which is what we call the SCAI language nowadays, based on the first working editor) is an easy to learn language that makes campaigns and custom maps insanely customizable with little effort, and can make for some truly amazing sequences and campaign scenarios if you're willing to spend time learning it. Huge thanks for all the thought you've put into the original AI.
If you wrote the language for SCAI scripting today, how different would it be?
BF: I would probably not write a language for AI these days. I'd use lua and write a library of routines that could be called to do most of the heavy lifting, that was extremely short and simple AI "scripts" could play the game with minimal changes to handle many different strategies and campaign needs.
N: Any cool anecdotes on SCAI or the dev process you can share?
BF: I'll always remember the look on Chris Metzen's face one day. I was programming the AI all day and we were in crunch mode so this was probably at the end of a 30-hour shift or something crazy. Instead of finishing and going home to sleep like a sane person, I decided I wanted to PLAY the game before I went home. (Looking back, this is also the moment I knew the game would be a hit. I had just worked 30+ hours and instead of sleeping I wanted to play it.) I started up an AI game and got going. It was an amazing game. It was back and forth. I was almost dead and then I pulled myself from the fire and started turning the tables. It was so exciting that I was cackling. I didn't realize I had let my tongue hang out of my mouth a little too, but because of that I started drooling. Before I could pull in my tongue and close my mouth and wipe my cheek, I look up and Chris Metzen is standing in my office doorway. Staring at me. Staring. Still staring. Yep… fun times.
I'm not sure what you call it, but I had an object called the "Captain" that was responsible for attacking.
Captains had fields like: current EP area (trivia: that's for Equal Potential and was coined by the pathing programmer), target EP area, owning player, mode, priority, action, delay, flags, stage, desired force strength for ground and air, current ground and air strength, total ground and air strength (counts troops that are on the way but have not arrived yet), visible enemy ground and air strength, a list of priority targets to kill on ground and in air, the group's "leader" pointer (usually a slow ground unit, choses again if killed), and the current detector unit being used to find cloaked things.
I looked up eval_harass and it's a boolean function that returns true if ready to attack, while also calculating a desired target. It returns true if the estimated AI attack power is greater than the target's estimated power at the target EP area. It only needs more vs air OR more vs ground power to return true.
N: Looking at it all I think you're just referring to what we'd call AI regions, but they're used for more than just attacking, they're also responsible for everything defense-related and many other AI functions.
The most talented programmer that works on this [Neiv] told me about some debug strings like SAI_Captain, but my understanding of attacking is that a region is picked, units congregate around the central point in the region, there is a attack list composed of units from attack_add/prep_down/etc, and after the attack is filled successfully (with some caveats, such as units that are in combat already don't count) or after 120(melee)/180(campaign) game seconds (1920/2880 frames) have passed(or less with quick_attack...), the attack launches and picks a random target that depends on script class.
Some more details come in campaigns and melee but they're usually not super well described.
BF: Above... the melee AI does try to attack close targets. The campaign AI randomly chooses a target EP area after doing a calculation of "what are all the ways I can get to there from here" thus causing the attacks to come in from different directions instead of how melee is always hitting the same frontal assault spots. Trivia: The routine that calculates the different possible attack paths I called "The cholesterol algorithm" Long story...
N: Last question (I promise) [Neiv] wanted to ask - did you ever develop the difficulty idea more, was it planned out beyond just making a couple stray commands, or did it never take off? (There are 2 or so commands that do different things based on an unused difficulty variable, easy_attack and if_dif)
BF: Difficulty levels were planned from the beginning, but mostly we accomplished difficulty levels by reducing attack force sizes and attack frequencies. There are a few extra tactical changes too, like normal AI tries to focus fire down injured units. The easy AI does not.
easy_attack is actually a "do this attack IF the difficulty setting is EASY" or more accurately i think it's "use this unit in the attack if set to easy" which let me change the units being used on easy (probably in melee, maybe not in campaigns, can't really remember)
if_dif is a boolean test, "if the difficulty is ____ then jump" and the parameters determine how it's handled, three params: comparison type (byte), diff level (byte), jump location (word)
type 0 is if diff < param then jump
else if diff > param then jump
After this Bob had to go, and we ended the interview. Thanks for your time, Bob! ^_^
Post has been edited 4 time(s), last time on May 4 2019, 12:54 am by Nekron.
