BMJ: Mining Simulator (pre-pre alpha)

[Professor James Moriarty]

 I buy as much btc as possible at the start of the game and so far never reached 2013 nor 2014 , but now I am on june 2013 and the price is 0.05 , it was a lot more than that , so I take it that price is irrelevant to real life prices? So how would we know when it will go up? Like real btc price its just a mystery?

[Kluge]

 I buy as much btc as possible at the start of the game and so far never reached 2013 nor 2014 , but now I am on june 2013 and the price is 0.05 , it was a lot more than that , so I take it that price is irrelevant to real life prices? So how would we know when it will go up? Like real btc price its just a mystery?

The game has "historical trend checkpoints" where it tries to emulate big run-ups (and down-falls) with regard both to price and difficulty, but this only influence their rate of change within certain periods of time - it doesn't try to "hard-set" difficulty or price based on historical outcome. I haven't added checkpoints after... I think it's February '12, so it defaults to slow growth after that. It's also influenced by the user's selected luck (eventually, luck will start moving a bit based on karma, but I haven't added any "karma events," yet) - difficulty increases more slowly with high luck, while prices increase more quickly with high luck - and high bad luck, of course, has the opposite effects. Before 001, I'll write up a quick Python script to simulate the simulation so I can figure out a range and median for where the price and difficulty tends to end up at certain points in time so I can adjust my formulas to be very, very roughly in line with history but still with large variance game-by-game... right now, the formulas for these are basically just gut instinct.

For instance, from what you say, I'm unsure if it's because the 2011 collapse numbers were too harsh or because the general trends have price and difficulty increasing too slowly, so the Python script's essential.

[Professor James Moriarty]

 Yeah not sure why I am complaining I have about 26 billion dollars from it ahahah , you haven't put asics yet right ? If asics come out I might buy all asics in the world and make a %51 attack possibility with 26 billion dollars ahahahah

[Kluge]

 Yeah not sure why I am complaining I have about 26 billion dollars from it ahahah , you haven't put asics yet right ? If asics come out I might buy all asics in the world and make a %51 attack possibility with 26 billion dollars ahahahah

Could be an interesting "bad ending." No ASICs, yet.

[Kluge]

Lending's turned out to be the most ambitious update to date. I'm getting closer, but it's taking a damn long time. In case I haven't lied about an ETA enough -- I definitely won't be pushing it today, but probably within a week. I mention gambling a few times in this.... it'll come out shortly after as I begin to add a more colorful interface to the rest of the game. By October, I'm hoping, since we're taking a trip around the East coast to visit family and go to Coins in the Kingdom from ~9/30 to ~10/15.

Lending - just the facts
*Loan requests are generated each seven days (starting at the date p2p lending is unlocked, January 16th, 2010).
*The lending screen is not a proper screen, but a pop-up screen, accessible by clicking the gold money icon on either the Main or Stats page. Opening it will pause time.
*There are three loan slots. You may not give out more than three loans, and each active loan will decrease the number of loans generated by one.
*Loans can be denominated in USD or BTC, and pay out USD and/or BTC. If BTC price < $.01, loan will only pay out BTC.
*The value of loans are determined largely by price, but also by luck (both "your luck" and the variables Good Luck and Bad Luck). When BTC price is low, people will want (in nominal values) more BTC and less USD. When BTC price is high, people will want less BTC and more USD.
*The rate listed for loans is over its listed duration.
*Lendees may default. You won't know until the end of the loan. You may lose everything or may be offered a settlement. If the settlement includes extending the term of the loan, they may and are more likely to (compared to the original default risk) default on that.
*Context provided in the generated backstory will help you determine whether or not the lendee's trustworthy. In a later update, a person may approach you to help you analyze default risk and provide "real expected value." Without this analyst, you can also guesstimate default risk by rate of return (high rate of return = high risk of default), but variance may well mislead you.
*At the end of a loan's term, you may have a "critical success." In this case, you may either be offered more than what was negotiated OR offered to renew the loan at slightly better rates. Chance of default decreases at each renewal UNLESS it's a long con, which you won't know. In a later update, the renewal system will be changed to be a more proper deposit program, similar to Pirate's and others'. When GLBSE is eventually added, you can effectively start your own deposit program.
*Some loans are "karma loans." You tie up your money and risk losing it in exchange for no interest, but only increased future luck. Karma, I should mention, would be more appropriately called reputation. Outside increasing good luck, a positive karma balance currently has no effect (this will change).


User debt:
If you should have a negative cash or BTC balance, you will be charged a base weekly rate of 5% interest on it (ouch!). This rate is heavily affected by your karma and your "financial credibility." Financial credibility is basically your default risk, determined by your karma and the amount you have out relative to the earning power of your hashpower. The hue of the lending icon will gradually shift from gold to red based on your financial credibility, becoming saturated when you've reached a "danger point," and with the icon eventually increasing in size once the game believes you're nearly guaranteed to default. Once fully saturated and red, it's possible the loan icon can grow to such size, the game becomes unplayable. The icon will not start growing until you've had a debt for at least month, though this could cause it to suddenly balloon up and ruin your game once that grace period ends. This is an intentional, very unsatisfying ending. The game will try to deduct interest payments from your cash balance, but if insufficient, it will add it to your debt and bump up your interest rate a small amount. A negative balance will not be reflected in the HUD stats (you should never have a <0 balance showing there). You are not allotted a proper line of credit -- you only take a loan if regular/maintenance costs should push your USD or BTC balance negative and are still not permitted to buy HW or (soon) gamble unless you have a positive cash balance. HOWEVER, a positive cash balance does not necessarily mean you have no debts, and you must manually repay any debts on the Lending screen. If you give a loan or (soon) gamble while you have an outstanding debt, your karma will decrease (buying HW is okay). However, if your icon's growing, gambling's probably the only straw you'll be able to grasp at with any chance of success.

ETA: I'm going to stop referring to karma as "karma." Instead, both in-game and in posts here, I'm going to refer to it as reputation, which makes more sense.

[Kluge]

There are now more events in the p2p lending script group alone than any other single sheet excluding it and contains multiple events multiple times larger in text than any other single event previously existing. As far as variable count goes, p2p lending has nearly as many new variables associated with it as the entire rest of the game. Everything associated with the lending pop-out generates, now (but the formula needs tweaking), so the buttons just have to commit all the generated stuff into a "loan bundle" and the events on when the loan's term expires need to be set up, still, and then all that's left is some minor "housekeeping" stuff and factoring loan gains/losses into the weekly I/O sheet. The user debt scheme should be relatively simple, so I'm still going to try fitting that into 0004 before releasing it.

Thinking about casinos more... provably fair casinos aren't really all that old. I think the game'll start with an unfair and largely unexplained casino - just enter in how much you want to bet, confirm, and then who really knows what the fuck happens... maybe you get 5x payout, maybe nothing, maybe you get a PPUSD code (Hell no, not a real one! )... others unlocked in time. Maybe a simple video poker game later, too.... or whatever you guys want that isn't brain-meltingly complex. ETA: Blackjack's simpler and played by more -- maybe that, instead.

[r3wt]

exchange logic broken. bought 22 million btc on day 1 for about 20 cents.

[Kluge]

exchange logic broken. bought 22 million btc on day 1 for about 20 cents.

Yeah. I'm still thinking on solution there. I don't want to try calculating how many BTC should exist, but do want to get some kind of slippage calculation in there to prevent that. Maybe each coin bought or sold simply increases or decreases price by X%... so buying a ton early becomes non-viable. It'd allow the user to manipulate the market, which isn't something I've thought through, so think I'll wait for one of the "1/4" updates -- maybe 000425, with casino in at 00045, backgrounds in at 000475, and less-ugly buttons and boxes for 0005.

ETA: Actually... that's a really simple fix ... only need a few events for it. I forgot I changed the BTC price change formula when I added the adoption trend checkpoints. I was worried if users could manipulate price to be "too high" early on, a BTC would cost $millions by 2011.

ETA2: Lolno, that's not a simple fix.... thinking on it more. Will have something in by 0004, though. Funny how some things are so much easier when users have to generate the data, and some things are much easier generating "their" data. If price increases .5% for each coin bought/sold... .... and that doesn't make any sense, anyway... You could take BTC to $0.  .... there were plenty of times Satoshi could've taken BTC to $0, though, so maybe it's a legit thing to do? Bleeehhhhh.

[r3wt]

exchange logic broken. bought 22 million btc on day 1 for about 20 cents.

Yeah. I'm still thinking on solution there. I don't want to try calculating how many BTC should exist, but do want to get some kind of time-based (and quantity-based) slippage calculation in there to prevent that. It'd allow the user to manipulate the market, which isn't something I've thought through, so think I'll wait for one of the "1/4" updates -- maybe 000425, with casino in at 00045, backgrounds in at 000475, and less-ugly buttons and boxes for 0005.

cool man, its definitely a neat project. you need anyhelp shoot me a pm

[Kluge]

ETA4: Lol... I could've just modified a common compound interest formula. I'm dumb sometimes... Problem solved.

Could someone help me with my math deficiencies?

I need a formula to determine how much a user should receive or spend when selling or buying BTC given BTC price will increase x% for each satoshi purchased, where the user specifies a quantity.

I'm thinking it's something like SatoshisPurchased*PricePerSatoshi^(1+PriceIncreasePctPerSatoshi*SatoshisPurchased).

ETA: Okay... 1BTC... 100,000,000 satoshis. Let's say price is $.00001/satoshi ($1000/BTC) and price increases .00000000005% per satoshi.

100,000,000*.00001^(1+.00000000005*100000000)=$944.06

Okay, so that's wrong.... 100,000,000*.00001^(1+(.00000000005*100000000)) = $1035.14

That looks right. Then to sell... 100,000,000*.00001^(1-(.00000000005*100000000))= $966.05

Price increase/decrease is too high, of course... ... done.  

So... okay - r3wt bought 22M BTC for ~$.20. So price was ~$.000000009/BTC. Under new scheme, it'd cost:
2,200,000,000,000,000*.00000000000000009 ^ (1 + (0.00000000000025 * 2,200,000,000,000,000)) = uhhh, a lot. So... success, I guess. Can tweak %increase/%decrease more... ETA2: -and Price*Qty needs to be made >1. Alright, all set now, I think.

ETA3: So.... wait - how do I figure out what price the final satoshi was purchased at? ((1+PricePerSatoshi)^(1+(PriceIncreasePctPerSatoshi*SatoshisPurchased))-1)? In the r3wt example, it looks like one satoshi would cost $550 after he buys 22M BTC, which seems right. Pretty sure I'm not keeping price > 1 correctly, either... do I need some kind of logic there? If price < 1 (or Price*QtySatoshis for original formula), then do that?

[Kluge]

Oh, FFS. -So I finally realized I should've just used the common compound interest formula, where principal is QtyBTC*BTCPrice and time is QtyBTC. Back to working on lending. Need a change of pace, soon. Will take a couple days off and not finish user debt system before pushing 0004.

ETA:
Calculates perfectly fine most weeks, and then sometimes:

-and I'm like... WUT?! (but now I've fixed the spacing issue, at least  )

ETA2: Ran into bug with Construct 2 which is preventing lending from functioning. Waiting for fix.

[Professor James Moriarty]

 You are working so hard on it , I just wish to see you make real amount of money out of this. I think this can make at least 10btc+

[Kluge]

 You are working so hard on it , I just wish to see you make real amount of money out of this. I think this can make at least 10btc+

Yeah, well there's a difference between working hard and working smart. I'm hoping it'll help me work smart if I want to try something similar in the future, because I'm really taking ~5-10x longer doing things than I should. Right now, everything's implemented, just not correctly - even found a workaround for the game-breaking bug from Construct 2 itself... just fixing my own mistakes, now. The lending screen looks so damn simple, but there's a crazy amount of stuff going on under the hood.

I don't understand the social misfit stereotype of developers, now. Their brains are clearly trained/pruned to function exceedingly well at saying exactly what they mean and planning out their statement to ensure there are no inconsistencies.... .... and that they don't get caught in loops or forget to destruct what they say, I guess. A lawyer/coder hybrid would have to be a flawless person, morality notwithstanding. I've had to script things in C before, and it clearly requires some type of mutant super-brain to write fluently in it. Python, I can understand, but C looks like it was written by God or something, with its mysterious ways and incomprehensible thoughts. If someone tells me they can speak a few different human-spoken languages, now, I'll probably my eyes. What I'm doing is a cake-walk in comparison, but I still struggle... would've been a great thing to start learning much sooner than later... I'm already near the end of my final major synaptic pruning stage (well, until dementia, I guess).

[Kluge]

0004 pushed, finally. It features a small handful of what was supposed to be released something like a week ago. What a disaster! Plenty to fix, now, so at least I'll have bite-size things to do for 000425. I don't want to look at this project for a couple days, though.

000425 squish list:
1) Exchange screen is terrible -- fix overflow-prevention. If better way found, apply to HWInv quantity box, too. What the Hell is "integer emulation," anyway? How can you not have integers? Probably other currently-unknown ways to game Exchange logic, too. Fixed, revamped screen (see OP). Variables will still reset if you switch from buy to sell or vice versa with a quantity set in cases where you don't have enough cash or coin.
2) There's frequently no indication whether a loan was repaid or defaulted on, while notification, when it is given, is too easy to miss. It seems to always be firing and I don't see anything wrong in the code... loan icon will now change color on loan repayment or default to try being more informative and visible.
3) Dice sound needs to be compressed. 266kb (+ more since it's re-encoded in two more formats for browser compatibility) for that is insane... I doubt anyone would ever play this expecting... 2128kbps or whatever... audio quality for the single SE in the entire game. I guess Construct removes the original uncompressed file automatically, so it's fine.
4) Adjust slippage formula... Fixed.
5) Effect of BTC price on loan amounts needs to be rewritten and should apply on a logarithmic scale, instead of now when BTC price increases to something like a penny, loan request amounts tend to be <100BTC. Fixed -- price effect lessened - is now more random. Also found and fixed an issue with some rolls where it'd pay nothing. ... And found another issue where USD payout wasn't being calculated correctly. ...... And another where BTC price would sometimes not be rounded correctly. Also removed BTC price restrictions on which loan offer types would commit in hopes I fixed the problem warranting that workaround.
6) Date&Time box is sometimes displaying [] instead of [0x], esp. after layout changes. Fixed.
7) Prevent time-flow while lending pop-out is popped out? I don't see why to restrict it. If the user wants time to flow, that's his choice. It still pauses upon first opening which is what was important. ETA: -But it may cause bugs if there're any events which pop up "inside the screen." The Fire event will likely become unclickable unless its components have a higher Z-level (which'd still possibly cause display issues). Needs to be fixed. ETA2: No, that's not a problem. Fire event no longer pops up inside screens but instead uses the "Events" screen.
8 ) Inconsistent to be able to click hashrate to get to HWInv page, but you can't click exchange rate to go to exchange. Maybe HWInv page should have its own clickable box to get to it, then.... or maybe the box approach is just clutter. Fixed. Clicking the BTC price box when exchange is unlocked will send user to Exchange screen.
9) Game is loading the "Updating" page & scripts twice. Tempted to leave it in... better safe than sorry. Looks like it stopped displaying update progress in %, though. "Fixed." %updated should now display. Game will also now spend less time waiting for handshake. It will now only wait 100ms instead of 1s before switching screens if it doesn't detect an update. It "should" wait for a handshake without my "explicit pause," but I don't fully trust the engine. If anyone experiences an issue where their game doesn't update to 000425 once it's out, please let me know! Game will still load Update screen twice when there is an update.

Planned feature additions:
1) User debt, karma loans, debt settlement.
2) "WGSE" (casino)
3) Color-coding of Weekly I/O page line items (tiled background?? Can't change CSS for parts of multi-line text box). Right now, it's inconsistent and confusing. Shelved. I can't get this to work right with the special boxes the I/O screen uses.
4) Tiny progress bars for loans in Main & Stats screen? Done. Has some minor cosmetic quirks I'm not going to bother with (bars start completely filled due to null variables, bars all reset to 0% for any day where a new loan was issued but corrects the next day). However, because the progress bar is not styled by the game, it's possible there will be more significant issues I need to resolve for people playing in non-Chrome browsers, in Win8 or non-Windows OSes. Please let me know if this is the case!

Unplanned feature additions:
*You can now pause and unpause (set to last speed) time flow by pressing your space bar. Only applicable in "Main" or "Stats" page.

Unplanned changes:
*BTC price will now have a 1.15x multiplier added to "Adoption Trend." This simply means the price of BTC will increase faster and be more significantly affected by changes in the "Adoption Trend" variable.
*Initial difficulty reduced from 5 to 2.5. Difficulty will have a .9x multiplier added to "Adoption Trend," slowing its rise and decreasing the effect of "Adoption Trend" changes while also making it more likely to decrease. Tweaked difficulty to massively reduce the effect of "raw time" on difficulty so it's a) more viable to mine, and b) more reliant on "Adoption Trend" and less extreme exponential additions.
*Attributions button added to Options screen. It launches to a basic html with exactly the same info as what's in the resource attributions list of the OP to better ensure I'm not violating OFL & CC.BY licenses.
*BTC price starts out 100x higher than originally (now $.00001/BTC) to help compensate for USD loan payout initially struggling to pay out even $.10.
*Slippage is now a bit more significant, but still less than in 0004.

Unplanned fixes:
*Special "newb-detection" variable which has the increasingly useless/outdated welcome info will now automatically declare a user not a newb after six in-game days instead of relying on them to buy hardware which caused display issues if it was still up after lending was unlocked.
*Stats page wasn't displaying "F u l f i l l" in lending pop-out.
*Lending pop-out was saving "Speed" as a number instead of string, leading to minor screw-ups, esp. with pause/unpause feature.

Bugs introduced (but I'm too lazy to fix for next release):
{Cosmetic} Text boxes look particularly ugly on revamped Exchange screen. Maybe it's finally coming time to replace them? -Or a workaround solution by changing additive display property...?
{Cosmetic} Images in the WGSE screen need some TLC to blend it together better. As-is, I just used a feathered square selection and tweaked curves to try lessening how obvious the cutting and pasting was, but the cuts are still far too rigid without a large-enough semi-transparent bordering.
{Gameplay} Pause/unpause variables occasionally become confused. SpeedCarryover is possibly not being set appropriately on all game-caused pause events.

*Co-location will remain disabled until 00045. Will restrict electricity usage at Mom's House then, too. Ideally/realistically, someone could keep rigs at their mom's house along with other locations so they can always put some at mom's house without electricity cost liability, but this'd be a bear to code. Game should also quietly track debt to Mom and randomly present good opportunities to pay her back (maybe she loses her job or something) and wipe the karma/reputation debt.

[Kluge]

Have 1/4 of family migrating down South for Winter, other 1/4 sold house and need help moving (and w/garage sale), 1/4 encountered some water damage and need help putting in a replacement door and subflooring, and final 1/4 just came in from Virginia for a visit. I won't have much free time until after driving all the way back up from Florida after Coins in the Kingdom event. If there's a critical bug (worse than how little the loan amounts are as BTC price rises), I should be able to fix it some time before the end of the month if alerted to it. Otherwise - see y'all again in early-mid October.

[Kluge]

Casino will eventually have a total of 4 games. Three are single-player, one is multi-player.

First game is WGSE and unlocks 14 days after p2p lending is unlocked. You bet 1-1000 BTC and simply click "confirm." You can receive 0x-50x payout + $0-1000 in cash. The service can semi-randomly be "hacked." The larger its losses (based on USD value of winnings), the more likely it is for the operator to disappear. Luck affects "hack" chance, while reputation ("karma") will impact whether you win or lose. House edge will be somewhere around 5-15% excluding hacks. This'll be released in 000425.

Second game is blackjack, unlocking two months after p2p lending is unlocked, with "basic" rules (can double-down, no insurance or splits, dealer with 21 doesn't immediately end game), but card generation is unfair and favors the house. Reputation ("karma") also has a minor impact. House edge will be somewhere around 2-10% given a sane player. Bet amount is 1-100BTC. This'll be released in 0005-0006.

Third game is yet to be determined (maybe some kind of "physical" mining game similar to Dig Dug), but will be original and skill-based, EV+ given a skilled player but should "average" to be roughly EV neutral. Bet amount will be static... unsure at what amount. This'll be released with 001.

Fourth game is competitive + co-op multiplayer "original." You'll start out with a Spades-similar game. If #tricks claimed <= #tricks taken, you'll receive cards to hold in a Hold'Em-similar game in an amount equal to the number of tricks you claimed. Winner of the Hold'Em-similar round goes on to play physics-based Plinko-similar. Losers have the totally-not-humiliating option of blowing on the puck. Where puck lands determines multiplier of pot taken by winner as well as whether or not losers will receive a % of their lost stake. This is significantly EV+ for sane users, but I probably won't have this ready for alpha (001) in ~4-6 months. Buy-in will be set static at something high... unsure of amount.


At some point in the far future, a "provably fair" game may be introduced.

ETA: I'm not sure why you'd want to, but you can visit the site using https now. It's self-signed so you'll get the "blah blah blah, a centralized authority didn't bless this" warning. Certificate's also controlled by web host, so you should assume they could decrypt whatever, too. Everything's stored in the server covered by self-signed cert except for fonts, which are loaded on-demand from Google's font API via insecure connection, so the government may know which fonts you're requesting. If you're worried about that, the game should still be playable offline, so if you'd like, you can download a copy to play while forcing no http (so insecure content - fonts - won't be requested) and fonts will default to something like Ariel and probably look wrong. -Or just quit being so god-damned paranoid.

[ruins]

 Not that I know anything about game making but my 2 cents would be ;

 Focus on finishing the game with basic stuff without any features and all , just make a game that will go on for a long time without chrashing etc etc so people can start playing.

 After all of that , add features to the game , that way people will start playing the game and won't have to wait but you would still implement new stuff and people can check them if they feel like the feature worth starting over

quite reasonable, bro
good thinking!

[Kluge]

Back from Florida. Went through ~50% of 000425 squish list today -- fixed a lot of bugs with lending and completed the new exchange screen. Should have rest of it fixed tomorrow. Then it needs to be tested and re-fixed the next day.

WGSE should only take a day to implement correctly. Additional loan feature additions will take 2-3 days only because the list of events for it is terribly long and complicated; hard for me to follow and comprehend. Color-coding I/O page and adding progress bar for loans should take a day... so 000425 "should be" ready for release in 7-8 days.... so it'll probably be released in 10-25 days.

[busterroni]

Back from Florida. Went through ~50% of 000425 squish list today -- fixed a lot of bugs with lending and completed the new exchange screen. Should have rest of it fixed tomorrow. Then it needs to be tested and re-fixed the next day.

WGSE should only take a day to implement correctly. Additional loan feature additions will take 2-3 days only because the list of events for it is terribly long and complicated; hard for me to follow and comprehend. Color-coding I/O page and adding progress bar for loans should take a day... so 000425 "should be" ready for release in 7-8 days.... so it'll probably be released in 10-25 days.

Awesome ^.^

[Kluge]

*You can now pause and unpause (set to last speed) time flow by pressing your space bar. Only applicable in "Main" or "Stats" page.

Doesn't that sound trivial?

It took me about two hours to figure out how to write this. I tried "gut feeling" for a good while, testing and realizing I messed up. Then, I tried writing down my logic in Notepad. Over and over and over, simulating the results and still messing up because my timing was off.

Finally, I settled on:
"IF
   Speed = 0x
      Set tempspeedcarryover to speedcarryover

IF
   Speed =/= 0x
      Set speedcarryover to speed
      Set tempspeedcarryover to 0x

IF
   Speed = 0x
      Set speedcarryover to 0x

ALWAYS
      Set speed to tempspeedcarryover"

Here's my "simulation" of it:
User has 0x speed. User has 4x speedcarryover.
   Tempspeedcarryover set to speedcarryover (4x).
   Speedcarryover set to 0x.
   Speed set to tempspeedcarryover (4x).
Next instance.
   Speedcarryover set to speed (4x).
   Tempspeedcarryover set to 0x.
   Speed set to tempspeedcarryover (0x).
Next instance.
   Tempspeedcarryover set to speedcarryover (4x).
   Speedcarryover set to 0x.
   Speed set to tempspeedcarryover (4x)
Next instance.
   Speedcarryover set to speed (4x).
   Tempspeedcarryover set to 0x.
   Speed set to tempspeedcarryover (0x).


That was great! I finally figured it out. -But Construct doesn't accept my goofy brain syntax. -So I started trying to figure out this elaborate way of checking things with 5 or so events, then an event with sub-events, and every time, it failed after the first time-flow change.

In the end, two hours of chain-smoking and brow-furrowing gave the final product: