Talk:Planet landing risk-reward formula

Inspiration

This is an idea that has been on my mind since I first played SC2 in July 1994. I always wanted to come up with a "simple" formula for calculating whether gathering valuables on a dangerous planet was worth it. Also, planets with no lander damaging threats but poor return on fuel spent (for example, a planet full of commons or sometimes trace or light amount of corrosives or base metals) may not be worth your time and effort. I admit, this is a bit ambitious, and someone may have already done something similar for this game, but I thought it could be a fun exercise, especially since we have access to how the game values certain lander damage, as well as hard numbers for all planetary data within the game. If the template idea is a bit much, a program could be written (I'd be willing to try if provided with the data) to read all of the game's raw planetary data (which is static) and construct a list of the top 100 most valuable planets, star systems, areas of the hyperspace map which we could then use to construct a wiki table. This program could also produce wiki table formatting for easy modifications/updates to the formula, if deemed necessary. Part of this idea was briefly mentioned while I was discussing the feasibility of the StarBox template with Svdb here.

Before jumping in and modifying the formula (which doesn't exist as of yet), I ask that we discuss some of the ideas behind it here first. For instance, I believe that the formula should produce both negative (very bad) and positive (very good) values, and that it should not simply consider 0 (zero) its lowest possible value. Rather 0 (zero) would be considered "breaking even". It's my opinion that the positives of this formula are fairly straightforward with the exception of the various Alien Artifacts. Most likely, as a group, those should be given a high positive skew since the rewards of collecting them often far outweigh most dangers. Coming up with a reasonable formula for calculating the negatives is going to be a lot more difficult. There are also other factors that may affect planet landing that I am not aware. For instance, I would like to know if a planet's tilt, atmospheric thickness, rotation rate somehow affect how closely the lander lands next to the destination initially chosen. There is always a bit of landing "drift" that the lander suffers. If this is not purely random, it may be slightly important in a more complete formula in how much it affects how quickly certain minerals can be collected. The trick about landing on an extremely violent world to get one huge exotic piece and leave immediately comes to mind. Obviously someone who is intimately familiar with the source code, such as Svdb, would play a vital role in answering many of these questions, providing insight, and showing us how to access the raw game data (though I'm sure it's been mentioned repeatedly somewhere else, such as the various forums). Thanks in advance for any interest (even if you tell me this is a really bad idea), and your participation. --PsiPhi 15:49, 16 October 2007 (CEST)

Excellent idea in my opinion, maybe when I'm not quite so busy I'll be more helpful, for now my only suggestion is to put it in the game mechanics category, like the Lander Hints page. - Zeracles October 17 2007

Any help would be appreciated Zeracles. I have looked over your website, so I can say with confidence that you are more experienced with mathematics than myself. Formula derivation has never been one of my strengths. My initial thought was that this was more in line with actuarial work, based on what little I know of that profession. This formula does not have to be perfect. A half decent formula that gives a good idea about the risk involved would be useful. It doesn't need to include all the terms I listed either. I just wrote down all the possible factors I could think of that could affect the final value, ignoring harder to quantify values, such as player's skill (driving the lander).

Formula Creation and Conversion Issues

I was also not sure if the final value should be assigned a specific unit, such as "fuel units" (since both Minerals and Bios can be converted to fuel), or something arbitrary instead, such as "points". The difficulty is comparing the value of Minerals to the value of Bio data. In the early game, Bio data is extremely vital, perhaps more so than Minerals, but towards the end of the game, especially after you have exhausted all of the Melnorme tech (and info), Bio data essentially becomes an emergency fuel supply. However, by that point in the game, Mineral collecting is no longer necessary either (since you can collect RUs directly from your many battles). Therefore, if this formula is most useful in the early game, when you do not have any Melnorme tech, and you are starved for RUs, it may not require any of the modifiers, which makes the process of creating the formula much easier. If we build the formula with the assumption of no lander upgrades, and Minerals and Bio data being equally important (given their respective conversion to a common fuel unit), then we can ignore the modifiers completely, and focus strictly on the Positives minus the Negatives. What do you think? --PsiPhi 14:57, 17 October 2007 (CEST)

Sounds interesting, but I think you are trying to cover too many bases by including minerals, bio and energy in the same formula. Devices, I'd say, should be left out, since they only have a plot-advancing value, not a RU value, and bio should be treated separately from minerals. So we should have one "risk" indicator and two "reward" indicators, one for minerals, another one for biodata. Valaggar 16:41, 17 October 2007 (CEST)

I'd be willing to ignore devices. I only included them for completeness with the idea that they'd be given a high skew value, but upon thinking it over, those worlds fall under the "no-brainer" category. You should not have to think "should I land here?" when there is an energy signature. As for minerals and bio, I'd really like a unified formula, but I'd be willing to create two separate formulas at first, and if possible, marry them later. The issue is, it's relatively easy to equate the value of minerals to the cost of crew/shuttle/fuel used. The more difficult aspect would be comparing the importance of bio data to those three potential expenses. This is why I proposed a series of equivalences based on real game values. The problem with bio data is that Credits to Fuel is a one way street ... once credits are spent, there is no way to get them back via trade-in. So when it comes to comparing the value of bio data to crew and shuttle cost, we have a slight problem. Given the level of importance of bio data in the early game, we could just ignore this inequality and treat it as if it is a two-way transfer ... see how that goes. If later, we find that this does not work well ... the results don't look right, we can find a way to "fudge" them a bit. Also, since it is possible to acquire credits through other means (rainbow worlds, the Umgah), this does slightly downplay the importance of bio data collecting. But we must keep in mind that this formula is intended for players who are at the beginning of the game, when the Umgah and most of the Rainbow Worlds are very hard to reach on limited fuel supplies. Regardless, the mineral-risk formula should be somewhat straightforward. Perhaps we can start with that initially and build from there. --PsiPhi 17:53, 17 October 2007 (CEST)

I'd have to agree with Val in that sense that you are casting a wide net. I'd be in favor of using bio=credits=fuel=RU as a conversion even though it doesn't go both ways. (Related to this would be figuring out how the RPRG determined the "20 overall richest star sytems" which appears to combine the two somehow). You're already making several approximations and simplifications so it seems like a camel and a gnat. Although separating the two may be a good solution - the only problem with this is the two are coupled when calculating the risk/cost. This is because if you try to collect all the bios on a planet, you will spend more time on it and increase the cost due to the hazards and you may have take more trips to collect them all. However, in my mind here's my two cents on how the algorithm in general should look:

Rewards

• mineral_reward=total RU value of all the minerals (duh)
• bio_reward=total bio value or (bio value)*40 to convert to RUs

Costs (and cost related)

• landing_cost=(fuel to land)*(times to collect everything (may differ if collecting bios))*20 RUs
• time_mineral=not a cost, but dependent on the distribution of minerals
• time_bio=dependent on distribution, total hit points, and mobility (and maybe attitude) of the bios
• hazard=time*(frequency)*crew cost RUs (I'm guessing the class #/temperature determines the frequency of the hazards. The frequency then is how many of that type of hazard the lander will encounter each second.)
• bio_hazard=time*(danger weighted by mobility and attitude)*crew cost RUs

The hardest one to figure is the bio_hazard (how to weight the dangers). In some sense it might be better to express it rather than a sum, but rather as a ratio and then in the form ### / ### that way it's easy to see why the number is good. Ratios are usually better for gauging things like this (like signal-to-noise ratio in electronics and communication). An alternative that you may consider is something more along the lines of NFPA 704. I see these a lot since I do a lot with dangerous chemicals - in that case there's so many ways that chemicals can be dangerous that too much info would be lost by simplifying it to one number. Something like this may be difficult to implement in mediawiki and may drift to far from a quick and simple metric and too close to the scan data in the planetbox, but I thought that I'd throw it out there as an option anyways.

Anywhos, I'd say remember that this is a multivariate problem that you're trying to map to a smaller parameter space so don't sweat simplifications like interchangedness or modifiers or other sources of bio. The only other page we have to compare to is Flagship Energy Management, but that has a easily derived algorithm but it is multivariate, hence the two tables showing the two approaches/ways to consider the problem. Overall, for this not to descend into fan speculation and extreme, subjective extrapolation, this needs to rely heavily on hard, canon values like the energy management page - for example, the hazard frequencies are probably coded based on the class #/temperature, the RPRG lists the hit points of all bios, the mineral distribution can probably be extracted from the code... But I ramble on. Anyways, good luck. --Fyzixfighter 05:45, 18 October 2007 (CEST)

Thank you Fyzixfighter for participating. I will never hold long replies against you as I am usually guilty of them myself. Your emphasis on avoiding speculation and subjective extrapolation is an important matter we all need to keep in mind. You mentioned the RPRG. I only discovered this resource while researching for this page (about 2 days ago). I had no idea until then that PR3&FF had created and published this. Upon reading the three tables containing data on top 20 systems for resources, I nearly stopped and erased what I had. But then I realized these tables do not mention anything about how dangerous these planets/systems are (and some of them are very dangerous). So, this article was spared the ax, for now. I've taken the values from the first (combined) table and put them into a spreadsheet. I then applied the Bio*40 (1 Bio = 2 Credits = 2 Fuel Units = 40 RUs) and added on the Mineral Totals (I take it these are in RUs also; it doesn't explicitly state this). I discovered 2 minor discrepancies, and 1 major one (off by almost 2000 RUs). See table below:

Star System	Mineral Totals	Biological Totals	Bio. * 40 + Min. (RUs)
Delta Aurigae	11005	256	21245
Beta Carinae	7982	304	20142
Beta Scorpii	12680	178	19800
Beta Circini	6897	248	16817
Delta Sextantis	5901	322	18781
Beta Tauri	5747	277	16827
Alpha Olber	6940	241	16580
Epsilon Draconis	7298	230	16498
Zeta Scorpii	4134	309	16494
Gamma Tauri	7307	219	16067
Gamma Geminorum	2388	341	16028
Epsilon Scuti	8365	175	15365
Lambda Hyades	1949	329	15109
Beta Vulpeculae	6208	214	14768
Gamma Circini	4903	247	14783
Delta Chandrasekhar	4299	259	14659
Aldebaran	6488	201	14528
Kappa Hyades	4736	186	12176
Fomalhaut	4158	191	11798
Alpha Chandrasekhar	4799	175	11799

Unless these can be ignored as printing errors within the RPRG itself, we must assume that PR3&FF used some other formula for determining the value of Minerals vs. Bio data. Simply replacing the 40 with higher or lower numbers does not fix this discrepancy, and usually creates a lot of new ones. I must admit, I am at a loss here. Unless they used some unstated modifiers on either Bio data (value/speed/danger of aliens), or Minerals (?size of deposits?) I can't figure out how to explain this. If anyone ever has the opportunity, perhaps someone should ask them how they came up with the rankings for these systems in the RPRG (that is, if they can remember something this obscure from that long ago). Any hunches? Best guesses? Thanks, as always for participating. --PsiPhi 14:12, 18 October 2007 (CEST)

Just some thoughts. There's so many things which if done properly would make this really hard, but I like the simplifying assumptions thus far (we can be cheap and nasty, no hard core mathematicians here I hope). I think Fyzix has pretty much nailed the basic form.

Fyzix's time_mineral variable, to do this rigorously would I think be a too-difficult graph theoretic MST type thing, but we could fudge it by assuming even distribution of goodies, and calculating the average separation between them. This would give the time_mineral for each one. If we decide this is the way to go I could probably find how this mean separation varies with number (I work with code which does similar stuff).

Also, where do we assume that the player bails and returns the lander for more crew? I mean, when crew is down to three? We all know it varies. If we assume a player reaction time of a second or so, the ideal player bails when the lander is within a second or two of biting it. Probably three seconds for a bit of a cushion. So the crew escape threshold would be Fyzix's hazard variable with 3 seconds or so. This affects landing_cost in the way Fyzix describes. Again, this is a problem which is probably too difficult to solve properly, I think we would have to model the hazards as a Poisson process and take into account how much these different hazards hurt to really find out where the optimum escape threshold is.

If we don't decide to just ignore this aspect, just for the record I propose the name bailout_crew for this variable. If someone has a better name please go ahead!

If the bios are reasonably mobile, bio_hazard decreases with time as the player picks up kills, as the frequency of encounters falls. This means that bailout_crew changes with time, as well as changing bio_hazard over time. I guess we need to decide how properly we want to do this. We could maybe take the simplest approach, assume these things will change linearly, and for example just halve bio_hazard to model its fall to zero.

With the lander's dual mineral / bio capacity, I assume we assume (heh) for simplicity that it returns to offload when one of these is full? So this makes the number of trips easy to figure out. Otherwise it would be more correct to do the formula in stages.

One last thing, there's been talk of not taking into account the Melnorme lander upgrades, but it looks like the proposed formula is sufficiently general to handle this - just change some of the values.

BTW noticed Fomalhaut in that list, anyone else remember sc3's goof in putting this in a different quadrant? I don't remember it being quite so bountiful then, heh.

Cheers everyone --Zeracles 19:40, 18 October 2007 (CEST)

Thanks Zeracles for this contribution. I respectfully suggest in the future that you explain or at least link to an explanation for things such as MST and Poisson process so that others can get an idea what these concepts mean. Having studied things like MSTs, your mention of it got me thinking that optimal mineral collection is likely closer to a Travelling Salesman Problem minus the need to return to the origin. As part of complexity theory, this problem is definitely computationally complex and would be hard, even for a computer to solve efficiently, especially given enough data points (mineral deposits). Personally, I'm not seeking that level of sophistication. Although, I cannot deny that Fzyix has a good point about time mattering in terms of increasing the probability of crew loss because the planetary dangers are time dependent, based on both direct exposure (how long the lander is touching a hazard), and how long a lander must spend on the surface to complete its mission, increasing its overall exposure to potential dangers. We may have no choice but to assume certain things as even distribution to avoid this level of complexity.

In terms of human actions, as in when to choose to flee, I wouldn't dare to guess. Adding a human element to the equation adds another level complexity I was hoping to avoid, if possible. We would need to come up with "reasonable" standards. No small task, I know.

Speaking of renaming things, if anyone has a better suggestion for naming this formula, I'd like to hear it (aside from "Impossibly complex thing PsiPhi dreamed up"). ;-)

In terms of the lander returning when one of the two (bio or mineral) is full, I must say, that's not how I play, or would play. I always try, if possible, to fill both to near capacity before returning, in order to ensure least amount of fuel used. Keep in mind, at the start of the game, 1 fuel unit equates to nearly 7 crew members (as horrible as that is to admit), so as long as your shuttle is still half full of crew (given the landing takes 1 fuel unit -> 0.5g), you might just risk it, but I guess that would be part of what this formula could determine.

The reason I did a reversal on the Melnorme upgrades is that I meant for this formula to be of the most use to someone at the start of the game, i.e. no upgrades. If you think they can be factored in without much effort, that would be great!

As for SC3 and Fomalhaut ... that sounds familiar ... I don't recall the condition of that star system.

In summary, I think I am seriously starting to regret ever suggesting this idea in the first place. What a nightmare! hehehe! :-D What a disaster all this would be if we finally created a working formula only to realize "Hmmm, this isn't really as useful as we had wished." Part of me is thinking that maybe I should have started with the idea of calculating the return on all "safe" worlds (Class 2 or below and 100°c or less; bios would be OK since they are arguably the easiest to avoid of all hazards). This would have the effect of significantly reducing our list of data to be processed and we could focus purely on mineral + bio values - fuel used (assuming player plays optimally avoiding all bio damage). One last thing about this formula ... I was wondering about distance from Earth (ignoring the Portal Spawner), in terms of fuel used for a round trip. What would be the point of spending 200-250 fuel units (4000-5000 RUs) if you don't make a significant return. It's times like this I get to thinking, "hey, forget all this ... here's the alternative":

• max out your thrusters ASAP
• fill two fuel tanks and fly to A. Pavonis to get the Warp Pod
• fly to the Quasi Space opening, get the Portal Spawner
• systematically fly to all the Rainbow Worlds (maybe even get the Taalo Shield, free the Umgah)
• Find Trademaster Greenish, get all upgrades
• focus on making the Flagship into a death dealing machine, by collecting RUs from VUX, Ilwrath, Thraddash, Mycon, etc.
• forget all this resource collecting nonsense!

And then I think, "Oh, right, as a new player I probably wouldn't know all this". If anything, this says a lot about the complexity and open-endedness of the game. You have options! --PsiPhi 21:55, 18 October 2007 (CEST)

Sorry about leaving out links for MST and Poisson process, it hadn't occurred to me that people would be interested, especially since I was suggesting that we not go down these paths. Ah, but SC fans live for concepts, and are interested in many such things. By the way, you say you've studied MSTs, I may be working with them before too long for characterising galaxy distributions. Another technique for doing same is Voronoi tessellation. Maybe I'll work with this too, but I mention this because you said you loved . If you look at the Voronoi tessellation article you'll see why I bring it up. For what it's worth, I like it too ;) Nice going.

I agree that we should assume uniform distribution rather than tackle things like the Travelling Salesman Problem. Although, what initially excited me about your idea was its difficulty. Well, for the article anyway, you're definitely right that we can't do it in all its complexity, what a shame.

You speak of reasonable standards for human actions, I think at least for what I was saying about bailout_crew, this is something which wouldn't be too difficult, it's just that because this only applies in rather hostile environments, when to return the lander is the least of: time to fill bio capacity, time to fill resource capacity and time to get down to bailout_crew. So our formula could be conditional in places, or, if one prefers, includes terms which play no role in many cases. So I guess (and as you and others have probably seen) the control structure of the formula might not be as simple as Fyzix's starting point.

About returning the lander when one of either bio and minerals is full, I don't think anyone plays like that, I was just saying it might be easier for the formula.

You mention "forget all this resource collecting nonsense!", I've thought this often and rather than think it over I often go looking for kills and rainbow worlds (this last one is kind of cheating one must say). But it does get boring. Quicker in Ur-Quan space though of course (this makes Fwiffo my ultimate hero at the beginning).

You bring up another significant question, that of whether to visit a star system in the first place. In my eyes this is just a scaled-up version of the same problem, where fuel to get there is like fuel to send the lander. It's just that fuel to get there obviously depends on how far away one is. If we work out the rewards of visiting a star system though, we would be able to say how close one would have to be to make a resource-gathering detour worthwhile. I think this could be worth considering while or after we discuss this planet-landing formula. I know I might use it. What do we think?

Do not despair yet, PsiPhi, it's a great idea and I reckon it can work, I like your style! --Zeracles 20:54, 19 October 2007 (CEST)

I don't know if assuming an even distribution is that good of an idea. To me that seems like it would flatten out the time such that the total time is the same for any number of deposits. However, I'd be interested to see what you get Zeracles by running it through some code and seeing how the total time varies with number. I was thinking of just having time_mineral be some standard dt times the number of minerals, scaled by the standard deviation to handle how the deposits clump, in other words T=N*sigma/v - dirty and cheap I know, but simple. To me there's a big difference between a close cluster of deposits on a hostile planet, and several scattered deposits on a similar planet.

As to the crew_bailout, I'd say that the easy way to factor that in would be to take the calculated total crew lost from all the hazards and divide that by the amount of crew you're willing to let die (12-crew_bailout) to get the number of trips someone will take. A similar thing can be done with the minerals and bios where the number of trips is the max(bio_total/capacity,mineral_total/capacity). The sum of the hazard and mineral/bio trips would give a high end estimate of the total number of trips. No idea though on the best value of crew_bailout, 3 maybe? I wonder if we should add a term in there for losing the lander (500 RU) on extremely high risk planets.

Yeah, I know this is extremely simple and probably ignores several factors, but I think one of the keys has to be making this as applicable to any player. A good player will look at a low reward/risk ratio and be more willing to try than a less experienced player, so I wouldn't worry to much about the human factor. Whatever algorithm you use, it really should model your thought process as you look at the scan of a planet. Of course there are some things you can't know like the aggression and mobility of the bio types, but I guess that's in part what this whole in endeavor is for. Anyways, in the words of Einstein, "Make everything as simple as possible, but not simpler." --Fyzixfighter 05:09, 20 October 2007 (CEST)

I've never heard of the Voronoi tessellation. Thanks for pointing this out. You know, this image looks like something you would see at the Museum of Modern Art. I love this map so much because of its quick usefulness. Back when I first played the game in 94, I actually taped together multiple pages of graph paper in order to be able to record information and write on a map (the original game map being all black made it hard ... besides I didn't want to ruin my map!). I believe I still have it somewhere folded up, along with my extensive notes on planets/star systems, Orz word approximations (our best guesses) and obscure game notes. I never completed the map (even for someone as patient as I am, it got tiresome), but I believe I marked all of the outlets from Quasispace. I know I definitely had the coordinates down. A concept similar to this occurred to me, but without precision drawing tools, I would have botched it, especially given how complex some of these intersections can be. In the end, I just "eyeballed" it. I was (am) all about efficiency, so finding the best QuasiSpace opening was always an obsession whenever we needed to get somewhere, such as when we finally started to figure out the pattern of the Rainbow worlds. That's when my map really paid off, since I was able to draw two lines directly on it. I still feel that was one of the best mysteries of the game, and figuring it out with only a limited dataset was an incredible feeling. Groombridge was the key ... on a hunch from looking at the map and the few Rainbow Worlds we had recorded (I think it was two near the "top" and two near the "bottom" of the map), I said, "let's go there ... I'm curious about something". When it turned out to be right, I drew two light lines on that map and we began our quest. Fun times.

I was thinking that parts of the formula would have to be conditional, which only makes things worse for me, because I know how to express that in a program, but not mathematically, at least not fully (I have a rough idea).

As for Fwiffo being great early game ... I agree, I usually sell my Earth ship.

I did stumble upon the Earth ship switch trick accidentally the second time I played the game ... I was trying to figure out why there was an "Earthlng"(sp.) and a "Human" ship among the game files, so just for fun, I started renaming the files on my hard drive, just to see what would happen to the game. Soon, I had a Chenjesu Broodhome as my initial vessel. It seemed somehow fitting since it was one of two Alliance ships missing from the SC2 full game, and I wasn't a huge fan of the X-Form.

Instead of Fwiffo, I usually ally with the Orz fairly early (ahhh, the Arilou are just paranoid silly cows, they're harmless fishies, it is for sure). Their aiming turret works just as well if not better than the Spathi BUTT missile when you turn it around completely. In this way you can fire while fleeing. I tend not to use the GO-GO space marines. The Orz cannon projectile is a lot faster and harder to destroy than the BUTT missile. Since the Orz are relatively on the way towards Ur-Quan space, forming an alliance is very easy with them. (just my two cents)

As for the fuel-distance portion ... yes, let's keep it in mind ... perhaps we can factor it in later. Zeracles, as always it is a pleasure discussing this topic with you. I like your style as well, and after reading through some of your site, I can understand why. Cheers. --PsiPhi 05:44, 20 October 2007 (CEST)

Some Plots

Interesting, Fyzix. I've just run some (well, two) quick tests. At this place I've put the results along with the little matlab script which did the job (I love matlab, easy and powerful, which is a good combination, I'm glad I haven't had to do anything so numerically insane as to require fortran). So if anyone wants to toy with this little script, hopefully they have matlab or work at some institution which has paid an exorbitant amount to subscribe for it ;) Feel free to ask here or on my talk page or email me for more info on how to use it, but I put some comments in, and in truth it isn't very complicated.

So, here's what I did (I think, hopefully there are no mistakes). The script populates a rectangle with a uniform random distribution of points, and for each point, it works out what the distance to the closest point is. Then it averages all these to find the mean (closest) separation. The script has three modes. Mode 1 does this once. Mode 2 does this several times with different (user-specified) numbers of points. The result of this test can be seen here, called varynumber.jpg. Strong dependence throughout the range. Perhaps we could fit a power law through it. The second test I did was with the script in mode 3, which varies the size of the rectangle (at present this is just a square, though). The result of this can be found here, called varysize.jpg. So this investigates Fyzix's point above. Strong dependence again throughout the range, looks linear.

In view of the latter result, Fyzix is right that uniform distribution is possibly not a great assumption, and while this wasn't unexpected, we've been motivated by a need to keep the formula tractable. But perhaps we could use the data from the game's source and run something like this script on each planet? A quick note on something which I'm not sure has been pointed out, we would have to subtract the number of return trips from the number of distances. Finding the number of return trips (I don't know, number_landings) might be the first step of the formula. But then we still get some extra time when the lander doesn't land exactly where it's supposed to, so subtract number_landings*separation_mean and add number_landings*distance_landingerror perhaps to get the distance (and therefore time, hence hazard) estimate. On a very hostile planet with valuable resources, one can be reduced to landing for just one deposit at a time, taking separation_mean out of the hazard calculation. But this variable would still have been important in the first place for dictating such a mode of operation originally.

Worthy points about crew_bailout there, Fyzix, I agree about how crew_bailout would feature. I was wondering about factoring in the cost of the lander too, but haven't wondered very much. I think we should put a term in for it. It'd be interesting to see how often it is of consequence. And that's a good point about not needing to worry about the human factor (phew).

Of course, this script doesn't work out what happens for the geometry of a planet in sc2, with the wrap-around. Also it doesn't give the total time as Fyzix was saying, for that one would have to multiply the mean separation by number. So, the dependence in varynumber.jpg gets reduced, and the dependence in varysize.jpg gets increased (underscores your thoughts against assuming uniform random distribution, Fyzix).

Happy to take suggestions on any similar investigations. Maybe I'll look into doing total time directly. PsiPhi, you made your own starmap? Me too, ah, the memories, I'd guess many of us did! --Zeracles 01:05, 21 October 2007 (CEST)

Losing Landers

When thinking about factoring in the cost of the lander, we need to think about the probability of losing it (this isn't really new, for factoring in the cost of crew, we use frequency of hazards which is related to probability per unit time of hazard striking). For thinking about this, I guess one could think about what has to happen for a lander to be lost. Hazards have to conspire to destroy the lander within a time such that the player doesn't have time to react (I'll just say time_reaction for now). We could call this conspiracy event_loss. The probability of event_loss increases as the lander loses crew. The probability of losing the lander, then, is the integral of this probability over the time the lander spends on the surface (so we just sum this probability, which is changing, over the lander's time on the surface). Sound fair? I'll go on if no-one wants to add anything. --Zeracles 01:44, 30 October 2007 (CET)

I know I said in my edit of october 18 (when speculating about what crew_bailout would have to be) that it probably wasn't a good idea to go down the path of thinking about Poisson processes, but now I'm having second thoughts.

I haven't looked at the code, but presumably this is how the hazards work. This just means that the probability per unit time of a hazard occurring is constant. A good example of this is particles from radioactive decay, or things popping up in hyperspace within a sphere of influence (I assume, but Slylandro probes are not a good example, see fact 2 here). We want know what the probability of event_loss (see above) is. Presumably (and someone could check this), the rates of the hazards are characterised by the probability of them occurring per unit time such that for each unit of time there can be said to be an expected number of occurrences. Then the probability of actually getting some number of occurrences may be found by using the first equation here (this tells you how likely lambda occurrences are when you expect k).

So let's assume for a simple example that on some planet there is only one hazard, and it does one damage every time it happens. Its occurrence is a poisson process. The chance of losing the lander when it has x crew is the chance of the hazard striking x times within time_reaction. We can find this probability (by using that equation I mentioned) because we know how often the hazard usually strikes within time_reaction (probably because we just looked at what "class" the planet was for this particular hazard).

The punch line is that this simple example is straightforwardly generalised to many hazard types simultaneously, and by multiplying by how much these hurt. I'll go further. Now that we know this, we can find an optimal crew_bailout. The reward for staying on the surface is the value of the next reward. From this we would subtract the likely crew losses and (probability of losing the lander)*(lander cost). Probability of losing the lander increases of course as one loses crew. So we subtract this risk from the reward and if our answer is positive then it's a good idea to stay on the surface. crew_bailout is when this goes negative - its value depends on the distances between goodies, hazards and lander cost.

I don't know how complicated that sounds, but I don't think it would be difficult to implement, there are some fiddly issues of course. I think the part about the lander cost influencing crew_bailout is intuitive - whether or not to bailout is going to depend on how worried you are about losing the lander, and this depends on how much it costs.

Also a quick note that it isn't just the cost of the lander, it's also the cost of losing all the things you've picked up. People are still interested in this right (I'm happy to explain anything which seems confusing)? This is interesting enough for me to go on regardless, though! --Zeracles 22:49, 3 November 2007 (CET)

I am, of course, still interested, but as I said earlier, my skills in this are not the best. This is why I never proposed an actual equation, even rudimentary. I figured a person (or a group) out there with better knowledge and understanding would be able to work on this and create something usable and sensible. I thank you for all your time and effort, and I look forward to further discussion. I'm hoping someone (perhaps you Z.) will start to elaborate on the equation beyond what little I currently have. If not on the article page, at least here, proposing how it might look, giving possible examples, so that the less inclined, such as myself, might have a better idea of where your thoughts are going, and what it might look like. Thanks. --PsiPhi 23:20, 5 November 2007 (CET)

While I still find this interesting, I'm going to have to respectfully bow out of any in-depth discussion as my real life grindstone (ie grad school/research) has become at least an order of magnitude more complex and involved. That said, I'll probably still throw in a couple pennies here and there, but honestly I think Zeracles has the best set of tools to tackle the nitty-gritty of this problem. On a more related tangent, I think you're onto a very important subtlety of the hazard of losing a lander - losing all the resources that would already have been collected, which can drastically reduce the reward of the planet. On the other hand this might be equivalent to increasing the net cost since one alternative to avoid this drastic loss is to do multiple, single mineral node runs, such that instead of the lost lander cost, you get a larger overall landing cost. Anyways, looking at your post below, I would say that this could easily fit into the iterative, computational solution you propose. I'd be interested to see at what values this strategy becomes more cost effective than the traditional one. Okay, enough rambling from the person who just recused himself from doing the heavy lifting - whatever you come up with in the end I'm sure would be much better than what I could conceive. Have fun, good luck, happy hunting, break a leg, win awards and all that jazz. --Fyzixfighter 06:35, 7 November 2007 (CET)

State of Play

Fair enough my friend, I wasn't getting annoyed or anything, I was just wondering if people were starting to consider this too hard to take seriously. This is a fun problem. Here I will consider many of the things which have appeared on this page (a review article!), and elucidate my humble thoughts.

PsiPhi's excellent idea is about a choice, whether or not to land on a potentially hostile planet. This choice could, one supposes, be made via a formula bearing a true or false (1 or 0) outcome. However, we have agreed that it will be best to have positive and negative outcomes, where positive is good, negative is "don't go there" and zero is "break even". Fyzix has cleverly suggested that the outcomes of such a formula need not labour the player's skills overmuch, since skilled players will be the ones who are game enough to tackle planets with the lower values, et cetera. Devices won't be considered, as they have plot-advancing value (as Valaggar pointed out), and effectively have infinite value I guess.

Fyzix proposed a first version of the formula in his edit of october 18, weighting hazards by their frequencies. However, we note that some parts of the formula may be conditional; we may need to think a bit more about the control structure. This takes nothing away from Fyzix's suggestion of course.

Some testing I've done (prompted by Fyzix) suggests that assuming an even distribution of minerals isn't a good idea. The value of the variable crew_bailout has been an object of some speculation, and I've suggested a way of finding this which factors in the cost of the lander. At this point, I think progress is encouraging and I agree with PsiPhi that there are enough pieces of this for us to begin assembling a sequel to Fyzix's first version. --Zeracles 16:16, 6 November 2007 (CET)

Pronumerals

So, I think we should begin by adopting some pronumerals for these variables, to make this easier on the eyes. I've noticed that variables have been scattered throughout this page, and it would be good to just be able to go to one place to find the variable definitions. Also a place where we can change them at will, I'll list some of these below (starting with Fyzix's variables!), and if anyone has more appropriate names, just change them. Also, we can add more variables here as they become necessary. --Zeracles 16:23, 6 November 2007 (CET)

General

• RR=risk-reward=an array of RU outcomes for exploiting a planet or moon with repective strategies - can take positive or negative values
• S=strategy=strategy space=a vector-valued quantity which describes strategy - alternatively, this may be thought of as a space which contains the strategies which might be employed by a player - individual positions (vectors) correspond to individual strategies

Rewards

• M_r=mineral_reward=total RU value of all the minerals (duh)
• m_r=average mineral reward per deposit (the above divided by number of deposits)
• n_m=number of mineral deposits
• M_p=total mineral parts, i.e. how much space they take up in the lander
• m_p=average mineral parts (the above divided by number of deposits)
• B_r=bio_reward=total bio value or (bio value)*40 to convert to RUs
• b_r=average bio value per lifeform (the above divided by the number of lifeforms)

Costs (and cost related)

• l_c=landing_cost=(fuel to land)*(times to collect everything (may differ if collecting bios))*20 RUs
• n_l=number_landings=number of landings required to collect everything
• d_m=mean separation between minerals
• t_m=time_mineral=not a cost, but dependent on the distribution of minerals
• t_b=time_bio=dependent on distribution, total hit points, and mobility (and maybe attitude) of the bios
• H=hazard=time*(frequency)*crew cost RUs (I'm guessing the class #/temperature determines the frequency of the hazards. The frequency then is how many of that type of hazard the lander will encounter each second.)
• d_n=damage_node=damage sustained during a single mineral node run
• b_h=bio_hazard=time*(danger weighted by mobility and attitude)*crew cost RUs
• t_sl=time_safelanding=time spent on the surface when filling lander to capacity, ignoring hazards
• c_b=crew_bailout=when crew gets to here, bail out
• t_b=time taken to reach crew_bailout
• c_p=crew_pre-emptivebailout=if after picking up something, crew gets to here, return to the ship rather than staying on the surface to get more

Lander Parameters

• L_$=lander cost
• L_s=lander speed
• L_c=lander capacity
• d_le=distance_landingerror=how much on average the lander misses landing point

Control Structure

I think the main question here is the number of landings, and whether this is determined by the capacity of the lander, or by the hazards. On a planet which is relatively safe, the former will be true, and the latter when it's dangerous. I've been thinking about a mathematical way of doing this, and I don't see an easy way (to the rigour which I've been looking for at least). What I suggest we do is trial and error.

Tell our formula to do rewards minus risks on the assumption that we ignore the hazards no matter how dangerous they are. Include all rewards and hazards, as well as the risk and cost of losing the lander (on a dangerous planet, the result may be that the lander gets destroyed pretty well every time). From this we will get an RU estimate of the risk/reward. Then tell it to iteratively try the same thing with each possible crew bailout. We then have several RU estimates. Take the maximum of these, and there's our answer.

I realise this could be seen as a really cheap tactic to solve the problem, but what this does is turn a computational problem into a more mathematical one, to my mind (i.e., my suggestion is to do everything and take the best option rather than do this conditionally). I'm having fun with this problem, cheers everyone! --Zeracles 16:31, 6 November 2007 (CET)

Strategy Space

That's a shame (re Fyzix's edit under Losing Landers). At least an order of magnitude! You know, I'm only part time these days, because those sorts of things happen. I think it's a very underrated undertaking, to work full time, or am I just too laid back? It's no coincidence that I recently switched to part time and started editing the ultronomicon a bit later, and life has been so much better. I couldn't be paid enough to give this up. In what we do, Fyzix, research, I found the situation intolerable. There are few things worse than having to tackle tricky/tough research problems while under the pressure of time, under the pressure of your supervisor wanting to publish. And research problems are fun (like this planet lander problem) if you are allowed to take a step back and really think about them, potentially not so if you aren't. I have a bit of story here - at the end of my honours project last year, my supervisor told me that I could go ahead and write a paper. What ended up happening was, because I was part time and had enough time to think a little, I was able to come up with a new algorithm for characterising galaxy distributions. Fast forward to now, we've just got a referee's report on this paper, and the referee reckons that this algorithm is the strongest point of the paper, and it is the basis of my work at the moment. It goes to show that in research at least, it can really pay to take it slow if you see something which you'd like to think about a bit more, despite the constant pressure to publish.

I think you're more experienced on the research path than myself, Fyzix, so this is probably nothing new :)

But back to business - with my suggestion about iteratively trying strategies, this is like having a "strategy space". One could think of the RU estimates which we get as a way of choosing an optimal strategy from this space. In my last edit I really only proposed one variable for this space. This is so because what I said reduces to the following: land, collect stuff until one of two things happens:

• lander capacity is reached
• crew_bailout is reached

The case I spoke of where one simply ignores the hazards is equivalent to setting crew_bailout = 0. So, because lander capacity isn't a variable, our strategy space has just one dimension.

It isn't this simple, and Fyzix has just pointed this out by citing the case of deciding to do "multiple, single mineral node runs", in his words. I'll put this in perspective - once one has picked up something and has enough space for more, does one get more and risk losing the lander, crew and what has already been gained, or return to the ship and attempt to land close to the next piece? One can generalise what Fyzix is thinking of here to the possibility of not just single mineral node runs, but perhaps to "some integer" node runs.

How to put this in our strategy space? Putting ourselves in the player's place, this amounts to, I think, a kind of pre-emptive crew_bailout. I'll call this c_p. I've added it to the list of variables, but -

c_p=crew_pre-emptivebailout=if after picking up something, crew gets to here, return to the ship rather than staying on the surface to get more

This c_p becomes another variable in our strategy space, which is now two-dimensional (it's kind of degenerate where crew_bailout is greater than c_p). c_p = 0 corresponds to the strategy where one isn't thinking about doing this at all, and where one is only prepared to return to the ship when crew reaches crew_bailout or lander capacity has been reached.

Effectively, coming up with this formula now has two parts.

• come up with all the possible strategies
• figure out what happens for each of them

I may be silent for the next two days or so as I need to prepare to chair a research meeting, but I think this is open for people to think of other strategies to add here. If anyone would like to propose them, I can think of how to "parametrise" them and work them into the strategy space. --Zeracles 10:50, 7 November 2007 (CET)

Modeling What Happens

This may not be the most exciting SC development for all of us, heh, but I have written a (matlab) code which models what happens for the strategies of a given strategy space, which can be found here (I couldn't help myself!).

I'll briefly describe what the code does (I'll list all the assumptions made below). First define dimensions of the planet. Then define the "catalogue" of stuff on the surface. Say something about hazards. The variable "inputmode" determines whether this is input from maybe the game's source or something we're making up for testing purposes. Then define our strategy space and the values which we will sample. Then input reward and cost values (rewards will come from catalogue data when we do this for real). Under "FUN WITH DISTANCES" we take all the coordinates of all the catalogue positions, find the nearest distance to the nearest other position for each position, average these (the same thing I described in my edit of october 21). Lastly we get to the simulation bit. The process here is to try all the strategies of our strategy space and see what happens. So here is a nested for loop ("for" every strategy). The exact details of this will vary as the various assumptions of the code are ticked off. Rather than spam this page with every detail of the changes I make, I'll give more detail on this little web page (which you can see now for details of precisely what the code does at the moment), maybe making notes on the list which I'll put together below. --Zeracles 21:30, 12 November 2007 (CET)

Oh and I just want to say that I will illustrate all this with a nice example to make it accessible to all (because preliminary results are promising!), so uhh, maybe wait until I've done this. While you're waiting, maybe read this story or something. --Zeracles 21:39, 12 November 2007 (CET)

I have now put an example of this here, ask me if you have any questions. --Zeracles 22:53, 16 November 2007 (CET)

I've done some variations on this example here. I demonstrate that with this approach we could take into account changing mineral abundance, hazards and melnorme tech. I realise that I haven't really demostrated yet that this iterative approach is really better than a conditional formula, but I think we are starting to see effects which would be troublesome to do with a formula (I mean the areas with same pixel values) as this gets more precise. --Zeracles 23:17, 20 November 2007 (CET)

Below I'll list the assumptions which the code makes (not an exhaustive list), I'll probably add more, cross off and modify them as I go. The code is on that web page; I'm happy to plough through these, but of course if any of you have any suggestions, they are welcome. This doesn't list the strategies which still haven't been listed fully, or the information we would need from the game source (this would be a separate list, which people can feel free to start below this one). --Zeracles 06:04, 22 November 2007 (CET)

• crew costs nothing
• only one hazard type
• geometry of a planet is square
• no wrap-around for a planet, so the edges can't be crossed
• ship can carry infinite number of landers, infinite crew, infinite fuel
• zero turning time
• all mineral deposits are the same
• no bios
• need to work in a proper time thing, i.e., crew losses are a subtraction of hazard frequency from crew
• hazards are treated only as frequencies (which is probably fine until crew gets low)

And while I'm in the mood for lists, here's a list of the things we need to know from the game source (again, I don't think this is all). Again I can look into this myself, but anyone feel free to have a look, as I know nothing about the source. Remember, I'm happy to do it all but at the same time I'm not trying to monopolise this discussion, there is still room for suggestions on strategies to build into strategy space, modeling what happens and the blanks listed below. --Zeracles 05:31, 23 November 2007 (CET)

• how do the hazards behave?

• are the hazard frequencies governed by poisson processes?
• how do the "classes", temperature et cetera affect how bad the hazards are?
• how does gravity affect how much fuel it takes to land?
• what are the precise rules for how much they hurt?

• and how does this change with melnorme tech?

• what are the lander parameters?

• speed?
• turning rate?
• firing rate?
• and how do these change with melnorme tech?

• how do weather and/or gravity affect error in landing position?
• how do the bios behave, exactly?
• what are the dimensions of a planet (I just mean width and height in the box on the screen)?
• and obviously, all the raw data for each planet and moon

Formula Construction

Basic elements

This iterative approach was supposed to be a way of not having to come up with a formula. But having seen how the risk-reward can be so easily visualised, and realising that we can come up with a formula which fits what we see, it looks like we could construct a formula in parallel with the code development, making the formula more and more complex as we do likewise with the simulation. The code will be an easy way of making sure we don't get it wrong (I seem to be laying out a lot of things without actually doing anything!). Now, as soon as I learn how to make equations in wiki . . . --Zeracles 05:09, 30 November 2007 (CET)

I begin setting this up below - the latex version looks nicer.

For any given planet or moon along with the attributes of the lander depending on melnorme tech, one can build up a map of what will probably happen for each possible strategy in strategy space. Performing this analysis leads to a definite conclusion on two things.

• The ``risk-reward" in RU for the planet - an indication of how worthwhile landing on the planet might be. This is the value of the brightest pixel on the map in strategy space. This is really a relative indicator - whether or not a player should land will still depend on that player's skill.
• The best strategy for the conditions, indicated not by the value, but by the location of the brightest pixel in strategy space.

Now we will put this in mathematical terms. Suppose we are dealing with a two-dimensional strategy space defined by, as in first example, crew bailout (c_b) and pre-emptive crew bailout (c_p). Let (i,j) be an index which identifies each strategy, with i labeling c_b and j labeling c_p. The RU value of the risk-reward (RR) for a particular strategy defined by the pair (i,j) can be denoted by RR_i,j. Thus, the RU risk-reward for a strategy in which one bails when crew is down to 5 in any conditions, and when one bails when crew is down to 10 immediately after collecting a deposit is RR_5,10. We can call the corresponding strategy S_i,j.

Now we can express the two items in the above list using this formalism. The risk-reward for a planet is max(RR), where we treat RR as a set of numbers, one number for each strategy. The (i,j) which identifies the best strategy is that pair for which

max(RR) = RR_i,j.

--Zeracles 19:46, 3 December 2007 (CET)

How to get formulae

I've updated the latex version.

Given an n-dimensional strategy space, we have an n-dimensional surface formed from individual RR values specific to each strategy. We can do calculus with this surface (at least, I hope, I haven't thought about the details yet). For this, we are interested in the derivative of RR with respect to S, dRR/dS - S being vector-valued makes this is a vector calculus problem. We are motivated by the relation above, max(RR) = RR_i,j, which describes the maximum value taken by our surface, and many of us will know that calculus is often a good tool for finding maxima. The first derivative

dRR/dS = 0

will give us local maxima and minima. A condition on the second derivative

d²RR/dS² < 0

tells us which of these are maxima. Both of these conditions must be satisfied for local maxima in our surface. We want the maximum of these for max(RR) (which is also the maximum of the maxima and minima, so depending on what's fastest, we may ignore the second condition). This is where this becomes a conditional formula, as we have long suspected - there will be certain conditions under which some maxima are higher than others. --Zeracles 20:48, 12 December 2007 (CET)

The RR Surface

I've updated the latex version (which is superior because it contains figures).

The first step is to describe the RR surface with a formula. As I think I mentioned somewhere on the little web page I made for this, we already have this for the first of the figures here. For just the smooth part, everything but the pixel in the top left hand, this is

RR = m_rn_m - l_cn_l.

But we need to have RR in terms of the strategy space variables (S).

RR = m_rn_m(S) - l_cn_l(S)

For this part of the RR surface, all the minerals are collected from the surface, so this is constant. On the other hand, n_l has a surface of its own in strategy space, which one can see in the latex version. And I'll be back when I know what this surface is in terms of S (simple, probably, but I don't know yet). --Zeracles 17:31, 10 January 2008 (CET)

In terms of S

Here's a chain of reasoning which puts n_l in terms of c_b and c_p.

• number of landings = total minerals on the surface / amount collected with each landing
• amount collected with each landing = (1 + number of single node mineral trips) * amount at each deposit (plus 1 at the beginning because the lander picks one up instantly, for the moment)
• number of node trips = min(number of node trips until c_b forces bailout, number of node trips for c_p to force bailout, number of node trips until lander capacity is reached)
• number of node trips until c_b forces bailout = (12 - c_b) / damage for each node trip
• number of node trips until c_p forces bailout = ceil((12 - c_p) / damage for each node trip)
• number of node trips until lander capacity is reached = (lander capacity - amount at each deposit)/ amount at each deposit

In the second last item, ceil just rounds up to the nearest integer, so ceil(1.5)=2. The difference between the last two items comes from what c_b and c_p are, exactly. c_b can force bailout in the middle of a node trip, while c_p only does it immediately after the lander picks something up. As an example, if 2 crew are lost on each node trip and c_p = 9, the number of node trips until c_p forces bailout is not 1.5 but 2.

All this means that we can write an equation for the RR surface in terms of S. I'll test it first. --Zeracles 18:27, 24 March 2008 (CET)

Don't know how to display an equation like this in wiki, but you can see it at the end of this. To put it in context, we have an extremely rough expression for the worth of exploiting a planet, for each possible strategy. One could take the maximum value of RR as a measure of what a planet is worth, and the strategy which allows this as the optimal strategy. Better would be a formula which spits both of these out. --Zeracles 22:22, 20 April 2008 (CEST)