[keen]

Берем вариант что клиент спрашивает сервер раз в 100мс что рисовать

погоди, раз сокеты - то клиент сам ничего спрашивать не должен, зачем эти лишние действия и нагрузка сети.
клиент информирует сервер только об измененях (например если нажата клавиша), а сервер отвечает, типа "ок, информацию принял", плюс сам же, не дожидаясь никаких запросов, периодически рассылает всем клиентам информацию о состоянии игрового мира (дабы не было рассинхрона).

теперь касаемо визуализации.
рекомендую вот эту библиотеку - http://www.greensock.com/ , в некоторых тестах показывает производительность раз в 10 больше чем jquery.

вообще говоря, сам процесс отрисовки должен выглядеть примерно так:

засекаем время t1; рисуем игровой мир; засекаем время t2; считаем разницу (deltaT=t2-t1); отрисовываем игровой мир; переходим к началу.

то есть процесс отрисовки идёт с учётом дельты для того чтобы просчитать какие кадры спрайтов рисовать:
например есть у нас.. м.. спрайт бегущего игрока, частота кадров которого 10 герц (10 кадров в секунду, значит каждый новый кадр должен отрисовыватся каждые 100 мс).
допустим, у нас мощный комп и процесс отрисовки выдал дельту 50 мс.
тогда следующий цикл отрисовки по-прежнему должен выводить 1й кадр анимации бегущего игрока.
а если комп тормозной и отрисовал игровой мир за полсекунды (500 мс), то следущий цикл отрисовки начнёт сразу с 6го кадра.

зная дельту легко расчитать fps. и при высоких значениях все движения будут отрисовываться плавно, а при низких - резко, но - самое важное - от fps не должны зависеть скорости передвижения игроков в игровом мире.

ну вот например глянь на небольшую демку на webgl, которую я делал - там в исходном коде как раз хорошо виден тот принцип что я выше описал.
если бы всё отрисовывалось без учёта дельты времени, на слабых компах модель бы вращалась медленно, а на шустрых - быстро.