What is an acceptable resolution for character turning in a 3D RPG?
If the resolution were 4, he could face forwards, right, backwards, and left.
If the resolution were 360, he could face any of 360 directions around him.
At what resolution do we stop noticing disjointedness or granularity in turning?
Acceptable for what purpose and type of game? There are some popular first-person games that you can only rotate in 90 degree increments - Legend of Grimrock (PC) and Etrian Odyssey (3DS), for example.
However, note that they don't instantly jump from 0 to 90, but ease between the two over several frames. So even if you want your game to only have 4, or 8, or 16 different directions to face, your displaying of it to the player can be more finished.
This is similar to tile-based games showing the character moving between tiles, but always landing snapped to a single tile.
An MMORPG like WoW or GW2.
Is it first person, or third person? Overhead, or over-the-shoulder?
Are you asking what's acceptable, gameplay-wise (if so, how will it affect gameplay?), or what's acceptable visually (if so, what's the rest of the visuals of the game like?)?
Why are you asking? Are you wanting to use larger increments of turning, like 90 degrees or 45 degrees, for ease-of-programming, and are trying to justify that choice? Or are you wanting to use larger increments for gameplay-related features?
What's "acceptable" depends on the game. Do you have apprehensions about a choice you want to make? If so, what choice, and what apprehensions are you having? And what is the motivations that are leading you to want to make that choice?
I noticed you put this under 'Game programming', instead of 'Game design' - is there a programming-related reason why you aren't just using a float with increments between 0.000 and 360?
3rd person. Bandwidth concerns. I could use a 64 bit double to represent rotation but that'd be a waste of space.
3rd person. Bandwidth concerns. I could use a 64 bit double to represent rotation but that'd be a waste of space.
A 32 bit float is more than fine for rotation, client-side. If you're really concerned about bandwidth, you could cram the rotation even into 256 increments - 8 bits. I'm not advising that, just tossing it out as an example. But is it really a problem? I haven't ever programmed an online RPG, let alone a massively-multiplayer online RPG (by non-standardized definition, an MMO is greater than 1 million actively paying monthly subscribers). Personally, I'd just not send the rotation every frame - I'd instead interpolate over several frames. 
Just because the server knows the accurate rotation and position of each player, that doesn't mean that every single player within view needs 100% precise up-to-date details of every other player. Interpolate between positions. I think this is called 'client-side prediction'. i.e. the clients use their existing knowledge to predict where other players will be moving to, and only 'sync up' every so often.
So this is actually more of a networking question - and one that I'm not qualified to answer. However, I find some of the existing answers very helpful in understanding it:
Smoothing corrections to client-side prediction
Client/server movement - when to update?
Figuring out the cause of jitter
Also:
Entity Position Interpolation Code
Sorry for link-dumping. I'm not experienced in this area, so I can't answer it directly, yet I've read (and saved) several links about the subject, so hopefully they'll be of use to you. 
I'm using 2 bytes for orientation of players in my multiplayer game, this gives you a resolution of 1/182 of a degree, which is more than plenty.
I could use a 64 bit double to represent rotation but that'd be a waste of space.
64-bit is overkill. It will be converted to 32-bit for graphics processing anyway (rotation matrices passed to the graphics card are 32-bit). The minimum resolution of 32-bit floating points is 1e-7, IIRC (0.0000001), but it depends how you scale it. If you try to add 1e-8 to a 32-bit float, it will not change. If you use values between 0.0 - 1.0 scaled to 0 - 2*PI, you can rotate your object into 10000000 different directions - more than enough, IMO.
if necessary, heading can be compressed from float (or double) to short or even byte before transmission, as stated above. but you only save 2 or 3 bytes.
the whole idea is to send the least data possible, and only when necessary, and THEN compress that (if needed), before transmission.
so the client should know an object's heading, and an object should send a "turn" (rotate) message to the clients, who then do the math. packets only get sent when they change heading.
if a packet already includes entity type info, and that entity type's turn rate is constant, you can send the data in 2 bits: 00= no turn. 01 = turn left. 10 = turn right. 11= undefined.
always send the minimum data possible, and only when you must, and let the client do as much work as possible. then the vast majority of packets will be of the form: timestamp, entity_ID, nochange. or, if you only send change packets (as opposed to state packets), timestamp, entity_ID, change type, value.
In a NON-DETERMINISTIC networked startship flight sim i was able to get steady state down to 23 bytes of data per turn (for the ENTIRE simulation).
in short: its often less data transmitted if you tell the client what to do, when it needs to be done, rather than telling the client the results of doing something every turn.
what to do can often take less data to send than sending the result of doing that something. and only sending state changes, as opposed to sending current state every turn reduces the number of packets transmitted when things don't change.
what this boils down to is you basically want to send inputs (turn left, move forward etc, perhaps sent as a single byte), rather than results like new x,y,z,xr,yr, and zr (6 floats).
for minimal network lag, you should never transmit anything the client can figure out for itself.
in the particular case of a 3D RPG, you'd send a new heading only when it changed. you could send the new heading, or the turn amount, whichever is smaller.
you'd need to transmit 4 bits per turn for movement (0 thru 9 = no move, or one of the 8 cardinal directions). the client could figure it out from there.
for attacks, if the game is determinisitic, you can just send 1 bit for they attacked or not, and let the client resolve it and be guaranteed the server result will be the same. if its non-deterministic, you'll need to send damage and hit location, along with any critical hit type results.
