rPman

Когда то давным давно, еще до WFP используя обычные Windows Forms и классы Dataset писал сложную прослойку-кеш для базы данных, десятки таблиц. Речь шла о 'покликать лениво мышкой', вся база в памяти, сохранение штатным сериализатором (в ту же xml - две строчки кода), сотни мегабайт, работало с приемлемой скоростью.

p.s. Сказано что без sql? берите любую готовую nosql базу данных ;) например redis

Подключение обычные tcp сокеты (в udp пока не лезте, но с ними тоже реально).

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

От сервера передаете изменения содержимого экрана, по объектам, змейки, корм и прочее. Само собой при подключении вместо дельты сервер должен вернуть текущие координаты. При потере связи тогда все будет автоматом восстанавливаться. Разработайте формат сообщений, воспользуйтесь готовыми сериализаторами, не изобретайте паровоз, хотя...

На клиенте перерисовываете все это каждый раз как получаете данные от сервера.

Вся игра должна крутиться на сервере, тогда у вас не будет никаких проблем с расинхронизацией, читерством (кроме автоматизации) и прочим.

Недостаток - у всех пользователей будет небольшой лаг на действия, в зависимости от пингов.

К сожалению не все игры можно так реализовать, но частично да.

это вообще фича операционной системы, и точно знаю в win98 (плюсом) и в winxp это настраивалось твиками.

Смешная идея - javascript pdf viewer загрузить в WebBrowser, туда же закинуть свой pdf-файл
viewerjs.org
https://habrahabr.ru/post/122034/
и т.п.

Если сравнивать c# и java именно в направлении разработки desktop приложений, то c# объективно выигрывает.

Нет особой разницы на чем реализовывать вашу задачу, но лично мне удобнее клепать формочки на древнючем WinForms, чем на той же java fx (даже с использованием GUI построителей) реально меньше телодвижений, проще изучение, идеологические баги все простые.

Доступ к данным именно microsoft office это фигня, хотя я очень редко но встречал проблемные документы, доступ к данным которых был только из запущенного офиса средствами его языка (или interprop communication в c#, когда запускается скрытый офис и язык имеет доступ к объектам самого офиса и открытого документа), на java кажется это будет еще менее удобно.

Ваша задача очень эффективно решается обычным файлом на диске (открытый с запретом lazy writes, либо принудительным flush после каждой записи). Если инструментарий (язык программирования и библиотеки) позволяет - откройте файл маппингом на память.
Индекс для таких запросов не нужен, ведь ячейки можно индексировать примитивно - (x+maxx*y). запрос 100x100 блока превращается в 100 быстрых чтений по 100байт. Если это оправдано, можно хранить не ячейки а блоки 100x100, тогда при чтении будет читаться в 4 раза больше данных но четырьмя чтениями. Но если блок данных экрана влезает в буфер опережающего чтения операционной системы (драйвере файловой системы) то такой метод хранения будет неактуален.

Любой другой метод будет медленный либо по записи (например хранить в базе не ячейки а блоки 100x100, соответственно при запросе блока будут считываться четыре соседних), либо медленный по чтению (хранить по одной записи на ячейку) и не эффективный по месту на диске.

sqlite — одна из самых медленных реализаций на запись (на средней win машине от 100ms на транзакцию), даже у ms access быстрее, но чтение шустрое, плюс совместимость высокая (если нужно отдельный файл, значит нужно переносить с машины на машину? а sqlite есть под ВСЕ платформы)

nosql вообще сложно сравнивать с sql, наибольшая скорость (на порядок выше sql), но key -> value создает ограничения, и имеет смысл в основном для document-oriented баз данных, т.е. если у вас есть 1->m то придется сериализовать списки и следить за целостностью самим.