Hi there, I am doing a Networks and Data Communications module in my H.Dip, and I choose 'Gaming over the internet' as a topic to write a technical report. However I have never written one before, let alone Networking! Way over my head. I have been thinking on focusing on 'latency', how it is caused, why it is something that it is not wanted, and some ways of fixing it. Do you think this would be sufficient? Could someone suggest a way of planning this out in relation to 'sections' and 'topic headings'? I just can't get a clear plan in my head to get me going, I'm all muddled up. Also, A technical question. Am I correct in saying things like 'Lag Compensation' 'Client Side Prediction' are all 'Application Layer' on the OSI Model? Are these things what the 'Game Networking Engine' achieve? And things like whether to use UDP/TCP are on the Transport Layer? It is at this layer that the actual delay happens am I correct? Because if it is TCP, it has to resend the packets, which is why most high paced multiplayer games choose UDP. Would I mention about the quality of the Physical Layer also I wonder? My main layout at the moment that I am thinking of going with is.. Lit Review - Read the collected papers on networking gaming, and focus on latency when writing this sections, what have they said, what have they suggested. Main section - Discuss latency divided into these headings. -Routing [Network Layer] -UDP/TCP [Transport Layer] -'Netcode' Things like Interpolation, Lag Compensation Conclusions (?) The thing is if my main section is just going through explaining how these different aspects affect latency, is that really a report? And if my lit report is all ready filled with these terms, am I not doing things the wrong way around. Like should I not go over all the basics first and then get into the literature that is out there discussing them. Sigh.. This is stressing me out. Thanks a million for your help! It would be a massive favour!

I think you would benefit from trying to determine the "audience" for your report. What kind of person would benefit from reading it? To me, you seem to be mixing at least two different discussions, "dealing with network latency in real time games" and "where does latency come from in the OSI model". Most audiences I can think of will only be interested in the details of one of these topics, and might be presumed to be familiar with the other. Audiences unfamiliar with either might not really benefit from reading something at this level at all, they may need to start with more basic material first. Once you have a clear audience in mind, it should be easier to determine what is relevant to the report and leave out extraneous detail.

Now, as the author *you* might need to research both simultaneously when you are writing your report - that is ok! But the final report doesn't have to reflect the exact mix of research you did.

I'm not saying you can't mix topics at all - just that you should focus on one above the others. Examples in particular are good, so if you were talking about "dealing with network latency in real time games", then you might want to refer to examples of where latency comes from in the real work (e.g. speed of light, network congestion, etc). However in the context of "dealing with network latency in real time games", I think it would be weird to start talking about the OSI model and worrying about which "layer" this happens at. In this context, there are two main "interesting" latency sources, those that are outside the control of the game developer (speed of light) and those that are affected by implementation choices (whether a server might immediately broadcast input updates or whether there is some "buffering" time).

As for approaching such a report, a "Top Down" approach of starting by defining "sections" and "topic headings" might suit some people, but I typically prefer to write things bottom up, diving in writing various paragraphs, and allowing the structure to evolve as the work progresses.

I don't know how much help this is, unfortunately I'm not familiar with the expectations of a report at a "H. Dip" level in whatever country you are in so it is difficult to offer concrete suggestions.

I'd second the recommendation to focus the report a lot more.

Actually finding out where latency comes from, and describing it in some detail, would be a fine report IMO.
Examine typical computers and games (where a game loop latency of 16 ms is common,) WiFi versus wired networking, Cable modems versis DSL versus cellphone modems, various back-haul networking tech, and then the difference between "hosted servers" in a data center, and "user run servers" that go all the way out through the same kind of connection to someone's bedroom.

If you actually draw a diagram of the major options at each hop, and list their properties and how they compose (loss & latency) that, in itself, could be a pretty solid report.