Sorry your browser is not supported!

Hi all,

I went ahead and made the wrong assumption that node.js was the solution for a realtime multiplayer server. Now that iam googling alot more and came to the conclusion that maybe node.js is not the solution.

I will explain what iam doing and what i need:

What i have now is a strategic (singleplayer) game for android. Works fine on android. Now i want to make it so that multiple people can play the game against eachother.
In a game there should be room for max 4 players. The game server should be able to have multiple player rooms.

The game needs to send realtime data to the server, and the server needs to send it back to all connected players in that player room.


My questions are these:

1. My assumption is that if a make a server in AppGameKit itself, i can not host it anywhere online, is this correct?
2. What server language is suitable for connecting with AppGameKit on android?
3. If a have a server made in above language, can it be hosted online?
4. If the server is in a different language, do i only need the 'Sockets' section in the docs?
5. What language, for the server, would you recommend to use with AppGameKit?

Maybe above questions are a bit basic to ask, but i need to start learning somewhere.

Any help related to server language or any server related info or info about above questions are welcome.

The quality of the server depends on the game you want to create, if you want 100's, 1000's etc.. of players then you'll
need load balanced dedicated servers.

You can look into solutions such as https://cloud.google.com/solutions/gaming/ and https://www.pubnub.com/solutions/multiplayer-games/

If I have one server, I know you can do things such as quotas and things so what would be the concept of doing load balance on one server? Is there a separation or some type of virtualization that has to be done? Or do I have to rely on a third party resource (website) seeing that I see this load balancing as 2 or more sources or servers being able to provide redundancy?

i have a socket server built in agk that can safly support hundreds of users. i built a front end server that directs traffic to instances of the socket server. if to may people connect say 2k it can start another instance and direct all traffic to the second server untill the first server has room again for more. it was difficult to build. but it works well. also servers need lots of time-based code control some code i run every 5 minutes some every 30 seconds some i run 1000 times a second. controlling the speed is important. agk is suitable for a server and it can be ran from the web on a dserver. multiplayer networking is not a small task. especially builiding a server from scratch. you may want to find a prebuilt c++ or python server if u are not up for the work

A • Incorrect.
There are two types of Network Protocol...
UDP (Universal Data Protocol)
TCP (Transmission Control Protocol) … this within AppGameKit is called "Sockets"

Now the difference between these two is that a Socket (TCP) is more like an Open Line of Communication., so once you're connected you can essentially directly talk to the other Computer as you would any Internal Data Set.

So say you wanted to push out Positional Data... well you could just Broadcast (Send) three Consecutive Floats and they'd be sent as you called said Function. The same with receiving... so in this regard TCP is great for say talking to a Website that's going to send back a String as a Response, or Simple Data; but if you want to do anything more complex, such-as say sending Positional Data; well you then have to write some redundancy to ensure that said Data has actually sent correctly (and in the correct order).

This is actually why Server-Client approaches were first Development., because it's better to have Clients all sending their Updates to a Server that can handle all of the complicated Back-End; with the Clients essentially receiving Consistent (and Important) Updates ONLY for them.

UDP is a little different, as instead of sending individual data transmissions... instead you create "Packets" (Messages as AppGameKit calls them)., which are always going to have the same structure; in-fact you can tag them with IDs to handle Different Data Packets.
In this regard it GREATLY streamlines the process of say a Multiplayer Server-Client approach., but it also alternatively opens up (or rather makes it a dang sight easier) to use other approaches, such-as Peer-to-Peer or Round-Robin (Dynamic Hosting).
As for all intended purposes everyone on the UDP Network can acquire said Data Packets, and make sense of them without the need for Dedicated Hosting Backend; thus eliminating the need for a Server-Client Model.

What approach is best for you... well it will depend entirely upon the Game you have, and what Data is needed to support Multiplayer.

•

A common rookie mistake I see all the time., is that people will assume that a Single Player Game can simply be made Multiplayer via connecting two Instances of the Game and sending Update Data between the two; simply swapping out AI for a Human Player.
This really is rarely the case...

Typically speaking if you want Multiplayer, then you kind of have to design your Game Engine AROUND being Multiplayer... then for Single Player you can Emulate the Networking Elements when you want to use AI.
It might sound backwards to do it this way... but you'll find there are a lot of important considerations in HOW you handle the internal Data Messages that typically won't really mesh well when you develop the other way.

Heck something as simple as a Message Priority System... i.e. "Is it important that X is Updated Each Frame?" because when you're Networking, sure some of your Players MIGHT be on Fast 100Mb+ Broadband; but A LOT of them wont (esp. on Mobile) and then there's Data Plans / Bandwidth Restrictions... which a lot of territories and mobile internet providers will typically cap.
Such efficiency has to somewhat be baked into how the Game plays and feels., else the experience is going to be entirely different between the two.

Hi Raven,

Thank you for your time to make a comprehensive explanation.



Iam not sure really, it looks like i need the UDP approach.

These are roughly the steps for my game:

Player lobby:
- a (new) player connect to a player lobby with all players
- from there they can choose to play a game
- if they do, they come in a game lobby
- max 4 players in a game lobby, if everybody is ready (pressed ready) (or auto ready, if all players joined)
- then the game starts

game rounds:
- per round: all 4 players will click somewhere in the field, so i need only to send X, Y location (+ probably info about that player) once
- 10 rounds per game
- end of game will show total scores
- back to player lobby

Its not really network intensive, i just need to send: X, Y locations and player info once per round to the server, and when the server have all the player clicks its sending it back to all the clients in that player room.
I think this a low bandwith game for mobiles. Since its not streaming X, Y locations like a FPS does.



I knew this before i started to make the singleplayer, i knew i had to start over for making multiplayer. Thing was i needed to know first if AppGameKit was capable of doing what i wanted to do. Now i know it is capable, i can proceed to make multiplayer from scratch. I didnt wanted to deal with 2 uncertain things at the same time.


What should you advice me to use?

And if i later want to add chat to the player lobby, is that still possible with UDP?

dont let raven confused you. udp stands for user datagram protocol. but alot of people refer to it as unreliable data protocol. tcp and udp both send identical packets. the only difference is the information in the header files and how it is treated. a tcp packet is "reliable" and packets will be read in order because they are numbered automatically within the header. some packet are broken up into smaller pieces and re-numbered. tcp is slower then udp. if you send three packets with x y and z positions in each one. and your game needs all three coords to update it will wait for the last packet. sometimes it will get lost but tcp tells the other end what packets are received and will request another if one is lost. thus is all handled automatically in the background. waiting for a packet can slow down games that needs fast updates but it is reliable guaranteed data transfer to its destination. the downside is extra bandwidth for three way hand shakes updates and requests. the pro side is u only need to send information once. udp on the other hand has smaller packet sizes. they do not need all the route information or IP addresses along the way do not need numbering. but most importantly UDP packets do not need to be verified. this makes them unreliable but also fast. if you lose 4 out of 10 packets with UDP you lost that information you have no way of knowing if it reached its destination. you were building a game that needs very fast rapid updates I would go with udp. however if data reliability is crucial then TCP is the way. UDP can be reliable as TCP but it must be handled manually. manually label your packets and number them and program into the server what to do when one is not received within a certain amount of time. mass multiplayer games use UDP for communication for positioning data. the client will send several positions a second. sometimes the position that has not received. this causes jerky player movement. most servers however will estimate the current player position based on their last coordinates received what key was pressed their velocity rotation angle. and it will send that data out as if it were real or the player may end up standing still for long periods of time we're jerking back and forth. for smoothing purposes a server may take the next position data and average it with it current made up data so it is a smooth transition. for a turn based game like yours i would use tcp 100% and i would run a php server on a free webhost for stat tracking. and data handling.

however that being said. if u dont want to mess with databases sql php scripting in a whole other langugage build ur own dedicated server or rent one much easier in my opinion if ur not a web guy.

just my 2 cents




Remember, to prevent firewall change requirements, all communications must be initiated by the client. The client will mostlikely be behind a firewall and can't listen to a port itself , only send data. (well it can listen but the firewall will probably prevent receiving data)

so, the actual events would be
client sends X,Y self
client requests X,Y others

this could be done in a single request of course, you can put the self X,Y in the request to retrieve the X,Y of the others.

Also using standard ports on the server (like 80, 443) might prevent firewall issues. Some firewall are tight and even limit outgoing connections to specific ports

I'm not sure how free you are in picking ports for listening on AGK.

Since the server doesn't need to be multi-platform you can pick any coding language you want to create it. It does not have to be the same as AppGameKit, they just need to understand each other on what data they receive/send.

@smerf
I now understand the difference between UDP and TCP.

UDP = unreliable but less network traffic
TCP = reliable but more network traffic

I indeed need TCP, for my turn based game.

As it now stands i have 3 options:

1. Make the server in AppGameKit itself, when thats ready for public, i can hire a VPS(?) somewhere to host it
2. Use Node js (when googling about PHP turn based server games, answers would saying to use Node js server)
3. PHP based server (i dont think its a good practice to requesting like once per second to the sql database and see if another player already set their move)

is above correct?



@vennis73
I think it depends on the language iam using.

If iam using PHP i need to check from the client every second or so if theres a update from the other players. There is no direct connection between the client and server. (in my knowlegde you cant really push data from the server to the client with PHP, the client should always request data from the server)
But if iam using nodejs or agk server there is a connection between client and server until someone breaks the connection. So i can send data between server and client anytime i want.

Is above true?

I sort of tried with node js already (not a clue if iam using the right package for networking) see my other topic about it:
https://forum.thegamecreators.com/thread/225576

there us nothing wrong with connecting to a sql server once a second ideally u maintain the connection and just request information. however the best option is for each player to request the other players session ip then connect two people directly. also vennis brought up the firewall issue. all agk applications need manual port fowarding. routers these days are generally locked down. the alternative is using protocol hole punching through a router firewall which is a bit advanced.

With PHP you indeed normally handle http requests.

HTTP request contain a lot of overhead (headers etc) unless you really strip them off on the server and client. So if it's intensive in exchange of information you might want to strip them.
If it's just a call every x-seconds you could use it as is. The advantage of HTTP gives you the easy option to use HTTPS instead and have easy access to encrypted communication (which you should use if you going to exchange GPS locations or other private info)

Also mind the amount of data exchanging, if people use GPRS or have limited connection or data-usage, you don't want to burn it or get things slow.

With AppGameKit or NodeJS you can choose how you're going to exchange data. So yes you could keep the connection open which should be prefered if it's network intense. But if it's like a call every-x seconds i think you could choose what fits you most.

Ofcourse an open connection is the coolest one (less overhead).

Whatever you choose make it slim and lean, but still secure with a good and safe authorization method. You server-service will be tested by hackers or bots.

I am going with the PHP + SQL route, because i used to be programming in that a few years ago. If that dont work out, i can always make it in AppGameKit itself.

Thank you both for explaining it all.