А почему, простите, jee исключается ? Что значит серверная часть должна быть "как консольная" ? Без сервера приложений вообще ? Тогда к чему вопрос "на чем захостить ServerSocket" (чтобы это значило).
Возвращаясь к тому, на чем писать - да на чем лучше знаете, хотите - действительно пишете на простом java.io, открывайте сокет и читайте из него свои json'ы, но это как-то уныло xD Можно написать консольное приложение на netty, например. Он из коробки умеет и json и кучу всего остального, плюс получаете в нагрузку много плюшек. Можно написеть rest-приложение, на Spring или Apache-CXF, например. Если у вас нет сложной логики, то можно зафигачить просто маршрут на Apache Camel, он из коробки умеет кучу интерфейсов. Поднять там rest-сервис, прочитать и распарсить json и отправить куда-то дальше можно буквально десятком-другим строчек кода.
Можно проще. Например сделать applet, но тогда пользователем нужна jre на их рабочих машинах. Можно сделать чат на сервлетах, примеры легко гуглятся. Например docstore.mik.ua/orelly/java-ent/servlet/ch10_03.htm
Ну если много (больше 100) одновременных сессий не используется, то пишите по упрощенной модели, thread per socket - каждое сетевое подключение обрабатывается в отдельном потоке. Ну с JSON все, имхо, понятно. Куча либ, jackson, json-simple. Ну и для работы с БД подучите jdbc, не вижу смысла для, наверное не сложного проекта, использовать какие-либо ORM. Да, ну и почитайте про java collections, наверняка потребуются какие-то удобнее структуры для хранения данных в памяти. С учетом того, что у вас многопоточное приложения, можете начать сразу с java.util.concurrent.
Ну вот точный алгоритм серверной части вам ессно никто не раскроет, так как компания на этом деньги делает и это ее затраты на R&D. Поэтому единственное что остается, чтобы понять как все работает - это реверс-инженерия со стороны клиента. Если кратко, то ответ [b]
victorvsk [/b] очень похоже описывает и механику травиана.
Вот тут есть пример как сделать клиента, который пишет и читает в разных потоках javatalks.ru/topics/7772
Второй класс в первом сообщении. Сделайте по аналогии.
А что в нем не так/противоречит моим словам?
Еще раз, вы можете использовать для разработки и для тестирования своего аппликейшна любые оракловые продукты. Как только вы решили использовать разработанный апп внутри своей компании, или у своего заказчика - неважно, вы должны купить лицензию.
Без разницы, один вы разрабатываете или внутри компании. Вот использование в продакшене без лицензий уже не разрешено. Oracle XE кстати это не касается, ее можно использовать и для коммерческих целей. Weblogic нет.
Возвращаясь к тому, на чем писать - да на чем лучше знаете, хотите - действительно пишете на простом java.io, открывайте сокет и читайте из него свои json'ы, но это как-то уныло xD Можно написать консольное приложение на netty, например. Он из коробки умеет и json и кучу всего остального, плюс получаете в нагрузку много плюшек. Можно написеть rest-приложение, на Spring или Apache-CXF, например. Если у вас нет сложной логики, то можно зафигачить просто маршрут на Apache Camel, он из коробки умеет кучу интерфейсов. Поднять там rest-сервис, прочитать и распарсить json и отправить куда-то дальше можно буквально десятком-другим строчек кода.