The consequences of a programming quiz

[vimes]

It's late, I've got some finals tomorrow and I just completed a 6-8 hour programming quiz sent by Terminal Reality upon a request for an internship. T'was hard, with something like 10 pages of questions in txt format and the interdiction to use the internet, books, friends... The left part of my brain feels numb, I'm eating curry and it makes me feel shapes in my palms: I had to try to remember stuff I had heard ages ago and then decide if my recollections were correct or not.

Damn, is answering to this kind of thing usual when you try to get a real job ?

[elmuerte]

Damn, is answering to this king of thing usual when you try to get a real job ?

It's common, depending on the minimal degree for the position it's more common.

For internships its very common, because there is usually a large selection group and not a major need to have the position filled. And ofcourse because it's for a rather short fixed time.

But 10 pages sounds a bit much.

[Marek]

Yes many developers give assignments or tests to programmer candidates.

[vimes]

Looking back at it, the exercise was really useful to me because it highlighted all the limits of my knowledge on several topics( for example, I don't know shit about multiplayer programming and not a lot about physics) so it gives me hints as to what to study next.

What's weird is that the quiz is the same for entry level or senior level.

[elmuerte]

Yeah, it's best to know a bit about every programming aspect of games and a lot about +-2 aspects. But it's only about the most vital basics. If you're not going to do any network programming you don't have to know a lot about network simulation, congestion control, different communication schemes, etc. Knowning just want thos things mean and how they work in principle is enough.

[vimes]

Yeah, but stuff like mathematics solver for multiple contact physics situation aren't easy to study just for the sake of it. And it's not like I had project that make me investigate this kind of problem:tmeh:

Fortunately, I think I did quite well on the programming problems.

And I do know quite a lot about network programming for wired and wireless environments (I'm deep into NS-2 right now, for god's sake) but they asked me what were the issues risen by multiplayer gaming for each genre and how to solve them... and that, I must admit, I don't know a lot about.

[elmuerte]

And I do know quite a lot about network programming for wired and wireless environments (I'm deep into NS-2 right now, for god's sake) but they asked me what were the issues risen by multiplayer gaming for each genre and how to solve them... and that, I must admit, I don't know a lot about.

Networking stuff on an abstract level is quite easy. It all starts with: what information does a client absolutely need to play the game.

For games where the player is bound to a single avatar it is usually everything the player can see (including some of the stuff behind the player). But for example for real time strategy this would include almost everything in the current game. but this is partially the same with other networking things, like the difference between streaming media and webpages. The other common issue is trust, this is very related to the networking scheme you use (client server, peer to peer, ...), what information can you trust. Trust is very important for p2p schemes, since there is no all knowning server. But these things have been worked out pretty well in the "game theory" research area.

The key factor is to know a thing or two about the genre. Actually... even though a game is in the same genre doesn't have to mean the same thing goes. It's very well possible to create a real time strategy game where client-server communication is much better suited than p2p.

NS-2 is only TCP right? TCP is way to heavy for games, a lot of the TCP features are mostly unwanted. afaik most games use UDP and perform their own lightweight initial handshaking and package validation. Just like with streaming media it's not that terrible if a bunch of packages get lost (or arrive out of order).

[vimes]

It is interesting, I would have thought that multiplayer games would use light TCP vs UDP as , in my opinion, in order delivery should be respected 90% of the time. There are already lag problems, if out of order packet would occur, the thing might be a huge mess, no ?

As for authentication, I must say that I hadn't thought of it at all - I had only consider client/server scheme. So in P2P, what do they use for authentication : scheme from cryptography like MAC scheme, signature scheme and challenge/response scheme or stuff that were specifically designed for games ?

[elmuerte]

It is interesting, I would have thought that multiplayer games would use light TCP vs UDP as , in my opinion, in order delivery should be respected 90% of the time. There are already lag problems, if out of order packet would occur, the thing might be a huge mess, no ?

As for authentication, I must say that I hadn't thought of it at all - I had only consider client/server scheme. So in P2P, what do they use for authentication : scheme from cryptography like MAC scheme, signature scheme and challenge/response scheme or stuff that were specifically designed for games ?

light TCP?

Out of order packets are often simply dropped unless there's a queue of packets to process. Multiplayer games usually work on the principle of send data as quick as possible, it's a lot of small packets.

Servers create a session with every connected client, during the creation of the session the authentication is performed, after that the server assumes the client is still properly authenticated. Sessions usually time out after a while of no data, since the server doesn't know if the connection was dropped. The kind of authentication scheme is used doesn't matter much, except that needs to be limited in size because UDP packets can not be fragmented. But besides that you could also initialize the session through TCP and then use UDP for the actual game communication.

The UDP protocol often implemented includes an acknowledge system where both client and server acknowledge receiving a given packet. This ACK is usually included in the next UDP packet send. In the session the server keeps track what packets have been acknowledged and it will act accordingly. So basically they simplement part of the TCP features in the application protocol over UDP. This allows you to do stuff in 2 packets instead of 8. But it also means the application must perform the accounting instead of the server/hardware.

As for the p2p scheme, the whole session handling is done in pretty much the same way as the client server scheme, but every client is also a server. And from here on it's just like a normal p2p scheme were every client is connected to a number of other clients (doesn't have to be all) and using the information it receives from the other clients it will know the whole playing field. Ofcourse you will need to implement a system to check the received data (because on peer might be telling a lie). But that system is already worked out in theory (can't remeber the name of it though).

[Tantrum]

It is interesting, I would have thought that multiplayer games would use light TCP vs UDP as , in my opinion, in order delivery should be respected 90% of the time. There are already lag problems, if out of order packet would occur, the thing might be a huge mess, no ?

Just wanted to add to the excellent response by elmuerte.

The thing is to pick your mess. By using UDP and coding some of the needed features of TCP in to your UDP protocol you can at least aim fubars in a direction you can handle, if not gracefully, at least without borking the whole thing. The way you choose to treat network errors is as much defined by the type of game as anything else, so 'multiplayer games networking' isn't so much an answer as it is a question. Ommmmmmmmm.