is SignalR appropriate for making online real-time games?

Started by
4 comments, last by moeen k 6 years, 1 month ago

there are many different tools to make online-real time games on unity like photon, Unet and .... . they are good tools to make real-time games easier. but I need a low level tool to have more control of data transfer.

as I worked previously with signalR and its a very simple framework its a nice tool for me to work with and its known as a realtime connection framework. but there are some doubts. signalR is built on http and http basically uses tcp for transfer layer. as we know udp is more appropriate for making real-time games as its a faster protocol.

can you explain me can it be a good tool or not.

thank you for helping

Advertisement

It's an acceptable tool if you don't need to transfer a lot of small bits of data really frequently.

I don't know what you mean by "low level control of the data" but you can probably do almost all of that with Unity's LLAPI.

37 minutes ago, Kylotan said:

It's an acceptable tool if you don't need to transfer a lot of small bits of data really frequently.

I don't know what you mean by "low level control of the data" but you can probably do almost all of that with Unity's LLAPI.

thank you for your answer. I mean complete control of how and when to send and receive about low level. let me be more specific. I'm working on a side scroll shooter game. I think there can be 2 approach to code these games. sending commands like jumping shooting and.... in other point you can update variables. I think you mean of "don't need to transfer a lot of small bits of data really frequently" is to just send and receive commands. as I searched node js supports both tcp and udp and basically is real-time. what can be a good replacement of node on .net as I am a c# developer. its possible to use sockets but  it can be a hard process as many things should be defined in sockets  thank you.

ALL networking (at least as far as games are concerned) uses sockets - it's just a matter of how many layers there are on top of the sockets.

Also, the term "real time" is fairly worthless, because it means a lot of different things to different people. What you need for a multiplayer shooter game is low latency networking, and for that HTTP is a bad idea, partly because the HTTP protocol is optimised for text-based request/response transactions, and also because it's built on TCP which is designed for reliability at the expense of average latency. TCP can be especially bad for latency over WiFi or mobile connections because the large number of dropped packets means that other packets can get held in a queue for quite a while, when as a game developer you usually just want to get the latest data and are happy to lose occasional messages.

SignalR is technically not based on HTTP - it's really a Websocket, which uses HTTP to start the connection but then functions mostly like a standard TCP connection after that. As such, it's better than an HTTP-based approach, but still not ideal for faster-paced games.

It's not clear why you think you need "complete control" but I would recommend that you use a game-oriented protocol that is layered on top of UDP. Unity comes with one of these in the form of the LLAPI and if that isn't good enough for you, explaining the exact way in which it doesn't work for you would help us recommend something else.

1 hour ago, Kylotan said:

ALL networking (at least as far as games are concerned) uses sockets - it's just a matter of how many layers there are on top of the sockets.

Also, the term "real time" is fairly worthless, because it means a lot of different things to different people. What you need for a multiplayer shooter game is low latency networking, and for that HTTP is a bad idea, partly because the HTTP protocol is optimised for text-based request/response transactions, and also because it's built on TCP which is designed for reliability at the expense of average latency. TCP can be especially bad for latency over WiFi or mobile connections because the large number of dropped packets means that other packets can get held in a queue for quite a while, when as a game developer you usually just want to get the latest data and are happy to lose occasional messages.

SignalR is technically not based on HTTP - it's really a Websocket, which uses HTTP to start the connection but then functions mostly like a standard TCP connection after that. As such, it's better than an HTTP-based approach, but still not ideal for faster-paced games.

It's not clear why you think you need "complete control" but I would recommend that you use a game-oriented protocol that is layered on top of UDP. Unity comes with one of these in the form of the LLAPI and if that isn't good enough for you, explaining the exact way in which it doesn't work for you would help us recommend something else.

nice answering. thanks a lot. it seems LLAPI is the right solution.

This topic is closed to new replies.

Advertisement