I’ve noticed that the machines that take 2 days to run make the income kind of tricky to follow sometimes. To fix this I would suggest having those machines perform a half cycle draw of funds (the pill machines running at $10/half cycle instead of $20/cycle for example). This would smooth out income and help provide a more intuitive user interface.
So you want all processing cost values to impact your daily balance evenly while in use rather than just lumping it all when it the process starts. Sounds reasonable to me, assuming this is what you meant. The only real issue this could cause is with how rounding is handled. For example, you have a chromatograph running with it’s processing cost at $55 and a speed of three. That’s 18.3 repeating. Does this mean you round down to $18, saving a dollar; or round up to $19 and lose two dollars?
The only solution I can see would mean coding in something like 18.5 for the first two cycles of it’s three cycle process then 18 for the third… thus a to much work for the coders.
Short Hand, manually program in the cost per cycle in a multi-step process.
Which then makes me think about how I’d solve that problem, and realize It take longer then I have to post.
Yes, that is what I mean.
Honestly I’m not sure. My gut reaction is to either always round up or always use the version with the least delta to the original. The game is still in beta, so it’s still being balanced as well, so changing the total running cost of the machines is likely going to happen anyways.
The answer isn’t to try to use decimals, the answer is to adjust the running cost of the machine to something even divisible by the number of cycles. That circumvents the entire discussion about partial dollars and is what Christian was talking about with rounding.
That doesn’t work. When you upgrade machines with research points the cost drops by integer values that will screw up any division by two or three.
Hmmm. Perhaps an adjustment of that system as well? Idk, would certainly require more thought to go into it. Perhaps a simpler solution is display some sort of calculated per day estimate instead of an instantaneous income. It would have the same effect that I’m looking for of a good, consistent estimation of my income.
Hmmm. Maybe the daily value shown could actually just not show you the decimal, but it’s there.
Why do you even care about the daily upkeep? The only value that matters is profit per pill.
I base my expansion decisions on how much per day profit I’m getting contrasted with my guesstimation of how much lump sum and per day the expansion will cost. As well as how much wiggle room I have and how much cash reserve I have for the month or so that I’m no longer going to be making money.
It can be done even easier than that guys…the daily profit should be done on a moving average value (because it is only an estimate anyway). A simple 4 or 7 day move should be enough to make it so that it doesn’t jump around so much.
To the programmers (as my descriptive skills are lacking when it comes to math), this is done as follows:
W = wallet (actual cash shown to the player)
P = daily tick profit (before the tick starts, P is reset to 0, each machine/import will lower this amount and each export will raise it)
D = daily average
At the end of the daily tick:
D = ( 3 * D + P ) / 4
or
D = ( 6 * D + P ) / 7
Depending on 4 or 7 day moving average. Let’s pretend we are doing a 4 day average with a $32 import, $20 line, 1 pill machine at $20 and $101 export, the numbers would go like this:
0, -8, -19, -32, -37, -20, -3, 5, 16, 19, 26, 26, 31, 30, 34, 32, 36…etc.
(First pill produced at -32, first one sold at -20)
In fact, if you were so inclined, you could actually allow the players a “slush wallet” where the number rises and falls based on this moving average value, determined by “behind-the-scenes” actual money dispersion. This would make the money more uniform rather than bouncing up and down as things get paid and income comes in.