Nano Hash - криптовалюты, майнинг, программирование

Идентификация потоков в игре (также связанных с TCP)

Это школьный проект, пожалуйста, не указывайте код, я только ищу подсказки, которые направят меня в правильном направлении.

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

Цель этого проекта — получить опыт работы с Java, TCP и многопоточностью.

В моем текущем дизайне и реализации есть 2 файла: server.java и client.java.

  1. Файл сервера имеет 3 класса: Сервер, Лобби и Игра.
  2. Файл клиента имеет 1 класс: Client.

Реализация "игры" тривиальна, меня это устраивает.

В настоящее время класс сервера устанавливает TCP-соединение с классом клиента. Каждый раз, когда создается экземпляр клиента, сокет принимается в классе сервера, и программа продолжается.

Продолжая, класс сервера создает класс лобби.

У меня проблема с классом лобби. По умолчанию я создаю 1 «игровой» объект и передаю clientSocket:

game g = new game(clientSocket, playerID);                 
g.start();

Класс игры расширяет поток, и я считаю, что это правильный способ сделать это. Каждая «игра» будет, так сказать, отдельным потоком, поэтому игроки A и B могут совместно использовать 1 поток, а игроки C и D могут начать новую игру с другим потоком.

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

Прямо сейчас, когда я создаю 2 экземпляра клиента, они оба присоединяются к одному и тому же «потоку» (они оба находятся в одной игре и могут общаться друг с другом).

Как я должен это сделать, чтобы новый игрок мог ввести «новый» или что-то еще в лобби и создать новую «игру», где это новый поток.

Я уверен, что неправильно понял некоторые части о многопоточности или еще о чем-то, но я ценю любую помощь.



Ответы:


1

Во-первых, я бы посоветовал вам прочитать о разработке многопользовательских игр и организации сетей на Java (UDP/TCP). Я не разработчик игр, но просто случайно прошел курс Java по сети в колледже, и у меня был похожий проект (сетевая игра).

Во-вторых, работа с несколькими потоками пропорциональна сложности. Вы хотите минимизировать сложность. Я бы посоветовал отказаться от менталитета «Мне нужно найти место для использования потоков». (Не втыкайте квадратный колышек в круглое отверстие ;))

Далее, следуя требованиям:

Напишите и протестируйте игровой сервер, на который подписываются клиенты.

IIRC, это довольно просто (и вы, вероятно, прошли эту часть).

После подписки клиент получает список игр (одна и та же игра, просто разные ее «экземпляры»), которые в настоящее время разыгрываются

Это также должно быть довольно просто, поскольку TCP-соединение между сервером и клиентом уже установлено.

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

Еще одним соображением на этом этапе является объем клиентских функций в системе. Типичной реализацией, вероятно, будет архитектура толстый сервер, тонкий клиент. По сути, это означает, что клиент не выполняет реальной обработки данных (вводимых пользователем) и вместо этого полагается на сервер. Таким образом, большую часть времени клиент ожидает только ввода от пользователя или ответа от сервера. С другой стороны, сервер занимается обработкой данных от клиентов, обновлением состояния системы (включая отдельные состояния игры) и уведомлением заинтересованного клиента о соответствующих изменениях в состоянии системы/игры.

Затем клиент может присоединиться к игре или начать новую

На самом деле здесь происходит отправка клиентом данных «Я решил присоединиться к игре» или «Я решил создать игру» на сервер. Сервер действует в соответствии с этим и уведомляет заинтересованных клиентов (я говорю заинтересованных, а не всех, поскольку некоторые клиенты могут играть, и им не нужно знать, появились ли новые игры).

Перед началом игры должно быть не менее двух игроков.

-

Система должна поддерживать несколько клиентов, играющих в одну игру, или несколько клиентов, играющих в несколько игр.

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

Наконец, что касается использования потоков. IIRC, диспетчеризация отдельных потоков для открытых сокетов полезна для предотвращения блокировки приложения в ожидании ввода. Я не совсем согласен с вашей идеей «разместить» игру в треде, но, поскольку вы учитесь в школе, я могу только восхищаться вашими попытками.

Это может помочь вам в дальнейшем: Урок: Все о сокетах. Возможно, вас также заинтересует UDP.

09.02.2013
  • Большое спасибо за подробный пост. Я поработаю над проектом позже сегодня и отпишусь. Спасибо! 09.02.2013

  • 2

    Я бы не стал сопоставлять игры с потоками. Вместо этого сопоставьте клиентов с потоками. У каждого клиента будет свой собственный поток, работа которого инициируется получением команд от этого клиента. Когда вам нужно создать новую игру, просто создайте новый объект в общей коллекции игр. Отслеживайте в экземпляре клиента, с какой игрой он связан.

    Если вы обнаружите, что вам действительно нужен поток для управления игрой, вы можете создать его. Когда клиент отправляет команду в конкретную игру, просто поместите эту команду в очередь команд, которая считывается потоком, управляющим этой игрой. Игровой поток должен знать только, какой игрой он управляет. Он может завершиться, когда эта игра закончена.

    09.02.2013
  • Я действительно не понимаю этого ответа. Сначала вы говорите, что не сопоставляйте игры с потоками, но затем вы говорите, что игровой поток должен знать только, какой игрой он управляет, подразумевая, что вы уже сопоставили игры с потоками... 09.02.2013
  • @MirroredFate Я говорю это во втором абзаце, который начинается с если вы обнаружите, что вам действительно нужен поток для управления игрой. Например, вам может понадобиться, чтобы в игре что-то произошло, если в течение определенного времени никто ничего не делает. Лучше всего это можно сделать с помощью потока. Но реакцию на то, что сделал игрок, обычно лучше всего делать в треде, который понял, что игрок сделал это. 09.02.2013
  • Спасибо за предложение. Я скоро к вам вернусь! 09.02.2013
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

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


    © 2024 nano-hash.ru, Nano Hash - криптовалюты, майнинг, программирование