Архитектура движка игры. (54 стр)

чуваки, я вас всех люблю. я просто напился и мне грустно =((((((((((((((((((((((
не поймите меня не правильно
ну что ж у нас всё-таки за система образования такая, что не могут как в матане нормально всех обучать хотя бы 10 определениям? что за берд. ну почему всё так=(((((((((((((
всё ж могло бы быть так хорошо, архитектуры хорошие, игры, мы впереди планеты всей в индустрии...

вобще проблема реально глобальная. это само мироздание такое, ну как в за миллиард лет до конца света - должен быть где-то порядок, где-то хаос, но почему этот хаос должен быть именно у нас?! нечестно =( пойду лучше спать

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

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

Я заявил, что критическая оценка опыта полезна. Ты говоришь о нормальном поведении отцов, о перенятии опыта. Ты точно отвечаешь на мои слова? :-)

> chiaroscuro
> > поэтому рассматривать "монолит" в самом начале имеет смысл
> большинство тех кто выпустили игры его не рассматривали, так как еще в универе
> учат "разделять и властвовать"...

Кто там чего рассматривал нас (ну ладно, меня лично) не интересует. Интересуют разные подходы к структурированию движка (кода игры), их преимущества и недостатки. Повторю: подходы, а не их рассмотрение теми, кто выпустил игры.

> к модульным и компонентным архитектурам мы
> так и не подошли...

Конечно, ведь гораздо интереснее устроить срач с выяснением всех имен, явок и паролей. :)

> и вообще складывается ощущение что лектор пытается
> переделать под себя архитектуры ОС...

Опять же приписываешь лектору качества. Зачем?

Xunter
> тут и вопросов нормальных было раз-два и всё.

Потому что кое-кто не умеет спрашивать, обосновывать и вести спор (нацеленный на выяснение истины).

> сомнению кхм.. подвергалась возможность заранее собрать все требования и все
> спроектировать.

Да ладно, какое уж сомнение. Давайте называть вещи своими именами.

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

Гамедьев
> ну что ж у нас всё-таки за система образования такая, что не могут как в матане
> нормально всех обучать хотя бы 10 определениям? что за берд. ну почему всё
> так=(((((((((((((

Программирование -- очень молодая штука. До того же матана еще идти и идти. :)

chiaroscuro
> Потому что кое-кто не умеет спрашивать, обосновывать и вести спор (нацеленный
> на выяснение истины).
согласен полностью

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

почему ты критикуешь нас, а не задаешь вопросы лектору? ведь тебе интересна эта тема, значит есть что спросить...

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

> Интересуют разные подходы к структурированию движка (кода игры), их
> преимущества и недостатки. Повторю: подходы, а не их рассмотрение теми, кто
> выпустил игры.
у не совсем тривиальных подходов (посложнее монолитов) к структурированию кода игры - откуда можно узнать преимущества и недостатки?

Вот как раз на это
>"у не совсем тривиальных подходов (посложнее монолитов) к структурированию кода игры - откуда можно узнать преимущества и недостатки?"
автор-докладчик и пытался навести здешнюю публику. Он хотел предложить им вариант инструмента для анализа и построения сложных систем, таких, как игра. Обладая им, возможно, удалось бы получить то, что так нужно многим простым смертным(исключая гениев) в т.ч. и разработчикам игр- уверенность в своих решениях и знание заранее, к чему выбранная модель может привести. А это- практически самое ценное в такой сфере, поскольку позволяет уменьшить заранее число тех самых "подводных камней" на пути разработки игры. Даже более, это то знание, которое наиболее сложно получить от "отцов" потому, что они перешли на другой уровень "реальности" и просто многие из них теперь не могут понять проблемы и дилеммы возникающие у "простых смертных". Вот поэтому есть такие, которые пишут вечно "костыли, недовелосипеды и т.д." у них не остается иного пути, нет необходимой информации, а получить ее, как видим совсем не просто. Классический путь ее приобретения - подход "проб и ошибок" или просто "набивания шишек", но так поступают чаще те кто остался "за бортом эволюции" в т.ч. и она сама за неимением иного пути. Цивилизованный человек по истечению некоторого времени способен приобрести возможность начать избегать "простых ловушек" и неприятностей именно благодаря развитию критического подхода и обучению. Создание моделей описания явлений и выработка стратегии принятия решения не просто "сначала делай- потом изучай что вышло", а "подумай, прикинь сильные и слабые стороны, выбери самый приемлемый на основании желаемых критериев и только потом начинай реализацию задуманного". Вот последнее - признак высокого развития личности в профессиональном отношении к делу. Оно и есть часть того самого процесса "проектирования", который автор-лектор пытается(надеюсь еще будит это продолжать) представить на простых "модельных примерах" заинтересованной аудитории. Причем, надо отметить, вовсе не "сферических...", а вполне реальных и понятных.

Xunte
>назови годный способ оценки и проверки кроме получения своего опыта
По вашему, ув. выходит нет иного способа узнать что наркотики- зло, яд, и т.д, кроме как самому их попробовать?
Пример грубый, но суть очень показательна. А для получения опыта, что "розетка бьется током и может убить если засунуть туда пальцы"- тоже нужно проверять самому, а с крыши 10-го этажа спрыгнуть- тоже нужно самому проверять? По моему, ответ очевиден- иной способ оказывается есть. Нужно строить модели, которые уже проверены ранее, к примеру, увидев что "лупа" направленная на солнце выжигает на дереве, не стоит ее направлять на себя.

Nub1981
> нет иного способа узнать что наркотики- зло, яд, и т.д, кроме как самому их попробовать?
да, потому что мы получаем это знание от общественного мнения, которое получает эти знания у тех кто пробовал их
> "розетка бьется током и может убить если засунуть туда пальцы"- тоже нужно проверять самому
да, очень сложно представить что это значит когда ни разу в жизни не било током, хоть и слабым
> а с крыши 10-го этажа спрыгнуть- тоже нужно самому проверять?
да, человек не будет знать что это плохо если не падал с более малых высот в детстве, и получил опыт
учимся на простых вещах, получаем опыт, и проецируем их на сложные, так мы живем, если это новость...

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

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

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

Nub1981
> Он хотел предложить им вариант инструмента для анализа и построения сложных систем, таких, как игра.
ждем, надеемся, верим.

> Цивилизованный человек по истечению некоторого времени способен приобрести
> возможность начать избегать "простых ловушек" и неприятностей именно благодаря
> развитию критического подхода и обучению.
на счет "простых ловушек" я в этой теме неоднократно писал - есть конкретные вопросы - спрашивайте тут, на этом форуме - с неплохой вероятностью ответят. а на главный вопрос всего сущего - можно ответить "42" - тебе это поможет?

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

> По вашему, ув. выходит нет иного способа узнать что наркотики- зло, яд, и т.д,
> кроме как самому их попробовать?
ну или поверить на слово, что некоторые упорно не хотят.

> Нужно строить модели, которые уже проверены ранее, к примеру, увидев что "лупа"
> направленная на солнце выжигает на дереве, не стоит ее направлять на себя.
да, но если человек направив на себя лупу от луны начинает говорить о том, что круто от любого светила ее направлять на себя - то что ему и окружающим стоит говорить тем, кто видел как или сам направлял от солнца? а если тот человек при этом упёрт и никогда не видел солнца?

Собственно то что я хотел сказать "со своей колокольни" я уже написал касательно формата общения.
А теперь можно и вопросики задать:
1. Чем в архитектурном плане отличаются рендеры у 3д-пакетов(таких как 3д-макс, майа и т.д.) от игровых?
2. Подозревая, что основные различия в устройстве сцены, спрошу: какая из использованных в них схем считается наиболее удачной на сегодня?
3. Какие вообще архитектуры 3д-движка известны и наиболее актуальны в нынешнее время?   
4. Стукнул еще такой момент: какие компоненты, подсистемы или еще как их назвать рационально выносить в отдельные потоки, т.е. распараллеливать?
п.с. было бы здорово увидеть схемки таковых.:)

Nub1981
мы как раз этого и ждем... уже 70 страниц, а нас все кормят недостатками монолита, а теперь еще и слоями...

Nub1981
// я не специалист

1. рендеры.
Я не знаю что там внутри.
Но предпологаю, что програмы для создания полигон-модэлек можно сравнивать лиш с "редактором этапов для игры".

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

Думаю, что рендер не является частью игры. Если его делает "тот-кто-хочет-сделать-игру", то это печаль.
Я сам несколько раз кое-как собирал оболочку OpenGL аля "рисовальный клас" для своих игр - это не дело
для человека, который хочет делать игру. Однако, мне это было интересно, как альпинисту некая гора.
// Вероятно, есть готовые удобные библиотеки "для создания игровой картинки", но я не пробывал.

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

3. ничего не понял. Наверно, это снова про "устройство сцены" плюс обязательность Vec3( хикс, угрик, зэд).

4. Потоки исполнения - для меня это самая ужасная тема.
Я как-бы против "открытых для фрилансера потоков" (фрилансер - все прогеры вне-интэл-микрософта).
Хотя для себя изобрёл "систему фигур" (entity system), в которой несколько фигур могли-бы на разных
ядрах одновремено обновляться и не получать глюков.

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

Nub1981
> 1. Чем в архитектурном плане отличаются рендеры у 3д-пакетов(таких как 3д-макс,
> майа и т.д.) от игровых?
разными задачами. вторым надо быть более-менее риалтайм, от этого они более другие.

> 2. Подозревая, что основные различия в устройстве сцены, спрошу: какая из
> использованных в них схем считается наиболее удачной на сегодня?
универсальной "удачной" сцены для всех игр нет.

> 3. Какие вообще архитектуры 3д-движка известны и наиболее актуальны в нынешнее время?
ждем. еще не плохо-бы уточнить, что такое 3д-движок )

> 4. Стукнул еще такой момент: какие компоненты, подсистемы или еще как их
> назвать рационально выносить в отдельные потоки, т.е. распараллеливать?
http://blog.gamedeff.com/?p=303