A company asked me a small app for a job interview. The rules was about creating “foo”, “bar” and “foo-bar”, I’ve transformed it into “coffee”, “servers” and “app”.
The game is entirely in elm. I’ve used Tailwind for CSS and MaterialIcons for icons.
Also here I got 2nd dev at 0:32 while my best is 0:30 (but that is quite rare as it requires fast server mounting times in addition to 100% success for first apps).
Yeah what’s happening with the first dev really is sensible for the rest of the game. What would you think about making app creation 100% successfully when there only is 1 dev?
Currently there is 22% chance of getting no failures with first three apps, so making that 100% would be OK in my opinion. It’s already quite easy to just restart game until you get that success.
However making app creation 100% successful when there is only 1 dev, without app limit, could change optimal tactic. Currently you should recruit 2nd dev as soon as possible, but if that decreases success rate from 100% to 60%, then maybe you should stay with single dev a bit longer?
I still think this would be a good change, even though it might change optimal tactic a bit.
My idea was even more precise: 100% success for the first 3 apps (so you don’t have to refresh the page to have this). However, it will be a hassle to get it in the code in a “not-to-hacky” way .
add threeAppsCreated: Bool to LoadedModel, initially False
in updateLoaded / GotNewFrame, set threeAppsCreated to threeAppsCreated || (List.length newStock.apps + newStock.balance / 1000) >= 3 and pass threeAppsCreated to startDevAction as additional parameter.
in startDevAction use if success || not threeAppsCreated then
EDIT: Actually it seems to be a bit more complex, as newStock is updated using startDevAction …
I’d prefer to have a appsCreatedCount:Int in LoadedModel , it will be easier to detect if we already have created 3 apps (rather than checking the balance). But this way brings a lot of noise, forcing us to pass this data along the way…
I was thinking about splitting my LoadedModel in something like: LessThan3Apps Int LoadedModel | NormalGame LoadedModel
this way, we keep the current game logic for the NormalGame and we can set new rules for the LessThan3Apps.
I finally took your approach @malaire . The fact startDevAction updates the stock is not a big deal since this function can only “consume” resources, whereas updateTime only creates new resources.