120

No, UDP is still superior in terms of performance latency, and will always be faster, because of the philosophy of the 2 protocols - assuming your communication data was designed with UDP or any other lossy communication in mind. TCP creates an abstraction in which all network packets arrive, and they arrive in the exact order in which they were sent. To ...


52

I would like to challenge the framing of the primary thrust of this question: the notion that "flat" design is a good idea. Game design is really not that different from plot structure in narrative entertainment (movies, TV shows, books, etc). In a plot, things start off simple. Then, a complication occurs. Then a couple more. More conflict is added. This ...


19

We agree upon both TCP and UDP being protocols built on top of IP, don't we? IP specifies how messages are delivered across the internet, but nothing is about the messages structure, format. Here come TCP and UDP protocols. They use IP properties, but let the programmer focus on the message exchange without worrying about the lower layers of net ...


18

Very good advice in comments (which got moved into chat). I'll just add, since I'm in the middle of implementing such "flattening" into my RTS (Knights Province) right now. Classic strategies are unlike many other kinds of games: They deliver too big of a change from 1st to last minute. In other games the main “gameplay element” is evenly spread along all ...


13

You could use OpenStreetMap data. It is liberally licensed. In particular, their wiki says: 3c. If I make something with OSM data, do I now have to apply your license to my whole work? No. For example, if you have written a game or published an artistic map which includes OSM data, only the data is covered by the license. This is called a ...


11

Ideas for removing micro from the game : No units at all (at least physically present in the game) : you win by spreading your control over areas like in the Go game. You have units but you can't control them, they automatically go attack some critical point of the enemy. This could work like the minions in League of Legends by following a line or as in ...


9

TCP <- Transmission Control Protocol. It's made to control transmission. TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example: Receiver detects a ...


8

I recommend Natural Earth Data as a source of public domain cultural and physical GIS data with global coverage. Vector data sets include landmasses, countries, populated places etc, while raster base layers are available with optional details like land elevation, climate, waterways and submarine elevation. This data is intended for use with GIS software, ...


8

Fair warning: if you don't find this sort of game play in the RTS world, that means there's a good chance that your market of gamers don't find value in this sort of game. Always be careful with the "if you build it they will come" argument. What makes a non-twitchy RTS tricky is the limited interface that we have to our computer. It's very good at making ...


7

Most RTS games provide you with automation tools to automate some menial tasks, but in many cases these are implemented poorly, as to give you a disadvantage. If you made sure that these systems don't penalize someone for using them then that would go a long way to alleviate your problem. Problem 1: Queues should not consume resources. Most RTS games allow ...


6

Real Time Collision Detection does indeed have this information - look at section '5.3.2 Intersecting Ray or Segment Against Sphere', page 178/179 in my copy. I'm not sure if it is okay to reproduce the code but I found many copies of it online (google books, for example) - here it is verbatim from Real Time Collision Detection: UPDATE: The following ...


6

Yes, you can change a mesh at runtime. get the current mesh from your object using Mesh mesh = GetComponent<MeshFilter>().mesh. Alternatively, if you want to replace the mesh with a completely new one, create one with Mesh mesh = new Mesh(); and assign it to your object with GetComponent<MeshFilter>().mesh = mesh; When you intend to modify the ...


6

Micromanagement There are a few approaches to minimizing the impact of actions-per-minute on the outcome of the battle. Other answers have touched on these: Removing micromanagement by only allowing you to issue macro commands. You issue objective-based orders and the units fulfill them. The downside to this is that AI is often remarkably dumb and ...


6

Tactics win battles. Strategy wins wars. Either remove, or disincentivise the ability or need to micromanage tactics, whilst allowing and incentivising the player to focus on strategy. The fact that your units stand under a bomber's path in TA unless you tell them not to is a flaw in the game. They should dodge even if you don't tell them to. I started ...


5

Given the options in your question, separate timers would be the best approach. I'm not sure what your implementation of the "timers" is but you can get a major performance increase and simplify things by using a different approach. Rather than using timers (as in stop-watch type timing) you could use time stamps that represent the expiration of a cooldown ...


5

EDIT Actually, Timer's schedule method should work in this case - maybe it's running straight away because you have 100ms as your delay time instead of 1000 (from your code above that is). If you're working in a multi-threaded environment, then make sure you handle possible concurrency issues. A possible alternative would be to use System.nanoTime() ...


5

Making an answer of my comment. You could remove the parts where the user has to create their base and their army. So when the player starts the game, the base and the army they have is all that they'll get for the rest of their play session. There could be a way to regenerate these units automatically (a clone bay, in space) and to auto-repair the ...


4

Unless you want players to be able to teleport through walls using their browsers build-in JavaScript debugger, you will have to implement any game mechanics worth manipulating on the server. This will lead to more noticeable lag, so you might implement it both on the client and the server. That way the client can perform the action locally so the player ...


3

You may compare the first diagram of RFC 768 (UDP) to the first diagram of RFCP 793 (TCP) page 15. Both show 16 bits for a “source port” followed by 16 bits for a “destination port”. Both show 16 bits for a “checksum”. According to RFC 768, UDP's “checksum procedure is the same as is used in TCP.” Whereas ...


3

Is real-time usually modelled as just a really quick loop, or a thread with interrupt and sleep / wait / join? Good that you edited to add this since I cast my eye over this 10 hours ago, because this is at the core of your question. Since we're otherwise unaware of your requirements, it isn't immediately clear whether you suggested threading for any ...


3

A* operates fundamentally on a graph, not a grid. When you create a grid for A* to search, what you've actually done is created something called a "lattice graph." The connections between nodes in the lattice can be anything. They don't have to just be straight lines between neighboring grid cells. In your case, you can combine the best of both worlds just ...


3

The first fact that any multiplayer game needs to accept is: "No matter how good your connection is, there will always be some unknown delay between the server and clients." Because of this, contemporary real time networked games "run" the game on the server and the clients are just snapshots that are as accurate as possible, given any network latency. ...


3

As Philipp said, you can change the mesh at runtime. You might have performance issues though (it's not "streaming" at all); in particular RecalculateNormals will probably be quite long. If you're willing to accept the maintenance burden, another possibility is to compute the vertices position directly in the vertex shader. Since you have custom collision ...


3

I believe you are talking about serializing MonoBehaviours. This is something we have struggled with since the dawn of humankind. There are third party tools available on the asset store, but they each have their own limitations and learning curves. You can write your own tool using reflection, but considering what a strong desire there is for a tool that ...


3

From this article, I would say 100MByte/hour is a reasonable estimate for the popular multiplayer games out there: https://www.rhoonet.com/how-much-data-does-online-gaming-use 100MByte/hour converts to 28.4KByte/sec, which is 228KBit/sec. Therefore your current usage of 16KBit/sec is definitely acceptable, even if you were to triple it.


3

Regarding an RTS that comes remotely close to this, I recommend experimenting with StarCraft II, archon mode: 2 players control a single side. If you got a couple friends to experiment with, you can try to figure out which of the tasks you want to offload to the second player to get the kind of steady experience you're looking for, and then for your game ...


3

You can answer this question yourself with a quick trip to the documentation: Time.time The time at the beginning of this frame (Read Only). This is the time in seconds since the start of the game. Time.deltaTime The completion time in seconds since the last frame (Read Only). This property provides the time between the current and previous frame. etc. ...


2

Here's something off the top of my head, trying to minimize expensive operations, without resorting to approximation hacks (ie. with infinite precision real numbers, the algorithm below is exactly correct, although in practice finite precision will introduce numerical errors). Recommendations/edits to improve performance are welcome. Let s be the start ...


Only top voted, non community-wiki answers of a minimum length are eligible