Manifesto

[DaviddesJ]

Client-server is a real issue for games with complex graphics, e.g., World of Warcraft, where the server may send information to the client and the client still has to do a lot of work to display it to the player.

It's much less of an issue for a game like Angband, where the data that the server would send to the client is almost exactly what the player would see. You just have to display it.

There are certainly things that the client could do without consulting the server. E.g., you could decide that the client can keep track of the player's inventory, and display it to the player on request without additional server communication. The client could also do things like displaying help pages or spoilers (if desired). But the scope of all this seems just not that large.

[ekolis]

Client-server also opens the door for alternate frontends written in languages more conducive to complex graphics - probably not like WoW, since Angband is turn-based, but perhaps on the order of Dungeons of Dredmor, with animations for attacks and such.

[Derakon]

No, it's the UI/core split that enables that. Client/server is a superset of UI/core. Sorry if this sounds nitpicky, but I really think that aiming for setting up a client/server system is overreach at this point.

(Of course, I won't be doing any of the work on this project, so who am I to judge? Then again, how many of the people arguing for client/server will be contributing either?)

[DaviddesJ]

No, it's the UI/core split that enables that. Client/server is a superset of UI/core.

I would tend to agree with ekolis. If you have a client/server model with all communication through a network API, probably based on HTTP, then it's really easy to have client and server in different languages. But you could have a core/UI model with an API for communicating between them and yet the API might be very language-specific and you would have to do a lot of extra work (essentially, the same work as implementing a client-server model) to write a UI in a different language and have it interface with the core API.

If you really want to make the API language-independent, then it's basically no more work to make it a full network interface.

There is one other question, which is whether you want the UI to be trusted or untrusted. I.e., are you willing to have the core give information to the UI that the player shouldn't see, but trust the UI to display only what the player should know, or is the core supposed to enforce the player's knowledge limitations in what information it gives to the UI.

[ekolis]

I agree with Derakon that client-server is a superset of UI-core - that's why looking at multiplayer variants is a good place to start, since they're guaranteed to have already implemented a UI-core split. And it would be possible to design a UI-core architecture that has each component written in a different language, but in practice it might be difficult to implement without a true client-server architecture. Too tempting to take shortcuts and break the abstractions

[Nick]

If anyone is wondering what I'm actually doing about this, the answer is nothing for now (I have an FA comp to play, and various RL stuff). I'd certainly encourage (and participate in ) further discussion, but I'm unlikely to do any code work for a few weeks. But that shouldn't stop anyone else. I'm envisaging a fairly loose management structure...