View Single Post
Old April 12, 2015, 13:32   #5
Bandobras
Knight
 
Join Date: Apr 2007
Posts: 725
Bandobras is on a distinguished road
Quote:
Originally Posted by Narvius View Post
The sample implementations for Client and Server really help
Yep. They are 'sample', but they should actually be enough for a lot of crazy games. I suppose one would extend the main engine code rather than add an extra state component to CliState and then transform the extra state in some external code. But the generality helped me ensure via types that engine doesn't depend on the concrete representation of the state data underneath. [Edit: and on the fact, that there's the IO monad underneath.]

Quote:
Your CliImplementation is a newtype wrapper around a small monad stack.
Yep, and a very similar stack for SerImplementation.

Quote:
the plethora of MonadClient* instances
Yep, I use those and the read-write and read-only monad a lot to ensure clients can't modify the main game State they share with the server, etc. (Actually, they can modify it, but only in the little bit of code (Atomic*) where they update the shared state based on messages sent by the server. Also, only restricted bits of the the state are shared based on what clients' actors can see, etc.) [Edit: I also use it to make sure only tiny bits of the client code can send/receive messages from the server, etc.]

[Edit: this is described in https://github.com/LambdaHack/Lambda...r-architecture, though it may not be very accurate nor specific. It will also get abstracted a bit more when I let the client-server communication operate via net and so they will no longer reside in the same binary (and not in the same binary as the frontend thread either).]

Last edited by Bandobras; April 12, 2015 at 14:09.
Bandobras is offline   Reply With Quote