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

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.

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.

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.

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.

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.

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