Blitz3D multiplayer game question

Started by Santiago, November 14, 2018, 20:01:46

Previous topic - Next topic

Santiago


Hello!; me again!

I ask you a question, I want to know which concept is the most appropriate to achieve a multiplayer game.


I want all users to connect to my server. the most important thing is to have an online login, where I can transmit some data. and then have a chat.

Then as a second stage I would like the users to transmit their position, address and speed, and a couple of more data: p, and I can receive them.

The third stage would be to be able to send users the positions of the most remote users.


As it is a game of boats, the speeds of the objects is slow, which allows me to have fluid speed although the data is not transmitted quickly, I just want it to appear, I do not need fluids.


I could do tests locally by writing and reading files, not prehistoric?

I can put a PC in my house dedicated as a server.

Or I could hire a server in Amazon.

but I have no idea what is most appropriate.

regards!
Santiago

RemiD

#1
if the gameplay is slow, and you need a few properties ( for the world, for each player ) to update from time to time, you could use a simple txt file and a php file on a shared server...

if the gameplay is fast, and you need more properties ( for the world, for each player ) to update often, you will probably need another executable to run the show, on a fast server or something similar...


about the testing of a multiplayers system, i have recommended again and again to first write read files on the same computer, then once it works well, on a local network with TCP or UDP (several computers same place), then once it works well, on a internet network  with TCP or UDP (several computers different places)

Santiago

Thank you again for the answer! I agree on the first internal method, with files.

I used for wifi, with 20 computers sharing a folder by network z: \ server, in which I wrote and read files, between server and users.

It turned out to be a super stable and solid system for an event that lasted for months.

but it is a slow system.
the interesting thing is that just start the application and everything worked, if a computer was turned off did not affect the operation to restart, never failed in months.

I can share it if someone is interested.


Derron

Writing to the same file (shared/mapped network drive) means you need to lock files (concurrent write access => garbage) means you introduce waiting times. Imagine all 20 want to write at the same time, now they need to wait all a bit ... until the last of the 20 was able to write. Not that troublesome - as long as none of the other 19 decides to write again - so maybe the 20 of 20 will be delayed and delayed and ... you got it.

If you really want to have a simple "server-client" thing then put up some script (php) or even use a java-solution which has everything "in memory" (useful if you have some thousand requests per second - which is not the case here). Ok, so simple: create a API-esque-reacting PHP script or even easier "index.php?gameID=hashofthegame&player=uniqueplayerhash&gametime=xyz&do=updateposition&x=10&y=20"). This script is verifying input and stores in in eg. an SQL database (sqlite, mysql, mariadb ...). This way all players can hand in their information. Another step is to fetch all information ("do=fetchpositions") and the script returns an array of player positions.

Make sure to have unique playerhashes (and not expose them to the others) so manipulation is a bit more difficult. Also the game hash should be unique - and is also there to allow multiple games to get played the same time.

There is a lot of more stuff to handle for multiplayer, but you wanted a "simple" approach.


bye
Ron

RemiD

Quote
Writing to the same file (shared/mapped network drive) means you need to lock files (concurrent write access => garbage) means you introduce waiting times.

@Derron>>think about how UDP works : packets (similar to datas files) are sent from clients to the server, then packets are sent from the server to the clients.
Well, you can do exactly the same on 1 computer (several executables (clients and server)) or on a local network...
you only have to add a procedure to delete the too old datas files (similar to packets), regularly...

Derron

local machines <> remote machines.

If you open a remote file for writing others wont be able to write to that file until you close it or a timeout happens (eg. the player suddenly shuts down his computer). Concurrent file access is only possible when "reading", not "writing" (who writes first, which content is the valid one?...).


You are right that _data_-wise it is similar to UDP (or whatever protocol you use) but we are not talking about the _content_ but the way the data is transferred - and files are "blocking" and not "non-blocking".


bye
Ron

RemiD

#6
well since packets are similar to different data files, i don't see any problem...

my suggestion was to code a reliable, multi players system on 1 computer and then on a local network with several computers, using different data files (one data file corresponding to one packet) before playing with UDP... then you can replace the writing / reading of data files by the reading / writing of packets...

i did this, and it worked well for a past project (instant messages + drawing area)...

MagosDomina

This should be right up your alley. The author originally made his game using Blitz3d, which is still available for download.
https://www.bridgecommand.co.uk

Quite am impressive simulation he's created I must say.


3DzForMe

That is a very impressive looking SIM, shipmates.  8)
BLitz3D, IDEal, AGK Studio, BMax, Java Code, Cerberus
Recent Hardware: Dell Laptop
Oldest Hardware: Commodore Amiga 1200 with 1084S Monitor & Blitz Basic 2.1