Соображения об игре-симуляторе

Question

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

Что-то более похожее на серию "Поселенцы".

Давайте предположим, что в данный момент мне не нужна графика , которой Я думаю, что смогу справиться.

Итак, мои сомнения следующие:

1. Должна ли каждая сущность быть классом, а каждая - иметь поток?
2. Должны ли сущности быть сгруппированы в списки внутри классов, и у каждого есть поток?

Если взять реализацию 1, будет очень сложно работать на машинах с низкой спецификацией и плохо масштабироваться для больших чисел.

Если взять реализацию 2, она будет лучше с точки зрения ресурсов, но тогда ...

Как мне группировать сущности?

1. Есть класс для домов в целом и список интерфейсов для управления этим?
2. Есть класс для определенных групп домов и Список объектов для управления этим?

а что за темы?

1. Должен ли я иметь упрощенный цикл основной игры?
2. Должен ли я иметь поток для каждой группы классов?
3. Как рабочие / транспортеры вписываются в картину?

Answer 1

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

 while( 1 )
{
    foreach( entity in entlist )
    {
        entity->update();
    }

    render();
}

Answer 2

MMORPG Eve Online использует Python без стеков и модель актера для эмуляции системы поток-сущность без попадания ресурсов.

Проверьте эту ссылку для получения дополнительной информации: http://harkal.sylphis3d.com/2005/08/10/multithreaded-game-scripting-with-stackless-python/

Answer 3

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

Я немного запутался в части вашего вопроса, касающейся занятий. Если я правильно понимаю ваш вопрос, я бы предложил создать класс для каждого типа дома (свиноферма, ветряная мельница и т. Д.), Основанный на общем абстрактном базовом классе House. Затем вы сохраните все дома в игровом мире в списке домов.

Answer 4

Хотя ответ @Mike F в основном правильный, вы должны иметь в виду, что итерация по объектам в цикле foreach делает порядок оценки существенно детерминированным, что имеет нежелательные побочные эффекты. С другой стороны, введение потоков открывает возможности для heisenbugs и проблем параллелизма, поэтому лучший способ, который я видел и использовал, основан на объединении двух циклов: первый собирает действия от агентов / работников на основе предыдущего состояния второй цикл объединяет результаты действий и обновляет состояние симуляции. Чтобы избежать возможного смещения, в каждом цикле порядок оценки рандомизирован. Это, кстати, масштабируется до массовой параллельной оценки при условии синхронизации в конце каждого цикла.

Answer 5

Подумайте об использовании Erlang. С Erlang вы можете создавать намного больше процессов (= легкие потоки), чем обычный системный поток. Далее он распределяется, то есть если ваша система недостаточно хороша, добавьте еще один узел.

Другой альтернативой будет python без стека (или текущая альтернатива python), так как он также поддерживает некоторый тип lightweightthread, что очень здорово для игровых движков. Eve Online использует его для своих серверов. Но это не распространяется, но это может быть легко достигнуто вручную.

Answer 6

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

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

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