our networks are fast enough to handle it.
The problem with TCP has nothing to do with the "speed of the network." The problem with TCP is that the receiving end will withhold newer information from the application, while it waits for dropped, older data to re-transmit, so that it can present all the data in order. For many applications (including many games,) timeliness is more important than order and completeness, and TCP is just the wrong solution for that.
I meant realible, not fast, my bad on this part.
My point is: for a non-FPS game, it is highly likely that TCP will be fast enough, I don't think that the gain you have by using UDP is worth the time of implementing it.
One important thing I noticed, we may be going off-topic here, my advice is: use TCP, if anyone want a TCP vs UDP discussion on my arguments, please PM me, I will gladly defend my point/change my mind.
*how can i transform this model to better suit a game over UDP that requires decent response times
*how can i account for packet loss?
First, I would create an id for each message type, the I would create two categories: messages that can be interpolated and messages that cannot. This way you can process messages different data you received without the need to wait the retransmission of othe messages.
The program should keep one sequence number for each message id (for instance, message of id 0 is start moving while id 1 is stop moving, each has a diferent sequence number).
To find lost packages I would create a list for each message id, order them by sequence number and act accordingly (either ask for retransmission or interpolate results).
Things may be a little more tricky on messages sent to the server, as a few pakages lost may seen like the client is trying to cheat, so you need to implement a prediction and a rollback capability. For messages as moving character, stop moving, jump and so on you need to either make then a message that requires confirmation or keep sending a message to tell the server that you are still moving, you're not moving, etc, so if the server lost some packages it can sync with the client again.