Лучшая форма IPC для децентрализованного рогалика? - PullRequest
0 голосов
/ 12 февраля 2012

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

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

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

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

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

1 Ответ

0 голосов
/ 13 марта 2012

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

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

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

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

...