Соображения о симуляционной игре

Question

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

Что-то больше похоже на серию поселенцев.

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

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

1. Если каждый объект будет класс и каждый из них имеет резьбу?
2. Должны ли сущности быть сгруппированы в списки внутри классов и у каждого есть поток?

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

Если требуется реализация 2, это будет лучше с точки зрения ресурсов, но потом ...

Как я должен группировать объекты?

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

а как насчет потоков?

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

Answer 1

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

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

    render(); 
} 

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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