rPman

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

А вот вычисления, требующие доступ к оперативной памяти видеокарты (майнинг scrypt) будут нагружать ее по полной.

Я не знаю, пробовали ли вы этот вариант, основанный на утверждениях:
1. полностью вся карта игрового мира изменяется не сильно
2. обычно карту можно попытаться поделить на зоны или в тупом варианте ячейки (или точнее варианты перемещения между ними), которые так же меняются очень редко и не сильно
Простейший пример: пусть зоны — просто квадратные ячейки внутри простой сетки, размер ячейки сравним со средним размером препятствия на карте.
Более сложный пример: многоугольная область поделена на зоны по границам больших препятствий, и перпендикулярно пересекающие типичные пути движения юнитов (грубо говоря магистрали их движения), такую статистику в процессе игры собрать не сложно, сложнее выбрать размер зоны, как враиант — фиксировать количество таких зон от среднего количества юнитов в игре…
Тогда из соседних ячеек пути перемещения обычно либо в обход через соседние ячейки либо через соединяющую грань между этими двумя.
Размеры ячеек должны быть подобраны таковыми, чтобы вмещать некоторое (не сильно большое) количество препятствий… десятки или сотни.

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

Весь путь считать не актуально, достаточно рассчитывать в пределах 1-2 ячеек вперед (по уже известным вам алгоритмам) и получать ответ, есть ли вообще возможность попасть к цели. Добавить к алгоритму пересчет пути в зависимости от игровых объектов актуальных для расчета коллизий (тут проблема — возможны ли заторы).

Такие ячейки — это аналог памяти юнитов о том, как можно было бы примерно пройти в соответствующую зону.
Добавит даже больше реализма, например поведение при заторах, юнит как бы еще не видит что путь впереди закрыт, но послушно топает, пока не попадет в ячейку с этим затором… тогда возникнет событие что путь достигнуть нельзя… так как меду ячейками вариантов перемещения всегда несколько, это создает не один путь перемещения по ячейкам несколько, соответственно временно помечаем что путь закрыт и выбираем следующий.

Не надо мучиться, напишите на моно простейшее консольное приложение использующее штатный контрол WebBrowser (при запуске под mono используется firefox), и пишите всю логику на javascript, запуская тут же на этой же странице на onload (точнее его аналог события на контроле).
Оно действительно получается очень простым, вся логика влезает в javascript с использованием jquery (его можно грузить в отличный от '$' идентификатор). И при этом запускается такое приложение на любом самом дешевом vps linux.

Я думаю между этим приложением и своим на php обмен сообщениями осилите c простейшими push ajax запросами или даже websocket?

Выбор между с++ и java (добавьте сюда .net c# ) это больше не выбор между языками программирования и синтаксическим сахаром, а выбор между фреймворками (библиотеками) которые идут вместе (или для) с этим языком как 'стандарт по умолчанию'.
Тем более эти языки на столько похожи, они вышли то и одного лона 'старого c++'!

А это значит выбирайте то что вам нравится, но будьте готовы просто выучить еще один фреймворк (и чуть чуть языковых конструкций), ведь программист, не готовый изучать что то новое… слабовато выглядит и заранее обречен на провал.

В winXP я спокойно запускал приложение, сохранив его exe в атрибутах к текстовому файлу, запускается даже из командных bat файлов.
a.txt:b.exe

p.s. Сейчас проверил в win7x64, не получилось вообще прочитать любой поток (хотя данные пишутся и разные утилиты показывают его наличие).

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

В данном конкретном случае лучше постараться избежать сохранение и использование текстового представления таких неоднозначных вещей как вещественные числа и даты… первый же запрос в гугл на вашу задачу — сериализация вещественного числа в целочисленном представлении: stackoverflow.com/questions/4733147/portability-of-binary-serialization-of-double-float-type-in-c

При необходимости — серверную часть делать на какой либо SAAS платформе, например google app engine (хотя в вашем случае там так мало кода что нет разницы на чем делать… php/asp/..)

Клиентскую часть можно сделать на ru.wikipedia.org/wiki/Twitter_bootstrap

Формально, да, даже просто набор констант по уму объект права. К тому же бывают такие *.h файлы, в которых больше кода чtм в *.cpp.