there seems to be a mismatch between income and pricing/time.
I currently have 0.20 for baking, 0.19 for slicing and 0.18 for packaging with 92 per pizza. this should give 92/0.20 (baking is the bottleneck)=92*5=460/s, but i'm not getting more than 410/s (which is even less than 92/0.21=~438/s, so it can't be a visual rounding error)
This is probably due to small repercussion that happpens, like little lag spikes(maybe when saving) that causes "holes" in each the production.
But since the productions are in sequence the production hole is amplified at x3 in the end.
The effective production time is something like
PRODUCTION_TIME + 1/FRAMERATE
Best case is 0.1 + 0.016 = 0.116
@carlinda: if you are talking about the spell-level indicator in the object bar, that simply shows the spell-level required for the currently shown row. (rows 1 and 2 are spell-level 0 spells, row 3 is spell-level 1 spells, row 4 is spell-level 2 and row 5 is to be determined by the dev)
@cueballkev: there are games here on Kong that can update small portions of themselves without reloading (EG: Holyday City Reloaded updates its redemption-code every day) so it shouldn't be that hard (just give it the start-date of the event and the lack of content will trigger the "reload for upcoming event"), but I never said that it's a big issue.
minor issue: the game shows no indication of an event until it reloads with a version that has the event's content added, which can cause players to not be informed about said event until after it has finished already. (a "reload for upcoming event" message should suffice)
@filigree, that's a safety. the sellers need to make sure that enough is left for the dependencies as they don't necessarily start their cycles at the same time.
until recently the space bar served as an alternative to clicking on the production circle (allowing for slightly faster 'clicking' without cheating). now it serves as a shortcut to the videos/ads (which is seriously disruptive). could you please restore this to how it was?
While it may be too complicated for this game to give warnings about resources reaching zero, it could at least show resource-gain-differential (how much has resource-gain gained/lost since the last frame) to simplify estimations. and the resource boxes each have one quarter unused so you could easily put it there.
general tip: include version-based checksums in the save-data. This way the game can know when the save-data needs conversion (or even when it's unsalvageable).
Well, I have to admit the whole saversystem I made here is rubish anyways. To build in a checksum would be the way to go but a hazle with my current mess. Many things are stored as ints while the patients are stored as strings. And even worse, every single patient has his own save string.
suggestion: give the office-icon a number indicating how many investments can be chain-bought after claiming fee. some of the investments are relatively worthless and you're better of waiting for a chain to form. (EG: sometimes it's faster to wait until you can purchase three investments in a single go than to claim them one by one) Adding this number would reduce the need to constantly check the post-fee bank-account size.
suggestion: show a number indicating the number of sequentially buy-able investments/managers after claiming-fee on the office-icon. (some of the investments aren't worth purchasing on their own, and I now have to continuously check the office to see if a chain has formed that is worth the effort).
 "Idle Pizza Factory"){kind=icon}
 "Evil Gode"){kind=icon}
 "Crafting Idle Clicker"){kind=icon}
 "Idle Medieval"){kind=icon}
 "Idle Intelligence"){kind=icon}
 "Realm Revolutions"){kind=icon}
 "Idle Clinic"){kind=icon}
 "Idle accelerator"){kind=icon}
 "Holyday City Reloaded"){kind=icon}
 "Cividlization"){kind=icon}
 "Multi Miner"){kind=icon}
 "Prestige Idle"){kind=icon}
This is probably due to small repercussion that happpens, like little lag spikes(maybe when saving) that causes "holes" in each the production. But since the productions are in sequence the production hole is amplified at x3 in the end. The effective production time is something like PRODUCTION_TIME + 1/FRAMERATE Best case is 0.1 + 0.016 = 0.116