Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (784)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Conversations, where to store?  (Read 2138 times)
0 Members and 2 Guests are viewing this topic.
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Posted 2004-03-13 10:58:04 »

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.


Offline morbo

Senior Newbie

« Reply #1 - Posted 2004-03-13 12:07:02 »

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.
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #2 - Posted 2004-03-13 12:41:06 »

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). you want to spare server bandwidth?

Or...more likely, I 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?

 - 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.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #3 - Posted 2004-03-13 13:10:29 »

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 Wink


Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

theagentd (112 views)
2017-02-18 13:42:33

theagentd (116 views)
2017-02-18 13:35:16

h.pernpeintner (1280 views)
2017-01-24 22:39:11

h.pernpeintner (1268 views)
2017-01-24 22:38:32

Galdo (1828 views)
2017-01-12 13:44:09

Archive (1932 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2470 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2301 views)
2016-12-15 21:50:57

Lunch (2380 views)
2016-12-06 16:01:40

ral0r2 (2156 views)
2016-11-23 16:08:26
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!