Conversations, where to store?

[kevglass]

In mini adventure I want to have a conversation system. It'll be something fairly simple driven by XML.

Currently, I store the majority of the map data on the client since I don't want to download maps to the client every login. What d'ya reakon to storing the conversation scripts on the client as well.

So the server would say -> "START CONVO X" and from that point on its all controlled on the client until an actual result of the conversation has to happen. At which point another message is sent to the server to indicate that something needs to happen. I realise this is slightly insecure but I'm trying to balance security on the client against bandwidth usage on the server.

Kev

[morbo]

Storing them on the client should be fine, and there is a way to keep it secure.

Instead of the client just sending the final result, have it send the entire 'path' of the conversation (I'm assuming you're using an option/menu-based system here). If the client sends every option the user selected, in order, then the server can validate these against it's copy of the conversation: if the client has altered the convo in any way, it'll be quite apparent.

[blahblahblahh]

What, exactly, are you trying to achieve here?

For instance, as you describe it, it sounds like you intend to tie the content of conversations (the text) to the control-flow (which records what options lead to what other options).

It's also not clear what problem you are proposing to solve by doing it on the client. You only say that you store maps on the client to save bandwidth / access-latency, and nothing about why you might want to do something similar with the conversations.

Is it just the same as with maps - you want to spare the latency of downloading conversations? (generally minimal, text compresses so well). Or...do you want to spare server bandwidth?

Or...more likely, I think...do you want to offload the whole processing, AND avoid the RTT latency, thereby increasing the responsiveness of conversations even on slow connections?

And once you've decided all that, what's your threat-model - what are you afraid someone might try to do?

e.g.:
 - reading the raw text of conversations would give away secret info about the game
 - reading the chain of possible conversations would give away an in-game advantage (e.g. I've played RPG's where you can only have certain parts of certain conversations once - you have to make an irreversible decision; being able to see the outcome before making the decision might be a cheat)
 - ...etc.

Depends on how you're structuring the game, but each such threat may have a 100% secure solution (there are easy ones for hte two I just mentioned) so that you could have the best of all worlds.

Games published by our own members! Check 'em out!

[kevglass]

By bandwidth I didn't mean latency, I meant literraly bandwidth. I don't want to download masses of conversation scripts from the server at the start of the client. I could do this of another server via webstart if I stick it in jars and package it with the client.

Tbh, I hadn't even considered the processing of the conversations, but thats another good reason to put it on the client yep.

The three threats mentioned:

a) Someone supplying a particular option before they'd have chance to.
b) Someone reading the full conversations and getting an unfair advantage
c) Reading the conversation and getting info that should be available.

seems to cover everything I was worried about. I like the idea of sending the chain. That seems to cover that problem fairly neatly.

I had considered encrypting the conversations in someway but I don't know much about it.

In all honesty, I guess I was just looking for pros/cons for either solution, which I've neatly recieved

Kev