4 проблема:

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

Что это значит для игрока?
По большому счету, так же как и в пункте 3.

Как решить такой вопрос?
Тут нет однозначного ответа, появились всякие рекапчи, всякие капчи-игры и прочее, к сожалению, хорошо натренированная ИНС может решить почти любую неитерактивную капчу, т.е. (зачеркнуто)больше "экшона" больши пиу-пиу!(/зачеркнуто) решить такой вопрос не переделывая систему капчей не выйдет, т.о. привет ботоводам

5 проблема:

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

Что это значит для игрока?
По большому счету, так же как и в пункте 3, однако вам может повезти так же, что скрипт отработает некорректно (или вы сами через инструменты разработчика у браузера так сделаете) и вместо призыва защитника на свою сторону, вы его призовете на сторону врага, и он будет защищать не вас (грустно, да?)

Как решить такой вопрос?
Добавить проверку, "на какую сторону" призывается такой защитник.

Кстати говоря, скорее всего такой же трюк может быть выполнен и для всяких иных призываемых существ, так что, да настанет эра боя человек vs мышь и куча ос!
Муха-ха-ха-ха!


---
Дополнительные вопросы, что были во втором письме:
- почему не используете более агрессивное кеширование, скриптов/картинок и прочего?
- почему не используете пакетирование (объединение в один пакет нескольких запросов/ответов)?
- онлайн до 300-х человек, и думаю около половины - пассивные игроки, что сидят медитируют, работают и прочее, почему ваш сервис не может держать 300 конектов, насколько вижу, не слишком велика должна быть нагрузка, в чем просадка?
- у вас в БД содержится хренова туча "умерших игроков", у вас применяется архивирование и "урезание" базы?
- какова фрагментация баз?
- в таблицах используется принцип инсерт/делит или инсерт/дисейбл принцип? (удаление строк, когда данные не актуальны, или же проставление в соответствующим столбце выключено)?
- какая СУБД используется?
- как понимаю резервирования нет?