NoQ wrote:To me, some of the biggest flaws of Nexus included inability to counter spam (tank spam, cyborg spam, tower spam, machinegun spam, rocket spam) by countering them with tech and production choices
I definitely agree. The fact that Nexus doesn’t produce good units or choose good research choices means that it’s essentially unplayable for decent players but newbies don’t realize that. I fixed this by statically populating the template and research arrays. This is an example of what I mean when I say fix something and be done with it. Now that the template and research arrays are ordered from the beginning of the tech tree to the end using each weapon path, this AI essentially cannot be out-researched or produced. The arrays can be adjusted a little bit for specific game/map settings but generally speaking it makes the best units and researches the best things at all times for its chosen profile and the profiles are chosen based on map/game settings so it’s not really possible to achieve anything better in regards to droid designs and research objectives, there’s nothing left to do, it’s fixed and done with.
Nexus pursues research objectives regardless of power and I set power management checks on droid production; cyborgs, tanks and VTOLS only produce with minimum of 25, 50 and 700 power I think. Those numbers can be adjusted but the arrays themselves are pretty much finalized.
Profiles are chosen based on 40/40/20 chance of choosing rocket, cannon, flamer for no allies or no shared research. If shared research then flamer if map size < 130, cannons 130 – 170 and rockets 170+. Likelihood of artillery branch uses the linear function with map size 90 = 0
- Code: Select all
Code for selecting research profiles
_ally = 0;
_count = 0;
while(_ally < MAX_PLAYERS)
if(_count > 0 and multiPlayerAlliancesType == ALLIANCES_TEAMS)
if(_mapSize < 130.0)
curTech = branchFlameVtolLaser;
dbg("going rockets (" & _y & "/" & _rnd & ")", me);
else if(_mapSize < 170.0)
curTech = branchCannonMGMortar;
dbg("going cannons (" & _y & "/" & _rnd & ")", me);
curTech = branchRocketMGMortar;
dbg("going Mortar (" & _y & "/" & _rnd & ")", me);
//probability to choose artillery branch for map size 90 = 0; probability for map size 200 = 55
//build a linear function: y = ((y2 - y1) / (x2 - x1)) * x + a depending on two values given (short: y = mx+a)
_x1 = 90.0; _y1 = 0.0;
_x2 = 200.0; _y2 = 55.0;
_m = ((_y2 - _y1) / (_x2 - _x1));
_a = -(_m * _x1);
//calculate probability for the current map
_y = _m * _mapSize + _a;
dbg("_m = " & _m & ", a = " & _a, me);
_rnd = (float)random(100);
if(_rnd < _y)
curTech = branchArtillery;
dbg("going air (" & _y & "/" & _rnd & ")", me);
__rnd = random(10);
if(__rnd < 4)
curTech = branchRocket;
dbg("going rockets (" & _y & "/" & _rnd & ")", me);
else if(__rnd > 6)
curTech = branchCannon;
dbg("going cannons (" & _y & "/" & _rnd & ")", me);
curTech = branchFlamer;
dbg("going flamer (" & _y & "/" & _rnd & ")", me);
The same goes for the base building. I set base build sequence to factory, research, power, derrick and then the base building triggers for each structure are called every < 7 - 10 seconds. Structure modules are upgraded from nearest to furthest as soon as modules are available. You can attempt to make a bot that builds a better base but programmatically I don’t see how it can be improved much.
There are 4 things I can think of that still need fixing with base building before I would declare that it’s close to perfection. The first is building base structures in the closest spot location instead of elsewhere in the base, the second is to check if there is a cliff between the truck and proposed building location, the third is to set a 3 truck minimum when upgrading structures and the 4th is to create multiple build groups. If I fix those 4 things then base building behavior is essentially done with, it’s not really possible to build a faster base but even without these 4 items the base building performance is still optimized and better than all other bots. Base building is another one of those things that once it’s fixed it’s done with.
Berserk Cyborg wrote:MIH-XTC wrote:This bot will smash all other current and foreseeable bots most of the time with the exception of certain small map, low oil rush games.
Naturally. How can you expect other AI, which are only 'balanced' in regards to the base game, to be anywhere near as good as your bot when introduced to all of your changes? It is totally unfair to make that judgement unless the other bots are tweaked for your balance. Anyway, the modified Nexus AI you included is amazing none the less.
It doesn’t have anything to do with the stats but rather 3 of the 4 components of a WZ game are near flawless, base building, research objectives and droid designs are all near optimal performance. It’s really just a matter of not being able to make a better AI outside of droid behaviors. Although my bot does take advantage of the fact that I made mortar arrive earlier (after sensor tower instead of factory).
The only remaining and subjective component of a WZ game is droid handling and that’s where things get complicated. I haven’t done much with unit orders as that is the hardest part of making an AI.
NoQ wrote:, and also inability to group up units before engaging in combat. Most of NullBot's complexity is about these features.
I haven’t touched anything with droid behaviors besides changing most of the DORDER_MOVE’s to SCOUT because too many times I seen Nexus droids suicide into other armies because they don’t know to stop on enemy contact. Actually bonecrusher does a really good job of grouping units and then attacking, bonecrusher’s rally points are very observable prior to attacking. Not sure if Nullbot does the same. Bonecrusher also does a really good job of 1v2’ing.
There is a small bug I created in an attempt to get VTOL’s to attack relentlessly in which the VTOL’s remain idle over their target. Instead of attacking targets I made the VTOL’s patrol to their target coordinates meaning they attack anything in sight on their way to their target. The problem is that the secondary patrol order needs to be set after every new DORDER and once the VTOL’s are done attacking an object in route to their target, they proceed to their target without any attack order. One alternative is to set secondary patrol orders on vtols every time they arrive at their destination but then this overrides the rearming orders and the VTOL’s are stuck flying around without ammo. The solution to that is to check vtol ammo levels but there aren’t any functions available in mp for that. Right now I have the VTOL’s set to attack anything in route to their target but after they kill one object the patrol orders come off and then they’re stuck idling around their target until they die.
NoQ wrote:Note that the former is quite useless in AI vs AI matches, because AIs already avoid spam strategies, but newbie humans don't, and the primary sense of having good AIs is to teach humans to play better.
AI vs AI games essentially end up being a spam fast. Testing AI vs AI is almost like creating a droid collider similar to a particle collider. The weapons with longer ranges usually win in AI vs AI, especially grenadier although Nullbot did a really good job of using flamers and mg’s to overcome that. In larger games no AI will be able to stop the spam of this Nexus AI because it’s guaranteed to have superior droid upgrades and designs.
I also agree that the purpose of an AI is not to win but rather to prepare players for mp because mp and base are two totally different games and Nexus does not prepare players for playing in mp. I prioritized variation over winning in terms of droid designs, some of the research choices, some of the strategy choices and decision to build defensive structures. If I wanted to make a bot that would win all of the time then I would just do flamer + truck rush but the default AI should showcase how all of the different strategies are intended to be used.
NoQ wrote:At the same time, winning AI vs AI matches is a good achievement, but i suspect i could easily provide a NullBot personality (~100 lines of code) that would be better than your AI on your test cases (given the test cases);
I think not because the only thing that’s possible to do better is droid handling. The research objectives, droid designs and base building are already optimized to near perfection so the longer the game goes on, the harder it will be to beat this AI. The only time this Nexus AI is vulnerable is in the early base building phase because it takes the gamble of building a base instead of rushing. Other than that, once this bot gets going it will always win in AI vs AI because like I said, the research arrays, template arrays and base building are optimized to the point where you won’t be able to develop a better AI. It’s not really possible unless you have the same or very similar arrays. It’s fixed and done with…
Once I improve the droid behaviors and defend against early rush then this bot will be unbeatable. Actually, the only time it loses now is because some of the droids stand around in the base while it’s being attacked and they don’t do anything. Once that’s fixed, there’s really no chance for this bot to lose vs another bot…
Yea but that stuff is transparent to the end users/players, I don’t mind to use any programming language, I didn’t use .js only because I don't understand how the Nullbot triggers work (where are they?) and I'm very desperate to be finished with this project and move on. I’m under the impression that once I get this stuff “fixed” it’s done with and I’ll never have to return to it. Since I’m already familiar with the .vlo and .slo files I just want to keep going. Someday I will go back and look at the .js for the sake of learning .js but I have too much WZ and IRL stuff to do. I just don't want to invest the time to learn .js right now. I'm actually impressed that you could even pursue something like that. Rewriting the Nexus files in .js sounds like an insane task. Like you said in your dear programmers thread in "other talk" people work on whatever makes them happy.
NoQ wrote:That said, i appreciate your work and i'd approve adding your AI to the game (as long as it's using the base game's data and works without your data mods), probably as an extra AI alongside Nexus if we want to keep Nexus available as a nostalgic "like the old times" option (i personally don't enjoy having Nexus around, so i'd approve replacement as well).
That’s unfortunate you don’t like the stats, I bet it’s about 45% you want to preserve originality in the code and 45% I changed so much stuff that you don’t have any way of verifying the changes, 10% lost credibility of things I might have said in this thread prior to knowing what I know now. The problem with the current stats is that the game is too deterministic in terms of strategy. Everyone thinks that because there are hundreds of research items and thousands of droid designs that WZ offers complex strategy but it’s actually the opposite, you can just straight up calculate the best strategy for any given map/game settings to guarantee victory 100% of the time unless the same exact strategy is employed. That's not obvious to other people but I'm sure I can beat any player in mp. In fact, if you provide me the game and map settings then I can tell you down to the keystroke exactly what I would do before the game begins and still win. The game consists of the 4 components I mentioned above with droid handling being the only subjective one. Here’s an example of the best strategy on Arid map consisting of build order, truck order and research order https://www.youtube.com/watch?v=u8irDuPU7Sk exact instructions are in the description. That’s why I want to change the stats because I already know exactly what to do for all maps and there is no counter strategy. That strategy in the video cannot be countered by flamers or rockets, there’s nothing you can do besides the same thing. I hope you reconsider on the stats. Sorry for coming off as dogmatic but I know WZ very well.