I love rts but i just have an old-ass android phone! look for me, 551154305985 TIM
Show HN: I made a browser-based RTS game
41–50 of 65 posts
Re: Show HN: I made a browser-based RTS game
#42remind me of my old old abandoned side project where i tried to create a diablo clone in browser with scala.js does not work in most browsers, think in safari it works :D http://diablo-forever.com/
Awesome dude
Re: Show HN: I made a browser-based RTS game
#43I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…
This is a common vector for cheats, so most developers eschew some sort of P2P lobby system.
Re: Show HN: I made a browser-based RTS game
#44Hi Gluten, I never wrote a real-time game, so I'm curious about a lot of things.
* Does the server have a tick rate and it updates clients at a set interval, or does it only update when things happen?
* Did you ever run into any issues getting enough throughput from the server? e.g. maybe too many events happening at once to update everyone?
* Do you have to manage situations where two clients have a different view of the game state (due to extra latency for example)? If so, how do you resolve it? For example, I know that Team Fortress 2 follows the rule for guns that "if the shooter thinks it hit, then it hit", which means that people get shot around corners sometimes.
I'm working on a turn-based game using websockets which has been hard enough, a real-time game seems much harder to make! Thanks for sharing!
Re: Show HN: I made a browser-based RTS game
#45Hi Gluten, I never wrote a real-time game, so I'm curious about a lot of things. * Does the server have a tick rate and it updates clients at a set interval, or does it only update when things happen? * Did you ever run into any issues getting enough throughput from the server? e.g. maybe too many events happening at once to update everyone? * Do you have to manage situations where two clients have a different view o…
It's probably a completely different architecture, see the classic article "1500 archers on a 28.8":
https://www.gamedeveloper.com/programming/1500-archers-on-a-...
Re: Show HN: I made a browser-based RTS game
#46I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…
A client-solves-server-verifies model introduces an interesting metagame that you'd have to be prepared to embrace. To run with your pathfinding example: odds are the stock client's pathfinder isn't ideal for every circumstance. You'd inevitably see alternate clients emerge with better or specialized pathfinding that would still check out with the server but would accomplish the player's goals better.
As far as I can tell there's no way to have the server prevent this while still saving any compute time, so you would have to design your game around the idea that this metagame exists. It could be really interesting for a certain type of player, but frustrating for many others.
Re: Show HN: I made a browser-based RTS game
#47Hi Gluten, I never wrote a real-time game, so I'm curious about a lot of things. * Does the server have a tick rate and it updates clients at a set interval, or does it only update when things happen? * Did you ever run into any issues getting enough throughput from the server? e.g. maybe too many events happening at once to update everyone? * Do you have to manage situations where two clients have a different view o…
It's probably a completely different architecture, see the classic article "1500 archers on a 28.8": https://www.gamedeveloper.com/programming/1500-archers-on-a-...
This is interesting, thanks! So sounds like there is too much data to send the entire game state every time.
Re: Show HN: I made a browser-based RTS game
#48I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…
A client-solves-server-verifies model introduces an interesting metagame that you'd have to be prepared to embrace. To run with your pathfinding example: odds are the stock client's pathfinder isn't ideal for every circumstance. You'd inevitably see alternate clients emerge with better or specialized pathfinding that would still check out with the server but would accomplish the player's goals better. As far as I can…
This showed up a few months ago, but I never got over the "activation cost" to actually try it out: https://blog.zkga.me/announcing-darkforest
Re: Show HN: I made a browser-based RTS game
#49Earlier quoted context omitted.
A client-solves-server-verifies model introduces an interesting metagame that you'd have to be prepared to embrace. To run with your pathfinding example: odds are the stock client's pathfinder isn't ideal for every circumstance. You'd inevitably see alternate clients emerge with better or specialized pathfinding that would still check out with the server but would accomplish the player's goals better. As far as I can…
This showed up a few months ago, but I never got over the "activation cost" to actually try it out: https://blog.zkga.me/announcing-darkforest
That is a super cool concept, thanks for mentioning!
Re: Show HN: I made a browser-based RTS game
#50I'm curious if it's reasonable to push more processing to the browsers to save on server costs. I know multiplayer games generally need a server to "referee" (and to matchmake) but I wonder if games ever offload most of that work so the client does the heavy lifting (e.g. find a path from A to B) and then submits its work for the server to validate (e.g. this path from A to B works) and broadcast rather than the serv…
A client-solves-server-verifies model introduces an interesting metagame that you'd have to be prepared to embrace. To run with your pathfinding example: odds are the stock client's pathfinder isn't ideal for every circumstance. You'd inevitably see alternate clients emerge with better or specialized pathfinding that would still check out with the server but would accomplish the player's goals better. As far as I can…
That's true. I don't think it would matter much, other than it being easier to make superhuman micro-capable bots in RTS or aim-bots in FPS games. For the former, a limit on actions per minute might work.
On the other hand, once such bots exist it might just mean the game needs to evolve.