Topic: BMJ: Mining Simulator (pre-pre alpha) (Read 9630 times)

I've decided to shelve this project altogether. It's clear to me that I belong with the modding community, not here (and Rimworld's caught my interest). I don't have anywhere near the time this needs, which is disappointing because I'm not terribly satisfied just altering someone else's narrative.

I might push out a quick update fixing the lending and block generation formulas some day... still need to figure out the right way to determine future difficulty, though.

Heh. That's actually from the text overflowing the box. It comes from the game trying to create "substantial" (in USD value) BTC loans. My thinking was that it'd be ridiculous for someone to ask for a $.02 loan in BTC. When BTC price is very low, it takes so much BTC to be "substantial," it takes up more space than it's allowed and displays blank.

Wait a couple weeks for the loan offers to reset. Might need to wait four weeks. It needs a higher BTC price. I'm not sure how to solve this outside either checking for BTC price and disallowing BTC-denominated loans if price is too low, or just pushing out the date p2p lending's unlocked. Then again, I haven't even simulated the formula for how it'd look mid-game and late-game (I changed the formula around in 00043 to require loans be more substantial).... so'll need to check and might just come up with a new formula altogether which maybe solves both problems (early loans needing way too much BTC, late loans being relatively insubstantial in amount).

I start a new game...and this bug occur!

I've been having a Hell of time with the block generation rewrite. I remembered what I forgot... Part of the trouble is just staying focused enough to get my mind wrapped around all this, the second will be worrying about how much processor power this will take.

Here's what I'm thinking the difficulty & block generation formulas should look like:

//determine #blocks network "should" generate
NetworkHashPerHour=NetworkHashrate*60*60
UserHashPerHour=UserHashrate*60*60
PctChanceHashSolvesBlock=1/(CurrentDifficulty*4295032833)
//Thank God for Pieter.
PctChanceNetworkSolvesBlock=NetworkHashPerHour/PctChanceHashSolvesBlock

//determine #blocks network "does" generate
//"25" is arbitrary, meant to be a balance between being an okay estimate without over-straining PC by rolling too often (if more than 25 blocks have ever been generated in a single hour, lemme know and I'll adjust this)
If random(1.00,100.00) > (100*PctChanceNetworkSolvesBlock)/25, then add 1 to NetworkBlocksSolvedLastHour, add 1 to BlocksGenerated
^do 25 times
//PctChance is ~24% each roll (.24*25=6) if NetworkHashrate and CurrentDifficulty were perfectly aligned
//BlocksGenerated tracks... blocks generated since the last difficulty reset.

//determine #blocks user generated of those
PctChanceUserSolvesBlock=UserHashRate/NetworkHashrate
If UserBlocksSolvedLastHour < NetworkBlocksSolvedLastHour AND random(1.00,100.00) > (100*PctChanceUserSolvesBlock)/25, then add 1 to UserBlocksSolvedLastHour, add 1 to BlocksGenerated
^do 25 times

//determine future difficulty
//RawHour tracks how many hours have passed since the start of the game
When NetworkBlocksSolvedLastHour > 2015, set CurrentDifficulty to LastDifficulty*((336/(RawHour-RawHourLastReset))+1)
//Definitely not right...


Need to double-check to make sure pool formulas are right as-is.

[WIP!] New workflow schedule. One of these formats will stick, eventually. Seem to work most efficiently when I separate the thinking and doing of writing process.

Focus of 00045-0006 is to give users more options to affect the environment. Right now, a lot of things just "happen" to them; it's more EvP (and EvE) than PvE, which I don't think is accurate for the early adopter the game has the user playing, especially with the change to price calculations made lately. The user should be drowning in cash and given plenty of opportunities to see their dreams crumble by their own hand.

00045 (Q1 2015)
000475 (Q1 or Q2 2015)
0005 (pre-alpha!) (Q2-Q4 2015)
000525 (Q3 or Q4 2015)
00055 (Q4 2015 or Q1-2 2016)
000575 (Q1-3 2016)
0006 ()
*Feature Creep* projects will be completed "whenever"


Personal finance mechanics
Minor feature: rewrite lending formula to always require a substantial value of BTC or demand USD instead of BTC (self-explanatory).

Major feature: User debt (user can go in debt, as indicated on the lending screen)
Components

• Negative USD & BTC balances must be zeroed and added to new, positive debt-tracking variables
• Debt balances must accrue interest on the start of each month
• Debt must cause the p2p lending icon to expand and morph.
• Too much debt results in a non-explicit game-lose scenario (the debt icon has taken up too much space for the user to be able to play effectively), with the exchange rate box being one of the last to be covered
• Merge p2p Lending screen into Offers/Communication screen
• Disallow BTC debt from automatically being taken
• User BTC debt must be negotiated each time via BTCTalk and is not guaranteed

Offers/Communications mechanics
Major feature: Bitcointalk (speculation, used mining hardware)
Components

• Copy BTCTalk elements to recreate forum style
• Create dictionary pool of speculation thread components (threads are procedurally generated)
• Create "SignalToNoise" variable, 0-100, starting at 20 and moving slightly and randomly each time tick (luck is a factor)
• Game factors in SignalToNoise, AdoptionTrend, and TOTHEMOON variables to create threads out of thread components
• Generate used CPU & GPU hardware offers by combining "new" price, a 15% "off the lot" discount, and further discount factoring in HW age.
• Generate used ASIC offers solely by their value in mining.

Major feature: GLBSE
Components

• Try to recreate look of GLBSE 1.0 from memory (uhh, without the PGP)
• Create dictionary of GLBSE business components ("ad libs")
• Piece together to generate needed variables to form businesses the user can invest in
• Pirate offers a way to invest with less clicks....
• User can start their own business (they roll the ad libs until they find a business plan appropriately amusing)
• User fills out personality survey to guide business (there are no right or wrong answers, just answers with good or bad consequences) and goes to event window for major decisions
• Really need to figure out JS chart generation

Game economy mechanics
Minor feature: "Post-tx slippage" (transactions have both an immediate effect on the price, but can also weaken or even reverse current trends, but which are "corrected" further down the road)
Components:

• User transactions on the exchange will trigger short-term changes in the "TOTHEMOON" variables. (AdoptionTrend unaffected)
• Game will guesstimate the effects of "post-tx slippage."
• AdoptionTrend checkpoints will include a new variable marking whether or not it is so large that the change is unstoppable
• "Unstoppable" trend changes will also attempt to correct any user-created market manipulation (intentional or otherwise) using the guesstimated "post-tx slippage" effects and multiplying the "TOTHEMOON" variables appropriately.

Mining mechanics
Minor feature: Time-unlocked GPU releases
Components

• Release new GPU models using historical time-frame
• Decrease price of "old" GPUs each time a new GPU model is released (decrease MV of relevant current user equipment by %)

Minor feature: Rewrite block generation events
Components

• Block generation checks need to roll 6 times with 1/6 %chance each roll
• Try to remember why this won't fix the problem and re-fix it (dammit)
• Apply fix to every single time-tick event both in Stats & Main, fix weekly mining income formulas to account for change

Minor feature: Co-location
Components

• Add variable tracking whether or not co-location's enabled
• Duplicate existing time-based events (yep... all of them, including duplicating the duplicates checking whether or not the user uses a pool... and then do the same thing for all of "Stats'" unique time-tick formulas ), originals having the condition that co-location not enabled, new ones with condition that it is
• Determine formula adjustments needed and apply to the duplicated time-tick events

Minor feature: Convert fire event to use HW age instead of being random
Components

• Track amount of time between date of HW purchase and "now" (use "RawDay" variable)
• Create %chance of fire event by looking at per-slot HWAge variable each time tick

Minor feature: User contribution to global hashrate (no explanation needed)



Major feature: FPGA & ASIC introduction
Components

• Create separate drop-down in HWInv for FPGAs & ASICs when unlocked
• New FPGAs and ASICs come with a lead time of 2 weeks to infinite
• FPGAs and ASICs are sold by brand and version number -- each time a new version comes out, the third-last-released version goes out of production
• Users are permitted five new hardware cluster slots specifically for ASICs and FPGAs. If all slots are filled, old FPGA/ASIC hardware must be sold before more can be ordered.
• Pre-production ASIC/FPGA "place in line MV" is determined by lead time estimated remaining and consumer confidence.
• Post-production ASIC/FPGA MV is NOT affected by age, only by their value in mining.
• Places in line can be purchased on Bitcointalk and sold on the HWInv page ("bail")

Casino mechanics


UI
Minor feature: Convert casino to tabbed window (no explanation necessary)

Major feature: Communications/Offers menu
Components

• Create horizontally-tabbed window with slots for Bitcointalk, GLBSE, personal businesses, email/Skype, IRC, and p2p lending

*Feature Creep* UI Overhaul ("Main," "Stats," "HWInv," "Exchange," "Options," "Land")


Other
*Feature Creep* Procedurally generated music (music mood influenced by game events, maintaining a stable beat throughout and transitioning seamlessly)
Components

• Create a beat using time-ticks
• hard-limit game ticks/second to something a weak PC can maintain (PCs outside specs advised to disable music )
• Fill out time between ticks using samples (each sample is its own file, pitch adjusted by the game's audio engine if reasonable, otherwise full "ticks" made in FL) made for the default 1x speed but which sound alright at 400% tempo increase
• User can change out instruments used (money sink!)
• User can purchase additional melodies, bridges, etc (money sink!!)

Squish list:
1) *Feature Creep* There's an audible "pop" between sound transitions (audio or audio engine??).
2) Wk I/O page's lending income is.... not right.
3) I broke mining income calculation somehow. ETA: If personal hashrate significantly exceeds 1/6 of global hashrate (as determined by difficulty), you will always mine 1/6 of all available blocks per day. This is partly due to user hashrate not being accounted in global hashrate and also due to a longstanding issue where users cannot mine more than one block per hour (there should be six rolls taking place, not one). ETA2: This bug requires a complete re-write of the block generation code to be fixed. Need more time.

00043 pushed. Introduces >10 new bug fixes, a fluctuating global energy market, usage-based electricity cost discounts, ability to re-wire office for 220V outlets, and a new noise pass applied directly to the AdoptionTrend variable.

000425a pushed. This is somewhere between a hotfix and a minor release. >15 unique bugs fixed with a major re-write of the BTCPrice formula (it now takes four separate variables into account, has three random rolls, and seven sets of parentheses). Game's quickly approaching 2mb in uncompressed size!

There are still some major bugs lurking. Loans aren't re-rolling when they're supposed to, there's something very wrong with how the game's calculating mining income again, and half the weekly I/O screen is miscalculating what it's claiming to show. Wanted to get through those today (well, two days ago), but fixing the price formula took up more time than expected. Will call the next release 00043.

I wasn't able to test out BTC price formula much after 6/30/11, so all checkpoints after are guesstimates, and I have no idea what'll happen once the game goes off the rails on 7/2/14. Lemme know what happens. Important checkpoints to look at price are 4/29/11, 6/29/11, 7/27/11, 11/14/11, 1/6/12, 3/6/12, 6/6/12, 12/6/12, 1/30/13, 4/8/13, 5/1/13, 6/25/13, 7/5/13, 7/19/13, 10/5/13, 11/8/13, 12/16/13, 1/4/14, 2/3/14, 2/23/14, 3/2/14, 4/9/14, 5/17/14, and 7/1/14. If you use the exchange, your stats'll be useless to me.


ETA: In case anyone wonders how the weekly I/O screen could be so fucked... this is what the USD text box looks like on my side:
"Week's USD income from difficulty and events: $" & WeeklyBaseUSDAccumulation & newline & "USD sold at exchange: $" & WeeklyUSDOutgoExchange & newline  & "USD bought at exchange: $" & WeeklyUSDIncomeExchange & newline & "Lending profit: $" & (round(WeeklyUSDLendingIncome*100)/100) & newline & "Electricity costs accrued: $" & WeeklyUSDElectricityCost & newline  & "This week's share of office lease costs (estimate): $" & round(((OfficeSize-10)*OfficeSpaceCost)*(7/30.4)) & newline & "Hardware depreciation: $" & (round(WeeklyMV*100)/100) & newline & "Gambling profits: $" & (round(WeeklyCasinoUSDGains*100)/100) & newline & newline & "Total USD gain/loss for week: $" &  (WeeklyBaseUSDAccumulation-(round(WeeklyMV*100)/100)+(round(WeeklyUSDLendingIncome*100)/100)-(round(((OfficeSize-10)*OfficeSpaceCost)*(7/30.4)))-WeeklyUSDElectricityCost-WeeklyUSDOutgoExchange+WeeklyUSDIncomeExchange+(round(WeeklyCasinoUSDGains*100)/100)) & newline & newline & "Don't forget -- electricity and your office aren't billed for until the end of the month!"

Most of those variables have their own long formula on a separate sheet I have to hunt down, some referencing >10 other variables all which have their own formula, and which may reference even more variables.

Lol... I was scratching my head trying to figure out why the recovery would've failed to materialize. I must've lost all the checkpoints from late 2011 to 2014 at some point when I was having trouble with backups not saving properly. Found a boat-load of other new bugs... hotfix might take until some time tomorrow to release. ETA: This project save was also apparently at a time when I didn't have the checkpoint logic saved in a group and carried it over to the Stats page, so if someone were on the Stats page, difficulty and price will calculate very differently.

I've settled on the "killer feature" which'll bring BMJ out of pre-pre alpha and into pre-alpha. It'll introduce a faux email client which takes in all private offers from sources like Skype, IRC, and bitcointalk (... and email, obviously). This is where all the long-term offers will eventually come, along with used hardware offers. This'll come with a faux Google Docs browser which'll allow you to monitor long-term offers as well as withdraw, deposit, and determine whether or not you re-invest dividends. In case of a default, you can choose how you want to try resolving the issue (publicly call it a scam, file a police report, send a demand letter, or kiss ass and pray - all options with %success chance modified in different ways by variables tracking the user's standing in the community).

I might merge this all into what's now the lending pop-out, so it becomes a tabbed pop-out with all investment opportunities, preventing too much screen clutter. This'll come with the introduction of a new casino game and a switch from the current casino display method ("dumbass rectangles") to a tabbed format, too. Alpha will probably then come with the introduction of the websocket and multiplayer features (haven't determined where multiplayer elements would be useful outside the casino).

In lieu of a proper Android/iOS release (there are still some elements in the game I haven't figured out how to convert from click to touch since the game treats touch like the player's using an auto-clicker), it's possible the multiplayer casino could simply be copy-pasted and use all touch commands, so a user could now play, say, multiplayer poker on their phone and have it contribute to their cache of coins and cash on their BMJ game. I don't have the resources to even try handling anti-cheat properly, so instead, it'll use hash functions locally in BMJ and the phone casino. The games will locally verify enough funds exist to generate the hash code which also includes the user's declared name. Names between BMJ and the mobile casino must be identical. I'll need help setting this up when the time comes, but it prevents people from "accidentally" cheating, at least, or just simply pasting the same deposit codes over and over and over.... this is something like a year out, though. Sounds like too much a PitA to be hand-copying hashes from phone to the full BMJ client, though (would be pretty pathetic if it's easier to cheat than deposit legitimately-earned cash & coin)... there are options here... will think about them more at the proper time.

Hotfix'll be out tonight. Almost through the squish list.

That is perfect! I spit out my drink because I was laughing so hard.

A loan recently came due and went unpaid. The lendee has come to you asking for a $2M investment in a music festival, promising to repay $3M by selling bottles of water while offering the shadow of his soul as collateral. Loan $2M?

ETA: Actually... that could be fun. The lendee tells you the music festival will occur in four months.

... eight months later ...

The lendee has directed you to "dank's virtual music festival [YEAR]." Visit?

-So this crude page pops up with a horrible trumpet MIDI file playing. "Thanks for visiting." -And then it's never mentioned again.

Please add a dank scenario.

Thanks!

I expect 00045 to be released in late January or early February, so a reasonable person should expect a release in late March or early April. Possible a hotfix will be released in a couple days.

000425a (released)
00043 (released)
00045 (unreleased, ETA 1/??/14-4/??/14)
shelved until later release

000425a-00045 feature list
1) Finally re-enable co-location.
2) Implement user debt and the user debt lose scenario
3) Add more loan outcomes other than default or being repaid in full
4) Add more WGSE payout options
5) Implement procedurally generated music (000475)
6) Add more news events, some which are educational/cosmetic, some which impact the user and may provide agency
7) Investment option for casinos, more business opportunities, special moral dilemmas in business operations (000475-0005)
Karma (will wait until the character creation system's rolled out)
9) Add more weight to non-historical crash and rally generation Done (also affects difficulty).
10) Tweak historical trends to better-replicate what happened, add new noise passes to price generation. Done-ish.
11) User can cause rallies and crashes by "threatening the market" ("post-tx slippage")
12) Historical difficulty checkpoints (it currently uses the AdoptionTrend variable [which is, appropriately, set for BTC Price, but is not fine-tuned in the difficulty formula] and then separated calculations factoring in time and luck) with separated calculations for time, possibly affected by user hashpower.
13) Fluctuating global energy market. Done (simple).
14) Quantity-based electricity prices. Done. (for each 10kW of power draw [rounded], electricity costs drop 1%, up to a 25% discount)
15) Global energy trends affect difficulty. (alt energy?)
16) Ability to re-wire office for 220V outlets. Done. (m³*$100 for 3.5% power efficiency increase, does not carry over if you switch office)
16) Re-write block finding & difficulty formulas to allow multiple block findings per hour and user hashrate affecting global network difficulty. (bug 27)

000425a-00045 squish list
1) Fix the WGSE logo not displaying Fixed.
2) Increase or perfect reliability of using space bar to pause and unpause time "Fixed." Chrome (likely most browsers) was disallowing JS to "see" the space bar keystroke when a clickable element was selected or previously selected (in a non-highlighted state). There doesn't appear to be a way to correct this behavior, so instead, I assigned the same function to clicking the middle mouse button (scroll wheel). Knowing not all people have a middle mouse button, the space bar is still an available option, keeping in mind it's unreliable. ETA: Casino & Lending screens will disrupt the speedcarryover variable if speed is at 0x when you click them. Also fixed.
3) Add ability to open and close casino in stats screen Fixed.
4) Force loan progress bars at zero if no loan is in progress Fixed. Issue was from copy-pasting formulas in determining whether or not to update the progress bar and only using the first loan slot's data.
5) Fix issue where users can't click the exchange rate box to get to the exchange screen Fixed.
6) Redraw the "Clear" button on the exchange screen (it's relatively blurry and slightly off-center!) Fixed.
7) Look into why BTC price & adoption trend formulas are resulting in very low, consistent BTC prices rather than high volatility Fixed!
Display appropriate warnings when a user is adding to Cluster 1 when the slot already contains hardware Fixed. (can finally stop including that in "Known Issues" for releases!)
9) Confirm Loan 3 button not working properly. Fixed.
10) Lending pop-out's "Repay" button off-center. Fixed.
11) Attributions page needs to be updated. Fixed.
12) Casino roll music is too loud. Fixed.
13) "Back" button in Stats screen is mis-handled with pop-out displays. Fixed.
14) Casino music really ought to stop when the bet button's pressed again. ETA: Actually, the "confirm" button should just be disabled until a run's finished. Fixed.
15) There's an audible "pop" between sound transitions (audio or audio engine??). (000475, holding up feature 5)
16) Casino roll alert texts should change color based on whether it's a win or lose notification. Fixed.
17) Loans are not re-rolling upon detection of expiry. Probably fixed. Needs testing. Changing lending code always intimidating...
18) Wk I/O page's lending income is.... not right. ETA: Unable to determine cause... need to look at it with fresh eyes later.
19) "Guy sounds like a cool guy" is embarrassing. "Fixed." The static phrasing is awkward.
20) Loan progress bars should be made invisible on Exchange (visible on layout exit). Fixed.
21) Loan slot 2 isn't re-rolling every two weeks. Fixed.
22) Hardware depreciation calculation in Wk I/O is not setting its variables which track cluster value at the last two week period correctly (and check HWInv page to ensure it's also resetting that when the cluster's sold). Possibly fixed... needs testing.
23) Price affects loan amount too negatively during the first major rally. Fixed? Needs testing.
24) Any rig with more than 2 GPUs should be assumed to need an external case and thus require both more space and more money. Fixed & added alert.
25) Slippage is still a bit too extreme. Slippage effect decreased by an order of magnitude.
26) Hardware should depreciate ~10-25% immediately after it's purchased. Fixed. (15%)
27) I broke mining income calculation somehow. ETA: If personal hashrate significantly exceeds 1/6 of global hashrate (as determined by difficulty), you will always mine 1/6 of all available blocks per day. This is partly due to user hashrate not being accounted in global hashrate and also due to a longstanding issue where users cannot mine more than one block per hour (there should be six rolls taking place, not one). ETA2: This bug requires a complete re-write of the block generation code to be fixed. Need more time. ETA3: Workaround is to use a pool to mine, which is not limited this same way... though I'm not sure whether or not I prevented the game from generating >100% of the block reward if you should have more hashpower than the network (in next update, user hashpower contributes to network hashrate).
28) BTC price & difficulty displays should quit rounding to decimal places when they're no longer useful. "Fixed." Difficulty display drops decimal places once diff>1k. Bitcoin price will now always only measure down to the thousandths rather than ten-thousandths place.
29) HWInv page isn't zeroing out volume consumption impact of cases on layout start. Fixed.

bmgtg.cu.cc works for me

I'll look into the formulas. I don't have much time to play - try to spend it writing in new stuff, so can't bug-test too well. I thought I let the game "auto-pilot" with moderate growth from 2014 onward (since I don't have historical data for the future, yet), but I probably mucked it up somewhere. Thanks! Were you selling many bitcoin in your game? You're on version 000425, right (with the casino)? What's the network difficulty at?

Slippage works both ways, so if you buy 20kBTC, the price will go exactly where it was when you sold 20kBTC (or at least, it should). As a side note, the exchange screen has logic in it to prevent the price from hitting absolute zero. Iin some displays, it will round to zero, but if the game detects the actual price variable at or below 0, it'll force the price to something like $.0000001 -- the exchange screen also has sanity-checks to prevent users from selling for less than nothing.

I have a couple days off to work on it, now. Could someone confirm http://www.bmgtg.cu.cc/ works?

You need to fix the 'bug'.
I mean, the $/BTC...

Whenever the price is > than $0.1/BTC the price starts to drop very 'bad' till it reach $0/BTC.
When the price reach $0/BTC it went up slowly.
After that, it drop again till $0/BTC!!!
The process is repeated endlessly.

My $/BTC never reach > than $0.1/BTC

I'm on year 2019 now...the Bitcoin price is still the same.
I mean, it never change! From $0.1, drops to $0..then repeat.
I was scared...
If that happen to Bitcoin price..in the future, Bitcoin will not go nowhere.

I'm addicted to your game. lol

PS: If I sold 20k Bitcoins. The Bitcoin price will go to 0, and there I can get unlimited Bitcoins.

Now imagine having $10k in user debt accumulating 25% annual interest and $1000 in new debt each month from rent and electricity costs once that system's implemented.

The game should self-correct in the next time tick if it truly hits zero (price is very likely to hit zero if you flood the exchange with coins because users cause slippage -- as a very early adopter, your own purchases and sales of coin which may be a small percentage of your holdings can have a massive impact on the exchange rate). The game has "adoption trend checkpoints" which attempt to simulate crashes and rallies based on the date in the game. They are not tied to to specific prices but are procedurally generated in each person's game, so no game is likely to emulate exactly what the price did, but there are time-based "trends" (based on historical data) in the movement of price. It is possible (but extremely unlikely) for price to increase in historical slumps and decrease during rallies. I think I also implemented some random changes to the adoption trend variable which aren't historically accurate to keep things interesting, but I might be imagining that (in such a case, the game can create new crashes and rallies or stop crashes and rallies before they did historically).

It's worth $0/BTC now.....

Because that's what happened back in the day? It's one of the most famous Bitcoin crashes