Sorry your browser is not supported!

I'm just doing a little research to see how practical it would be to make an online RTS game. It would be similar to AOE where it has game rooms. And I would like it to have at least two game rooms for my friends to play on. Ive decided that setting up my own server for this is not realistic and was wanting to pay for a server. The problem is how much bandwidth per month one would require.

If you have lets say 1000 units and 200 buildings at most in the game and each player was sending there units/buildings location, angle they were facing,health and probably some other stuff that I cant think of . And then they were getting the other players info from the database on the server and the game lasted for an hour. I don't Know how many times you would have to update every second . At a guess 4 times per second. How much bandwidth would this take up to play one game.

Using this I can sort of get a grasp of the amount of bandwidth I will need per month for a server. And please no comments about how about you write the game first then worry about the server because I'm wanting this mainly to be an online game. It would be stupid making the game only to find out that it isn't feasible having it as an online game.

Also Ive been having a look at a few servers that are around and what they have to offer. Can anyone recommend any good servers . Or ones they have used before and have found good. Thanks in advance

Try to be specific as to how complex you want the RTS to be (ie. what is possible to do in it). Can you construct buildings, manufacture units, attack buildings, etc.


You wouldn't send all that stuff. If you start constructing a building, the other player needs to know about this. After this, it'll remember it, and therefore you will not have to mention it again.

I can imagine online RTS games being quite complex in terms of the type of data you would be sending. If you're going to do this, it'll take a lot of planning out.

As well as that, you would be interpolating positions.

Imagine your pathfinding. You say "Unit X go from Y to Z", and simply send that to the other players. From there, you can extract the positions it will be for its entire journey. If anything changes on the way, then you send fresh data, otherwise, the unit can get from one side of the map to the other with sending only 3 ints (unit id, end x/y - it should already know the start x/y).

You really have to plan the game first, figure out ALL your data structures, then you can work out what to be sending and what not.

As well as sending the data raw, you can compress it somewhat by sending it as a byte rather than an int, etc.
On top of that, you can use bit-masks for flagging what kind of data is coming in, meaning you can have up to 32 commands in an integer (or 8 in a byte, etc).

Regardless of what data's being sent, don't forget to make a wise choice in the protocol you use as they all take up header space.
UDP is probably the best. It doesn't worry about things like packet loss, etc, and you can even strip off the parts at the application layer if you write your own networking code.

Jess.

Erm, that depends. If you're sending data regarding a building you've started constructing, you want it to reach its destination, at any cost. UDP should only be used for data that is constantly being updated, where it doesn't matter if you miss an update or two. I would personally just stick to TCP for everything, although I suppose a hybrid of the two could be used.

Thanks for the advice Jess and Benjamin. I can see now that just sending all the raw data would just be stupid. Having to send only a units waypoint to where its going and updating the units if there stats change would save a huge amount of bandwidth. To be honest I have no Idea what protocol I'm going to be using. Its one of the many things I will have to learn about while making it.

A question. How do you tell the each user's computer that one of your units have been updated or does each computer download all of the data base to check for updates. Do you use a database of all updated objects and if they are in that list then you update them? You would probably need some way of checking that each computer has used the updated list before refreshing it with new updates.

By the way, I'm not sure how you're planning on doing this, but if the server is actually one of the players, then it would be slightly different than using a dedicated server. For simplicity I'm going to assume for now that the server is one of the players.


When something changes, you can either:

1. Send data about it right then to everyone.

2. Queue the data up to send at a set time - this avoids the flooding effect that would occur if you were creating loads of buildings one by one.

I would personally prefer #1 in some situations because I feel it would be better to keep players as up-to-date with your data as possible. In situations like when you create multiple buildings of the same type, you could have an option where you perhaps drag the mouse cursor to create a group of buildings, then send data about all those buildings at the same time. #1 would be best for data regarding the new waypoints of units.

If #2 is used for certain things, then you'll need to queue the events, and when you send all the data at once you need to send the current progress of that event. For example, if constructing a building, you must send data for the progress of the building; if moving units, you must send data for the current position of the units.

The most difficult problem I think you'll probably have is when it comes to moving units - you don't want another player to calculate a different path for units you have moved, otherwise you will have synchronization issues. The most sensible thing would be to have the server calculate all paths for units - yes, even for units of the other players.

Considerations exist in the side of the other players (the clients). When another player does something - for example starting the production of a unit - this event data should first go to the server, then the server will give some sort of reply telling the client to show the player that production has started. The delay might be annoying if one side has a slow connection, but it's the only way to be sure that everything is synchronized.

Once you get a working version, you could just play it across 2 computers and monitor the network traffic. That'd give some idea as to how much bandwidth you'd need.

I think thats the only way I'm going to know for sure. Ill have to have a server for developing the game anyway to test the code I will be working on. If I need more Bandwidth I guess I can always upgrade or find a better one.