I am making a small Online 2D RPG multiplayer game that uses a client-server architecture. I was reading up on the max bandwidth a client can receive from the server for I don't just kill players' connections, but am having a hard time finding real good data on google.
Currently updating the status of a player on screen takes 29bytes. I send an update every 100 ms, so that's about 300 bytes per second per player. I read that the Valve Source engine targets only 5-7KB/s. Whats a good safe limit I should shoot for, for I can catch all but the lowest bandwidth users.
Remember, 5 KB/s is 40 kilobits/second. 0.3kb/sec should be perfectly fine. Anyone still on dialup is going to be getting 56kb/sec (7KB/sec), and there aren't many people on dialup playing multiplayer games I'd imagine.
Related
I did several effects, and only on PC the fps fell from 170 to 80. What can be done to make it consume less resources? Is it possible to decrease the resolution
I am looking for a method to test the scalability of my WebGL multiplayer game (built in Unity 3D). The game is currently based on the PUN (Photon Unity Network) library and cloud service for multiplayer communication. I would like to know how to efficiently find out if the server hardware and architecture can support, let's say, 20, 50, or even 100 players in one room, with the limited number of computers at my disposal. Ideally I would like to know the frame rate each player will experience. I do have access to some powerful servers. A preliminary idea I have now is to run a bunch of virtual machines on these servers, each of which runs a browser tab with the game. Just want to know the industry practice or what you think would work. Thanks!
Framerate is hardware dependent and if you are sending data to the server EVERY frame you are doing it wrong.
Basic premise on doing it right would be, a player shoots a projectile..
Get its spawnpoint, direction and speed and then pass that to the other players/server to then process without the need to send data each frame.
This is a simplified example but gets the point across.
We are trying to develop a low-cost ultrasound device that can be used by inexperienced operators for health care in developing countries. We have created a low-profile optical tracking system that connects to the ultrasound probe. It outputs positional data from both the binocular camera and an on-board 9-axis IMU. The ultrasound pictures are collected on an iPhone at a frame rate of 60 per second and are time stamped to the millisecond based on the iPhone system time. The optical tracker collects positional data onto a Windows 10 laptop. We need to exactly synchronize the system time of the 2 devices (iPhone, laptop) at least to 1/10 sec and preferably to the millisecond.
Is there a way to access the precise system time on the iPhone and synchronize this with the laptop?
Full disclosure: I am an obstetrician and not an engineer. But I’m not satisfied with the story I’m getting from the developers about this. It must be possible.
We've tried pointing the laptop to the same internet clock as the iPhone, but the sync is not good enough. Maybe because of wifi latency?
i am creating a multi player iPhone game using the multi player tutorial as the skeleton in the following link http://www.raywenderlich.com/3276/how-to-make-a-simple-multiplayer-game-with-game-center-tutorial-part-12.
With the architecture i am using (GameCentre peer to peer)one of the devices plays the role of the server. I have a question, just what is the limitation of the packet size? On average i need to send out 890 bytes per go...
Generally you should not rely on the network packet size. The packets can get fragmented (via TCP/IP and get re-assembled by the stack) or data get packetized based on MTU of the sending/receiving parameters.
Per the Game Kit Programming Guide:
Limit the size of unreliable messages to 1000 bytes or smaller in size.
Limit the size of reliable messages to 87 kilobytes or smaller in size.
I'm about to develop a simple 2D game something like chess, checkers, or reversi. There are only simple animations of the players pieces. No complicated math nor graphics therefore I'm wondering if it is better to go with P2P over a client/sever approach.
The game will be an iPhone/iPod Touch game (and later on run in a Web browser game using Cappuccino). Two iPhone players can play when near each other via bluetooth/bonjour. Or the game can be played against other remote iPhone players via the internet, iPhone to iPhone; (and later on - iPhone to Browser; or browser to browser).
The game starts off with two players, each having an agreed upon number of pieces to place on the board.
Both players are constantly connected because the game will have a countdown timer that is set to an agreed upon time limit of 10, 20, 30 seconds in which the active player (Player A) must make a move. If the Player A doesn't make a move before the timer counts down to zero the Player A will lose his turn and the opposing player (Player B) will become the active player. The timer count is displayed on each player's screen.
The game ends when the players run out of pieces, with the player having the most pieces on the board declared the winner.
Can I please get your thoughts on which is better for my game? P2P or client/server?
To some extent, it depends on your desired feature set. For example: are you going to have "high scores" or "saved games"? Are you certain your players are going to be near enough to always play via bluetooth? If not -- how will you "connect" them to each other if they're just using the internet? Do you have server infrastructure in place now?
Also, it would be helpful to know if this is just an "experiment/toy" you're doing or something you intend to commercialize/release to the public.
At the end of the day, you can do it either way. The 'which is best' depends on your specifics.
I don't know much about iPhone development but I think it would be better to support both if possible.
For the "local" scenario P2P is the way to go. The players can easily discover each other and start a game without the hassle of setting a server and connecting to it.
On the other hand if you want the game to be playable over the internet, I think a client-server model is more suited. You can also host statistics on the server (high scores?) organize tournaments and more.
In my opinion if it is something where latency could be annoying in-game then go p2p, adding a server into the mix is just going to increase latency.
Because of the low bandwidth required per session, you could probably use a scaled server approach. I'm not familiar with iPhone development, but you can keep the application requirements on the client low with a Web standards approach. The servers can be balanced on the back end, and tied to a unique session with multiple clients connected to a session.