Author Topic: Update on Progress  (Read 252725 times)

0 Members and 2 Guests are viewing this topic.

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Update on Progress
« on: May 28, 2018, 09:14:24 AM »
I haven’t posted any updates in a while, partly because of work commitments (the company I work for just bought someone else for $4.7 billion and will now become the world largest publicly listed gambling company – this will take some sorting out), partly because we have had several weeks of glorious weather on the island (so I am spending all my time outdoors with BBQ and Hot Tub) and partly because I am working on the AI, which involves a lot of thinking as well as programming.
 
In VB6, the AI is tactical-based and each squadron or ship is making decisions independently. So NPR fleets are fine at reacting to enemies and handling the mechanics of combat, but they are strategically dumb in terms of coordination and their ability to learn from experience is limited. The latter BTW is a much harder problem to solve. I have exposure to AI to some extent at work these days (in the sense that one of the teams in my department is focused on machine learning) so I understand a lot more than I did when I wrote VB6 Aurora. I hope to use some of that knowledge for the C# version and I will create strategic and operational layers for the AI to add to the tactical side.
 
VB6 has the concept of ‘Design Philosophy’ for NPRs, which sets such parameters as base hull size, amount of armour, proportion of engines, type of beam weapons, etc. for each NPR and generates all the individual component design for weapons, sensors, etc.. This means that all ship designs for the same NPR work on the same base principles. VB6 also has an ‘Automated Design’ process, which includes base parameters for many different types of NPR ship, such as missile cruiser, energy-armed destroyer, escort cruiser, FAC, energy-armed jump battlecruiser, freighter, swarm soldier, etc.. There are about 40-50 different automated designs. The combination of Design Philosophy and Automated Design determines all the NPR ship designs.
 
However, the above is still generic so every NPR is generated within the same overall potential parameters. There may be some difference in size or armour strength or overall technology, but they will still generally have missile cruisers, energy-armed destroyers, etc.. They will also generally have similar distributions of class types and there will tend to be a wide variety of types within the navy of a single NPR. This was originally intended to give players a wide range of threats to handle, within the overall AI-framework of tactical challenge, rather than strategic challenge. This many-classes approach also means that NPRs generally require a wide range of technology to support that wide range of class types, which dilutes their ability to excel in one area.

The first major change for C# is the new concept of ‘Design Themes’. This sits above the Design Philosophy, changing the way it functions by providing an overall guiding theme for how the NPRs handles its fleet methodology. For example, an NPR may decide to go for a ‘balanced’ fleet mix with large missile cruisers, mid-sized energy combatants, mid-sized AMM escorts and small energy escorts, plus scout and survey designs. This theme won’t build FACs, or carriers, or multiple sizes of the same type of ship. It will stick to a relatively small number of classes designed to work together (like a player) and will try to build ships to maintain a cohesive fleet mix. Design Themes will also determine if the NPR requires fighter or ordnance factories and will set other parameters, such as maximum number of survey or scout ships. Tied to the Design Theme is a Tech Progression Plan, so the NPR will only research technology that is applicable to its chosen theme.
 
There is a lot of scope for Design Themes. The Theme may be based around large carriers with small escorts (Starfire Rigellians), a Star Trek approach with large, multipurpose ships, a Raider theme with small, agile ships, Energy-only fleets using Railgun and Gauss-armed battleships, Turtle races with a lot of orbital bases, Ground-combat led fleets, etc.. This will add much more variety to NPRs and allow me to add modifications to NPR behaviours at a strategic level, based on their overall theme. While individual NPRs may not have as many different ship types, there will be much more variety at a game level.
 
In VB6, task groups are generally one type of ship, with a jump ship added in some cases. Escort-type squadrons will try to accompany major combatants but remain as separate task groups. C# replaces this with the concept of ‘Operational Groups’. Each group can have a number of different ships types intended to work together as a single fleet. As ships are built, they will join an operational group that requires that type. Each operational goal has a primary mission that it can handle on a tactical level, but the overall direction of these groups will be handled at strategic level. For example, several groups may be assigned a staging area before the command is given to advance against an identified target. Alternatively, they may be assigned an operational area, which the operational group AI cannot leave unless permission is given by the strategic AI. Worth noting here that there will be many AIs (ship, fleet, system, population, etc.) all working within the strategic AI.

The NPR has an Operational Group Progression, which determines what it will create with its starting build points. Larger NPRs will have more groups in the progression. NPRs now have to use shipyards in the same way as players, so shipyards will be tooled to build the most important ships. As new shipyards are constructed and expanded, they will be assigned other ships in order of importance. Each Op Group has a ‘Key Element’, which is the primary ship type and therefore the most important for shipyards.

Because higher level AIs will exist, the NPR will make decisions on a strategic level. One of those decisions will be deciding on the relative importance of different systems. Systems will be assigned as Core, Important, Neutral and Alien-Controlled. Once communication is established, the NPR will inform the player which systems it claims and which systems it believes should remain neutral (i.e. not claimed by the player). Beyond those systems, it will recognise player sovereignty claims unless it decides to start a war. However, it may also change its definition in some cases and claim a previously neutral or player controlled system. The player can accede to such a demand to avoid a war. Even if war breaks out, the NPR will have war goals and may accept peace once those goals are achieved or if it believes it cannot achieve them.
 
So far I have built the first design theme (which is based on missile battlegroups and no jump drives), the tech progression for that theme and the operational group progression. The tech progression is based on ‘Tech Groups’, with each group being series of techs linked to a common theme. So the Lasers tech group includes focal size, wavelength and capacitor recharge rate. The NPR uses its starting tech points to go through the tech progression in order. There can be multiple instances of the same tech group at different points of the progression. Each time the same tech group appears, the NPR will research the next generation techs. Once the game starts, the NPR will continue with the progression. The progression will only include techs that are required for the operational groups in the design theme.
 
Operational groups for this first design theme include Orbital Defence, Missile Battle Group, Jump Point Defence, Construction Ship Group, Gravitational Survey, Destroyer Squadron, etc.. Each group includes one or more classes to provide a balanced fleet.
 
For example, the Missile Battle Group has five missile-armed BCs, three missile CLE, three beam DE, two beam CAs, a FAC-Hunter DD and a Fighter-Hunter DD. I’ll probably add a fleet scout when I create the necessary design template. This force will operate as a fleet, which will correct many of the coordination problems inherent to NPRs in VB6. The Destroyer Squadron (Missile DD, FAC-Hunter DD, Fighter-Hunter DD) will act as a patrol force, while the Jump Point Defence group (3 Beam CA, 1 Missile CLE, 2 Beam DE) will be deployed to protect jump points. The Construction Ship Group has a JGCS, CLE and 2x DE. This concept of dedicated escorts within a wider group function should make NPRs more effective.
 
I have been running a series of NPR creations and checking the designs and naval organization. Based on those results I am tweaking the design templates and design theme / philosophy modifiers to ensure a sensible outcome. Once I am happy, I will generate some more design themes.

I have also been working on the population and empire management AIs. Population AIs handle decisions on producing fuel or ordnance, building installations and constructing ships. Ordnance is produced based on what is required vs existing stocks and production. Installations such as factories, mines, research facilities academies, etc. are built based on the status and size of the population. Shipyard construction and expansion, plus the construction of new ships, is based on the requirements of the operational groups. NPR Populations will also convert conventional factories. Everything in this paragraph is coded.

At the Empire level, each population is given a score for terraforming potential and mining potential. Terraformers are dispatched to those colonies which can be terraformed the fastest, while civilian contracts for importing mines are set for the best mining sites (all that is coded). Decisions on the placement of tracking stations and logistical installations will also be handled at the Empire level. NPRs will be using fuel in C# Aurora (and perhaps maintenance too – haven’t decided yet) so facilities for loading fuel and ordnance will be needed. They will also transport minerals to where they are needed, so you will be able to intercept and capture mineral and installation shipments (this needs to be coded).

The next major part is the movement and combat AI, plus the operational AI (for deciding where to deploy the operational groups). After that I will tackle the diplomatic AI. Making progress but still some way to go.

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Update on Progress
« Reply #1 on: May 28, 2018, 10:45:43 AM »
Hi Steve,

  Thanks for the update - sounds great!!  And congrats on the acquisition - must be making for interesting times :)

  One thing that struck me while I was reading was how much the modders (of which I'm NOT one) will be salivating over being able to get into the system to define new Design Themes.  So I instantly thought: they'll love it if Steve sets it up so that Design Themes (and possibly other types of AI parameter specification sets) as text files so they can mod to their hearts' content.  I then thought about that maybe being a pain for you; my next thought was "maybe Steve should write a Design Theme creation tool that is basically just one or more dialogs to make new parameters". 

  This post was intended to advocate in that direction by pointing out how much easier for you to make new Design Themes if you did it through a dialog, when I realize while typing that you already do this in VB6 with Design Philosophies so it's probably not a hard sell :)

  So I'm shifting course to advocating "go the slightly extra mile to make it easy for modders to write their own AI mods".  I think the primary thing missing here is the inability in VB6 to save what mods you've made in a way that can be used in a new game/DB - although IIRC for things like class name lists you can load text files (which I realize brings me back full circle to my first thought of using text files).  I think there's still room for this to be made a lot easier for modders with some conscious/directed effort on your part, and I suspect it will still make your life easier. 

  I think the main thing is to have two "data sources": game saves (obviously the classic DB) and game configuration "info sets", which is where the mods live.  I think the important thing is to have configuration info sets and saves be in separate files, and to be able to load more than one configuration info set; if that's the case then people will be able to build mods with extra info that are able to be loaded into their (or others') games at will.  If you went so far as to put class designs into the category of configuration info one could create whole pre-packaged races, but this is probably a bridge too far, at least initially.

  The other thing to be thinking about, and I'm not sure if this is or is not an added burden compared to if you didn't do it, is forward compatibility of mods.  I remember in SA that there was someone who would publish a DB conversion tool to keep up with the DB changes; if you're planning to strongly support modders, then that would also entail designing a mechanism to update the mods as the info requirements change.  The reason I think this might not be a big efficiency hit for you is if you were to use the tool yourself as your changing the game.  I think the most important part here would be to have a "immutable meaning" philosophy with parameter names in the mod files (whether they're text files or a separate DB), along with some sort of schema concept that tells you which names are used: If a change is made so that a the values of a parameter "BobV1" need to be changed, then "BobV1" is retired (by removing from the schema) and "BobV2" is added.  If these to concepts are available, then it should be easy to write a tool that auto-populates values from an old mod and allows you to type in new values (and/or just edit text files by hand).  Even if you didn't publish a tool, publishing the "schema" (not necessarily in XML format - more like a name and list of column name & type for each of the relevant tables) it would help a lot to set someone else up to write a tool.

Note that it sounds like I'm pushing for text (XML-ish) configuration files in the above but I'm not.  The same sorts of ideas could be implemented by combining a separate config info DB with one or more dialogs (probably one per table); the "schema" would then just be the column names in the table as described above.

The above sounds like a lot of work for you, but I'm thinking it might save you time in the long run by building a toolset that makes it more efficient for you to morph/add to the datasets as you go.  OTOH, I imagine you're pretty good at making these sorts of changes in the raw DB by now :)  If you do decide to go down the text file route and are thinking of using XML, you might want to look at the XMLSerialize class/function in .NET - it auto-generates a schema off of the public data members of a class.  This is GREAT, but I suspect it might be too fragile wrto documenting changes to the schema/data members.

John
 
The following users thanked this post: Jeltz, oleg, Bouchart, Bakho, Titanian, jonw, obsidian_green, RhysAnnwn

Offline Bremen

  • Commodore
  • **********
  • B
  • Posts: 743
  • Thanked: 150 times
Re: Update on Progress
« Reply #2 on: May 29, 2018, 01:33:59 PM »
Great news! Though I want to urge you not to get discouraged or frustrated if things don't turn out perfect; even the big AAA strategy games with teams of programmers assigned to AI for a year or more often end up with very handicapped or cheating AIs - it's just a tough problem to solve. And those games usually have much more simplified mechanics compared to Aurora.

  One thing that struck me while I was reading was how much the modders (of which I'm NOT one) will be salivating over being able to get into the system to define new Design Themes.  So I instantly thought: they'll love it if Steve sets it up so that Design Themes (and possibly other types of AI parameter specification sets) as text files so they can mod to their hearts' content.  I then thought about that maybe being a pain for you; my next thought was "maybe Steve should write a Design Theme creation tool that is basically just one or more dialogs to make new parameters". 

I don't think even a design tool is necessary; if the design themes are somewhere accessible with even reasonably parse-able syntax I'm sure there are people who would figure it out and be happy to write design themes.
« Last Edit: May 30, 2018, 01:30:21 PM by Bremen »
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Update on Progress
« Reply #3 on: May 29, 2018, 04:38:15 PM »
Will the AI be smart enough to combine these "Operational Groups" into larger fleets?  Because if not, even VB6 AI would likely defeat them soundly, just with sheer numbers.  The example you gave is only 15 ships, whereas I've seen NPR fleets of 30 or more.
 

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: Update on Progress
« Reply #4 on: May 29, 2018, 06:09:51 PM »
Will the AI be smart enough to combine these "Operational Groups" into larger fleets?  Because if not, even VB6 AI would likely defeat them soundly, just with sheer numbers.  The example you gave is only 15 ships, whereas I've seen NPR fleets of 30 or more.
I think that was addressed:
As ships are built, they will join an operational group that requires that type. Each operational goal has a primary mission that it can handle on a tactical level, but the overall direction of these groups will be handled at strategic level. For example, several groups may be assigned a staging area before the command is given to advance against an identified target.
 

Offline Barkhorn

  • Commodore
  • **********
  • B
  • Posts: 719
  • Thanked: 133 times
Re: Update on Progress
« Reply #5 on: May 29, 2018, 06:18:17 PM »
I just want to make sure the groups aren't limited in size.  That those numbers are more about class ratios than strict target numbers.
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2781
  • Thanked: 1048 times
Re: Update on Progress
« Reply #6 on: May 29, 2018, 06:21:39 PM »
No fear mate:
Quote
For example, several groups may be assigned a staging area before the command is given to advance against an identified target.

So you might encounter just a single group if you're performing a recon-in-force raid, but once the NPR comes after you, it might combine multiple groups if it knows enough about you.

This is good, because it prevents the doom-stack syndrome so prevalent in other strategy games.
 

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: Update on Progress
« Reply #7 on: May 29, 2018, 06:30:20 PM »
I just want to make sure the groups aren't limited in size.  That those numbers are more about class ratios than strict target numbers.
The groups may very well be limited in size, but according to Steve, they'll be able to work together on an objective.  If an NPR using operational groups of 15 ships feels like it needs to send more than thirteen ships, it sounds like it will be able to send multiple groups to act as a larger unit.
 

Offline Kristover

  • Gold Supporter
  • Lt. Commander
  • *****
  • K
  • Posts: 259
  • Thanked: 135 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: Update on Progress
« Reply #8 on: May 30, 2018, 09:03:59 PM »
Just a question but will the new AI design and build new ground units under the same theme template you are describing?  Also, will NPRs finally be able to initiate ground invasions/assaults?
 

Offline backstab

  • Lieutenant
  • *******
  • b
  • Posts: 169
  • Thanked: 2 times
Re: Update on Progress
« Reply #9 on: May 31, 2018, 03:46:17 AM »
I hope so ... that would be great
Move foward and draw fire
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: Update on Progress
« Reply #10 on: May 31, 2018, 06:24:01 AM »
Just a question but will the new AI design and build new ground units under the same theme template you are describing?  Also, will NPRs finally be able to initiate ground invasions/assaults?

Yes, they will design and build the new ground units. My plan is for invasions, although I haven't coded it yet.
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: Update on Progress
« Reply #11 on: May 31, 2018, 06:24:34 AM »
I just want to make sure the groups aren't limited in size.  That those numbers are more about class ratios than strict target numbers.
The groups may very well be limited in size, but according to Steve, they'll be able to work together on an objective.  If an NPR using operational groups of 15 ships feels like it needs to send more than thirteen ships, it sounds like it will be able to send multiple groups to act as a larger unit.

Yes, this is what will happen.
 

Offline SerBeardian

  • Warrant Officer, Class 1
  • *****
  • Posts: 75
  • Thanked: 37 times
Re: Update on Progress
« Reply #12 on: June 01, 2018, 06:42:29 AM »
Loving these changes and super excited.

Important question: are NPRs going to stop exploring way beyond the territory it can reasonably hold, while also building Gates everywhere all the time? I would think with fuel changes that would be a yes, but would be nice to get an official answer.
 

Offline Seolferwulf

  • Warrant Officer, Class 2
  • ****
  • S
  • Posts: 73
  • Thanked: 11 times
Re: Update on Progress
« Reply #13 on: June 01, 2018, 10:10:33 AM »
Loving these changes and super excited.

Important question: are NPRs going to stop exploring way beyond the territory it can reasonably hold, while also building Gates everywhere all the time? I would think with fuel changes that would be a yes, but would be nice to get an official answer.

If I remember correctly some NPRs might still plaster every system with Gates, but most should not.
It depends on the NPR's theme (if that's the right word for it).
Whether exploring has changed too I don't know, but I'd guess so.
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: Update on Progress
« Reply #14 on: June 01, 2018, 11:58:19 AM »
Loving these changes and super excited.

Important question: are NPRs going to stop exploring way beyond the territory it can reasonably hold, while also building Gates everywhere all the time? I would think with fuel changes that would be a yes, but would be nice to get an official answer.

They will need fuel, so there will be a limit to how far they can progress without the necessary logistics infrastructure. Some NPRs will also restrict themselves to a certain distance from their home system and others will stay out of systems controlled by other races.