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).

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)