steps:
- uses: actions/checkout@v2
- uses: sfdx-actions/setup-sfdx@v1
with:
sfdx-auth-url: ${{ secrets.SFDX_AUTH_URL }}
steps:
- uses: actions/checkout@v2
- name: Run deployment script
env:
HEROKU_API_TOKEN: ${{ secrets.HEROKU_API_TOKEN }}
The new one is browser based.
The mud engine runs in a web worker and takes advantage of some of the modern web tricks to do stuff. For instance, data files (think: area files that don't change often) can be stored remotely and then cached with a service worker. This allows the MUD to run offline. But that's only fun if you're playing solo.
IO between the UI and worker is handled by message passing.
Multiplayer is handled by the MUD opening an outbound connection (probably websocket) to a connection collector host. Other players would then connect to that host and have their IO routed appropriately. The host can even be smarter: it could be a specialized Discord client, allowing users to play from there. Firebase may also be involved. I don't know.
The important bit is that this is still basically message passing, so the engine won't need to know the difference between the local user and a remote user.
The MUD database would be an IndexedDB. Probably. I haven't thought as much about that yet.
I am sure all of this is theoretically possible, at least.