Gamedev LectureФорум

Лекция #33. Плюсы и минусы игровых "орхетектур". [Лектор - dDIMA] (комментарии)

#0
22:27, 3 июля 2007

Лекция #33. Плюсы и минусы игровых "орхетектур". [Лектор - dDIMA] (комментарии)

Это сообщение сгенерировано автоматически.

#1
22:27, 3 июля 2007

Спасибо за лекцию!!! Оч интересно! Зачетная трава! :) Я серьезно, очень познавательно. Только она как-то кончается внезапно...
>[00:09] <_Winnie> dDIMA, не раскажешь про ошибки в разрезе скрипт <-> C++ ?
>[00:10] <_Winnie> и про разные разрезы, при которых не больно.
>[00:11] <dDIMA> не больно - если прочитать заапрувленый диздок, обсудить его с гейм-дизайнером и со скрипт-программерами, после чего вынести нужное

Это окончание?

#2
22:44, 3 июля 2007

Да. Это вопросы и ответы. Это последний вопрос, про ошибки (в разрезе скрипт <-> C++) Дима не рассказал.

#3
4:07, 7 июля 2007

Насчет ошибок скрипт <-> C++ (мне кажется, что я про это говорил) есть 2 основных момента:
1. Неправильное разделение между функциональностью, которая должна быть вынесена в С++ код и функциональностью, которая действительно является level-depend и должна быть реализована в скриптах. К сожалению, очень часто бывает, что производительность игры при оптимизации реально упирается в скорость Lua/JVM/... без возможности дальнейшей оптимизации
2. То же самое, но в обратную сторону - когда сильно усеченная функциональность не позволяет задавать в скриптах актуально кастомизационные вещи.
Все остальное в этом разрезе - не страшно и не очень серьезно.

#4
22:10, 8 июля 2007

Да, точно, говорил - например, когда на скрипт вешают математику.
Но, например, в NewerWinter Nighs там в луа спец функции математические кажется были прибиндены, написанные на сях. (если ничего не придумал ;) ).
Суть понятна - золотая середина (как всегда, философский камень блин :) )

#5
10:21, 28 сен 2007

Картинки не открываются, а жаль - по тексту много ссылок на них.

<dDIMA> Такой анализ должен сопровождаться постоянным рефактором (хотя о его вреде я еще скажу ниже)
Ниже о вреде рефактора ничего не нашёл. :)

Насчёт чистого разделения игра/движок добавлю ещё один минус. Обычно движком занимается одна команда, а игрой - другая. Коммуникации при этом усложняются и ждать решения своих проблем со стороны команды движка можно дольше, чем если проектом целиком занимается одна команда. Кто-то из авторитетов говорил, что они отказались от такого разделения в пользу следующего: команда движка поставляет не готовые dll, а фрагменты кода - отдельные небольшие законченные решения.

Насчёт вариантов задания порядка вызова Update().
<dDIMA> Второй вариант более удобен для слабого связывания компонент игры и движка, но сложен как для реализации, так и для отладки
Имхо, связывания компонент там не меньше, чем в первом варианте. Просто эти связи описываюся в другом месте.

<dDIMA> На первый взгляд, получается дурацкая ситуация. Все персонажи будут испещрены кодом вида Fox::Render() { m_Model->Render(); }
Имхо, так не вполне оптимально: например, нельзя будет отсортировать объекты по типу модели перед рендером, что нередко увеличивает FPS. Ещё не раскрыт вопрос разделяемых данных между компонентами GameObject.

А вообще, лекция отличная. Респект. :)

#6
15:15, 29 сен 2007

картинки в студию!

Прошло более 6 месяцев
#7
9:32, 20 апр 2008

Картинки-то сохранились, дядя Дима?

#8
12:40, 21 апр 2008

dDIMA, к сожалению, удалил свой аккурант и больше здесь не появляется:(

#9
13:37, 21 апр 2008

aruslan
Где-то сохранились, надо будет пошукать...
Во, нашел на домашнем компе, зааплоадил в http://pics.livejournal.com/ddima/gallery/00001btk
Кто-нить из овнеров, поправьте, плз, ссылки на картинки на новые (внутрь моего ЖЖ)?

Прошло более 7 месяцев
#10
15:02, 23 ноя 2008

Эх, дядя Дима так и не поправил: в его мега-кодепасте http://www.everfall.com/paste/id.php?a434r6sa8vg9
вместо

/* clamp dt */
dt = min(dt, 0.001); // Max = 1000 FPS
dt = max(dt, 0.1);   // Min = 10 FPS

надыть

/* clamp dt */
dt = max(dt, 0.001); // Max = 1000 FPS
dt = min(dt, 0.1);   // Min = 10 FPS

А то всегда 10 fps буит.

Gamedev LectureФорум

Тема в архиве.