Разработка игровых объектов

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

10
задан Kev 2 October 2011 в 10:18
поделиться

11 ответов

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

Если я пишу:

new Ship(content, "resource", true, null, null, null, null);

Что делает второй ПУСТОЙ УКАЗАТЕЛЬ?

Это делает код более читаемым (но более подробный) для использования структуры для содержания параметров, если список параметров идет вне четырех или пяти параметров:

GameObjectParams params(content, "resource");
params.IsAlive = true;
new Ship(params);

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

5
ответ дан 3 December 2019 в 14:54
поделиться

Лично я нахожу чистое число конструкторов, у Вас есть немного нерасполагающее, но это - Ваш выбор, ничто существенно неправильно с ним :)

Относительно общей стратегии происходящих игровых объектов от общей базы это - довольно распространенный способ сделать вещи. Стандарт, даже. Я был склонен начинать использовать что-то намного более сродни MVC с невероятно легкими "образцовыми" игровыми объектами, которые содержат только данные.

Другие общие подходы, которые я видел в XNA, включают / вещи, которые можно хотеть рассмотреть:

  • Реализация интерфейса IRenderable вместо того, чтобы делать любой код рендеринга в основе или производных классах. Например, можно хотеть игровые объекты, которые никогда не представляются - waypoints или somesuch.
  • Вы могли сделать свой краткий обзор базового класса, Вы вряд ли захотите когда-либо инстанцировать GameObject.

Снова, хотя, детали. Ваш дизайн прекрасен.

7
ответ дан 3 December 2019 в 14:54
поделиться

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

Игры предоставляют себя очень шаблону Образцового Контроллера Представления. Вы явно говорите о части дисплея, но думаете об этом: у Вас есть векторы там, и т.д., и это обычно - часть того, что Вы моделируете. Думайте об игровом мире и объектах там как модели. У них есть положение, у них могли бы быть скорость и направление. Это - образцовая часть MVC.

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

Наблюдение, как я так уже записал о поведении Вашей модели, вот является другой вещью, которая помогла мне много: используйте стратегическую модель для создания поведения классов сменным. Стратегическая модель является также большой, если Вы думаете AI и хотите поведение изменить somewhen в будущем. Вы не могли бы знать это теперь, но через месяц Вы могли бы хотеть баллистические ракеты как ракеты по умолчанию, и можно легко изменить это позже при использовании стратегии pattenr.

Таким образом, в конечном счете Вы могли бы хотеть действительно сделать что-то как класс дисплея. Это будет иметь примитивы как Вы названными: поверните, переведите и так далее. И Вы хотите произойти из него для добавления большей функциональности или функциональности изменения. Но думайте об этом, после того как у Вас есть больше, чем поставка, специальный вид поставки, другой специальный вид поставки, Вы побежите на ад деривации, и Вы будете копировать много кода. Снова, используйте стратегическую модель. И не забудьте сохранять это простым. Что должен иметь класс Displayble?

  • Средства знать его положение относительно экрана. Это может благодаря модели его объекта в мире и чего-то как модель gameworld!
  • Это должно знать о битовом массиве для отображения для его модели и его размеров.
  • Это должно знать, должно ли что-нибудь препятствовать тому, чтобы он тянул, если это не обрабатывается механизмом рисунка (т.е. другой объект, закрывающий его).
5
ответ дан 3 December 2019 в 14:54
поделиться

Этот дизайн не разделяет части UI объекта и части поведения объекта, "модели" и "представления" так сказать. Это - не обязательно плохая вещь, но Вы могли бы найти следующие рефакторинги трудными, если Вы продолжаете этот дизайн:

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

Но если Вы соглашаетесь с этими компромиссами, и этот дизайн имеет смысл Вам, я ничего не вижу в высшей степени неправильно с ним.

4
ответ дан 3 December 2019 в 14:54
поделиться

Я очень интересуюсь Вашим методом хранения для вращения в векторе. Как это работает? При хранении углов X, Y, ось Z (так называемые эйлеровы углы), необходимо заново продумать эту идею, если Вы хотите создать 3D игру, поскольку Вы встретитесь вскоре после своего первого рендеринга злой БЛОКИРОВКИ КАРДАНОВА ПОДВЕСА

Лично мне не нравится так много конструкторы там, как можно предоставить 1 конструктору и установить все не нужные параметрические усилители в NULL. таким образом Ваш интерфейс остается более чистым.

3
ответ дан 3 December 2019 в 14:54
поделиться

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

В Вашем случае GameObject может иметь свойства как способность переместиться, будучи renderable, или имеющий некоторое состояние. Эти отдельные функции (или поведения) могут быть смоделированы как объекты и составлены в GameObject для создания функциональности, которой Вы требуете.

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

2
ответ дан 3 December 2019 в 14:54
поделиться

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

1
ответ дан 3 December 2019 в 14:54
поделиться

Кроме того, можно сделать структуру или класс помощника, чтобы содержать все данные и иметь многих конструкторов в структуре, тот способ, которым у Вас только должны быть конструкторы тонн в 1 объекте, а не в каждом классе, который наследовался GameObject

1
ответ дан 3 December 2019 в 14:54
поделиться

Я спустился по этому пути при первом создании игр в XNA, но в следующий раз я сделаю больше типа модели/представления подхода. Объекты модели были бы тем, с чем Вы имеете дело в Вашем цикле Обновления, и Ваши Представления использовались бы в Вашем цикле Ничьей.

Я вошел в проблему с не разделением модели от представления, когда я хотел использовать свой объект спрайта обработать и 3D и 2D объекты. Это вернулось к реальности грязное реальный быстрый.

1
ответ дан 3 December 2019 в 14:54
поделиться

Люди, здесь говорящие о разделении Модели от Представления, корректны. Для помещения это в большее количество разработчика игр ориентировало условия, у Вас должны быть отдельные классы для GameObject и RenderObject. Вспомните о своем основном игровом цикле:

// main loop
while (true) {
    ProcessInput();  // handle input events
    UpdateGameWorld();  // update game objects
    RenderFrame();  // each render object draws itself
}

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

1
ответ дан 3 December 2019 в 14:54
поделиться

Первая игра? Запустите простой. Ваш основной GameObject (который в Вашем случае более соответственно называют DrawableGameObject [отмечают класс DrawableGameComponent в XNA]) должен только содержать информацию, которая принадлежит всему GameObjects. Ваши живые переменные и скоростные переменные действительно не принадлежат. Как другие упомянули, Вы, вероятно, не хотите когда-либо смешивать свой рисунок и обновляете логику.

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

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

Другая вещь, которой необходимо опасаться... Не позволяйте своим плеерам выглядеть непосредственно или вниз на Вашей вертикальной оси, или Вы столкнетесь, как Peter Parker упомянул, проблемы Блокировки Карданова подвеса (который Вы не хотите смешивать с тем, если Вы делаете разработку игр для забавы!). Еще лучше... запустите с 2D (или по крайней мере, ограничьте перемещение только 2 размерами)! Намного легче, когда Вы плохо знакомы с разработкой игр.

Я предложил бы после Руководств по началу работы Клуба Создателей XNA прежде, чем сделать больше программирование, как бы то ни было. Необходимо также полагать, что поиск некоторых других более общих руководств по разработке игр получает несколько альтернативных предложений.

1
ответ дан 3 December 2019 в 14:54
поделиться
Другие вопросы по тегам:

Похожие вопросы: