Blackspace!

[Manspy 3]

That's the asteroid field with the UFO...

Note that you can't attack it.

 

[DarkUnderlord]

I thought of that and decided I didn't want to. Currently the formula that runs Thrust is the same one that works scanners and comms too - and they seem to be fine. Then again I did manage to spend a bit more time on those.

No, those don't work, either; it's just harder to tell that this isn't intentional. Scanner range drops if you add a low range computer of a higher information density. This didn't seem jarringly illogical to me at first, but it's not like you get "data" information on objects that exceed the "data" range; buying a data computer just shrinks your scanner range for no apparent reason.

Electromagnetic interference affects all comms and scanners.

Anyway, non-monotonicity (i.e., this property) is an undesirable quality in a diminishing return function

I could resolve that issue with the current formula by just removing the averaging that occurs first. Though it's still not ideal as depending then on what order I add things to the total, it affects the overall result and I then have to go the extra effort of making sure everything is ordered properly otherwise it just gets worse.

because you're dividing out the number of units of equipment, why not just calculate raw data banks and plot it on some asymptotic function?

Sure. All I need now is "some asymptotic function". Whatever works so that 1 device with say 22 data or 500 rto is better than 10 devices with equivalent total data or rto, so it's not a simple "Oh, that has more rto / sc than this so that is clearly better". Simply adding more devices should be inefficient.

Also, I'm not a math guy by nature so I'm really just playing around with "what happens if I square root this or put that to the power of that or divide that by that, then square root it and add one?". If I were I could probably get a handle of what I'm trying to do a bit better and work something out more properly.

 

[Kayerts]

because you're dividing out the number of units of equipment, why not just calculate raw data banks and plot it on some asymptotic function?

Sure. All I need now is "some asymptotic function". Whatever works so that 1 device with say 22 data or 500 rto is better than 10 devices with equivalent total data or rto, so it's not a simple "Oh, that has more rto / sc than this so that is clearly better". Simply adding more devices should be inefficient.

That's actually the dynamic I don't see the purpose of. The only result I can see is a more complex formula, one that's trickier to design and calculate. Decay of benefit conferred per unit of equipment doesn't actually result in complex decision-making about which equipment to buy; it just changes the optimal decision from "buy the engine with the most rto/sc" to "buy the engine with the most rto."

I suppose with a sufficiently large disparity between raw benefit vs. benefit/sc efficiency, the relationship could get more complex, but it'd still be complexity that players solve with a spreadsheet or a program, rather than an analysis of changing in-game factors.

I'm not actually trying to argue here; it's just that I don't see why this is a desirable effect, and that makes it harder to design a function that achieves that effect.

 

[DarkUnderlord]

because you're dividing out the number of units of equipment, why not just calculate raw data banks and plot it on some asymptotic function?

Sure. All I need now is "some asymptotic function". Whatever works so that 1 device with say 22 data or 500 rto is better than 10 devices with equivalent total data or rto, so it's not a simple "Oh, that has more rto / sc than this so that is clearly better". Simply adding more devices should be inefficient.

That's actually the dynamic I don't see the purpose of. The only result I can see is a more complex formula, one that's trickier to design and calculate. Decay of benefit conferred per unit of equipment doesn't actually result in complex decision-making about which equipment to buy; it just changes the optimal decision from "buy the engine with the most rto/sc" to "buy the engine with the most rto."

... but that rto/sc equation is still there because the engine with the most rto may still not be "the best".

Let's say you have 10x Engines that provide 12 rto each for a total 120 rto but with our Magic Formula™ it results in only 10 T/ph on a size 10 ship. Where-as we also have 1 Engine that provies 120 rto that on a size 10 ship would provide a full 12 T/ph.

The engine with more rto is clearly better but what if I then say that the larger engine takes up 50% of your ship space, where-as those smaller engines only take up 35%? You now have to work out how many of those small engines you can fit in 50% of your ship space and will that then provide more or less thrust when our diminishing return is added? Now if I say that the larger engine needs a much larger power supply than the smaller engines, how does that then effect it?

We're now not just considering rto/sc or even rto, but rto/sc and pu in various combinations. Maybe a bunch of smaller engines is better up to a certain ship size at which point the larger engine becomes more useful? Maybe this sounds more complicated than it really is and there is a simple solution but ultimately I want players to have options and different fit-outs. I want that one ship with the 3x Big Engines and I want that other player with the ship that has 1 Big Engine and 25 Smaller Ones because it inferred him some advantage that he wanted (maybe saving room on power to get that bit of extra Thrust compared to having 2 Big Engines or something).

I've got no doubt that ultimately a program or spreadsheet will resolve everything and work out "the best" for any given setup but that will still have to factor in all their other equipment. (Hmmm... These engines provide better T/ph than those but I need a mining drill and that's more power which means a bigger plant which means I may as well get that many of those more powerful Engines and a few Holds oh but I'll need one or two extra Hulls to fit it all in and optimise the fit-out...).

 

[Spectral Miasma]

Anyway, non-monotonicity (i.e., this property) is an undesirable quality in a diminishing return function

I could resolve that issue with the current formula by just removing the averaging that occurs first. Though it's still not ideal as depending then on what order I add things to the total, it affects the overall result and I then have to go the extra effort of making sure everything is ordered properly otherwise it just gets worse.

Just apply the same formula, but to each engine type individually and then add up the results...

i.e.

(rto_judson_base * sum(1/n, n=1..n_judson ) + ... )

 

[DarkUnderlord]

I actually tried that. The downside was that it was most beneficial to have one of each Engine type - and then to add specific Engines depending on their ratios to the other Engines. While it gave me a nice reason to have multiple Engine types on a single ship (something that's desired) it seemed kinda dumb to have one of every single type of Engine in the game on your ship. Part of that may be just the numbers in the Engines themselves though but it seemed kinda dumb at the time.

 

[Kayerts]

I agree that forcing players to make nontrivial decisions about what stuff to buy is generally good for gameplay. But in this instance, it doesn't seem like it's actually adding an element of interesting complexity; it's just making the decision process more difficult to reason about for the average player. They're still trying to optimize their engine purchases; it's just a little more convoluted now. From a game design standpoint, it seems better to introduce complexity by forcing decisions across different dimensions (how to balance your ship for trade / scanning / thrust / offense / defense) than by making consequences harder to understand for a single dimension. "What's the best way to go about this fight?" or "what's the best way for me to make $3B?" are questions that should be hard for the player to answer; "how do I get the best thrust for this amount of SC?" should be easy, I think.

In terms of forcing players to consider trade-offs, that will depend more on the stats you choose for the engines you offer players. Chances are excellent that you won't get that balance right on the first try, so I think a formula that leaves the relationships reasonably straightforward is going to make things easier for you to fine tune. The simpler formula means you think about problems like "hey, this engine is overpowered and lets this size 500000 guy zip around the galaxy like some kind of teleporting space wizard, I should nerf it" rather than "so this 2500 ship with 30 engines has a tph of 60, and, hey, this size 26 guy has a tph of 4000; this is all very weird, but I don't see how to fix it." You'll basically be working with two nested scaling functions for thrust (one on the per-engine level, and then another that compares thrust to size), and that's going to be both hard for players to understand and hard for you to balance.

All that being said, if you really want to keep the diminishing returns thing, the following pseudocode algorithm should provide monotonic and otherwise sensible-looking results:

1. Sort equipment types according to magnitude of benefit conferred, descending. Call the sorted equipment list sortedEquipment. 
2. For each equipment type thisEquipment in sortedEquipment: 
   benefitSubtotal += someOtherAsymptoticFunction(startPoint = equipmentQuantitySubtotal, quantity = thisEquipment.quantity) * (thisEquipment.quantity * thisEquipment.perUnitBenefit)
   equipmentQuantitySubtotal += thisEquipment.quantity

So, if you've got two big engines, three medium, and four small, you calculate them in that order. The equipment-based diminishing return factor for the big engines are calculated from 1-2, the medium engines' diminishing return factor is calculated from 3-5, and the small engine's diminishing return factor is calculated from 6-9. Diminishing returns are represented as a multiplier to the base benefit.

Let me know if any of this sounds like gibberish; otherwise, I'll try coming up with a reasonable version of someOtherAsymptotic function.

 

[meh]

What part of the ship determines the amount of clicks gained? Or is it constant amount per hour?

EDIT: is it thrust per hour?

 

[Gold]

What part of the ship determines the amount of clicks gained? Or is it constant amount per hour?

EDIT: is it thrust per hour?

Thrust per hour

 

[Kayerts]

One bug, and three thoughts on game balance.

Bug: It looks like after destroying a ship (at least, after destroying DU's ship), your message log is wiped.

Game balance issue #1: Freighter hulls are currently more efficient for tanking than battleship hulls, at least after they get big enough to fit Nova reactors. Versus armor-piercing enemies, buying shields is more efficient (even accounting for power costs); versus all others, buying armor is MUCH more efficient. The freighter also has the benefit of allowing you to cheaply convert that shield/armor space into cargo holds, thrusters, or weapons, which you can't do with a battleship hull. Basically, battleships suck and should be rebalanced, either by buffing their stats or lowering their base price to be significantly below that of freighters.

(Please don't do some diminishing return thing with power or shields. )

Game balance issue #2: Turret scaling currently doesn't make a lot of sense. Specifically, the top three high-end turrets are weighted heavily for shield damage. This is bad for two reasons. First, it's redundant, since the high-end ion cannon has a much better expected damage against shields. Second, it doesn't make a ton of sense to begin with, since shields are least efficient for little guys (as a general matter, and especially versus large ships). There aren't any armor-piercing turrets, so if you're going up against a bigger guy, massing armor is your best bet; there's no reason to buy shields at all.

Issue #3: If you die far enough out into space (against, say, some irritating race of flying saucer dopplegangers) it turns out that you can't get back to a station where you can buy engines, or even a black hole. With thrust = 0, this means you are stuck. Recommended fix: maybe give escape pods a base thrust? Something semi-respectable like 20 wouldn't be unbalancing. It's not like they can use that to trade gazillions.

 

[DarkUnderlord]

Let me know if any of this sounds like gibberish; otherwise, I'll try coming up with a reasonable version of someOtherAsymptotic function.

There are some issues with how I pull stuff out which would mean either more queries to handle doing that or re-sorting a multi-dimensional array a few times to get it right for each type of equipment. Not un-doable but at this stage I'm more inclined to re-work the calculation.

Bug: It looks like after destroying a ship (at least, after destroying DU's ship), your message log is wiped.

Oh erm... The original bug was messages weren't wiped at all when you were destroyed and you could still broadcoast. It seems I passed the wrong ship id when someone else is destroyed. Should be fixed now.

Aware of Freighter Hulls. Aware weapons need to be tweaked (I say tweaked because on the whole I think they're working all right but Big Baby's have too high crit and mobility of others will be looked at). Thinking about changing some of the AP / crit stuff around to mix battle options up a bit. Shields being good versus AP is the intent.

(Please don't do some diminishing return thing with power or shields. )

Actually I have toyed with making power something that generates every hour or something, you then "spend" power when attacking or moving and have to wait to re-charge if you're low on power. Mainly just trying to figure out how I can get my batteries in as an equipment item and solar cells that work within X range of a Star (Power Plants were originally going to require fuel too - still not sure on whether I will do that or not at this stage).

Shields and Armour will be looked at later.

Issue #3: If you die far enough out into space (against, say, some irritating race of flying saucer dopplegangers) it turns out that you can't get back to a station where you can buy engines, or even a black hole. With thrust = 0, this means you are stuck. Recommended fix: maybe give escape pods a base thrust? Something semi-respectable like 20 wouldn't be unbalancing. It's not like they can use that to trade gazillions.

Erm... Escape Pods automatically get 100 Clicks and 1 Thrust. If you die further out than that, that's your problem. Eventually I will look at ways you can dock with others and transfer equipment or have a rescue party come pick you up somehow.

 

[Kayerts]

All the other stuff sounds reasonable (shields vs. AP is definitely working already, especially since AP apparently damages equipment), and the idea of spending power is interesting. However:

Erm... Escape Pods automatically get 100 Clicks and 1 Thrust. If you die further out than that, that's your problem. Eventually I will look at ways you can dock with others and transfer equipment or have a rescue party come pick you up somehow.

1. Escape pods actually get 0 thrust right now; based on the above, I take it that's unintentional?

2. The Yaladi encounter was over a hundred clicks from the nearest space station / the black hole. (Except for Lonak, and that doesn't sell anything that would help me get back home.) If the intention's to include effective permadeath as one of the stakes for NPC encounters (or getting into a fight in the >100 region, I guess), that's one thing, but it doesn't seem like this was the intended effect.

 

[Baron]

The Yaladi station was destroyed? Lucky I bought that Hula girl figurine... not sure what it's used for though.

 

[Kayerts]

Yaladi was slaughtered to the last man by a squadron of six flying saucers, alien dopplegangers who copied the stats of their opponents. The genocidal xeno assault wing was defeated by my mighty exploration alt and his fearsome 22 points of attack.

Have you tried checking the wormhole or the jumpgate in the upper left with the hula girl? Alternatively, you might be able to bypass the current coordinate limits of |200|.

 

[Baron]

Thanks. Will give it a shot.

 

[Manspy 3]

Someone asked for the current TPH formula - it is:

TPH = {  1 + rto * sum(1/k, k=1..N_engines) / (N_engines * Size)   }  * pu_factor

edit - some clarifications:

N_engines = total # of engines
sum(1/k, k=1..N_engines) = 1 + 1/2 + 1/3 + ... + 1/N_engines =~ ln(N_engines) + 0.577 (for large N)

 

[Zed]

Shouldn't you move this to Codex Workshop?

 

[Manspy 3]

DU, may I ask again for a method of fast travel? I know I can spam clicks, but I'm sure there's a more elegant solution...

 

[Kayerts]

Here's my thrust formula revision proposal.

(It's long. I tried to show all my work here, so if you don't like the assumptions, you should be able be to tweak them p. easily.)

After giving it a bit more thought, neither diminishing returns for thrust based on size nor general diminishing returns based on number of equipment units are inherently unworkable. However, the limit of the benefit as size / equipment approaches infinity shouldn't be 0 for thrust, because that that creates the aforementioned pathological dynamic whereby, for big ships, 1 engine =~ 100000 engines =~ 1 tph.

As a final consideration, if you're already scaling thrust output based on size, raw thrust, and number of engines, then you don't need to penalize size with a second function to provide the desired handicap.

So:

Assume stated parameters; i.e. a rocket sled gets 56 tph and an optimized big ship gets 12.
Assume a big ship is one of size >=1000.
Assume a mean hull size of 110 on a big ship. (Which is probably dumb; see notes.)
Assume raw thrust follows old values, prior to you multiplying them by 100.

Then:

let tph = 1 + (thrustDiminishingReturns(engines) / size) * powerBonus

For the simple version of thrustDiminishingReturns, i.e. the non-monotonic one that's calculable in a single equation:

Consider that the optimal breakdown for a size 4 rocket sled is 4 microfusion reactors, 1 impulse array = 84 rto/size = 56 tph = 55 after the 1 tph freebie
Consider that the optimal breakdown for speed of the big ship is 384 impulse arrays, 12 Novas = ~129 rto/size = 12 tph = 11 after the 1 tph freebie

So we want the efficiency at 384 impulse arrays to be (11/55 *84/129) = 28/215 =~ 0.13023 times the efficiency at 1 impulse array. We do not want substantial decay in efficiency after the 384th. So all we have to do is plug in any regression function that goes from 1 to 0.13023 between 1 and 384, multiply the result by raw thrust, and then multiply that result by a calibration constant between rto and tph as desired afterward. For the calibration constant, since you want 84 rto/size to yield (56-1) tph, use a calibration constant of (56-1)/84 =~ 0.65476.

thrustDiminishingReturns = (regressionFunction(engines.totalNumberOfEngines)) * (engines.totalRTO) * (0.65476)

For regressionFunction, a simple linear regression with a floor of our minimal efficiency of 0.13023 may suffice, although see the notes:

regressionFunction = max(0.13023, -0.86977/383 * x + 383.86977/383)

So, putting it all together:

tph = 1 + max(0.13023, -0.86977/383 * numberOfEngines + 383.86977/383) * totalRTO * 0.65476) / size * powerBonus

I worked out a few test cases, and the results were pretty reasonable. Take a look at the results, and if you like them, try it out!

Notes:

1. To get the monotonic version, the algorithm supplied earlier in the thread, applied over thrustDiminishingReturns(), should probably work.
2. The way combat works, big ships are going to be forced into more of a tanking role than other ships, so assuming a mean hull size of 110 is probably unrealistic. Something in the 60-80 range may be smarter.
3. Using a bounded linear regression for regressionFunction may lead to some undesirable properties. So, for example, the average big ship getting 7 tph was a design goal; with linear regression, that requires a dedication of (7-1)/(12-1) = 54.45% of your total space to engines and engine power, which seems high. If you don't like that, you can use a more advanced regression of some sort. Let us know if that's the case and you want contributions.

EDIT--said max when I meant min. Thanks, Ninja!

 

[Spectral Miasma]

https://spreadsheets.google.com/spreads ... c&hl=en_US

 

[DarkUnderlord]

I actually had the formula pretty much dusted by the time you posted that - which I've now uploaded. I'll see how that plays for now because it gives me some unique properties and differences I can setup between engines, which you shall soon discover through experimentation (and math, no doubt).

Gentlemen, start your whinging about engines!

 

[Kayerts]

Could you either (a) offer Cijaas and impulse arrays at Yaladi or (b) code in the ability to destroy equipment at any dock? Currently, you have to sell off your engines at Ahbet, then make a 130-click journey to Yaladi. That's awkward.


Oh, also, the news has an error. The Xenos that attacked Yaladi did not "mysteriously disappear." They were scoured out of existence by the might of imperial justice. It wasn't mysterious at all.

 

[villain of the story]

I'm starting bitching in about 3, 2...

 

[Kayerts]

The new formula and acceleration dynamic look pretty reasonable; I imagine this will be easier for you to tweak to rebalance as the game goes on. Some of the engine stats seem wonky, but the new dynamic is a major improvement overall.

The jumpgate is a good and much needed addition; my only suggestion would be to add more of them.

Offering basic hulls, scanners, and engines at every docking station is a very good change.

 

[Gold]

Idk, there is a huge difference between 100 clicks an hour and 1 click an hour. One was a lot more enjoyable, the other just makes me sit in one port with the biggest ship I can afford and trade the best good as it randomly goes up and down.

Though with the nerf to hull prices Im sad I sold my 3751 hull ship to see if the new system was enjoyable and the best I could do was a 120 ship that got 11 clicks an hour. So I guess I will just stop being a space trader and become a warehouse.