> In other words, "real-time" in the sense that missing deadlines will mean that the quality of service is degraded. Deadlines here mean delivering the packets

> In other words, "real-time" in the sense that missing deadlines will mean that the quality of service is degraded. Deadlines here mean delivering the packets in time for the next simulation timestep. Yeah, that’s what happens in most RTS, if the feedback for the action you sent doesn’t come back before Xms, then the game pauses and waits (for example Starcraft 2 does that). And I know the lock step mechanism used in some RTS, I’m implementing one myself. But I don’t see how it makes it non-real-time. If quake or teeworlds associates a network packet (containing a player-position) with a frame, does that make it really-fast turn-based game (with turns being frames, or ticks, or what you want to call them)? That being said, > You and I agree on everything except the definition of "real-time". No, the “real-time” word is really not that important to me, I mostly disagree with you saying “TCP is […] useless for multi player gaming.” RTS, or MMORPG, or turn-based tactical RPG, or card games are not “some exceptions”. They probably even represent a huge proportion of the multiplayer games out there. I now understand that you were talking about “fast-paced action games like quake or the likes”, but that really didn’t sound like it. > I'm sorry if my words were a bit overgeneralized and it annoys you. This is not just you, I’ve seen a lot of these “— TCP sucks for all online game purposes! — but what about all these cases were it’s fine? — Oh, I was obviously talking about those other cases” But that’s ok, I’ve made my point public instead of grumbling in my head, now I’m fine and we can move on. :)