B
BlaXun
Guest
Hello everybody,
I recently got a idea for a game I'd like to prototype... a sidescroller. However, as my previous game I want this one to be online at one point as well.
For my earlier games I had two seperate programs. The client (game) and the server.
What happened due to this is that the client had to inform the server bout position and such...and thus it wasn't reliable at all.
This time I want to learn from my mistakes, use UDP instead of TCP, have client-side prediction of positioning etc.
However, what I am struggling with is how to actually let the server know the correct position of each player... and it seems like the common approach for this is to actually have the game and server share the same codebase... even being the same compiled executable (even though hosting this on a server would require a server with a graphics card n such). With this setup the server would have to know the map for the player and it should then be able to know where players are positioned... I did not have this in my earlier games. It did work quite well I'd say, but I know its not the ideal solution
So, yeah. How does that idea of having client and server in the same executable sound? I mean, the server would not have to render anything ...maybe for debugging... but actually I'd even be happy with just a command-line interface (which GMS doesn't support afaik).
To me it sounds like a good start and it could solve some problems. "Unfortunately" the game will have multiple rooms and thus my idea would be to load all rooms on the same screen and have em overlapp, but the blocks that players in each room can interact with have something like a room-id so they know what room they belong to and on collisions I'd always have to check if the colliding block is actually within the same room as the player. It sounds like all these overlapping rooms could account to a lot of collision instances. A alternative approach would be to load rooms next to each other with a x and y offset to have a x,y origin at 0,0.... however this could result in having a very big gamefield on the server-side.
Thx in advance
It feels nice being back and thinking bout game-dev!
Edit:
Some links I found helpfull
https://forum.yoyogames.com/index.php?threads/some-multiplayer-design-questions.31689/
https://forum.yoyogames.com/index.php?threads/lag-friendly-real-time-networking-tips.47951/
https://medium.com/@meseta/2e5a98e4105f
https://net8floz.itch.io/fix-your-timestep-extension
I recently got a idea for a game I'd like to prototype... a sidescroller. However, as my previous game I want this one to be online at one point as well.
For my earlier games I had two seperate programs. The client (game) and the server.
What happened due to this is that the client had to inform the server bout position and such...and thus it wasn't reliable at all.
This time I want to learn from my mistakes, use UDP instead of TCP, have client-side prediction of positioning etc.
However, what I am struggling with is how to actually let the server know the correct position of each player... and it seems like the common approach for this is to actually have the game and server share the same codebase... even being the same compiled executable (even though hosting this on a server would require a server with a graphics card n such). With this setup the server would have to know the map for the player and it should then be able to know where players are positioned... I did not have this in my earlier games. It did work quite well I'd say, but I know its not the ideal solution
So, yeah. How does that idea of having client and server in the same executable sound? I mean, the server would not have to render anything ...maybe for debugging... but actually I'd even be happy with just a command-line interface (which GMS doesn't support afaik).
To me it sounds like a good start and it could solve some problems. "Unfortunately" the game will have multiple rooms and thus my idea would be to load all rooms on the same screen and have em overlapp, but the blocks that players in each room can interact with have something like a room-id so they know what room they belong to and on collisions I'd always have to check if the colliding block is actually within the same room as the player. It sounds like all these overlapping rooms could account to a lot of collision instances. A alternative approach would be to load rooms next to each other with a x and y offset to have a x,y origin at 0,0.... however this could result in having a very big gamefield on the server-side.
Thx in advance
It feels nice being back and thinking bout game-dev!
Edit:
Some links I found helpfull
https://forum.yoyogames.com/index.php?threads/some-multiplayer-design-questions.31689/
https://forum.yoyogames.com/index.php?threads/lag-friendly-real-time-networking-tips.47951/
https://medium.com/@meseta/2e5a98e4105f
https://net8floz.itch.io/fix-your-timestep-extension