Let's face it: we all know that Sins of a Solar Empire's AI is stupid. Unfortunately, their most fundamental parts are locked into an exe or dll file, their source code most likely never to be released for modders to examine, alter, and fix. However, there are still ways to push the AI, however dumb it may be, to still put up a fight without resorting to ludicrous resource or stat bonuses. This post contains the following: my attempt at an AI-improvement mod for vanilla Sins of a Solar Empire, observations for players and modders about various in-game AI settings, and observations for modders about various moddable settings and a trick or two that influence how the AI behaves.
Even though my notes may seem thorough, both the research and the mod are very much a work-in-progress: as I continue to expand and double-check my notes, others will undoubtedly also start reporting their own observations, which I will try to aggregate and verify as much as possible. If I am missing something or you think a certain observation/conjecture is incorrect, let me know and I'll see what I can do.
Quick links:
Section 1: Artificial Unintelligence (mod v0.62 for Rebellion v1.82)
This mod takes advantage of the settings and tricks mentioned in Section 3 to make the vanilla Sins of a Solar Empire AI more competent; every single parameter mentioned has been altered, and every single trick mentioned has been used to some extent. The mod also has two gameplay-altering addons that help the AI (they are optional because they actually change gameplay) as well as a standalone addon that changes the way it behaves: The Quick Start modification addon adds a Culture Center to the Quick Start buildings. This was added to make it harder to quickly steal planets near an enemy capitol early in the game, something that the AI is very vulnerable to, and also because AIs will start building culture buildings much quicker if an opponent has already built one, so the Quick Start modification also enables them to get into the culture game faster. Ideally, I would have made the Home Planet improvement add flat culture in addition to its regular bonuses, but I have not found a way to do this, so for now, the Culture Center Quick Start is my best solution. The Kostura modification addon makes Kostura Prototype (the research that unlocks the Kostura Cannon) require 2 levels of NME Warheads. This not only brings the Kostura more in line with TEC and Advent superweapons in terms of how much research is required to unlock it (eg. you can't just build a ton of military labs and rush it, only TEC Loyalists can do that now), but also makes the AI more likely to research phase missile upgrades, since it is hardcoded to prioritize techs that eventually unlock new ships or buildings. The Rabid AI addon forces the AI to use some fallback, faction-generic routines for vanilla Sins factions instead of the usual, faction-specific ones. It is called "rabid" because these routines make the AI both a lot more aggressive and a lot more illogical, as well as introducing bugs into its handling of capital ships. Ship production, tactical structure production, and fleet management are all governed by fallback routines, while faction-specific routines still govern all other aspects (eg. research, starbases, logistical structures). This addon functions independently of other parts of the mod, including the main mod. Enable this addon at your own peril.
Sins Artificial Unintelligence v0.62 [for Rebellion v1.82] can be downloaded here (mirror).
Changes since the last version (v0.60):
Known issues:
Section 2: In-Game AI Info
In the absence of any official information on how the AI's operate, all info had to be acquired through weeks of running test games in various configurations.
General:
Behavior Presets:
Keep in mind that these descriptions only fit well on lower difficulty levels: at higher difficulty levels, the fact that one preset is better or worse at building their economy is made pointless by the fact that they're showered with resources anyway. When I mention "economy upgrading", I mean building, researching, or upgrading anything that increases income or decreases ship/module cost.
Factions:
The AI has a lot of faction-specific behaviors associated with it; not only do AIs of the three/six vanilla factions behave differently based on the factions themselves, but they follow different routines as well. However, if the AI cannot determine which faction it is controlling (eg. as a result of controlling a non-vanilla faction or extensive modding of a vanilla faction), it will instead resort to fallback, faction-generic routines that make it completely differently, to the point of being considered its own "faction" entirely. Note that the AI will not always switch 100% to fallback routines: in some cases, only certain fallback routines will be used, while faction-specific ones will still govern other parts of the AI.
Section 3: Modding AI Info
Since I do not have access to the AI's source code, all statements are based either on in-game observations from tweaking various values and/or on experimentally verifiable observations made by other players and modders.
As a modder trying to get into the AI's head, the Player Info menu ([d] inside the dev menu) is your friend: the four items [a] Show Mission Queue, [b] Show Fleet Comparison, [e] Show Spending, and [f] Show Build Lists are invaluable in relaying what the AI is thinking at any given time.
The AI operates using AI ticks: all AI orders are given out at regular time intervals. To clarify, this means all orders, from selecting techs to retreating fleets, are all given out at the same time, and the AI will wait a few seconds afterwards before giving out its next batch of orders. AI ticks happen roughly once every 10 seconds (9 to 11 income ticks), but they are out of sync between different AI players. To my knowledge, the time interval cannot be modded.
Missions:
The AI gives orders to its ships based on missions the AI creates for itself to complete: it will populate its mission queue with missions, then produce and assign ships based on its current mission queue, rated by priority. Modders can view an AI's mission queue via [d] Player Info > [a] Show Mission Queue from within the dev menu, then selecting a unit, module, or planet belonging to the AI in question. Scout frigateRoleTypes will be sent on Explore missions with targets on enemy, neutral, or undiscovered gravity wells, Colony frigateRoleTypes will be sent on Colonize missions to nearby neutral, colonizable planets, combat ships might be sent on ClearOrbitForColonize missions to nearby colonizable, neutral planets with hostiles in orbit, etc. Note that the AI will never remove missions, only alter their priority; this is why AIs tend to be more and more schizophrenic the longer a game lasts, as their mission queue expands to sizes it can no longer handle properly. The only way for a mission to be removed from an AI's mission queue is if it is completed or if its objective is no longer valid (eg. attack a planet that is now allied, clear orbit for colonization of a planet that was just colonized by an enemy).
Mission .entity Files:Some missions have their own .entity files, allowing modders a limited amount of control over them. Each mission has its own entityType, but all mission entityTypes have only one parameter, missionType. For the game to recognize a mission, its name must match its entityType, so multiple entities corresponding to the same mission are not possible. The missionType parameter is used to direct the AI to the appropriate algorithms. The framework means that, in theory, modders could redirect AI missions. For example, having the MissionAttackPlanet entity have a missionType of Explore would redirect the AI to its Explore routine whenever it wants to attack a planet. In practice however, the different mission types use different internal arguments, so redirects often cause the AI to lock up in the best case (eg. when redirecting MissionAttackPlanet to MissionFosterRelations) or the game to minidump in the worst case (eg. when redirecting MissionBuildMines to MissionBuildStarbase).
Gameplay.constants:
Abilities:
The AI will automatically enable autocast and use certain abilities on ships and buildings of certain roleTypes. For example, abilities will automatically have autocast enabled for CANNON planetModuleRoleTypes. Scout frigateRoleTypes will automatically be assigned to Explore missions (see Missions subsection), even if they lack an Explore-type ability. Colony frigateRoleTypes (and possibly capital ships with the COLONY roleType) will automatically use Colonize-type abilities for Colonize missions. Otherwise however, if an ability does not have autocast turned on by default, the AI will never use it.
Leveling Capital Ships and Titans:The AI will choose a random ability from its unlocked abilities that are at the lowest level, unlocking new abilities only if it cannot do anything else. Abilities with isUltimateAbility set to TRUE will be prioritized over those that are not. As a result, AI capital ships in the base game will always end with two random abilities and their ultimate maxed and will never have a non-ultimate ability more than one level higher than their other unlocked abilties. The same logic appears to govern the way Titans are leveled.
Planet Modules and Ships:
AIs strongly depend on frigateRoleType, planetModuleRoleType, roleType, and role values assigned to ships and planet modules. "Strength" calculations are never done when the AI is deciding what to build. Modifying these values will affect what ships/buildings the AI will create, also influencing its army composition. For example, setting the culture module's planetModuleRoleType to "REPAIRPLATFORM" should have the AI building it as if it were an orbital repair platform, while adding the frigateRoleType "AntiModule" to carriers will have the AI building carriers to try to counter starbases and static defense in addition to actual antimodule frigates like the Ogrev. Keep in mind though that altering these values may have other gameplay effects, notably on autocasting when the "IsDifferentRoleType" aiUseTargetCondition value is used; ships with the "AntiModule" frigateRoleType can only attack structures, so use it only sparingly, even if the AI does love it. For strike craft, the "role" value for the strike craft's squad is used, while the roleType value for capital ships is barely used outside of determining which capital ships can colonize.Note that messing around with modules' planetModuleRoleType is a lot more risky than messing around with frigates' and capital ships' roleTypes: the game seems to be very particular about certain roleTypes, and will crash if modules of a certain planetModuleRoleType do not comply with its expectations. For example, structures with the WEAPONDEFENSE planetModuleRoleType must have a weapon, otherwise the game will crash when the AI wants to build one.
Frigates with Bombing Damage:The AI handles these in an odd fashion: if a frigate can deal damage to enemy planets, the AI will order them to attack the planet upon entering the gravity well, even if they don't have the "Siege" frigateRoleType and/or there are high priority targets (ie. Colony Ships) nearby (thanks Seleuceia!). The game will crash if an AI is playing a faction with no frigates that have a particular frigateRoleType, such as "ResourceCollector" (thanks Seleuceia!); this is likely due to it searching for particular frigateRoleType ships when queuing possible missions (see Missions subsection).
Building Capital Ships:The AI is quite straightforward with building capital ships: if it has no capital ships or its lowest level capital ship is level 3 or higher, it will queue up a random capital ship at its home planet (thanks Lavo_2!). This queue is not the same as the in-game build queue, and the capital ship type will randomly change every AI tick until it actually gets queued in-game. In-game stats have so far shown that capital ship choice is truly random, both for the first capital ship built and for any subsequent capital ships. Giving the AI the means to reach capital ship level 3 quickly, eg. by making the XP cost of the first two levels 0 via gameplay.constants, will force the AI to spam capital ships. Note that if the AI has no capital ship factories, it is hardcoded to prioritize a new capital ship factory in a similar manner; the implementation is a bit buggy though, see the Build List Bugs subsection under Overall Production and Resources.
Building Titans:The AI is prioritized to research titan-unlocking techs; however, it will only actually start construction of a titan once it has enough capital ship slots. Since the AI only upgrades its capital ship slots if it currently has 0 slots, Titan construction is only possible once the AI has researched the first capital ship supply tech that gives 2 capital ship supply, or if it loses a capital ship while having the necessary techs unlocked. By default, this is capital ship supply tech 4, meaning the AI must either lose a capital ship after all titan-unlock techs have been researched or have at least 3 capital ships level 3 or higher before it will even consider titan construction. Once a titan is in a build list, it is hardcoded to have a higher priority than even capital ships, so gathering enough resources for it usually is not a problem for the AI.
Fleets and Army Management:
When managing armies, AIs make constant use of fleets. Though AIs can manage individual ships just as well as fleet groups, fleets will be an AI's smallest army element 99% of the time, so AIs will usually move to target planets as a fleet, retreat as a fleet, and move to locations within gravity wells as a fleet (attacking is a bit different). All AI fleets will adopt a cohesion range of All Standard, regardless of what is set as defaultCohesionRange in Fleet.entity. AI ships will organize into fleets regardless of whether or not autoJoinFleetDefault is set to TRUE or FALSE. However, AI ships that only have certain frigateRoleTypes will never make or join fleets, even if autoJoinFleetDefault is set to TRUE: these frigateRoleTypes are Scout, Colony, ResourceCapturer, ModuleConstructor, Cargo, Envoy, and StarBaseConstructor; Scout is a special case outlined two paragraphs down. Flagships are still included in fleet management processes, but the AI forces them out immediately afterwards, so they are practically exceptions.
Making and Rearranging Fleets:AIs will fire off fleet creation and rearrange routines throughout the entire game. Most creation and rearrangement routines will only fire if any ship in the gravity well has no current order. When a non-fleet combat frigate (any frigate that is created for a frigateRoleType that isn't Colony, Scout, ResourceCapturer, ModuleConstructor, Cargo, Envoy, or StarBaseConstructor) with no current order is in a gravity well or phase jump region that has no fleets and at least one other combat ship, it will initiate a fleet creation function at the next AI tick (roughly once every 10 seconds): either the originator of the creation function or a higher ranking (Titan > highest level Capital Ship > lowest level Capital Ship > Frigates and Corvettes), non-fleet combat ship in the same gravity well (ships in phase space count as being part of the gravity well to which they are jumping) will create a new fleet and invite all other non-fleet combat ships to that fleet. When a combat frigate enters a gravity well or phase jump region that already has at least one fleet, it will initiate a fleet rearrangement process on the next AI tick (roughly once every 10 seconds); every ship that takes part in the fleet rearrangement process (ie. has at least one frigateRoleType that is a combat frigateRoleType) will be part of a fleet after it is completed. All ships in the same gravity well assigned to the same mission (see top of Section 3) will be placed into the same fleet. Note that ships already in the same fleet can still be (re)assigned to separate missions. The AI will periodically check if ships in a fleet are still both in the same gravity well and on the same mission and if not, they will fire off a fleet rearrange. As a result, large fleets phase jumping to a gravity well will often be split up, since even though the ships are on the same mission and in the same fleet, the ships currently in phase space technically are not in the same gravity well as those that are preparing to jump; this triggers a fleet rearrange, splitting up the large fleet,
Scout frigateRoleType Issues:Although the AI treats the Scout frigateRoleType as a non-combat frigateRoleType, the moment a ship with it enters into a fleet with one other ship, even if that other ship is also a scout, it will switch over to a combat frigateRoleType for that ship. Since the AI will not attack with ships that do not have auto-attack turned on, those scouts are dead weight for the rest of the game. The AI will also not build any new scouts, thinking its existing ones (that are dead weight) are enough. A small workaround is to have an explore ability with autocast turned on by default; this will force the AI to still try to keep scouting with its dead weight scouts. However, the AI still recognizes those ships as combat ships, so they will often try to jump back to a gravity well containing normal fleets. If aiUseTime is set to Always on the explore ability, the scout ships will waddle back and forth between trying to scout a gravity well and trying to assist an allied fleet; though this is still no solution, it is better than nothing, and there is little modders can ultimately do to fix the scout grouping bug.
Giving Orders:The AI will only give fleet leaders explicit orders, making non-leader fleet member behavior fairly predictable; the sole exception is any frigate with planet bombing capabilities, who will always be ordered to bomb a planet. Unless the fleet is planning to jump to another gravity well, fleet members will move with the fleet leader at all times, matching the fleet leader's speed. This means that if a fleet member is faster than the fleet leader, it will move slower than usual. If the fleet leader is targeting an enemy that is not in the same fleet as a member's target, the member will move into formation with the leader (matching speed as well) until an enemy that is part of the fleet the leader is targeting enters the member's attack or autocast range; if the member cannot attack (eg. carriers) or doesn't have auto-attack turned on by default (eg. scouts), it will simply stay in formation with the fleet leader.
Overall Production and Resources:
To determine what it wants to spend resources on, the AI keeps track of six total spending queues, or "build lists": one for ships of all types, one for research, one for building research labs, one for building logistical structures that aren't labs, one for tactical structures, and one for planet upgrades of all types. These can be viewed at any time from the dev menu via [d] Player Info > [f] Show Build Lists. Build lists are where the AI queues up stuff it wants to buy but cannot. Every AI tick, the AI will choose a build list to focus on (highlighted in red), trying to buy whatever it can from the focused build queue. The build list to be focused on is determined by a combination of chance, AI preset, current spending allocation, current fleet stance, and the priority of the highest priority item in each build queue. Priority within build queues is largely dependent on hardcoding and AISharedDef values from gameplay.constants. The maximum size of each build queue is determined by AISharedDef values from gameplay.constants, but not in a 1:1 fashion (eg. a value of 3 for BuildModuleResearch will not force the AI to only have 3 items in its labs build list).
Resource Tracking:Credits are the main currency for the AI: they are what the AI keeps track of, while Metal and Crystal are only considered to the extent that the AI can afford what it wants to do. For instance, while Credits spent on buying Metal and Crystal on the Black Market are kept track of in the AI's spending log, Metal and Crystal sold for Credits are not.
Resource Allocation:Current resource allocation can be seen under the [e] Show Spending in the player info menu, while ideal resource allocation is driven by the AI's preset. An Aggressor AI is hardcoded to spend more Credits on ships, while Researcher AIs are hardcoded to spend more Credits on research. Spending Credits on the Black Market is tracked independently of everything else, so an AI that spends twice as many Credits on a tech due to having to buy Crystal from the Black Market will still only note down the tech's credit cost as "spending on research". The ideal allocations set by each preset don't appear to change over time, resulting in things like the Researcher preset researching every tech up to level 3 in the first few minutes of the game. Things get really wonky with ships that build structures or have abilities that cost resources. Specifically, the AI will not keep track of Credits spent on abilities or structures built by ships instead of from planets: in particular, this applies to starbases and non-TEC mines (TEC mines are built from the tactical structures menu, so the AI logs its spending as spending on tactical structures). Spending on ships will always be logged down as such, even if the sole purpose of the ship being built is to construct something, eg. starbase constructors. Starbase upgrades, on the other hand, are kept track of in their own category with its own allocation expectation. This is why Aggressors tend to have a lot of unupgraded starbases (their hardcoding prioritizes spending on ships, so they will spend lots on starbase constructors, not log down the cost of building a starbase, then not upgrade those starbases because they are hardcoded to not spend as much on starbase upgrades). The AI also has no resource allocation for diplomacy: spending on envoys is recorded as ship spending, spending on unlocking diplomatic actions and abilities is recorded as research spending, and sending resources to other players to complete missions is not kept track of at all.
Black Market:The AI is very liberal when using the Black Market. When considering what it can afford, the AI will always take the Black Market into account, even if it would result in spending three or four times as much on something. More often than not, the AI will decide what to do and try to find a way to afford it rather than choose something to build or research that it can already afford without splurging on the Black Market. This is why Aggressor Vasari AIs tend to spend mounds on buying metal (Vasari LFs have a fairly high metal cost for their build times and supply usage, so Aggressor AIs who keep spamming LFs will run out of metal real quickly, and their drive to build more ships results in their Metal buying sprees), while Researcher AIs, especially Advent, will tend to spend loads on Crystal.
AI Biases From Resource Cost:Due to set-in-stone ideal resource allocations and the fact that only Credit spending is kept track of, the AI will prefer ships and structures that cost less credits but more metal and/or crystals over those that cost more credits. For example, if a ship costs 100 Credits and 1000 Metal, the AI will spend 4500 Credits or so on buying the Metal, build the ship, and log it all down as 100 Credits spent on ships and 4500 credits spent on buying Metal. If the AI is an Aggressor AI, it will want a rather large chunk of its spending in the ships category, so it will keep buying the ship until it thinks it has spent enough credits on ships, theoretically building about 45 more ships than normally desired. The extra credits spent on buying metal are logged as Black Market expenditures, which lower the percent of expenditures in all other categories, even the one in which the bought resources were spent (in the case of the example, this would be ships).
Extractor Build Order:The AI will always build extractors in the same order, no matter their current income ratios. They will always build metal extractors first and crystal extractors second. When there are multiple asteroids available, the AI will alternate between building the two, but if possible, one metal extractor will always be built before a crystal extractor. This does not appear to apply to capturing neutral extractors (since autocast targeting is what controls AI behavior there).
Build List Bugs:Normally, the AI is programmed to only place items on build lists that are available to it at the time. For example, it will not place frigates in its ship build list that it has not unlocked yet, it will not place social upgrades on its planet upgrade build list when it has already chosen industrial upgrades for all its current planets, etc. There are, however, a few exceptions: the AI does not check if research prerequisites are met before queuing up extractors, frigate factories, capital ship factories, military labs, and civilian labs. While most of these will simply be queued up and forgotten, capital ship factories with research prerequisites will actually cripple the AI until it finally builds one. This is because capital ship factories are given hardcoded priority, meaning the AI will barely build any non-labs logistical structures, including extractors, until it finally satisfies its lust for a capital ship factory.
Research:
AIs have a very set-in-stone method of researching techs, and there is little modders can do to alter the process. Though the AI will not consider a research's cost, it will not try to research anything that it cannot afford outside of the hardcoded stuff mentioned later and the Research Victory tech. Due to the AI's reliance on resource allocation when determining whether it should research a tech or not, AIs will usually research lower tier techs first. Observations indicate that when the AI wishes to research something, it will queue up all techs that are currently available to it in its Research build queue (see Production and Resources subsection), though never queuing up more than one level of a tech at a time. It will then treat its research build list just like any other: rearranging it every AI tick, giving it focus based on the highest item on the build list and its current resource allocation, etc.
Hardcoded Priorities:The AI is hardcoded to greatly prioritize certain techs under certain conditions (they will always occupy the top of the research build list and will often cause the AI to shift focus to it). AIs are hardcoded to research every single tech and its prerequisites that unlock ships or planet modules, though it will only do so once it has enough labs to research all the necessary techs required: for example, this includes the first few levels of the extraction bonus techs for Vasari (unlocks Orbital Refinery), all the regular culture techs for Advent once 8 civilian labs are built (unlocks Deliverance Engine), and all missile weapon upgrades for TEC Rebels once 8 military labs are built (unlocks Novalith Cannon). However, since the AI can research techs before their labs complete, it may appear that the AI is unlocking techs even before it can research a prototype. Other techs included in AI hardcoding are as follows: supply cap and capital ship cap techs if the AI has maxed out the respective supply, techs that unlock the colonization of planet types the AI has discovered and wishes to colonize, wormhole travel unlocking techs if the AI has discovered wormholes, and interstellar travel unlocking techs if there are multiple star systems. All vanilla faction AIs in Sins are also hardcoded to research the relationship-improving techs from the Diplomacy tech tree. The AI is hardcoded to only ever research pacts if it has a ceasefire treaty with at least one other player, but said pact unlock techs get hardcoded priority when this is the case.
The priority parameter:This parameter in a tech's .entity file dictates its priority in the research Build List: a tech with a priority of 2 will always be placed above techs with a priority of 1. Techs with a priority of 0 will never be researched by the AI unless they have hardcoded priorities. The game will accept both negative and decimal values for priority (possibly up to the limits of a double-type variable), but it will treat negative priority values as if they were 0. Techs with hardcoded priority are always placed at the top of the list irrespective of their priority parameter value. The AI will rearrange its build list every AI tick, meaning that two techs with equal priority have an equally random chance of being researched before the other. Note that giving a single tech a higher priority value than others may effectively stop the AI from researching completely: since the AI will only ever compare the top items in each build list, and giving a single tech higher priority than all others will place it at the top of the research build list (under hardcoded techs), if the AI never wants to research mentioned single tech, it will never give focus to the research build list, stalling all research.
Dummy Research Ladder:A while back, a coding trick for prioritizing certain techs was developed by a group of enterprising modders, including Lavo_2, GoaFan77, and Zombie. The trick takes advantage of the AI being hardcoded to prioritize techs that unlocks ships/buildings, being able to define 2 research prerequisites for each tech, and being able to place tech buttons in an off-UI area so that human players will never see them, but the AI can still research them. It involves making a ladder of 0 cost dummy techs, with the bottom of the ladder populated with actual techs (endpoints for each tech chain are enough) and the top of the ladder containing a tech that unlocks a dummy ship or building that is too expensive for the AI to ever actually make in-game. Since the AI is hardcoded to prioritize unlocks, it will try to unlock the dummy ship, even if the ship is actually too expensive to ever purchase. To do so, it needs to climb up the dummy research ladder, and to do that, it needs to complete every single research in the game. Though the trick requires a long, ardous setup time (you need to set up a different ladder for each tech tree, requiring about n-1 dummy techs for n total "real" techs), and the effects usually only kick in once the AI has enough labs to research the highest tier tech at the bottom of the ladder, the payoff is that the AI will highly prioritize certain techs, regardless of its preset. Modders who use this trick must choose between two options: either having a smaller ladder, which results in the AI greatly prioritizing certain key techs and relying on the usual process for all others, or a large ladder, which results in the AI prioritizing all techs regardless of preset, but losing focus as a result.
Once again, the contents of this post are subject to change as current observations are reevaluated and new ones are noted down. If you see something missing or not aligning with your own in-game observations, please let me know.
I would expect indie developers to be the least lazy because they are inclined to compete with larger studios who greatly prefer quantity over quality.
It's not about making the AI moddable. Most companies who claim to be making something "moddable" don't even know what modding is. It's just about common sense and respecting one's own work, planning for the future, etc.
No doubt in my mind they were simply lazy.
GC3 is said to be much more moddable than previous SD games, and the AI itself will even fall under that umbrella....
But then again, Brad himself is working on it, and he's really into that stuff...
In any case, SD is at least trying...I can't speak for Ironclad, but it was mentioned that the game is as moddable as it is so they could easily change certain things...
It does seem more things are hardcoded though in Rebellion....Spaceponies, cosmetic titans, those type of things....
Someone linked me a video on that new engine (I guess it's for GC3? I haven't kept up with their newer titles). It was being developed as a toolset/engine independent of any specific game but designed towards space RTS in the vein of Sins, I think. It's using Mantle, so it has quite a lot of processing power behind it. If it's a toolset along the lines of Unity or the UDK, sins will be incomparable to it in any shape or fashion.
But yeah, you've got the idea. Moddability comes hand in hand with engine design and how its data was laid out. For example, in Brood War, the AI's build orders and so on was all softcoded. It needed a user-made tool to interact with, but it was, for all intents and purposes, quite moddable. Of course, micro and everything was entirely hardcoded - the developers never intended to expand or change that. But the AI build orders and stuff was rendered more easily accessible so they, as developers, could change it more easily. Later down the line, Heinermann I think his name was, decided to take it a big step forward with BWAPI.
Modders simply take advantage of what is available or make things available. Some games/communities are more accustomed to reverse engineering; stuff like the Sins AI being hardcoded would thus only be an issue for the developers (who in this case clearly never intended to iterate on it past those values in the personalities) and not the modders who altered the game to their desires. Such is the case for games like Diablo 2. Diablo 2 was a game never intended to be moddable by any means, but it's rather mod-friendly if you look past the countless hardcoded issues. There's an amazing map editor and everything made for it. But it also has a pretty steep learning curve, and you really need to know programming/reverse engineering to make the most out of the game. It's just, the developers designed the game's data in a way that it was relatively expandable (compared to Sins), and by extension this invited modders to do the same.
I wrote out tons of compendiums of data for AI and stuff related to brood war not unlike this thread. It's great to see people still trying to work past those limits, and never in any way would I try to discourage someone from doing what they want to do regardless of their skillset. However, I really wish the development ethic of locking all these basic things like build orders behind exes was a thing of the 90's.
Man, I am really stressed out. I shouldn't be posting when I feel like this. Time to huff some jenkem and bury myself in 3ds max for a few weeks.
GC3 is strictly turn based and has its own engine. Not the one that is being paraded around on the internet.
Ah. I did a fair bit of modding for Age of Wonders 2 a while back, which is also turn-based. Incidentally, also a very hardcode-heavy game (The AI was completely hardcoded, even moreso than sins). So, it's quite possible I might look into GC3 when it's available.
It's not just build orders. Sadly I haven't had the privilege to play with Sorian's AI. But I've played AI War.
The AI is super basic itself. It most certainly isn't "emergent". It's pretty easy to predict, and the harder difficulties are just altering the meta game
Well the AI in GC3 will and won't be hardcoded. It will be hardcoded (unless I am wrong) in the fact that we cannot get to the coding to change it ourselves. But it won't be in the fact that as long as you are connected to the internet (completely optional though) the AI will rewrite itself to better itself by watching not only your game but other games as well to change and develop better build orders and strats.
At least that is the way Brad (the AI coder) described it unless I misunderstood him.
That won't work for mods, lol
Mods change the game in ways the original devs can rarely ever account for, even if they spend years trying to write for fringe cases.
If the AI is locked behind compiled exes/dlls, it's hardcoded, and thus heavily restricted.
a lot of nice info. anything that makes the aI more balanced and smart and less cheesy is welcome
Sorry I haven't replied to the newer posts yet, was occupied with other matters. As a result, I haven't really gotten a chance to verify the buying promotions advantage yet, but I'll do it shortly.
Mediafire is quite reputable and has been around for years, almost 9 if Wikipedia is to be believed. Multiupload macros uploaded files to a whole slew of other sites, so if you don't like or cannot use Mediafire for some reason, you can always try your hand with that (when I was tinkering with Android ROMs, it was usually because the downloader was from China and their government blocked access to a lot of file sharing sites, so Multiupload was the only way to really cover all the bases). If you end up with malware from your computer after using these sites, chances are they aren't where the malware actually came from.
That's probably from edits to aiRetreatThreshold. Editting that value was real tricky, not because it was hard, but because of the trade-offs. If you haven't read the rest of the original post, it's what the AI uses to decide whether it wants to fight or flee: lower values make it fight more, higher values make it flee more. The problem is the AI's way of calculating ship strength is dumb, eg. it overvalues capital ships, undervalues longe-range frigates, and doesn't take fleet-replenishing ship produciton into consideration. If I increase the value, the AI will preserve its fleets more, but it will retreat from battles it could easily win just because the enemy brought in a level 1 capital ship. If I lower the value, the AI won't retreat from battles it could easily win, but it won't retreat from battles it would lose, either; it also is much slower to colonize neutral planets at higher values, which is the main reason I ended up slightly lowering the value (from 0.25 to 0.20). However, if you disagree with my choice, feel free to open up the mod's Gameplay.constants file and edit away (you'll find it in the GameInfo folder within the mod folder).
From what I've seen, heard, and read about AI design and development, the only time laziness is the reason for bad AI is when either the developer does not care about their game (extremely rare), and in those cases the AI is usually not the worst part of the game. More often than not, it's a combination of not enough interest, not enough manpower, not enough know-how, and not enough time. To start with, programmers are paid a lot less in the games industry than in other industries, so you've already discarded your best talent. Programmers are also usually a lot more familiar with code relating to graphics, sound, newtonian physics, memory allocation, thread management, and networking simply because they've been doing those things since they started programming, especially since said things are used quite often outside the games industry as well (graphics and newtonian physics for animation studios and simulations, sound for audio recording and moviemaking, networking for almost everything, DRM/cryptography for security systems, etc.). AI, on the other hand, is only really used in niche areas or specialized projects outside the games industry; as a result, most professionals don't know that much about AI programming, and the ones who do would never leave their specialized projects due to passion and being paid more than they ever would if they worked on games.
When it comes to AI modability and indies, you've got it the other way around. Disregarding the fact that both small and large developers care about the games they make and that it's usually publishers who ruin things (just look at how often high-ranking people from large developers leave the studio they founded years ago to start anew), modularity and modability get more and more important as the development team gets bigger and bigger. With two or three programmers, they could easily work together and quickly produce code that all three of them understand, but would take months for anyone else to start working with. However, when you're working with at least 20 to 30 people, some of them even changing from time to time (eg. Valve's way of getting people to shift effortlessly from project to project means you might be working with a completely new set of programmers 4 months down the line), it becomes incredibly important to make sure your code is modular so that everyone on the internal team can easily find and work on the stuff they need to/want to work on, as well as keep track of changes anyone else makes. This is one of the main reasons object-oriented programming languages took off like they did, the modular architecture makes larger teams of 100+ programmers all working on the same project exponentially more manageable. It's another matter entirely if the developer wants to make said modularity available to modders, but that's a different decision, often tied into the fact that the AI code is fused with other parts of the game's code, so opening up the AI to modding would be like releasing the game's source code. I'm not even going to mention how games are often designed with consoles in mind, so adding modability to a game is the least of a large developer's worries (sadly).
That said, BWAPI and Sorian's AI still fall into the same trap as the unmodded AIs of their respective games: they function off of pre-set, pre-determined AI scripts. Their only advantage is that modders have access to a competitive multiplayer community that invents build orders and set strategies that are a hundred times more efficient than the stuff the original developers thought up. No matter how good of a Brood War AI you make, it only takes a single unaccounted-for scenario to bring the whole thing crashing down. As you can imagine, it's a lot easier to have unaccounted-for scenarios in 4X, grand strategy, and sandbox games than traditional RTS's (non-traditional RTSs would be games like World in Conflict or C&C4), which is actually why the two AI mods you listed work so well.
Deary me, that sounds like the way Civ5's AI is implemented (and SoaSE's AI to a more limited extent): the scripts and logic are hardcoded and unchangeable, but said logic uses variables that are as easy to alter as editting a text file. The issue still remains, however: the ideal AI should use as little hard-set logic as possible, especially AIs that need to consider a lot of factors (ie. 4X and grand strategy AIs). If the logic of an AI is completely hard-set, you must either manually program in and account for all possible scenarios or be forced to leave in gaping AI vulnerabilities. Civ5's attempt to remedy this was to have the AI switch between "grand strategies" in a weighted random matter, but this just resulted in AIs with Multiple Personality Disorder. However, because making flexible AIs is infinitely more difficult to the point where it might just be better to stick with tried-and-true AI design and devote development resources to other areas, it's easy to see why 99% of games use hard-set scripts or training-model AIs (also called "Neural Network AI") in their games. Notable exceptions, including games that still have hard-set scripts, but let the AI figure out how/when to connect said scripts to each other: the Sims (the entire series is a gold mine for AI in my opinion), Crysis (first one, not 2 or 3), FEAR (first big game to implement the hard-scripts, soft-connections AI design), Rage (also uses the hard-scripts, soft-connections design), Tropico 3/4 (the way the individual citizens behave), possibly Far Cry (only the first one).
... on the other hand, distributing AI to scripting/interpreter languages like Python or Lua shackles AI capabilities to the limits of your scripting language and/or overly taxes system resources, especially in games that are faster-paced and/or require the AI to keep 100+ factors in mind when making decisions; plus programming in "safe" languages (eg. Java, scripting languages) bars you from implementing "intuitiveness" code, aka "let's randomly f*ck around with the stuff stored in the memory addresses allocated to AI methods during execution without actually knowing what we're modifying and see what happens". By the way, just because the AI code is in an assembled file doesn't mean it's heavily restricted: if the developer is smart, they can (re)write the AI code in a way such that releasing the source code would not jeopardize the game's security, then release the source code for modders to exploit. See: Civ4, where pretty much every larger mod includes some sort of an altered AI as a result of Firaxis releasing the source code for CvGameCoreDLL.dll.
Does this mod only work for vanilla Sins? Or would it be compatible with other mods?
I doubt that as it alters the Entity entries. compatiblity could be done, however, by editing the files...
The main area this mod effects is the gameplay constants file. There are some mods that mess with this (Distant Stars for one) so be care when merging mods.
The compatibility section in the mod's Readme is a bit more detailed, but I actually altered quite a lot of Entity files (for researches, ships, abilities, etc.), since so many AI behaviors depend on certain parameters in said Entity files. Gameplay.constants was the first thing I worked on, sure, and probably contains the most significant alterations, but the other files are possibly just as important: ship entity modifications influence AI fleet compositions, research modifications influence AI research priority, ability modifications influence AI ability usage, etc. As a result, though the mod would be partially compatible with a lot of mods, it will only really work to its fullest in unmodded Sins. This was one of the main reasons I included the modder reference/information stuff, so that modders would be able to use the information I found and/or know of to "port" AI improvements to their own mods without me having to worry about mod compatibility.
If, however, you mean Sins of a Solar Empire: Trinity or Rebellion without DLC by "vanilla Sins" (vanilla as in no expansions and/or no DLC), the mod will only work in Rebellion, but does not require any DLC.
Extremely rare? No... not at all, I'm afraid. You can blame publishers for a lot of things, but their involvement in disgusting programming ethics only goes so far. Once you've been around the block enough times you see patterns form in many different elements that allude to involvement from many parties. For example, in Saints Row 4, the fact the game is immensely rushed and lacking content is a fault of the publisher. The fact that the game still has severe bugs in it from Saints Row 2 is a fault of the developer. As a very quick and readily easy example.
As for the difficulty in making AI, it's really not that hard as long as you are willing to make a few small sacrifices for the sake of time and expandability. Simply testing a game and finding problem points (the group management in sins for example) is extremely easy. Most developers just simply can't be bothered to do that.
For Brood War, yes, I agree. It would be a difficult task to make an effective all-around AI. I don't expect an AI to be able to perform Jaedong-level plays. But, as an example, I would expect the AI to not crash its own internal hardcode at every given chance and ignore 100% legal code half of the time like it does in Brood War.
Supreme Commander is one of the simplest games ever created and has a very low skill ceiling. But with the limited infrastructure given to mods and with only lua to work with, I doubt Sorian's AI could achieve what BWAPI can. Nor would I expect either end to build a "perfect" AI mod. I would actually be quite content if a game had an AI similar to brood war but without the incredible amount of hardcoded issues it has.
You don't need to be a "professional to do a good job with AI. I wouldn't consider most developers in the industry professional by any stretch of the imagination. You just need to love your work and be willing to put in some time. Most people just aren't willing to do that.
Also, 30 person programming teams is just crazy sweatshop antics and I never take any games from such companies seriously.
I can't speak for Sorian's AI, but BWAPI is not restricted in the manner you describe because it's an external API with enormous functionality. The AI is essentially a bot and can be programmed in whatever manner the developer so wishes. It is, in essence, limited only by its creator and the game engine's ability to handle unit commands. This is a very different tool compared to what I had built my decade of modding with, which was the game's engine itself.
This is correct, but you won't see many developers do this because they are lazy or, more commonly today, intentionally want to restrict modding because it competes with DLC and annual re-releases. Generally, when a developer relies on hardcoding anything simple like build orders, it's mostly safe just to assume they are either incompetent or lazy.
Personally, I'm all for using compiled code in the nature you speak. Scripting languages are ugly, slow, and only sort of get where you want to be without actually offering any major advantages. But getting a good system like that is really not worth asking out of games, especially out of modern games. At the rate we're going, it's best just to make one's own game in an engine of their choosing rather than bother spending the time into modding. Kind of the part of the reason I stopped modding oh so many years ago.
After a bit of testing, I can confirm that the AI does buy promotions past the standard limit; however, they don't do it as often as the starbase limit bypass thing and will only start pushing caps past the promotion limit after all of their capital ships have reached the promotion limit, so it isn't as bad as the starbase limits thing. It's still worth mentioning though, I'll update the main post with this info shortly.
I put my faith in the fact that people make games they want to make; note how I said that in cases where the developer is "lazy" and not just short on manpower, time, and/or funds, the AI will be the least of a game's problems. Being a sandbox series, Saints Row is prone to bugs, and the only way to really fix them is to hire more QA, pay QA more (possibly in exchange for overtime), and/or allocate more programmers to fixing bugs filed by QA. All of these cost money, and when a developer is making a game with publisher backing, these things will inevitably boil down to publisher decisions as a result, not developer ones.
You don't need to be a professional to do a good job with AI. I wouldn't consider most developers in the industry professional by any stretch of the imagination. You just need to love your work and be willing to put in some time. Most people just aren't willing to do that.
By "professional", I mean people who do programming for a living and have for the longest time. It has nothing to do with individual skill, especially since hobbyists who specialize in a certain aspect of programming will most certainly be better at that aspect than paid programmers who move between projects on a yearly basis. However, no matter your personality, doing something more will make you get better at it. Programmers who worked on file syncing projects and secure transfer protocols for the past 8 years before getting into the games industry will naturally be better at anything involving net code or cryptography. However, because AI is such a highly-paid niche outside of the games industry, the few people who have worked on this kind of stuff long enough will never leave for the games industry. Don't forget that most professional programmers learned to code in a school, and said schools won't really teach coding design that is specific to the games industry the way that AI is. There's a reason running AI scripts has been the de facto AI programming design for the past 20 years, and it is highly unlikely that contagious, mass laziness is the primary explanation.
Supreme Commander (2007) had a total of 42 programmers working on it, from people working on net code to tools programmers (people programming the tools that other parts of the team were using) to visual effects programmers and campaign scripters; only one of these 42 programmers was responsible for AI (source). Starcraft (1998) had 15 programmers, Brood War (2001) had 12 programmers, but that's because the game itself is much simpler on a technical level than Supreme Commander.
From what I've read of BWAPI's functionality, it is still quite limited. For example, there is no support for self-modifying code. There is no support for game abstraction (ie. the AI takes information from a virtual game it runs in parallel with the one the player sees instead of directly from the same game). Programming in a "heat map" for Bayesian probabilistic mechanics (ie. the AI will be able to make predictions on what its opponent is planning) ranges from difficult (eg. build orders) to next to impossible (eg. army movement) with BWAPI. Finally, BWAPI has no support for script permanence, as in the AI dynamically stores information from past games it has played and recalls them in the future, usually to aid with prediction calculations.
Creators being protective of their creations is nothing new. Modding can pervert a game just as much as it can expand it: just look at how many (bad) nude mods there are for various games that don't need it (they're not even proper nude mods most of the time, since males are left clothed, because "naked breasts = good, naked penises = ewwww"), not to mention copy protection bypassing mods (they're still technically mods, though how much they actual "pervert" a game is definitely arguable when you use them with legitamite copies), multiplayer "trainers", etc. Even when the mods don't clash with the developers' vision or with the publisher's financial plans, most companies do not know how to use community modding to their benefit, with the exception of Valve (Steam Workshop, Community Market) and possibly Blizzard (Starcraft, Warcraft 3, and Starcraft 2 custom games culminating in the Starcraft 2 Arcade) and Bethesda (most people who buy Bethesda games do so because they know that even if the base game isn't that enjoyable, there will be enough mods to fix it). It's not about laziness, it's about whether something is worth a developer's time and publisher's money, and in most cases, their conclusion is that it simply isn't.
Ugh. Long quote chains and debating over the internet. I don't really want to continue this discussion as it seems pointless to me since I have no hope of convincing you of anything, but I'll give your hard work another reply for old time's sake. Prepare for a mess.
Except all of the game's most massive bugs are readily noticeable within the first few minutes of playing or can be found throughout the lifespan of a single playthrough and you don't need QA to find them. I'm just going to assume you've never actually played it. Fair enough. I have a video of the game if you want to see just how busted this game is and why it really should never have made it off a programmer's desk in its current state. I have to warn you, though, I have language that could whip the flesh off of sailors.
Absolutely. The average game design class doesn't prepare you for anything. These people are still students when they enter a company and remain that way for quite some time. Of all the people I know who trained in programming and/or are currently working in a big name company, only one I would consider "professional" in the true meaning of the word. That doesn't mean the others can't do good work, just that they don't have the experience or mindset to truly maximize the skill. Unfortunately, companies want the cheapest, most readily available meat to cut production costs.
This will vary on the genre and context but I think the majority of AI issues seen in games, just in general and not anything specific, is a result of programmers not applying player logic or never seeing the game themselves. Very few games demonstrate functionality that tell me "Hey, the developer actually sat down and played through this". Another reason why industrial juggernaut development negatively impacts games; programmers may not even see or get their hands on the final product their code contributes to. Communication becomes much more challenging, even ignored, in large environments. This was a big problem in Diablo 2, for example, one of the most notoriously buggy games I have yet to see. Just about everything in that game is broken. Literally every single missile desyncs immediately on spawning.
Big programming teams are people being lazy because they don't want to sit down and get the job done right. They just want it done fast. Communication problems arise when people are too lazy to properly manage their team and just let them free-float. So on so forth. Call it publisher laziness or developers, doesn't matter to me. It's not my fault that the developer saddled up with some retarded publisher. I'm looking at the end product and reading it into a set of mindsets and interactions the minds behind it had. Some of the worst games, e.g. Blizzard's games, in terms of programming are self-published or are so-called "done when it's done".
AI is not rocket science. It's clear just about anyone can get together core functionality. What separates professionals and John Doe to me is how their passion is expressed in the game. Can I break your AI in 5 minutes of gameplay? You didn't care about your game. I may have more experience in exploiting games than most people seeing as I sort get this sick pleasure out of it, but really. Sins as a game is not very bad on this when it comes to AI; the AI gets the job done, albeit very shakily, for the unmodded game. Only the group control and some other stuff really stand out to me. For a newly released product by a small indie developer, I can understand. I don't understand why none of that was fixed 3 expansions later.
Now, I suspect you might be European or at least non-American. If you are, it would explain your different experiences with the industry. If not, then you must be some kind of hardcore optimist. Mass laziness is a problem that mostly plagues the American industry. It's extremely obvious in just about everywhere. I would find it hard to believe even the most casual of individuals can't see it. There's a colossal amount of data behind this, data I really can't easily summarize in a forum post, especially when it's so far out of topic. But this laziness is something that has been here since the early era of gaming. It comes with Western culture. I'm not saying everyone is lazy. Nor am I saying entire companies are lazy. Some games that are evidently very lazily made still had some serious talent and effort behind them. But it's a big deal.
Probably. I stopped following brood war in 2009 and programming isn't exactly a skill of mine, so when BWAPI showed up my work with the game effectively vanished. However, most of the things you describe aren't necessary for a good AI. The best AI, perhaps, but it's never my goal (nor should it be a developer's) to bother making something that "learns" from players. This is a needless complication and bound to be filled with immense logic loopholes and brain damage. However, BWAPI is still immensely more powerful than what the game itself offers and, indeed, what most games offer even to their own developers. This is a mix of developers buying engines they don't actually know how to use, incompetence, laziness, or all of the above. Keep it simple. Keep it stable. Keep it steady. This is why Brood War has the best AI base sans bugs still.
It also performs terribly and has a lot of strange interconnecting problems in its code. I'm not surprised. Too bad, 42 is supposed to be the magic number. Brood War is filled with case-by-case hacks that lead to all kinds of strangeness, and many of their patches they made in an effort to fix something ended up breaking a ton of things. There's entire articles about how the game is hacky. Too many cooks spoil the broth etc. As you described, individuals working on something they enjoy will outperform a mass of people working on something just to make a quick buck.
These go hand in hand. An industry built on nothing but greed is bound to be filled with laziness, instant gratification design and development ethics, and all around mediocrity. The thing is, it's always about either laziness or incompetence. Publishers/developers want the quickest and easiest way to make money and don't want to put in the effort to make a game all it can be. So, they cut corners and min-max their way around content. This is inherently lazy. I'm not going to say it's bad business practice, because it obviously works. But I am a man who rates work based on quality and not on revenue. I know that kind of opinion is extremely unpopular, but I live by it nonetheless.
Major exceptions I see to this lay in Europe and Asia, especially Japan/Korea. Throughout the years, Japan has produced consistently high-quality titles. Whether you like the genres they focus on or the platforms or not, Japanese tend to be perfectionists, their respect and love for their work is often quite high (or they feel pressured to perfect). I am often hard pressed to call any Japanese games lazy, the major exceptions would be the two Souls games.
Sometimes. In the case of the context with having AI libraries open source, then yes. To an extent, it's not worth anyone's time to support mods. Like I said, most companies see mods as competition and openly oppose them (Starcraft 2 is very much like this; they support maps through battle.net but went through extraordinary effort to kill mods and local hosted content despite Browder expressing interest in the team color mod and such. Through the suffocating limits and censorship of battle.net, mods like what we see in sins are forever a pipedream in sc2). In the case of delegating certain basic fundamentals to hardcode or not, this gets more complicated.
I try not to judge a company too harshly until I see their work in action. When I review something, I try to remain as neutral as possible even though I am exceptionally judgmental. A part of reviewing is drawing a line between what is clearly developers not giving a shit about what they're doing and some kind of monetary or time constraint. I hope I don't come off as too harsh or aggressive. Such is not my intention.
Sorry for derailing your topic, by the way. Nothing personal. Just a subject I have to deal with each and every day... something I feel passionate about. I shall now depart.
Don't mind the derail, especially since I also post some sort of mod update with each reply, like the fact that I've started to notice the AI creates large armies of carriers simply as a result of adding AntiModule to carriers' frigateRoleType, and the fact that despite earlier claims, the AI can, in fact, scuttle strikecraft to change overall strikecraft composition, though because strikecraft only have statCountType to dictate roles, I don't know what the AI uses to calculate whether it should build fighters or bombers (or mines, in the case of Advent). Can't resist a reply though, but I'll try to keep it shorter:
About Saints Row 4 thing, I've played it a bit (2 hours) and watched quite a few Let's Plays, and it doesn't seem as riddled with game-breaking bugs as you say. About the school thing, I was talking about actual programming courses/degrees, since I know that game design degrees are even worse at teaching code (they're not really meant to, anyway); even if you wouldn't call your acquaintences "professionals", you'll still admit they know more about more "mainstream" areas of programming thought (eg. databases, networks, physics) than AI stuff, and if most games programmers are in a similar position... you get the idea.
About non-American/European, I was born in the US, lived there for 14 years, Eastern European heritage, lived in post-Communist bloc Eastern Europe ever since moving out of the US, so I'm more familiar with the whole laziness thing than I would want to be ("Pista" = John Doe). About the best AI being one that learns, everything I listed is required for such an AI: game abstraction separates the AI from the game (the AI becomes a player that happens to be controlled by code, and the virtual copy lets it "see" like a human player would), permanence lets it store past information (memorizing), Bayesian probabilities lets it process said past information (recalling), and self-modifying code lets it change its own logic (adapting) instead of being restricted to only using stuff that was defined by programmers ahead of time.
Longer reply for the laziness / large teams are bad / industry built on (short-term) greed: I think you know the actual cause of the problem, even if you don't realize it. Large teams miscommunicating and high-ups dictating an anti-modding stance have nothing to do with the programmers themselves and more to do with corporate structure; if a company is hiring less capable programmers than it should, it might have more to do with their hiring methods instead of "greed". It's not large companies that are ruining big-budget games, it's their overly traditional structure and inability to adapt to a new industry. Valve is both a large company (300+ employees) and a greedy one (read their handbook, they know their primary goal is to make money), yet they are celebrated amongst gamers, and for good reason. Take-Two is one of the oldest, largest, and most profitable publishers in the games industry, yet they are nowhere near as reviled as similar companies like Activision Blizzard, Ubisoft, Konami, or EA. Speaking of EA, the company actually started out quite small and with a non-traditional structure; let's see if you can spot a trend in EA-published games/franchises over the years (one title per developer): Populous (1989), Wing Commander (1992), Ultima Online (1997), System Shock 2 (1999), C&C Red Alert 2 (2000), Simcity 4 (2003), Battlefield 2 (2005), Crysis (2007), Army of Two (2008), Dragon Age Origins (2009), Dead Space 2 (2011). Also, Europe and Asia aren't exceptions, it's just that you only see the better stuff ported to English and come over to the US.
Err... re: wall of text on BWAPI....
What about the Berkeley Overmind?
I still have no idea how the AI chooses what strike craft to build, which bothers me immensely, since the following two pieces of data prove that it isn't random: 1) the AI rarely builds strikecraft mines, and never mixes strikecraft mines with non-mine strikecraft; and 2) the AI will actively scuttle and rebuild strikecraft in a non-random fashion (ie. it will only ever scuttle one strikecraft type at a time, usually 3-4 bombers or 3-4 fighters). The next thing I want to test is damage type (eg. changing bombers to do AntiVeryLight instead of AntiVeryHeavy), but since my power supply started dying about 2 days ago, I can't really run any test games until my new one arrives.
I've also been looking into Multiupload.nl possibly redirecting people to malicious websites, as even though the links I've tested for my own stuff seem to be fine, other people's links do redirect. It's possible the site was hijacked, in which case I'm considering moving the mirror over to Multiupload.biz or Mega.co.nz.
Since its source code is not publically available, I cannot comment on it. However, most BWAPI AI's switch between 100+ pre-set scripts based on various factors (chance, worker count, enemy units seen), so I can safely assume Overmind does a similar thing. As mentioned before, the problem with this setup is that everything has to be defined: if the AI scouts its opponent early and sees a fast expansion, the programmers have to have made a script for fast expansion-responding strategies for the AI to know what to do. This has to be the case for every single gameplay possibility possible, and sooner or later (especially when playing against a human opponent), the AI will encounter a strategy it has not seen before and/or cannot diagnose, in which case it will not know what to do. This is especially a problem in games where positioning is important, as the AI has to then be scripted for every single positioning combination possible, including ones involving different units.
Mega is pretty much the only non-Russian file locker I know of that is any good. If you like Russian, rusfolder and narod.ru are very good.
Due to suggestions made in the articles written about the Berkeley Overmind, I'm going to have to disagree with your safe assumption.
The situation that the AI didn't know about it was not recognising that units were being repaired by workers, so it gave the workers a lower threat than they deserved, and took more casualties against the units being repaired than it expected. It's strategy still caused it to win the match. It also created the strategy it used without explicit programming. I suggest you look up the articles written about it, as my paraphrased understanding is really quite basic, but it sounds to me much more complex than just a "select a script and run with it"
You misunderstand: in the case of well-made script-based AI's, it's not "select a script and run with it", it's "select 50+ mutually exclusive scripts and run them all at the same time". They could do some unexpected things if the connections between said scripts are "soft" (not hardcoded), but still cannot perform actions that are not defined in a script somewhere. For example, let's say Overmind were running on a custom map with rules identical to the regular game, except that Marines could repair instead of SCV's. Overmind would probably not know how to use the Marines' repair ability without its developers changing the "repair" script (the exception being if the repair script relies on any unit with the "repair" ability instead of strictly SCV's). A better example would be a custom game where Siege Mode was researched at the Armory instead of a Tech Lab: Overmind would not know what to do with itself unless the developers specifically rewrote the "unlock siege mode" script to rely on an Armory instead of a Tech Lab, or possibly used a generic "unlock tech" script and changed the "siege mode" tech reference to the Armory. Even if clever scripting can get the AI to do unexpected things (pretty much all AIs that opt for a hard-scripts, soft-connections design are like that, like the AI in FEAR or Rage), it still cannot do anything that has not been written in a script somewhere (eg. if Overmind had no "repair" script, it would be completely oblivious to the game's repair functionality).
Back on topic though, thanks to my new power supply arriving two days early, I discovered another AI advantage, though this one's probably the smallest of them all: AIs can give missions to other players without researching the necessary tech. I have also finally discovered what the AI uses to determine what strikecraft it builds: weapon AttackTypes. Changing the AttackType for Vasari Bombers from ANTIVERYHEAVY to ANTIVERYLIGHT resulted in all Vasari (and only Vasari) AIs having a Fighter:Bomber ratio of about 3:4 in three different test games, while all other players had a Fighter:Bomber ratio ranging from about 1:1 to 4:3. I'm currently experimenting to see if I can somehow *push* the AI's emphasis on Carriers to other ship types (eg. Heavy Frigates) without simply adding the "Carrier" frigateRoleType to said ship types.
Point taken - I was assuming you weren't talking about rule changes to the game that actually change the way you interact with the game, but rather rule changes that change the balance between units.. Those are changes that are likely to confuse people as well as AIs.
I take it that you have zero experience with anything that remotely resembles code or business... Its easy for an armchair analyst to criticize things but there is a reality out there that is grounded in fact. Even if you are an indie studio, economic laws still apply, as does the very simple idea of opportunity cost. It doesn't matter what your intentions are, the bottom line matters. The idea of "respecting" work is laughable when it bears no actual relevance to modularity. Battlefield 3 and 4 sure as hell are not moddable. However I would bet that the devs care a lot about them. AMD/EA got carried away in the mantle hype and die hard bf2 fans (me partly included) may have gotten sad at the situation, but these decisions are based on reality, not some fantasy world where everyone has time to do everything.
There are many great features available to you once you register, including:
Sign in or Create Account