Design ideas - ackmud/ackmud GitHub Wiki
Currently on deck to be hashed out/prototyped:
- Servers: some player-controlled, some autonomous
- Servers have ports that can be bound for RPC-style execution
- Binding to a port opens it and makes it vulnerable to attacks
- Basic user filesystem
- Some sort of shell with pipes and file redirects
- Scripting system
- Bladerunner-style distributed script execution system
- Editable/corruptible logs
- Some form of currency/resources
- Maybe think in terms of resources, and let currencies be an emergent thing?
- Some form of items/upgrades (for servers?)
- Encryption of network traffic?
- Servers with different sec levels?
- "Router" servers and "endpoint" servers
- Endpoints can be either players or NPCs, indistinguishable
- Set up a network with an actual network topology
- Benefit to running on nodes "close" to you: lower ping, less lag
- Benefit to running on nodes "far" from you: more spread out, harder to locate your central node(s)
- Could shut down parts of the network by DoSing certain connections between nodes? (or hogging resources, etc.)
- Do the parse LOCALLY on any custom async languages. Immediate feedback to the user about whether it's even valid code, then store the AST for async processing
- have most (all?) storage be "RAM" in-world (DB-backed in hackmud, obviously), with semi-predictable rolling blackouts
PVE vs. PVP: do we want these to be more similar, or less similar? (current state seems like a poor middle ground)
Accessibility
Tess:
My suggestion on that end is to have resources/tools/crafting that don't require code knowledge. So if I want to build say, a thing that scouts the surrounding nodes I would use... hm. [output] + [trace] + [identify] + [store data]? If I want a loop I need [output (for the return)] + [output (for the loop bounce)] + [input (for the function)] + [input (for loop bounce].
Aniketos:
Or tools are given in the form of code that can be examined/reverse-engineered if the user wants to understand more deeply or start coding