-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-implementation of the AI - Part 2 #5750
Conversation
Very cool concept here Jip. Or I need this income. The AI will know that it can build mass on various points. But it may also decide that to achieve the required number due to distance or risk a mass fab is more economical to achieve it at the desired time frame. The interesting thing about this type of setup is how it works with AIX multipliers. Since 6 factories for a 1.5 build/cheat AIX is not the same as 6 factories for a non AIX. The other interesting thing about it is how the AI's behavior would change depending on game balance changes or mods. |
This is exactly the idea! There will be 'strategic intents' that you can write out (for the brain, but also on a base level for local issues) that can describe exactly that. For example, say the brain picks the intention to create five additional air factories. The code with the intent can then evaluate the status quo of the game (how much income do I have, how much do I need) and then generate tasks to reach the required income. Combine that with the factory tasks and there you have it! Another idea: say the intent is to increase the economy by upgrading an extractor. The logic (that you wrote to perform the task) can not just take into account the economy status quo, but using the reclaim grid it could also take into account the reclaim! And as a result, it could say: we can build this, if we get engineers in that wreckage field near the base. Then order the engineers to go reclaim there. This can of course fail, but that's okay - it can fail for players too. The dangerous factor here is mass of course - as you can't build that everywhere. But it doesn't need to be perfect, just good enough 😃 |
I had a read through and it looks like a nice approach. I like the concept of the DefaultDistance. Also having assistees and builders, hopefully that might provide functionality(I didnt see anything that enabled this yet but its super useful especially for assistees) to pull an engineer off an assist task when its desired to switch to something else (e.g I'm assisting an upgrade but now our power is about to stall and there are no in progress power building happening so I'll disconnect and look for a new builder). Preferred chunk will be cool to, I tried doing a front and rear bias for my own AI's builders. It kind of worked but never quite. But I really like how this can potentially integrate the managers with modular strategy/tactical data sets. I tried(still do) doing torpedo bombers where the factory builders function off imap threat..but it turns out that engineers walking over water become naval threat and suddenly the AI's is making torpedo bombers to go kill them. Also really like the Deteriorating status for builders, since historically when the initiating engineer was killed you needed a special completion builder to get engineers to complete things but then your priorities and assistance counts were all off, where as now its effectively built in that engineers will complete things that are interrupted. Then having a task set to InProgress will stop the AI picking up multiple high value task just because the engineer hasn't arrived at the build location yet. |
One part of a long series of work on re-creating the foundation of an AI. Other chunks of work:
And of course #5633 . There are more pull requests but this gives you a rough idea 😃
Engineer tasks
In this pull request, we are introducing a new feature we coin as "engineer tasks." Unlike traditional builders, these tasks are exclusively designed for engineers, focusing solely on the decision-making process of what to construct.
Conceptually, engineer tasks function as a dynamic build queue that can be queried and modified. Several key aspects surround these tasks:
Strategic intent
Engineer tasks are generated by the brain, mirroring a player's strategic decision-making. In urgent situations, a base can autonomously generate tasks to address immediate concerns. The brain can articulate a 'strategic intent,' much like a player planning their moves. For example, if the goal is to establish four additional land factories in a specific navigational label (connected area), the associated task list might include:
The factory building tasks can be allocated to specific bases with the corresponding navigational label. Economy-related tasks can be assigned to any base, with a preference for those farther from the front lines. This approach allows for the creation of task lists that articulate strategic intents, providing insights into the required resources and progress.
Engineers at each base execute these tasks, leading us to the second crucial concept: the tasks are persistent until they are completed.
Persistent tasks
Engineer tasks exhibit persistence and are processed based on priority. When an engineer accepts a task, the task doesn't vanish from the task list. Instead, another engineer can take on the same task, collaborating rather than duplicating efforts. Unlike builders, which lack persistence and awareness of other instances, engineers naturally support each other in completing a task.
This persistence feature allows for efficient task management and resource allocation, contributing to a more organized and collaborative construction process.
more to come