Do Transmitter / End game goal stuff. Will assumedly also require its own checklist.
Make solids harder or easier to drill depending on the solid type. -- stone is the hardest.
Kill previous fixes to the major bug, they're creating new bugs.
Fix the damn major bug if it hasn't been fixed prior to this point. -- For some reason, crazy diamonds doesn't have this bug. Might be a solid way to fix it.Has to do with multiple gravity (and presumably) drill intervals being set on a keydown without a keyup. Not sure how to maintain keydown continuous movement and fix this bug yet, but I'll think of something. Preventing future sequential triggers sorta helps, the problem is that things are being hit asynchronously.Maybe basic movement won't work if there's a void below you (and I guess whatever the grapple implications are) and then the keyup is what triggers the gravity check so it only ever happens once. Alternately, maybe javascript can trigger a keyup, in which case all future movement gets ignored and gravity can go through.
Migrate the inventory to an id and display it above the menus -- it should always be visible.
Handle drill speed and animation speed values.
Drill speed upgrades should take any kind of metal -- however this alters the way metals work, so I think I need to either create another upgrade target or allow 4 other upgrades to also use any kind of metal. Figure out which works better and reflect it in the Reference post. Animation speed definitely makes sense. Maybe the ranges of stuff.
Get the menu links working -- don't worry about keyboard controls right now, can fix that in the UX phase.
Create upgrades{} and a bootstrapped .init().
List out all upgrades in the data. Allow for addition, subtraction and have maxes and mins. If it requires a specific module, indicate that in the data as well.
Seed the seed, and The init should loop through all metals and assign 3 (or 2 depending on the solution to the first point) upgrades to each metal, splicing as it goes. Similar to the research system.
Menu
List out all the data here, producing links and showing the number and type of metals required and the .metal_cost=5. Descriptions as well.
Clicking it applies the appropriate upgrade to the appropriate stat.
Create xval(name), which returns the value of the stat for easier access. Should be less ambiguous than other variable names I could've chosen.
Alter the menu so you need the appropriate amount of metal and if you don't have it, show how many you do have relatively and don't allow the action to go through and also change the menu a bit.
Add a checklist item somewhere about a Help menu that aggregates all unlocked upgrades and stuff that gets rendered initially (like how to move and a big list of keybindings) -- good for UX. Starting out in the Help menu makes a lot of sense, but that's something that I should determine during the UX phase.
If an upgrade requires a module, display it as a ??? instead and don't let you pick it. Don't display the metal total or anything.
Upgrades should indicate the stats they unlock better. Handcrafting it probably makes the most sense.
Next Phase
I will need additional checklists:
Handle drill speed and animation speed.
Get all existing features in place, via mod() checks.
Get all existing upgrades in place, via xval() checks.
Get new features in place.
Get new upgrades in place. Could theoretically do this at the same time as the above, just make sure they're tested correctly.
