simon987 / Much-Assembly-Required

Assembly programming game
https://muchassemblyrequired.com
GNU General Public License v3.0
923 stars 88 forks source link

Vault door #39

Open simon987 opened 6 years ago

simon987 commented 6 years ago

Implement vault doors. Vault doors would be the entrance of underground vaults.

fo1_vault_15_entrance Vault 15 from Fallout 1

screenshot from 2018-01-06 15-37-03

Prototype

The vault area would be similar to classic dungeon crawler games in design, and there would be interesting items inside the vault, however, the vault areas would be dangerous. There could be mutated creatures inside the vault. And there would be radiation, which would create memory corruption.

Items inside the vault could be ammunition for the Mortar Hardware (#20) and Uranium cells for the Nuclear Power Plant structure (#38).

Vault doors could be password protected, which would require some hacking to unlock. Players could obtain the password by sniffing the Radio Frequencies (#32) or by brute-force. Vault Door password could be traded by players.

sg495 commented 6 years ago

If the items inside vaults are limited in amount, then exploration is rewarded, but charting is not (at least not for long). What about also having few rarer vaults which give access to some kind of "lost tech" upgrades? The upgrades could be either fixed or procedurally generated, and users would have to find the vault and navigate it to access them.

simon987 commented 6 years ago

what comes to mind is a generic 'electric chip' item which you could spend however you wish to upgrade various parts of your cubot. e.g. spend the chip to upgrade legs so you can jump etc.
Similar to dead space's upgrade token "Power Node"

sg495 commented 6 years ago

I was thinking more of something that encourages people to re-visit vaults, and/or that makes it interesting to share the positions of different vaults in the world. Something unique to each vault (or otherwise rare enough) would encourage world exploration, while something that needs to be replenished/recharged or that otherwise spoils would encourage re-visit, and hence charting of individual vaults. I think charting of vaults would be quite an interesting use of the floppy disk peripheral (while for vault doors it is enough to remember the universe coordinates).

sg495 commented 6 years ago

A couple more points that I thought would be worth considering:

simon987 commented 6 years ago

Something unique to each vault

If we're talking about some kind of upgrade this does sound interesting however I don't want the progression of the game to be that hard. (I don't want a player to be frustrated because that one specific item required to do the fun stuff is hidden somewhere in a Vault. In other words, I don't want to restrict some parts of the game for players that can't figure out how to crack the vaults). I would prefer a leaderboard system, something that says player X cracked Y amount of Vaults, or maybe rare cosmetic items (like a hat or something). So each Vault would be some kind of puzzle to solve, which would require multiple different skills (password cracking, pathfinding, combat etc..) and each one would be different.

LiDAR path-finding should not work in vaults

I was thinking of placing harder to detect like booby traps / obstacles such as 'toxic cloud' or 'sharp edged item' to promote a more complex use of the pathfinder but both ideas could be combined.

Players could also trade/share data about vault maps

Players could trade the locations of obstacles

Vaults should be large enough

Agreed, this will require some refactoring both server-side and client-side

Will the corruption in memory extend to the code

The whole 128kb of memory should be at risk of corruption. The user will notice when his/her bot starts behaving incoherently. There also could be a client side particle effect or a HUD warning thing

sg495 commented 6 years ago

I don't want the progression of the game to be that hard

I agree with that, I wasn't thinking of anything that would block/slow down other players. .

leaderboard system ... rare cosmetic items

What about combining them and having badges unique to vaults? They could display as cosmetic items (or otherwise being graphically visible), and at the same time be tracked on leaderboards (by total number, by some scoring, by hardness/rarity, or other criteria).

sg495 commented 6 years ago

I find password brute-forcing a bit too simple: it consumes time, but requires no finesse. One way to make the password-cracking challenge more interesting would be to make the vault doors employ a randomly chosen (sufficiently weak) cypher: the door would then broadcast messages produced from a small set of plaintexts and encrypted using the password. The bots could sniff the messages and use them to break the password (with cypher-dependent techniques).

For example, the door may be broadcasting a message over and over again, possibly with small random variations (e.g. it could be including the time of day in its message, or info about the bot(s) in front of it). More advanced doors would involve harder cyphers and/or longer passwords, together with longer messages and/or messages with more variations in them. Even better, very advanced doors could react to messages received from bots. The simplest doors could be employing a Vernam cypher (or some variation), so that any previously discovered fixed/predictable pattern in the door messages could be used to instantly discover the key.

PS: perhaps the message structure for Vernam cyphers should be randomly generated and kept secret at server-side, otherwise people could just look up fixed message patterns in the code....

DBJ314 commented 6 years ago

I suggest that when you input the password, you also expend a large amount of energy (like 30,000 or so) regardless of whether the password is correct. If you only get 2 tries before you have to go hunt for biomass, brute-forcing would be really expensive.

simon987 commented 6 years ago

when you input the password, you also expend a large amount of energy

I'd prefer not placing an artificial limitation for brute forcing. An alphanumerical password of 8 characters has 2.821109907×10¹² possible combinations and with the current energy cost, a player could at most do 3000 tries per trip. The password will probably be a binary string of 8 words, meaning 3.402823669×10³⁸ combinations.

the door would then broadcast messages produced from a small set of plaintexts and encrypted using the password

That's more or less what I had in mind. The password length would always be 8 chars (which immensely simplifies the programming for the vault doors), and the broadcasted messages could be of varying length and be constructed from a random arrangement of known dictionary words. I'd prefer avoiding 'security through obscurity' and go for a wider array of cyphers/algorithms, some of which would be a challenge just to implement in assembly. Even if we make the message structure and the dictionary words secret, it would only take one person that explores the game universe for a while and discover the list of patterns and post them somewhere. (Though also don't want 'heil hitler' written at the end of every message either, it has to be random enough).

 it could be including the time of day in its message, or info about the bot(s) in front of it. Very advanced doors could react to messages received from bots

I very much want to make this part work in combination with the features already planned for the Radio Operator NPC. From #32: "It would be interesting to also implement a Radio Operator NPC that would periodically send random messages to nearby NPCs (such as "Go to this area", "Pause for X ticks" or even "Bring biomass to (X,Y)". The players could intercept these messages and act accordingly (for example, create an ambush at the expected delivery location, or avoid to stay in the path of hostile NPCs), or kill the Radio Operator to temporarily freeze the NPC communication system."

Since NPC behavior is already constructed in "Tasks" (Currently the only task is HarvestTask ), these tasks could be translated into a message. Harvest task, when initiated, could be translated to (Harvest|Consume|Withdraw|Gather) (Energy|Biomass|Blob) (at|where) (World|Area|Zone|district) <worldX, worldY> with some added noise, then put into a cypher (the algorithm difficulty would be based off the Vault 'level') and broadcasted. This would give a double incentive to crack the password.

For the leaderboard system I think that the amount of 'points' a player has for completing a Vault should be inversely proportional to the amount of players that already cleared that vault. This way it is more rewarding to explore and clear more complicated vaults before other payers, and players might be more reluctant to share their code so the game would stay more fresh I think.

sg495 commented 6 years ago

I'd prefer not placing an artificial limitation for brute forcing.

Agreed: brute-forcing a uniformly random sequence of 8 alphanumeric characters would take 2^48 ticks, or about 40 million years. No need for additional limitations IMHO.

broadcasted messages could be of varying length and be constructed from a random arrangement of known dictionary words

I very much want to make this part work in combination with the features already planned for the Radio Operator NPC.

Yes, that sounds like a natural choice. We could even go for a more structured approach using parts-of-speech and a simple generative context-free grammar, to ensure random messages sound natural when decrypted.

I'd prefer avoiding 'security through obscurity' and go for a wider array of cyphers/algorithms, some of which would be a challenge just to implement in assembly

Agreed! Can't wait to have a go at some advanced cypher cracking in assembly :smile: