Halo Wars Build Order Program

Couple of weeks ago I decided to switch from Anders to Cutter. However I was confused by many options for build orders offered by Cutter and his elephant unit. Since I am a programmer and I love numbers, I decided to create a program for that.

It took about 40 hours to create the program one can find from the end of this post. The early version had same functionality but then I decided to completely rewrite the code… so it took longer than I expected.

The best thing about the program is the game engine. It is not visible for user, but it follows quite nicely the mechanics used in real Halo Wars game. That makes it possible for future improvements.

The goal is to do a program that can tell answers instead of purely representing data. For example one could “ask” from it “Which is the fastest way to get 5 canister shell scorpions on Blood Gulch” or “Which is the fastest way to get wingmen hornets while getting 6 x hog and 900 supplies per minute production”.

Currently there is a bunch of minor issues with the software. Major issue is bad UI. Currently there is so many items in action menu, that it is hard to find the most used ones. The second issue is that there is no “tech-tree” yet. One can research f.e. hawk super unit before wingmen.

However, it has been fun to develop the program and play with it. Also it has been good practice for me to explorer new features of C#/.NET, Silverlight and Reactive Extensions.

The program works on any browser which has Microsoft Silverlight plugin installed.

https://sites.google.com/site/halowarsportal/

P.S. Sorry for that frame Google Sites forces to put in Silverlight applications.

Wow, I really like the idea behind this. What I’d like to see in the UI is a separation of unit upgrades and base upgrades. Also, adjust the list to cater more to the most commonly used/upgraded items, this will minimize a lot of the relentless scrolling around.

Try having the timer at the bottom move in correlation with the amount of time it takes to finish building the specified structures. For example, have it automatically move to 2mins if someone cues up 4 SPs to signify when the structure actions will be finished.

There seems to be a discrepancy between units building and structures building. i.e. I can build Hog,Hog,SP and have a different rate and amount of supplies than if I had a build order of Hog,SP,Hog. This also happens with early Expo construction.

So, as a problem I’d expect to be nearly impossible to solve (I tried to write a program similar to this and quit after tens of hours at this point), what happens to a player’s supply count if they build a Base at 1min instead of 0mins? To clarify, I tried to write it in a TI-84 calculator, which was more than likely the source of my many issues and constraints, but I still found an issue with your program here. My build order was SP,SP,Base,SP,SP. At 1min, the supply rate jumped from 209 (what it should be according to your math) to 548. I can see this working if I intended to cue the Base at the 0mins mark, but what if I meant to take it at 1min when my 2 SPs were done building? This problem shouldn’t be very hard to fix using C# (I took a class on Java console programing in C++ in case you’re wondering :slight_smile: ). You could make another window that displays an expansion’s build order. This way, the user could initiate the Expo at Xmins and keep the buildings going on it. It may take a variable number of timers and supply calculators at once.

I’m assuming that the equation you used for Resource counting is:
(Qs=Quantity of Reg SPs and Qh=Quantity of hvy SPs)
3.75 * (Qs + (1.4 * Qh)) / ((Qs + Qh)/ 13 + 1)

Now, I have found that the relationships between supply rates of varying numbers of SPs is closer to the exact ratio if the underlined 13 is changed to a 10. If you’ll remember, the relationship between 1 SP and 2 is an 82% increase in supply rate:

My program
375 calculated (from my program at 2 SP sr/min)
372.273 actual (based on 1 SP rate + (1SPr * .82))

Yours
390 calculated
380.38 actual

This supply gap will only increase over time and with more SPs. My adjustment could be wrong if the supply rate of the 1st SP is off or if what I’ve found about the relationships of SPs is wrong, however, you’ll find that mine is much more accurate to the ratios that I have.

So, I know that you had said that the mathematics behind your program resemble the game mechanics very closely, but I’d also point out that unit building times aren’t 100% accurate either (as you had noted) and this will, over time, seriously hinder your program from having accurate supply counts. Obviously, I don’t think that you can ever get 100% accurate with the supply count unless you have the coding from the developers, but the building times should be fairly easy to find. i.e. The Scorpion builds at 36 seconds with your program, whereas is actually builds closer to 37.5 seconds.

In addition, you need to incorporate Reserves into the program. It can be researched, but it will not have any visible affect on a unit’s build time.

Well, this is all I could come up with in the amount of time I have to spend on it, so I hope this helps you out a little with the debugging process :slight_smile:

Would be very interesting if it works, but the time commitment + the general lack of a community that would show interest would be discouraging.

> What I’d like to see in the UI is a separation of unit upgrades and base upgrades. Also, adjust the list to cater more to the most commonly used/upgraded items, this will minimize a lot of the relentless scrolling around.

I was thinking the same. It would be easy to divide buildings/upgrades/etc to different tabs. Another possibility is to show only items which are doable (for example not to show Power Turret if there is no Vehicle Depot + Tech 2 + Canister Shell).

> Try having the timer at the bottom move in correlation with the amount of time it takes to finish building the specified structures. For example, have it automatically move to 2mins if someone cues up 4 SPs to signify when the structure actions will be finished.

I will try to think something to here. It is little problematic to set slider time from simulation duration since slider should set the simulation duration. Which was first, chicken or egg? O.o

> There seems to be a discrepancy between units building and structures building. i.e. I can build Hog,Hog,SP and have a different rate and amount of supplies than if I had a build order of Hog,SP,Hog. This also happens with early Expo construction.

Actually you are a victim of poor usability. The program adds actions to “Build Order” list (visible in the middle) when user clicks those. Then simulation takes the first task and tries to do it. If it is possible - for example “Build a Hog” - then a Hog is added to the production queue of the Station. Here “possible” means that production/researching/upgrading can be started immediately.

Build order 1:

Hog : from 0:00 to 0:26
Hog : from 0:26 to 0:52 ← cannot be started since another hog is still in production
SupplyPad : from 0:26 to 0:56 ← delayed because previous action is not handled yet

Build order 2:
Hog : from 0:00 to 0:26
SupplyPad : from 0:00 to 0:30
Hog : from 0:26 to 0:52

This is an VERY bad usability, since it is so hard to populate products in correct order. I have to figure something for this. One solution would be to queue those products (then it would not matter if it is Hog-Hog-SP or SP-Hog-Hog). There is still problems in queuing actions.

> My build order was SP,SP,Base,SP,SP. At 1min, the supply rate jumped from 209 (what it should be according to your math) to 548. I can see this working if I intended to cue the Base at the 0mins mark, but what if I meant to take it at 1min when my 2 SPs were done building?

That was a bug. It was possible to start build buildings in New Base before it was a Firebase/Station (aka complete). Fixed.

Build order 3 (BUGGY):
SupplyPad : from 0:00 to 0:30 (Station building this)
SupplyPad : from 0:30 to 1:00 (Station building this)
New Base : from 0:30 to 1:00 (when complete morphs to Firebase)
SuppyPad : from 0:30 to 1:00 (incomplete Firebase building this)!
SuppyPad : from 1:00 to 1:30 (Station building this)

Build order 4 (FIXED):
SupplyPad : from 0:00 to 0:30 (Station building this)
SupplyPad : from 0:30 to 1:00 (Station building this)
New Base : from 0:30 to 1:00 (when complete morphs to Firebase)
SuppyPad : from 1:00 to 1:30 (Firebase building this)
SuppyPad : from 1:00 to 1:30 (Station building this)

> This problem shouldn’t be very hard to fix using C# (I took a class on Java console programing in C++ in case you’re wondering :slight_smile: ). You could make another window that displays an expansion’s build order. This way, the user could initiate the Expo at Xmins and keep the buildings going on it. It may take a variable number of timers and supply calculators at once.

> I’m assuming that the equation you used for Resource counting is:
> (Qs=Quantity of Reg SPs and Qh=Quantity of hvy SPs)
> 3.75 * (Qs + (1.4 * Qh)) / ((Qs + Qh)/ 13 + 1)
>
> Now, I have found that the relationships between supply rates of varying numbers of SPs is closer to the exact ratio if the underlined 13 is changed to a 10. If you’ll remember, the relationship between 1 SP and 2 is an 82% increase in supply rate:
>
>
>
> My program
> 375 calculated (from my program at 2 SP sr/min)
> 372.273 actual (based on 1 SP rate + (1SPr * .82))
>
> Yours
> 390 calculated
> 380.38 actual
>
> This supply gap will only increase over time and with more SPs. My adjustment could be wrong if the supply rate of the 1st SP is off or if what I’ve found about the relationships of SPs is wrong, however, you’ll find that mine is much more accurate to the ratios that I have.

I am using that same formula (in different format). I know it is off a little, but I do not how to fix the formula. I have measured all supply pad combinations for 1 base. I could copy those values for supply production. I would like to know exact formula instead).

> So, I know that you had said that the mathematics behind your program resemble the game mechanics very closely, but I’d also point out that unit building times aren’t 100% accurate either (as you had noted) and this will, over time, seriously hinder your program from having accurate supply counts.

I know that without seeing the actual source code of the Halo Wars I cannot mimic it 100 %.

> Obviously, I don’t think that you can ever get 100% accurate with the supply count unless you have the coding from the developers…

The supply formula is a good example about that. The best I can do is to do some measurements.

> , but the building times should be fairly easy to find. i.e. The Scorpion builds at 36 seconds with your program, whereas is actually builds closer to 37.5 seconds.

I measured the unit building times by building 5 x unit (or 10 x, if the build time was < 20 s). I can guarantee that nowadays the Scorpion build time is 36 s. I believe build times are exact.

> In addition, you need to incorporate Reserves into the program. It can be researched, but it will not have any visible affect on a unit’s build time.

That’s true. Anders bonus is taken into account. Also you can train as many troops as you want (no population limit). For build orders the bug/unimplemented feature you found is much more important.

> Well, this is all I could come up with in the amount of time I have to spend on it, so I hope this helps you out a little with the debugging process :slight_smile:

Yes, you found at least one bug + some other issues. Thanks for the very informative post.

> Would be very interesting if it works, but the time commitment + the general lack of a community that would show interest would be discouraging.

Who cares what this guys says… DO THIS!

If you need any Java support let me know :slight_smile:

Also - I would be willing to invest some art time to make GUI stuff for you. Just send me dimensions, file type requirements (memory related) and I can take a crack at some stuff for you.

> Actually you are a victim of poor usability. The program adds actions to “Build Order” list (visible in the middle) when user clicks those. Then simulation takes the first task and tries to do it. If it is possible - for example “Build a Hog” - then a Hog is added to the production queue of the Station. Here “possible” means that production/researching/upgrading can be started immediately.
>
> …
>
> This is an VERY bad usability, since it is so hard to populate products in correct order. I have to figure something for this. One solution would be to queue those products (then it would not matter if it is Hog-Hog-SP or SP-Hog-Hog). There is still problems in queuing actions.

So, I hate to be so stingy with this, and I know it’s something that’s usually dealt with later on, but I prefer to address usability very early on. In the way I was taught to program, poor usability is a bug. You kind of have to assume that your user is completely brain-dead.

> It was possible to start build buildings in New Base before it was a Firebase/Station (aka complete).
>
> Build order 4:
> SupplyPad : from 0:00 to 0:30 (Station building this)
> SupplyPad : from 0:30 to 1:00 (Station building this)
> New Base : from 0:30 to 1:00 (when complete morphs to Firebase)
> SuppyPad : from 1:00 to 1:30 (Firebase building this)
> SuppyPad : from 1:00 to 1:30 (Station building this)

So, I’d like to see another window pop up for expos. This would help de-clutter the UI since you intend to have a 10 minute time frame and anything can be built. The Build window will become very cryptic after a while and I think another window would help this later problem tremendously. Also, on that note, I’d recommend that you change the time constraint to 5 minutes or less (in the end, changing this doesn’t really matter at all) because nobody is going to be sitting on the same anything for more than a couple of minutes.

> I am using that same formula (in different format). I know it is off a little, but I do not how to fix the formula. I have measured all supply pad combinations for 1 base. I could copy those values for supply production. I would like to know exact formula instead).

For the sake of correct math, I think changing the 13 to a 10 would be best.

> The supply formula is a good example about that. The best I can do is to do some measurements.

If you’d like me to post my measurements, then I can get them for you, so just let me know. Hopefully I’m not too late and you haven’t already gone to the trouble of doing this :slight_smile:

> I measured the unit building times by building 5 x unit (or 10 x, if the build time was < 20 s). I can guarantee that nowadays the Scorpion build time is 36 s. I believe build times are exact.

So, this is why I believe I am right about the 37.5 second build time:

25 seconds is the build time of a Scorpion with Reserves (correct me if you disagree, but I’m sure it’s exactly 25secs). If Reserves increases a unit’s build time by 1/3, then (25 / (1/3)) = 37.5. If the time enhancement was (1/4), then the equation would come out to an average build time of 33 and a third seconds. I am basing this off of the assumed Reserves build time (Ensemble seems to love the number 25 in HW).

> So, I hate to be so stingy with this, and I know it’s something that’s usually dealt with later on, but I prefer to address usability very early on. In the way I was taught to program, poor usability is a bug. You kind of have to assume that your user is completely brain-dead.

Yes, even the best products are totally worthless if those are too hard to use. When I create UIs for money, I heard a lot that “apes shook down from tree has to be able to use it”. =)

> For the sake of correct math, I think changing the 13 to a 10 would be best.

See Supply Production thread. I have tried the factor 10, but it is even more of with supply pad counts < 8.

For example:

Configuration Correct Factor=13 Factor=10
1 x N + 0 x H : 235 209 205
0 x N + 1 x H : 330 293 286
2 x N + 2 x H : 860 826 771

Have I misunderstand your formula or do you get the same values? Is our difference in measurements? O.o

> If you’d like me to post my measurements, then I can get them for you, so just let me know. Hopefully I’m not too late and you haven’t already gone to the trouble of doing this :slight_smile:

Actually I have gone to the trouble measuring everything in the game. From unit build times, trough how much vortexing (with different updates) cost against different type units with different upgrades to supply rates. Feel free to post those values. Could you compare some of your values to the values I have posted to the another thread (see the link above). If there is a clear difference, check out whose measurement is closer to reality. That would help.

> So, this is why I believe I am right about the 37.5 second build time:
>
> 25 seconds is the build time of a Scorpion with Reserves (correct me if you disagree, but I’m sure it’s exactly 25secs). If Reserves increases a unit’s build time by 1/3, then (25 / (1/3)) = 37.5. If the time enhancement was (1/4), then the equation would come out to an average build time of 33 and a third seconds. I am basing this off of the assumed Reserves build time (Ensemble seems to love the number 25 in HW).

Actually the build time of Scorpion with reserves is 26 seconds. The reserves has factor 0.75 to original build time. So 36 s x 0.75 = 27 s.

Also veterancy of the Elephant affects to unit build times (produced from there). However Reserves does not have any affect to ODST drop down recharge time (it is 10 s always).

Thanks for the comments. I think the main problem is still the usability. Others are easy to fix (for example handling unit build times with doubles instead of integers and using better formula/values for supplies). The bad news are, that I am quite busy next weeks so I do not know when I have time for this project. It is hobby for me.

P.S. I would appreciate if you could do those few measurements by yourself. Is it possible that you have measured those values before latest TU?

> > Would be very interesting if it works, but the time commitment + the general lack of a community that would show interest would be discouraging.
>
> Who cares what this guys says… DO THIS!
>
> If you need any Java support let me know :slight_smile:
>
> Also - I would be willing to invest some art time to make GUI stuff for you. Just send me dimensions, file type requirements (memory related) and I can take a crack at some stuff for you.

I do not care, since I did not code the program for money. In that case I would be very concerned. =)

I appreciate your offer, but it would be way too difficult to mix Java to that C# engine I have coded. However, I think I will publish the code someday.

> For example:
>
> Configuration Correct Factor=13 Factor=10
> 1 x N + 0 x H : 235 209 205
> 0 x N + 1 x H : 330 293 286
> 2 x N + 2 x H : 860 826 771
>
>
> Have I misunderstand your formula or do you get the same values? Is our difference in measurements? O.o

Are the first numbers what the actual values should be? I hadn’t been able to find anything telling me what exact supply counts were suppose to be at specific times with a variable number of supply pads, so I used the percentage relationships between pads to find all of the values I have. Therefore, though my ratios are correct, however, it seems that my values are wrong if what you have for the supplies is right.

> Actually I have gone to the trouble measuring everything in the game. From unit build times, trough how much vortexing (with different updates) cost against different type units with different upgrades to supply rates. Feel free to post those values. Could you compare some of your values to the values I have posted to the another thread (see the link above). If there is a clear difference, check out whose measurement is closer to reality. That would help.

So, all I can give you that would help is what I have on supply rate. I’ll go check out the other thread and see if I have anything that’s relevant. To be honest, I’m not sure if anything I have would be beneficial to you other than seeing that my values correlate with their supposed ratios now that I see that you’ve done everything to unit production times. I don’t get on nearly enough any more to be able to test things like build times, so I have back-worked everything I know from the supply rates I have found to be most correct.

> Actually the build time of Scorpion with reserves is 26 seconds. The reserves has factor 0.75 to original build time. So 36 s x 0.75 = 27 s.

You sure the Scorpion doesn’t build in 35 seconds? 26/.75 = 34.666. Things like a 1 second discrepancy are like a thorn in my side, lol.

> P.S. I would appreciate if you could do those few measurements by yourself. Is it possible that you have measured those values before latest TU?

So, like I said earlier, I really don’t have the time anymore to do something like this, but am happy to post things I found out a while ago. I think you’re right with the TU thing; my stuff is outdated.

ADDED LATER:
I checked out the other thread and have to say that the math is right (no duh, right). The debate will be about what the right equation is. I’m assuming that my ratios have been tweaked through a couple of TUs and are no longer valid. I say this because your numbers came out the way they did and, disregarding pad rate ratios, because of the raw data you’ve collected suggesting that there is no definite ratio discovered yet (or at least that mine does not exist), my data doesn’t really have any significance any longer :confused:

Still, I’m pretty sure supply rate hasn’t been changed since the beginning of the game (correct me if I’m wrong) and this would lead me to think that there is another variable missing in the equation or maybe a variable is not being multiplied correctly. However, I am sure that the numerator of the equation I posted a bit ago is correct.

> > For example:
> >
> > Configuration Correct Factor=13 Factor=10
> > 1 x N + 0 x H : 235 209 205
> > 0 x N + 1 x H : 330 293 286
> > 2 x N + 2 x H : 860 826 771
> >
> >
> > Have I misunderstand your formula or do you get the same values? Is our difference in measurements? O.o
>
> Are the first numbers what the actual values should be? I hadn’t been able to find anything telling me what exact supply counts were suppose to be at specific times with a variable number of supply pads, so I used the percentage relationships between pads to find all of the values I have. Therefore, though my ratios are correct, however, it seems that my values are wrong if what you have for the supplies is right.

First numbers are my measurement data (so they are somewhat “real”). The second column is values got using original formula of Tim Deen. The third column is values got using formula of Tim Deen with factor 10 instead of 13.

I measured all the combinations up to 7 total pads. Then I derived (yesterday) from Tim Deen’s formula and my measurement data a new formula, which makes perfect sense. It is:

Sn = 258.0 x (9 / (N + H + 9))
Sh = 361.2 x (9 / (N + H + 9))

Sn = supplies produced by single normal supply pad
Sh = supplies produced by single heavy supply pad
N = count of normal supply pads
H = count of heavy supply pads

Note: 258 = 60 x 4.3 and 361.2 = 1.4 x 258

This formula is a perfect match for my measurement data. It also has same form as the original formula (from Deen). I believe that the formula is now correct and I will use it in the program instead of the original one given by Deen.

> You sure the Scorpion doesn’t build in 35 seconds? 26/.75 = 34.666. Things like a 1 second discrepancy are like a thorn in my side, lol.

Yes, the 0.75 is multiplier, not divider. It is the same with Anders research bonus (the base research time is multiplied by 0.75). Makes much more sense anyway to derive “bonus values” from “base values” than “base values” from “bonus values”. I am 100 % sure that 37 s is the correct value for Scorpion.

> I checked out the other thread and have to say that the math is right (no duh, right). The debate will be about what the right equation is. I’m assuming that my ratios have been tweaked through a couple of TUs and are no longer valid. I say this because your numbers came out the way they did and, disregarding pad rate ratios, because of the raw data you’ve collected suggesting that there is no definite ratio discovered yet (or at least that mine does not exist), my data doesn’t really have any significance any longer :confused:
>
> Still, I’m pretty sure supply rate hasn’t been changed since the beginning of the game (correct me if I’m wrong) and this would lead me to think that there is another variable missing in the equation or maybe a variable is not being multiplied correctly. However, I am sure that the numerator of the equation I posted a bit ago is correct.

You should check Selling a Supply Pad is a BAD Idea thread. There may be an explanation why your measurement data is incorrect even the supply rates have not changed from demo version of Halo Wars.

P.S. Now the supply rate is solved so I can focus to better usability. I already implemented Covenent leaders to the simulator.