Unreal Engine 4.22.3 and it is a Listen Server
I feel confident in knowing which blueprints exist where and who owns what. It seems I just cannot wrap my mind about how to make the server replicate something that a client did, so I'd really appreciate some help in understanding this.
In the Player Controller BP I trace under the mouse cursor for other players, when I left-click. If it found a player character, I want to run the "death" event in the Player Character BP. The replication works fine, when it is run by the host, but when a client clicks on another player, the event is only happening client sided. I actually thought it should work, as I set it up.
How would I do this properly? I am pretty sure I must be doing something wrong here.
EDIT: When the client clicks his own character, the player "death" is actually replicated fine. Only when a client clicks a different character than his own, it is not replicated to the server neither to the other clients.
From Replicating Functions in Blueprints:
There are 3 primary types of replicated functions: Multicast, Run on Server, and Run on owning Client. Multicast functions should be called on the server, where they are executed, and then forwarded automatically to clients. Server functions are called by a client and then only executed on the server. Client functions are called by the server and then only execute on the owning client.
The PlayerController needs to call a Run on Server function, so that the server's version of that PlayerController can update the authoritative information, which is then sent back to all the clients via a combination of replicated properties and client functions (probably Multicast in this situation).
I'm working on a client/server game and am looking for ways for the client to detect whether it is still connected to the server, like for example when the server is power down.
Right now all I can think of is passing a token over time from server to client to tell the client that it is still connected. What I want to ask is whether anyone can tell me a better way of doing server connection checks. Can someone please give me some advise?
I'm trying to enhance a server-app-website architecture in reliability, another programmer has developed.
At the moment, android smartphones start a tcp connection to a server component to exchange data. The server takes the data, writes them into a DB and another user can have a look on the data through a website. The problem is that the smartphones very regularly are in locations where connectivity is really bad. The consequence is that the smartphones lose the tcp connection and it's hard to reconnect. Now my question is, if there are any protocols that are so lightweight or accomodating concerning bad connectivity that the data exchange could work better or more reliable.
For example, I was thinking about replacing the raw TCP interface with a RESTful API, but I don't really know how well REST works in this scenario, as I don't have any experience in this area.
Maybe useful to know for answering this question: The server component is programmed in c#. The connecting components are android smartphones.
Please understand that I dont add some code to this question, because in my opinion its just a theoretically question.
Thank you in advance !
REST runs over HTTP which runs over TCP so it would have the same issues with connectivity.
Moving up the stack to the application you could perhaps think in terms of 'interference'. I quite often have to use technical stuff in remote areas with limited reception and it reminds of trying to communicate in a storm. If you think about it, if you're trying to get someone to do something in a storm where they can hardly hear you and the words get blown away (dropped signal), you don't read them the manual on how to fix something, you shout key words such as 'handle', 'pull', 'pull', 'PULL', 'ok'. So the information reaches them in small bursts you can repeat (pull, what? pull, eh? PULL! oh righto!)
Can you redesign the communications between the android app and the server so the server can recognise key 'words' with corresponding data and build up the request over a period of time? If you consider idempotency, each burst of data would not alter the request if it has already been received (pull, PULL!) and over time the android app could send/receive smaller chunks of the request. If the signal stays up, just keep sending. If it goes down, note which parts of the request haven't been sent and retry them when the signal comes back.
So you're sending the request jigsaw-style but the server knows how to reassemble the pieces in the right order. A STOP word at the end tells the server ok this request is complete, go work on it. Until that word arrives the server can store the incomplete request or discard it if no more data comes in.
If the server respond to the first request chunk with an id, the app can use the id to get the response and keep trying until the full response comes back, at which point the server can remove the response from its jigsaw cache. A fair amount of work though.
I'm trying to build an online game server for my Tank game 2D (Unity). In my game there will be 2-4 players control their tanks and fight each other.
I've tried to use Unity networking, it was not really suitable for my game because we have to choose 1 of the players in the room to become the "server", which is not really flexible for my future development (e.g. when the "server" quit, I have to do a lot of work to remain connections between the other players).
Then I tried to build my own server with Nodejs là socket.io for server-client communication. It's very simple: receive data from one and broadcast them to the others. It seems to work fine until the physics part comes in: the server must trust the clients when they say there's something being hit or explodes, then broadcasts it to the other clients. Not to mention the cheating clients, with the network latency, the physics simulation of the clients will vary. For example, a tank might be hit on one client but it finds cover behind the wall on another one and stays alive, but the tank behind it catches the bullet and explodes, because of the latency. In these cases, the server doesn't know which one to listen to.
Update
As #Catwood mentioned below, Photon PUN is another option for me. I
had followed one of their tutorials before. Photon doesn't need a player to be the "server" like Unity networking. But how do I implement my game logic on the server? (for authoritative server purposes)
Apparently Smartfoxserver is another good (and pricey) option. I haven't taken a deeper look at their API documentation. I don't know if I could implement my gaming logic and rules on this (their tutorial skip this part for the sake of simplicity).
In conclusion, I need a suggestion for my game server:
Is an authoritative server
Can handle game rules and decide what will happen (maybe it should have its own physics engine)
Works well with Unity2D
Javascript, C#, Java are preferred!
Am I going in the right direction, because seems like some game server services (such as Photon, Unity networking) don't care about how to implement game logic on the server? And does it make them not an authoritative server?
I am very new to this field, anything will be appreciated!
I would advise to create your own server for your game like you did with NodeJS. Most of the solution I know are quite hard to use and cannot do eveything you want to.
For example, Blizzard game's Hearthstone is based on Unity for the client and have a custom made server side.
Here are some advice on how to create your game server.
It seems to work fine until the physics part comes in: the server must trust the clients when they say there's something being hit or explode, then broadcasts it to the other clients.
When creating your server you must make every important decision server-side and not client-side.
It is the server who start the party, so the server must have the following information
The size of the map
The number of player
Data about each player (Health point, position, size, attack speed...)
Any other information required to make decisions
Now, the client should always send very small signal to the server like the following
Move left
Join party
Shoot
Rotate right
etc...
Based on user's action and user's data, the server can run a "simulation" of the game.
Check if the action is allowed
If it's allowed, simulate the action. If it's not, put it in a queue
Send to users informations about what is happening (Player one hit, player two dies, player four moves left etc..)
With this, the server knows when something happens and decide what happens. You do not rely on client side information, you only recieve the player's desired actions.
However, as you said, because of latency and other network factors, your client cannot be too dependent of the server. In modern games, the client have the same data about the player than the server and do not always rely on the server to display on screen what is happening.
If you played some online games, you may have noticed that when a connection with the server is lost, there's a small amount of time during which you can continue to play (move, shoot, etc..) but nothing moves except you.
This is because the client continue to "run" the game based on your action even without server's informations.
However, to avoid any huge difference between what is displayed by the client to the player and what is happening in the server's simulation, the client and the server "synchronize" at regular interval.
For example, if you decide to move left, the client knows your move speed so it can display the movement without relying on the server.
When the synchronization occurs, the server send to the client critical information and the client change any currently displayed informations with what the server send.
Whith the left movement example, if your movement speed is different on the server and on the client, when the client receives a synchronisation order, you'll notice that your player will be "teleported" from the displayed position to another. This can also occurs if some packet are lost or because of high latency.
Handling lantency is a huge challenge when creating an online game both on server and client side and it's not the topic of this question.
To summarize, your server should
be homemade
Only receive actions from clients
Simulate the game
Send clients information about what is happening
Synchronize at regular interval with clients
Hope this help =)
Here are some explanation on how to add logic inside your server.
Small disclaimer before, I've never used NodeJS so I don't know if this is achievable using NodeJS, I usually use C++.
Now for your game, I'll assume that the player can only use the action MOVE.
When a user connect to you server, you can launch the game.
Because your user can move, it means that there's a 2D map, that your user have a size and an initial position and a speed.
So your server should start a new "GameParty" and initialize the above data.
For the example, let's assume the following defaults value are set.
map_width = 512;
map_height = 512;
user_width = 2;
user_height = 2;
user_speed = 1;
user_posx = 20;
user_posy = 20;
When a client wants to MOVE, he send a packet to the server saying he wants to move. You can use any protocol you want for client<->server communication, I use a binary protocal but let's say you use Json
{action: move; value: left};
With this, your server will know that the user wants to move to the left.
So, you just have to decrease user_posx by the value user_speed to have, server side, your new position. If this position are on the edge of the map, you have two choice, making the user appear on the other edge of the map of forbid the action.
At regular interval of time, your server will send to the client the player's current position.
There is an asset on the asset store called Photon that is an authoritative server. It is free too for non mobile devices. This will handle the first part of your question for sure.
This great Tutorial will help.
I don't know very much about sockets at all. What I am wondering is how the sockets work.
1) Firewalls often block ports. Is it plausible that if I request a socket and it is behind a blocked port anything that is sent or received will get intercepted and destroyed? Is this an issue?
2) On the server side how do you keep the connection alive to send data back through, like if I was building a chat app is it possible to start a connection through a socket and keep that alive and have the server basically push new data through the stream. Instead of the apps having to query every so often.
3) If the app goes into the background apple says they will keep the socket as long its not needed (if it is voip). Does that mean that I could still send data through to the app and have it handled? If my app is registered for location updates and executing in the background already will the socket stay open?
Are there any server languages that make it simple? I am currently using python and Django for a simple http server. Are any tutorials on setting up a server that can keep connections alive. I really don't know much about this so what i'm asking may not make any sense but some direction would be greatly appreciated.
1) I haven't found an issue with firewalls at all.
2) I used a twisted server along side my web server to implement a event driven socket server and it works great.
3) the sockets will stay open as long as you are executing in the background and the delegate methods are called to handle stream events.
There is an excellent tutorial here:
http://www.raywenderlich.com/3932/how-to-create-a-socket-based-iphone-app-and-server
that goes over the twisted framework and how to create a chat app with sockets. I found that immensely helpful.