Would this Client to Server design work?

[Xata27]

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!

[kieve]

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?

[Xata27]

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!

[teletubo]

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) 

[Nate]

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.

[ddyer]

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.

[Eli Delventhal]

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.

[counterp]

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.

[Eli Delventhal]

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.