Лучшая форма IPC для децентрализованного рогалика?

У меня есть проект по созданию roguelike, каким-то образом абстрагирует UI от движка, а движок от создания карты, линии сайта и т. д. Чтобы сузить фокус, я сначала хочу просто заставить UI (клиент игрока) и движок работать.

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

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

Итак, мне нужно выбрать, какая форма ipc подходит эта модель лучшая.

  1. Моя первая попытка использовала каналы, потому что они самые простые, и я написал пользовательский интерфейс для игрока и программу для передачи инструкций, таких как, где разместить карту и игрока. Хотя это работает, он позволяет только одному клиенту - общаться через стандартный ввод и выводить его.
  2. Я думал о том, чтобы сделать движок демоном, который смотрит в спул, где клиенты при запуске создают уникальные временные файлы для каждого клиента, чтобы давать инструкции движку и получать обратную связь.
  3. Наконец, я сделал небольшое вводное программирование с сокетами. Кажется, что они могут быть подходящим вариантом и позволят игре, возможно, когда-нибудь превратиться в сетку. Я бы хотел, если возможно, использовать более простое решение, и, поскольку я с ними не знаком, оно более подвержено ошибкам.
  4. Я всегда открыт для предложений.

person SplinterOfChaos    schedule 11.02.2012    source источник
comment
Когда каждый монстр использует своего клиента, ваша работа усложняется. Какие выгоды вы ожидаете от этого подхода?   -  person tomdemuyt    schedule 13.02.2012
comment
Я надеюсь научиться это делать. Я тоже рассчитываю получить от этого удовольствие. Если вы скажете мне, что я излишне усложняю себе задачу, это будет то же самое, что сказать: «Перестань веселиться».   -  person SplinterOfChaos    schedule 13.02.2012
comment
Достаточно хорошо, мой следующий вопрос: какой язык / платформу вы планируете использовать?   -  person tomdemuyt    schedule 14.02.2012
comment
Мой дом написан на C ++, но я недавно начал испытывать симпатию к C, что потребовало от меня разучивания большей части того, что меня учили о том, что делает код хорошим / плохим. Прелесть этого заключается в том, что каждый компонент может быть написан на другом языке с использованием разных библиотек, если интерфейс остается неизменным. Чтобы избежать преждевременной оптимизации, лучше всего использовать Python для исходного кода. У меня нет Windows-бокса, так что это полностью Linux. Кстати, я отправил X-сообщение на Tigsource, и обсуждение там гораздо дальше: tig post   -  person SplinterOfChaos    schedule 14.02.2012


Ответы (1)


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

  • mmap для совместного использования больших двоичных объектов данных с сокетами домена unix, очередями сообщений или именованными каналами для уведомления
  • то же самое, но с использованием отдельных файлов для каждого BLOB-объекта вместо того, чтобы объединять их все вместе в mmap
  • то же самое, но без файлов или mmap (другими словами, больше похоже на обычный обмен сообщениями)

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

Это также применимо: https://stackoverflow.com/a/1428542/1264797

person stevegt    schedule 13.03.2012