The X and Y values are for a horizontal circle where the arrow will land, right? My thinking is that a much bigger range of different Y landing points would still hit the target because of the low, high velocity trajectory followed by the arrows. I suppose as a result the variation in X landing positions probably contributes a lot more to overall accuracy than the Y variations. I did a test: basic carthaginian archer at 60m with 0 techs versus hero (infantry hero): 1:42 to 3:47, duration of 100 shots according to unit fire rate. 87 damage dealt at 2.016 damage per hit gives us 43/100 shots hitting the hero. metadata.jsoncommands.txt I think if archers need a buff, we could boost their accuracy some and maybe there move speed slightly.     

Petra has some pretty obvious flaws. For example, if I take one of Petra towers, it's basically the beginning of the end for Petra. It doesn’t think like “There’s a tower here, I shouldn’t pass until I have enough units.” If there’s a tower (or fortress) in the way, their units will just walk right by it.. and die. Most of the new units it produces end up behaving suicidal because of that. Sometimes I even send all my resources just to keep Petra alive. Now plays better than the previous version, but what it really needs now isn’t stat boosts: it’s improvements in behavioral intelligence. Petra needs to be able to analyze the map and adapt to the situation. Also whenever I play against a random very hard Petra, it almost always launches an attack around the minute 10. This typical behavior doesn’t feel random to me at all, it seems like a very specific play style. Petra could behave in more diverse ways. Petra never harasses with cavalry or sneaks rams around for a surprise attack. Its predictability is, in my opinion, its biggest disadvantage, even in "random" mode.   Btw I checked the replay and this is 1v1v2. Green and Yellow had already weakened each other before you attacked them.  I’m sure you can handle a 1v3 as well. It’d be great if you shared the replay of it too.

Or better pathfinding, or larger bodies of water.   So is depth somehow taken into account already? Maybe, haven't played many water scenarios.

An amazing piece of advice: recommending a blacksmith in phase 1.  ChatGPT just scrapes a chaotic mess off the internet (95% from this forum) and regurgitates it like it’s been filtered through a drunken brain. It has zero real understanding of the game. Even if it somehow managed to play, it’d still be stuck at a singleplayer level.  Multiplayer strategies, as mentioned in the topic, are a completely different thing. Real opponents can instantly ruin whatever plans you come up with. You’re racing both against other minds and the clock. You usually don’t even get to trade at all (depends on the map and your opponents). And if you’re playing against Petra, you don’t really need any serious strategy anyway. Just produce a solid number of units and it will do. When would you ever actually need a strategy with Petra? Only if you’re playing 1v2+ on very hard. 

Careful. It's not the distribution that you are multiplying, it's each value. Otherwise, you would be changing the amplitude (height), not the standard deviation (width). And this works only because you are applying it to a normal distribution of mean 0 and standard deviation 1. On a side note, there are many "bell shapes": Cauchy, hyperbolic secant, etc, the normal distribution is a Gaussian, and before you mentioned "variance", keep in mind that's the square of the standard deviation.   I counted 3 given the phrase I quoted. But now I went to the code and I understand what's going on. You calculate first values for normal distributions for x and y (mean 0, standard deviation 1), and then you multiplied them by the distance spread (which changes the standard deviation of the resulting Gaussian, as explained before). Well, this shouldn't give you a square (I thought you were integrating with wrong limits to get the probabilities, but I think that's the part you are doing with a CDF calculator). This is the relevant part of the code: const distanceModifiedSpread = ApplyValueModificationsToEntity("Attack/" + type + "/Projectile/Spread", +this.template[type].Projectile.Spread, this.entity) * predictedPosition.horizDistanceTo(selfPosition) / 100; const randNorm = randomNormal2D(); const offsetX = randNorm[0] * distanceModifiedSpread; const offsetZ = randNorm[1] * distanceModifiedSpread; data.position = new Vector3D(predictedPosition.x + offsetX, predictedHeight, predictedPosition.z + offsetZ);   Which I'm going to simplify, in python, and fix distanceModifiedSpread = 60, for 100000 points: N = 100000 predictedPosition = {'x':10,'z':10} distanceModifiedSpread = 60 for _ in range(N): randNorm = (random.gauss(0,1), random.gauss(0,1)) offsetX = randNorm[0]*distanceModifiedSpread offsetZ = randNorm[1]*distanceModifiedSpread data_position = (predictedPosition['x'] + offsetX, predictedPosition['z'] + offsetZ) I get this density plot: So, not a square.   That's acceptable enough, but bear in mind that your calculations are approximations. When you used the CDF calculator to integrate a Gaussian with mean 0, standard deviation 1.35, between -1.5 and 1.5, and got 73.35%, and multiplied by itself, you are indeed calculating the probability of hitting a square. Then you multiply that by a factor telling you how much smaller is the circle respect to the square, but that multiplication is having the hidden assumption that the probability distribution is the same in all points of that square (that's what multiplication really means, weighing all elements the same way, and that's why integrals and convolutions are more powerful). If you want to get the exact result, you have to multiply first and integrate later (or use the CDF calculator, but that's for the weak :P). The actual CDF can be found for example in https://en.wikipedia.org/wiki/Rayleigh_distribution, since it's related to the problem of having a "two-dimensional vector Y=(U,V) which has components that are bivariate normally distributed, centered at zero, with equal variances , and independent".