Zerg Hex Forum

The pink barcode (Stealth/Uni) has killed this game on NA.  Trolling every game, kicking people from lobbies at random, quitting at 11 then making new lobbies.

Hey guys, I've been working on the simulator, and after doing some thinking and talking to Turbo - thank you turbo :>; I decided to remake my code and improve on it. The problem I'm facing is that following the ratio will not necessarely give you the best income. Let me explain why. A perfect ratio build does not consider that spawner costs way more than extractors (30 supply of extractors costs 440, while 30 supply of spawners costs 525) and take longer to build, so even tough a perfect ratio build would acomplish the best combination of spawner to extractor reguardless of time, when you factor time, it might be "too slow" and take longer to complete a full supply - which negatively affects eco. I admit that the difference is very small, but I have to be sure of it.

The way I think I can fix it is by simulating every single option and then pick the best one, because figuring it out mathematically doesn't seem viable, as there are too many endogenous variables (i was struggling with 3 imagine 4 or 5 lol). A new problem comes up then, because which one is the best option? If i pick the fastest one in a given time, I wouldn't factor how much supply left there is and how far away the player is from buying the next supply, and if I pick the biggest income when they all finish the supply, I don't factor which one finishes first - which is important. I might need to go into neural networks or something like that. I'll keep u guys updated on progress.

Meanwhile let me share something really cool I stumbled uppon:

https://imgur.com/7pgittk

This is a heatmap for the income given your use of the starting 54 supply. The lighter the color is, more income u get. The x axis is the number of extractors you build and the y axis is the number of slowling spawners. The reason why the bottom right corner is empty is that it surpasses the 54 supply limit.

https://imgur.com/MtMRuGP

This one is the same thing, but for strikelings.

It's beautiful. Bye :>

yea he's gone. we've asked to open source it, to monetize it, people have offered to donate, but nothing. i'd love to see the community version hit top 10 because this is going no where without updates. too unbalanced.

So while i think of a way to improve the terran simulator, I'm also working on the zerg simulator. This version i present is already functional, but it's lacking a lot of features. I'll keep updating it and posting the new versions with also somme conclusions i get from it. The first one i posted on the other channel "hex science" proving that the zerg eco isn't actually exponential. It's not user friendly, but if any of you want to use it on this stage i can explain personally how it works, just message me. Also, feedback can be very valuable if any of you feel like trying it. I kind of gave up on Excel's VBA and I started coding on Python, which probably makes more sense.

Here, E and S will refer to extractor/spire and spawner.

1 - I think my intended use of imperfect supply usage actually refers to dead weight loss. For example, if we're at 45 supply, then the only way to use all of that 45 supply is by making 3 spires, since 30 mod 4 != 0. We can't have fractional spawners, so this adds to the cumulative inefficiencies.

I also think that you shouldn't include cost of supply in your best growth scenario, therefore making your model depend strictly on E and S. The impact of increasing supply cost, I believe, is strictly to implement forced inefficiencies: you can't stay at perfect mineral usage (i.e. 0 unspent resources) because you need to wait for enough minerals to upgrade supply after using all of it. The linear increase in cost is just a penalty on time, which should converge to 0 at a large enough scale anyway, since your eco will grow by much more than 125 per supply. That is to say that cost of supply does not affect your build order.

2 - Notice that your utility function, U(E,S) is such that your decision to make an extra E depends on how many s you have. This implicitly creates a relationship between E and S, such that your number of spires is actually a function depending on spawners.  Similarly, your next building should be E if you have enough S, so spawners are also a function of E. This means that the full characterization of your utility function is U( E(S), S(E) ), since they depend on each other. This is because your 2 inputs are complements, much like how capital K needs labor L to be productive, and L is more productive if they are tools (capital). Intro econ classes will teach them both as explicit variables, I think because of envelope theorem, which states that 2nd order effects and beyond resolve themselves, but don't take my word on this.

Disregarding the previous paragraph (because now that I think about it, the effects might honestly be too small for us to care), I think at the minimum, your model should be U(E,S) and not U(n). This gives you the flexibility to test situations such as "what I were to lose 1 entire side? (i.e. -2E, - 4S)", or even consider "how long would it take me to get back to normal 3T eco if I had {1,2,3} 2:15 leavers?

3- Thanks for clarifying. I think your utility function should also have intercept whatever your hive gives per minute, since you mentioned that I = S * E + H. Of course, setting H to be your intercept also means that you would need to make U(E,S) = (S + 30) * E and set your initial conditions to whatever it needs to be.

5- That definitely does not seem exponential! That's pretty cool. Your time range was definitely long enough, and that log curve is very very far from being straight.

Great stuff