ご推察通り、移動方向指定型です。ただし、プレイヤーから見ると、
移動目標指定方式に見えるよう、最終的にはもっていく予定です。
つまり、移動目標座標をクリックすると、そこへ最短で到達しうる
「第一歩目の歩行方向」をクライアントが決定し、サーバへ送る
感じでしょうか。

設計初期には、移動目標を指定し、それ以上のメッセージ
送信は行わない方がローコストであろうと思い、そういう設計で
進めたのですが、上記のようにオブジェクト同士のすり抜けの
問題や、その他の整合性を優先するために、毎サイクル必ず１つ
のメッセージを送る方法をとりました。
（整合性においてはパーフェクトです）
これは一見とても無駄な通信ですが、実はそれほど状況は悪化
しなかったようです。C>Sは、メッセージの大きさが小さいですからね。
（UDPですので、エラーチェックもメッセージキュー的な物も
　自前でゴリゴリ書いてます）

問題は、やはりS>Cでして、サーバ側の回線が「使われていない」時間
があるのが、もっとも無駄だと考えます。
たとえば、ゲームを一定のサイクルで割ったとします。先ほども書きましたが、
１　C>S×人数分
　　↓
２　実質的な処理×人数分
　　↓
３　S>C×人数分
という流れですと「３」の時間のみ、回線がフルに使われるだけで、
残りの時間、回線がヒマな状態になってしまいます。
しかも、全クライアントは、自分から見えない範囲の者たちの
エントリーも待たねばなりません宿命に（笑）
これですと、プレイヤーはボタンを押してから、これらの長い行程を
へて、ようやく画面内が更新されるわけですから、とてつもなく
かったるいですよねー。
しかし、もしプレイヤー人数が少なければどうでしょう？
それならば、かなりあっという間にサーバからの返事が期待できます。

この手のゲームには千人なりのプレイヤーがアクセスする物が多いので、
そうはいかないのように見えますが、実は視野内にいるプレイヤー
は、それほど多くないはずです。これが自分の方法のヒントでした。