Google protobuf isn't very hard to implement but I do understand what you're saying,
From the research I've done there's two goals whether it be FPS or MMO.
1) Deliver the data as fast as possible.
2) Deliver as small of chunks of data as possible.
That being said the idea is to calculate only the values which may have changed since the last send before sending the next packet in order to make sure the size of the packet is as small as possible which is why I agree with you on the bit packing, I'm not sure how efficient protobuf is in terms of 'compression' of the data, I just figured it'd be a decent choice considering I'm already familiar with it.
And I'd have to argue that even MMOs tend to send a shit ton of data, sometimes even more then action fps games do.
...
Yes, exactly, if you want to send very frequent small packets bit packing is your best bet, protocol buffers seem to be better for slightly larger less frequent packets, I don't know if it supports bit packing but I feel like it would just send byte values, which is a waste of bandwidth when you're sending things a lot. However, I know most MMO games don't bitpack at all due to the cpu overhead per client and that's why I said Protocol Buffers would be more suited toward an MMO type game, especially since they tend to send larger state updates less frequently.
What you're talking about is known as delta state updates, it's very common all the way back to the quake multiplayer source. It's the obvious choice for any action game to keep the packet sizes small, bandwidth usage must remain low especially on a p2p network setup. It's a bit of a challenge to make it work with the udp protocol though since if a delta state gets lost you have to send it again before processing the newer delta states to keep things in sync. With a game like turok using a client/server setup it's possible to send full entire states compressed with common compression methods and bit packing and still stay on very low bandwidth usage, avoiding the complexity overhead of delta states.
MMOs do send a lot more data, less frequently (normally only 20 times a second or even less). They also typically use the TCP protocol. In these types of games latency isn't as huge of a deal since most actions are target based and they do sometimes trust the client too much to hide it and avoid cpu costs on the server. It's okay though, they are very good at hiding this latency since it's not critical and they have a LOT of player and ai states to send around to all the clients, that's a lot of data.
With bitpacking on a udp protocol you could achieve a reliable delivery system of bitpacked full(not even delta) state updates for 16 players at 60 times a second and still remain under 256kbps per client easy(I'm way over estimating too), which is more than feasible for ANY modern or even most outdated network connections. If that somehow DID cause congestion you just crank it back to 30 times a second or so for that client until the way is clear again. If you plan on a p2p setup rather than hosted servers, things get MUCH more complicated since the upload bandwidth becomes EXTREMELY constrained and you have to fit client updates into WAY smaller packets than you otherwise would have to.
The average consumer internet connection might have high download speeds these days, but uploads are constrained a lot, typically you have less than 750kbps to work with on upload. This is bad because if you have to update 16 other players they each only get about 46kbps of data... that's terrible and you can't always expect even 750kbps since clients might have someone doing something else on their network using upload bandwidth, or have even worse upload speeds than that. The only solution here would be to lower the player count, I suspect Turok would only have 4 player multiplayer anyway, so probably not too much of a problem? Even if you wanted 16 players, it's easy in Turok's case to fit player states into 46kbps at 60 packets a second(800 bytes a packet, very easy).
My point here is that you probably want packets as small as possible, especially if it's going to be peer-to-peer games, protocol buffers might not bit pack or compress data, but if you do write your own bit packing and compressing(not as hard as it sounds) you can easily fit within the constraints.
I'll try to start communicating with you on skype to avoid clogging up this thread with technical jargon, honestly I don't think this project even requires as much thought into networking as I'm putting in to it.