Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (594)
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  
  Would this Client to Server design work?  (Read 1989 times)
0 Members and 1 Guest are viewing this topic.
Offline Xata27

Junior Newbie





« Posted 2011-05-07 23:08:22 »

I don't know if I should make this into a flow chart to make it easier to read but if I should please tell me. Also how would one go about doing this system (Which library would I use)?

1. Client connects to Server
2. Account logs in
    - If it is new then create a new file with all the information. Account name, password, last ip, etc..
3. If there is no character goto character creation
   - Player chooses character's appearence and name. Client sends server the information and server writes it to a txt file

4. When a player moves Client sends to server to update the current x,y,z in the txt file.
5. Server checks if another player is near to send the information to the Client to draw the other player


Let me know any improvments I could make.
Thanks!
Offline kieve

Senior Newbie




I am Awesome.


« Reply #1 - Posted 2011-05-07 23:11:54 »

I know nothing about networked games, as I have not begun working on one yet. I suspect that SQL would have better performance that updating a txt file with every user movement?

import universe.characteristics.Awesome
class kieve extends Awesome{
    public kieve(){
        beAwesome();
    }
    public void beAwesome(){
        while(true)awesomeness++;
    }
}
Offline Xata27

Junior Newbie





« Reply #2 - Posted 2011-05-07 23:16:36 »

I'd think that SQL would be a bit overboard for something that'll probably on have a maximum of 5 clients. Anyway this is a bit of an experiment, I'm just trying to figure out how to go about doing this.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline teletubo
« League of Dukes »

JGO Ninja


Medals: 48
Projects: 4
Exp: 8 years



« Reply #3 - Posted 2011-05-07 23:48:25 »

Quote
4. When a player moves Client sends to server to update the current x,y,z in the txt file.

why save the position each move ? you might just keep it in memory and save the txt file when needed (e.g. player logged out) 

Offline Nate

« JGO Bitwise Duke »


Medals: 158
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #4 - Posted 2011-05-08 06:01:48 »

I implemented this and added it to KryoNet as an example:
http://code.google.com/p/kryonet/source/browse/#svn%2Ftrunk%2Fkryonet%2Fexamples%2Fcom%2Fesotericsoftware%2Fkryonet%2Fexamples%2Fposition
I did this because it is simpler than the chat example, which has a bunch of Swing stuff which gets in the way. My implementation uses command line input. You can use it as a base for whatever UI you'd like. To use it, grab KryoNet from SVN, run PositionServer, then run PositionClient as many times as you like.

Offline ddyer
« Reply #5 - Posted 2011-05-08 19:13:36 »

You have to adopt different strategies depending on the scale of the site.  If there are 2 users almost anything will work.  If there are 2 million users, no simple strategy will work.   Generally though, you should separate real time response from persistence.  Keep what you need to serve the client's immediate needs in working storage, and take care of recording the state of the world in a background process.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2011-05-09 15:44:11 »

I would generally avoid using text files mainly because you can get issues with reading/writing the same file at the same time (well, that depends on your implementation I guess). In general though the reason I use something like SQL is that I can read write overwrite whatever whenever and I know that I'm not going to get corrupt data.

If SQL is too heavyweight for you, then you can go with a keystore like redis or memchached. I quite like redis for lightweight things because I can just treat it like an asynchronous HashMap: redis.get("Player" + myPlayer.id + ".hitPoints") etc.

See my work:
OTC Software
Offline counterp

Senior Devvie


Medals: 11



« Reply #7 - Posted 2011-05-11 04:36:59 »

I would generally avoid using text files mainly because you can get issues with reading/writing the same file at the same time (well, that depends on your implementation I guess). In general though the reason I use something like SQL is that I can read write overwrite whatever whenever and I know that I'm not going to get corrupt data.

Since file access is all synchronized, data will not be corrupted. Worst case scenario is at the moment the file is being accessed for writing, another thread handling new users tries to read the file for login and throws an exception (which should be easy to handle, just wait for file access).

You should have a separate thread for handling file saves/reads by the way, since you don't want to be slowing down your main thread (depending on how many users you are going to have, if you're saving thousands of files in a short time it can get slow. you should queue requests to save on a single/multi-threaded handler depending on how many users. i don't think you intend to have a lot though?)

And as someone said before, you should really just keep the player data in memory and save on logout.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #8 - Posted 2011-05-13 00:27:09 »

Yes, you're either blocking a thread while you wait for a file to stop being used or you're having corrupted data being read (there are solutions to asynchronous file access, like this), either way I think is really really bad, especially for something like updating player positions. Then having even like 5 players walking around at the same time will probably throttle your FPS because file access is so slow. Seriously just avoid it.

And yeah, even if you're using SQL or Redis or whatever, constantly reading and writing to a DB is going to be really slow. You need other solutions for synchronous multiplayer, or save only when relevant stuff happens. I wouldn't do just logout though because if the user exits the game in an unusual way (crash, force quit, etc.) then it won't save.

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

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

PocketCrafter7 (14 views)
2014-11-28 16:25:35

PocketCrafter7 (9 views)
2014-11-28 16:25:09

PocketCrafter7 (10 views)
2014-11-28 16:24:29

toopeicgaming1999 (76 views)
2014-11-26 15:22:04

toopeicgaming1999 (67 views)
2014-11-26 15:20:36

toopeicgaming1999 (16 views)
2014-11-26 15:20:08

SHC (30 views)
2014-11-25 12:00:59

SHC (28 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (28 views)
2014-11-24 19:59:16
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org 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‑gaming.org
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!