Switch to client-server about lambdahack HOT 3 CLOSED

The separation of engine/content would be completely orthogonal to client/server. The content files would probably land in the common library or server land, while the config files would apply to both client and server (probably need to be split into server config and client config).

from lambdahack.

Log of an initial design discussion:

10:47 < kosmikus> mikolaj: re client/server: very funny. back when I started LambdaHack as a student project, my
original plan was to make it client/server. but then I quickly abandoned the idea. I still think
it'd be better though.
10:50 @Mikolaj kosmikus: sure, it forces a better separation of concerns in code, better control of "cheating" by
AI, etc., not to mention PvP, etc., etc.
10:50 @Mikolaj no idea how hard it will be though
10:51 < kosmikus> the main issue is hammering out an interface
10:51 < kosmikus> the rest should follow from there
10:51 @Mikolaj bah
10:51 < kosmikus> :)
10:51 < kosmikus> one point to think about: you'll probably end up with some duplication between the two
10:51 < kosmikus> so you might as well still have a common library
10:52 @Mikolaj sure; actually I intend to have all: AI client, UI client and server in each exe and switch
components on and off on the fly
10:53 @Mikolaj e.g., put some party members under AI, or peak into AI party action via UI
10:53 @Mikolaj peak/peek
10:53 @Mikolaj so the interface between the components will be inside Haskell, first
10:54 < kosmikus> most of the things that are currently there are probably server anyway
10:54 @Mikolaj yes
10:54 @Mikolaj then, a version of the interface will be translated to a network protocol
10:54 @Mikolaj or something
10:54 < kosmikus> so it's really just the frontend stuff that isn't
10:54 @Mikolaj and AI
10:55 < kosmikus> well, yes
10:55 < kosmikus> although you probably don't want to end up having to run a client for each monster :)
10:55 @Mikolaj I will switch AI to think about a party as a whole
10:56 @Mikolaj but each monster will have a mind, too
10:56 < kosmikus> right
10:56 < kosmikus> swarm intelligence is certainly a nice feature
10:56 @Mikolaj then each party will have a AI "client"
10:56 < kosmikus> also, the game should still be allowed to cheat, within limits
10:56 @Mikolaj agreed, but I'd rather explicitly allow that by sendint cheating info within the protocol
10:57 < kosmikus> aha, but if you allow that via the protocol, then people can write cheating clients, too
10:57 @Mikolaj in the future authenticating so that only true AI can get that, not malicious players
10:57 @Mikolaj yeah :)
10:57 < kosmikus> I see
10:57 @Mikolaj well that's tricky
10:58 @Mikolaj perhaps the "authentication" will be just residing in the same exe as the server
10:58 < kosmikus> I think for starters you can just work with capabilities that the server can hand to the clients
10:58 < kosmikus> since the server will probably start the client for the AI
10:58 < kosmikus> it can grant more permissions to that one
10:59 @Mikolaj oh, shrewd
11:00 @Mikolaj anway, players disconnecting AI and posing as AI, etc., etc., if far future :), I'd love to get
there :D
11:00 < kosmikus> sure
11:00 < kosmikus> lots of fun

from lambdahack.

Rudimentary client-server is done in the dev version. Buggy, changing a lot and still could be more structured and more type-safe, but it works. No network in this version, but communication goes through channels, so it's transparent. To decrease network load, some work will be needed to send diffs of state, not the whole state (and only the diffs legally visible to the particular client). Anyway, the basic structure: player commands, server commands and client commands, where the latter two are sent as messages, seems to make sense and will probably stay that way.

from lambdahack.