Ratjoy.com » Forums » Suggestions, Technical Support and Feedback » Exploiting the arithmetic-geometric mean inequality
You need to register or login to post a reply.
Exploiting the arithmetic-geometric mean inequality
|
Mister Death RJ: McFlono McFloninoo Post Rating: 1 + / - Total Posts: 266 Karma: 300 Joined: Feb 6, 2012 |
Posted on Apr 6, 2012 I noticed this by accident because I was cancelling a run of apple pies almost exactly halfway through an 8-hour run. I got almost exactly half the number of apple pies of the total run. If I had done the 4-hour run I had been planning, I would have wound up with fewer pies using the same input costs and factory time.Highly exploitable; please fix. If a run is cancelled, a company should get (not more than) the amount they would have got with a full run of that length. |
|
Scott (Admin) RJ: Ratan Joyce CO: Ratan Joyce Post Rating: 0 + / - Total Posts: 1175 Karma: 5083 Joined: Jan 13, 2012 |
Posted on Apr 6, 2012 (Last edited on Apr 6, 2012) Oh no! You found it the first time you clicked cancel!I actually saw this problem when I did the code, but left it as is for now because I wasn't sure what to use for the following statement in the "view production" screen: Approximately N units have been produced. I saw two solutions, but didn't like either of them: 1. Make the approximated N go slow at first, but lightning fast near the end. 2. Reduce the number of units given upon cancelling and say the approximation is wrong. |
|
Mister Death RJ: McFlono McFloninoo Post Rating: 0 + / - Total Posts: 266 Karma: 300 Joined: Feb 6, 2012 |
Posted on Apr 6, 2012 (Last edited on Apr 6, 2012) I'll be candid, I was watching for it because I was curious how you'd handle it :PThe "view production" screen isn't something one looks at for hours and hours, so a linear approximation should suffice for that ticker. Work out the present amount using whatever code you use in the "start a production run" screen, and working out the rate of change shouldn't be that hard. |
|
Scott (Admin) RJ: Ratan Joyce CO: Ratan Joyce Post Rating: 0 + / - Total Posts: 1175 Karma: 5083 Joined: Jan 13, 2012 |
Posted on Apr 6, 2012 Wouldn't be hard at all, but I can guarantee you people would ask me about the approximation screen whether or not I use (1).
|
|
Tony Wooster RJ: Johnny Appleseed Post Rating: 0 + / - Total Posts: 41 Karma: 51 Joined: Apr 4, 2012 |
Posted on Apr 7, 2012 I think 1 is appropriate, because it reflects what's actually going on. I've taken to thinking of the mechanism as a slow acceleration -- as you go, the more you make, the faster and cheaper you make it. In fact, it'd be kind of nice if I could keep my, say, water well running all of the time and eventually reach the best production values (obviously, there has to be a minimum limit on costs) -- and stay there -- so long as I had steady resources to supply.
|
|
David MacIver RJ: DRMacIver CO: David R. MacIver Post Rating: 0 + / - Total Posts: 47 Karma: 56 Joined: Apr 5, 2012 |
Posted on Apr 7, 2012 How about just making some proportion (20%?) of the money spent a lump sum paid up front which you don't get back when you cancel? It's pseudo-realistic and pretty easy to understand.
|
|
Scott (Admin) RJ: Ratan Joyce CO: Ratan Joyce Post Rating: 0 + / - Total Posts: 1175 Karma: 5083 Joined: Jan 13, 2012 |
Posted on Apr 7, 2012 (Last edited on Apr 7, 2012) From a lazy player's perspective, I like Tony's idea best.From a lazy programmer's perspective, David's is the easiest. So maybe we'll take a vote? |
|
Chandler Hill RJ: Chandler CO: Chandler Post Rating: 0 + / - Total Posts: 54 Karma: 113 Joined: Mar 25, 2012 |
Posted on Apr 7, 2012 David's in my opinion. Easy to code, and fair enough.
|
|
Josh Millard RJ: Tex Corman CO: J. Quaff Arabica Post Rating: 0 + / - Total Posts: 167 Karma: 231 Joined: Apr 3, 2012 |
Posted on Apr 7, 2012 (Last edited on Apr 7, 2012) David's solution is both clever and really, really brutal for folks who do very large runs but sometimes have emergencies. I can adjust and just be really sure about my run-length up front if that goes live, but yowza. 20% of the cash into a "I'm pretty sure I can run this for twenty four hours" lot in a big factory is serious cash. Even 20% of the total price on a small run is a nasty bite for smaller players not doing huge scale.Which isn't necessarily a bad thing. I kind of agree that as a real-world thing it's a fun wrinkle, because you don't just idly cancel a 100K production run without taking a penalty. But maybe scale the penalty to (a) the actual projected scale savings and/or (b) the percentage complete on the run at time of cancellation? So, like: (a) if you're going to to save all of 2% in cash on a smallish production run that barely scales up, you should be on the hook for a proportionally small deposit against that. Nobody should have to pay a 20% cancellation fee for a small lot run. (b) Proportional run ompletion as something like this: Deposit-Percentage * (1 - portion of run completed) So if you're on the hook for say 10% savings deposit against the run and you cancel the run halfway through, you're burning 10% * (1 - 0.5) = 5% savings deposit instead of the full 10%. If you're 90% through with the run when you cancel, you're burning 10 * (1 - 0.9) = 1% savings deposit. A nearly complete run should be less disruptive than one that is still far short of the goal. You could tack on a nominal additional firm cancellation fee if you wanted to just generally encourage better planning -- maybe 1% or 2% of cost as a flat additional fee no matter the size of the run. That's be enough to make sure people are taking at least a small loss on this stuff, without being egregious. |
|
Josh Millard RJ: Tex Corman CO: J. Quaff Arabica Post Rating: 0 + / - Total Posts: 167 Karma: 231 Joined: Apr 3, 2012 |
Posted on Apr 7, 2012 But at the risk of being a whiny realist, a lot of this is cool but jams up a bit against the current lack of any queuing function being live in the game. I play fast and loose with my factory run timelines sometimes because I don't know if I'll be back at the computer in two hours or six hours and I don't want a factory standing idle for a big stretch because I guessed wrong. So this system going in right now would punish players like me (which is probably most players) for covering for my inability to be at the game every hour of the day by doing longer-than-maybe-necessary factory runs that I might later interrupt and re-order as something else *IF* I have the time I wasn't sure I'd have. Once queuing is in place, something like this would be totally fair on a player's-sanity level because we could plan multi-stage production runs to keep real life time management sane and still have our factories working. At that point, the cost of wrong-sizing a factory run is totally on the player, as it should be. Because I am really liking the general idea. I just feel like it needs to be married to queue functionality going live or it'll just be a gimme to folks who can haunt the game all day every day and a blow against more time-strapped players. |
|
David MacIver RJ: DRMacIver CO: David R. MacIver Post Rating: 0 + / - Total Posts: 47 Karma: 56 Joined: Apr 5, 2012 |
Posted on Apr 7, 2012 For what it's worth, I'm in the same boat as Josh and would agree that it'd be preferable to have queuing in place first. I also like the idea of rather than it being a fixed percentage of the total it being a function of the amount you'd save on the run. Not 100% sure how that calculation would work in practice though as a lot of the savings on the run is in resources rather than cash. |
|
Josh Millard RJ: Tex Corman CO: J. Quaff Arabica Post Rating: 0 + / - Total Posts: 167 Karma: 231 Joined: Apr 3, 2012 |
Posted on Apr 7, 2012 The same calculation/tax could be applied to all consumables in the run, not just cash. So a non-refundable deposit on both the price in cash and in goods, proportional to each. Lose some money and a pile of flour, say. Ingredients that got stopped on the assembly line aren't getting scooped back into bins and reused.
|
|
D Patrick Michael RJ: Castun Post Rating: 0 + / - Total Posts: 41 Karma: 10 Joined: Apr 4, 2012 |
Posted on Apr 7, 2012 If he can work out the code to deduct the money & resources used to match runs of the production run when cancelled (so more goods are used up early in the run, same as if you did a smaller run in the first place) then I would go with that. Otherwise, some sort of flat rate penalty might be a quick fix until then, if so inclined.
|
|
Alexia Perdhaer RJ: Alexia Perdhaer Post Rating: 37 + / - Total Posts: 100 Karma: 30 Joined: Apr 6, 2012 |
Posted on Apr 8, 2012 (Last edited on Apr 8, 2012) Why not just have the counter always show the number of units you would have received if you had clicked cancel at the moment the counter was calculated?Rephrase: the number of units you would have received if you had batched for the length of time at which the counter is calculated. Maybe you meant that by option 1. In which case I vote for option 1, and am strongly against penalties unless there is queuing and/or a "grace" period. The game has plenty enough micromanagement without being penalized for thinking by doing. |
|
Kudaros Cornercutter RJ: Kudaros Post Rating: 0 + / - Total Posts: 17 Karma: 19 Joined: Mar 30, 2012 |
Posted on Apr 9, 2012 If queuing were in place then David's 'brutal solution' would be more acceptable. In any case, I agree with Alexia, and would like to avoid punishments for avoiding micromanaging, which could quickly get out of hand.
|
|
Derp Aderp RJ: Bertha Van Ation CO: Fancy McPants Post Rating: 0 + / - Total Posts: 22 Karma: -4 Joined: Apr 5, 2012 |
Posted on Apr 9, 2012 Planning for 10,000 units production and cancelling at 5,000 should update the cost as if you had started a 5,000 units batch, at least, if it's not already done. But yeah, paying up front a certain amount (10-20%) would be a good idea.
|
You need to register or login to post a reply.