Till now, I’ve had this pretty simple layout:
The browser fires up a signal/R client, which connects to a signal/R server, which talks to a driver, which talks to a game-specific engine.
One signal/R client maps to a user in the game somewhere.
This Situation is not Covered:
You are standing in a spaceport
You see:
a ship
>> board ship
You are inside the ship. you can ‘launch’ to launch the ship.
>> launch
At this point, something happens that tells the client “hey, start this other client up” – possibly in a new tab. Maybe it leaves the current tab in place. The new client connects up to its own hub, with its own mudlib, and does its own kinds of commands. The user can then fly the ship around in space. The space stuff doesn’t know that the ship is also a “mudlib” object.
This could also be used with Shop Transactions, or a Game of Uno, or whatever – custom client for custom situation, in the same user’s session.
What this Means
a) I need a different sort of Auth mechanism to bind the user to an Identity. I think I’ll probably go ahead and use the stock website’s authentication methods to get myself an actual UserIdentity; I don’t know if that would flow down into any signal/R client or not.
b) Every user can have MULTIPLE clients going on at any point in time.
This is making my head hurt. I’ll let it percolate. For now, no cross-jumping between clients.
HOWEVER, I do want to move the <T> that I currently have on the Driver so that the Driver stands alone, and the Signal/R Hub is the one that knows about the mudlib GameSpecific.
