Белый Барс

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

В разных играх разная реализация. В Dead Air (как писал сам автор) реализовано при помощи фейковых аномалий. При подходе/срабатывании играются партиклы имитирующие пыль. Но тут стоит отметить, что партиклы не затеняются, а значит к солнцу отношения не имеют. Для реализации чего-то подобного необходимо смотреть на реализацию светового блика от солнца и варианты Dirty Lens shader (которые описывались многими разработчиками еще в незапамятные времена, например KD).

Без указания цели вопрос не совсем корректен. Если не требуется взаимодействие с "внутренними" объектами, то достаточно общего шейпа. Если требуется (для каких-нибудь анимаций/разрушения), то это делается так: на внешнее кольцо подшипника вешается 1 цилиндр, на внутреннее 2ой, а на шарики сферы. При выстреле (условно) в данную модель, смещается внешний шейп (внешнего цилиндра). Анимациями или просто физикой. После чего остальные становятся доступными для воздействия. В остальных случаях, как уже написали выше - достаточно общего шейпа. P.S: я вижу это ~так. Так что тут необходимо точно понимать с какой целью нечто подобное делать.

Точно не уверен в причине, но... Скорее всего связано с работой движка. Т.к. в том же СДК есть определенные ограничения при выставлении параметров (которые заключаются в округлениях/кол-ве после запятой). Вероятно при компиляции все это происходит автоматически (почему не только в 3d редакторе, но и в игре видны изменения).

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

Самое интересное, что все обсуждение происходит на уровне сравнения. Но при этом упоминая PP, вы точно так же руководствуетесь догадками или восприятием в отдельно взятых моментах. Т.к. это получается выдирание из контекста (для чего и по каким причинам так сделано). Это еще 1 причина, почему в сравнительной форме обсуждение получается не корректным. Писать о том, по каким причинам что-то реализовано так, а не иначе, я не буду (т.к. тема модификации превращается во что-то другое). То-бишь вы просто уходите от рассмотрения каких-то аспектов Enchanced в сторону философских вопросов (которые можно отнести практически к любой разработке).

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

Опять "додумываете"? Я написал по поводу реакций. Понятно же и так, что в 1 теме человек написал, что не со зла постит. В другой теме написал о том, что ему понравилось (именно эти тезисы мной и отмечены реакциями). ----------- Как раз по этой причине я и написал тут. Потому что обсуждение началось в данной теме. Иначе какой смысл был бы писать об этом здесь? Но об этом я написал выше. ---------- Очевидные вещи. Странно, что их приходится объяснять построчно.

Реакции не имеют возможности выделять тезисы, только посты целиком. Точка зрения выражена текстом. Вообще удивительное умозаключение, т.к. в подобном случае не было бы смысла вообще как-то комментировать сообщения человека. Как показывает практика, многие любят "додумывать" что-то. Не понятно только, с какой целью.

В целом аналогии понятны. Мы с Михаилом (Разработчиком LA DC / Extended, на основе которого создана данная разработка) довольно продолжительное время плотно общались. Большинство взглядов на те или иные аспекты были схожими (возможно даже оказало некоторое влияние). Однако не стоит забывать, что подходы и отдельные нюансы - авторское видение. Что-то вполне может отличаться. Задача ведь не в том, чтобы создать кальку, а продемонстрировать задуманное так, как это видит автор. Честно говоря, понятны так же и вопросы по г. дизайну (отчасти они не лишены смысла). Но очень не хотелось бы наблюдать сравнения проектов в негативной форме. Т.к. непосредственно между разработчиками отношение всегда было хорошим, из-за чего прямое сравнение выглядит не совсем уместно, как прокомментировали выше. Лучше доносить информацию с позиции конструктивной аналитики непосредственно до разработчиков. Возможно они примут какие-то детали во внимание. Всем добра.

Ок) Просто довольно сложно объяснить в 2 словах. Из-за этого пришлось максимально скомпоновать информацию. Проект уже прошел не малый путь разработки. По этой причине объяснения без какой-либо предыстории выглядели бы туманно. Но опять же, пояснения есть все там же:

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

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

@ASSASIN64

Согласен. Я выдвигал аналогичное предложение на момент обсуждения внутри команды. Выбор был сделан исходя из привычной визуализации (даже посты выше подчеркивают, что игроками часто движут "привычки"). Миникарта выводится нажатием, она не вырезана. Любые изменения тестируются во время разработки и после (штатными тестерами). Это говорит о чем? Что не возникало ситуаций, при которых это было бы делать неудобно. Запрос на альтернативное отображение есть. Мы это знаем. Вопрос в другом: "Зачем миникарта требуется на постоянной основе"? Почему-то игроки считают, что вопросы со стороны разработчиков синонимичны отказу... Разве я писал, что это делать не нужно? Я спросил о причинах. Раз люди не в состоянии вести дискуссию, то возникает вопрос о надобности (именно в такой последовательности). Т.к. простой вопрос подразумевает адекватность ответа и, как следствие, понимание того, что игрок адекватен в своем запросе.

Работа с комьюнити подразумевает фидбэк. Вопросы задаются с конкретной целью. Обратная связь необходима для понимания возникающих затруднений. При чем тут "фудожники" - вообще не ясно. Говорить о привычках на основе оригинала можно, но не у всех игроков они одинаковые. Минимализм был выбран исходя из тех же запросов. Противоречивость можно наблюдать даже в рамках выбора отображения бары (полоски) из ТЧ, либо система "светофор", привычная для ЗП. Сам по себе выбор является предпочтениями (тех же игроков). Вопрос на тему миникарты не является случайностью. Он демонстрирует, что игроки сами не знают с какой целью на неё необходимо постоянно смотреть. Если отбросить вопрос функциональности, то можно весь худ завесить множеством параметров (в том числе теми, которые обычно не выводились). Разработчику необходимо понимать надобность чего-либо. Реальная необходимость и "чтоб было" - разные вещи.

Под таким углом вопрос не рассматривался. Когда Д.Вася задавал вопрос на стримах: "А зачем тебе (кому-то там) постоянно смотреть на миникарту?" Никто даже не смог ответить. Потому что подобных ситуаций (видимо) никогда не возникает. В тех случаях, когда игрок не участвует в перестрелке, то 1 пальца достаточно для использования. И даже с учетом этого миникарта не была вырезана, а осталась в таком вот виде.

Все зависит от контекста. Если в игровых реалиях, то можно заметить, что система урона имеет разовое воздействие или длительное. Со стороны визуализации "термическое" воздействие никакой разницы иметь не будет. Достаточно лишь отображения - соответствующих партиклов и т.п. Из этого можно сделать вывод, что чисто функционально подобная аномалия привнесла бы лишь элемент разнообразия. + или - температура будет являться чистой условностью. Для воссоздания более наглядных различий требуется создание "последствий", зависящих от типа урона. Условно: горение/обморожение.

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

Из-за того, что постановка вопроса такая. ЗОНА не может быть "правильной". Есть лишь различия логики игровых процессов, в рамках разных концепций. И далее по списку (на основе чего возникают дискуссии). Построение концепции может базироваться на разных элементах. Кто-то в качестве основы берет (выдирает из условного контекста) географическое положение и все, что с этим связано. Кто-то некий "быт" и жизнедеятельность сталкеров (причины их нахождения там). Другим важен смысл образования ЗОНЫ и уже от этого выстраиваются логические цепочки. Одно только это предполагает, что развитие идеи и ключевые моменты (от которых отталкивается разработчик) могут различаться уже на самом же первом этапе.

Правдоподобной м.б. только симуляция. Даже г.дизайнер ТЧ на эту тему высказывался. Но сталкер - это симбиоз, допускающий наличие игровых условностей. Нельзя быть "наполовину беременной", как говорится. Вот об этом я и писал ранее. Вся путаница возникает на уровне базовых понятий. Когда в одну кучу сваливается все "реалистичность" - она же симуляция/логика игровых процессов - иногда допускающая условности/разные взгляды на сеттинг и концепцию в целом. С таким подходом к вопросу даже компромиссы вряд ли возможны.

Это не отмазка, а отсутствие г.дизайнера в проекте. Подобные ситуации возникают: 1) Без надлежащего объяснения и грамотной подачи. 2) Наличие концепции, без возможности (желания) реализовать в соответствии с ней. P.S: среднестатистический игрок/разработчик может ощущать некое несоответствие только с точки зрения "вкуса"/логики/сопоставления, но в отсутствии г.дизайнера этого может быть недостаточно.

Обычно все подобные "недопонимания" возникают по 1 довольно банальной причине - разное понимание одного и того же. Почему в gamedev используется терминология. На уровне модостроя люди не всегда могут дать точное определение тому, что хотят объяснить. Под "реализмом" часто подразумевается симуляция, под "васянством" отсутствие выдержанного сеттинга или дизайна. Из этого часто проистекают противоречивые высказывания даже со стороны игроков. Таких примеров много. Скажем игроки допускают тот факт, что лечение длится секунды/вымышленные существа разгуливают по игровому миру и т.д, но другие игровые условности вызывают негодование. Почему? Потому, что путаница происходит на базовом уровне. Не соответствие элементов того же сеттинга (условно розовых пони) с не логичностью их нахождения в ЗОНЕ. Потому что эти вещи относятся к разным аспектам (хоть могут не соответствовать по всем из них). Странно, что такое огромное кол-во людей пробует себя в геймдизайне/занимаются этим/обсуждают, но до сих пор в массах противоречия возникают (реально) на ровном месте. Мне кажется, что надо сначала расставлять точки над "i" в данном направлении.

Изначально планировалась иная концепция. Именно с этого ракурса следует рассматривать подобные вопросы. ЗОНА не является отправной точкой. Из-за чего у многих возникает недоумение по тем или иным вопросам. Другими словами - сеттинг и "основополагающие аспекты" (по мнению многих) являются вторичными. Одну (первоначальную) концепцию спроецировали на другую. Но дело в том, что столь грубый подход не имел возможности/механизмов для слияния данных концепций. Требовались "условные переходники"/мосты между ними. Именно благодаря этому "сплав" перестал выглядеть противоречиво. Если же за основу брать тот подход, который подразумевается в заданном вопросе, то искать ответ в игре - бессмысленно.

Все он понимает. Ладно. Дальше уже будет не по теме, так что не хочу оффтопить. Напишу лишь 1. К человеку нужно относиться по человечески. Тогда возникает взаимопонимание.