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

Скриншоты : (03/08/2010)

На подходе также и другие возможности, на сей раз уже более новые, это в основном ИИ, но об этом позже.

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

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

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

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

Такие вещи как здоровье, или возьмем - уклонение от удара, что пытался показать автор - довольно часто для уклонения делается целый алгоритм, задействующий не только сами формулы но и другие данные, как данные от искуственного интеллекта, данные о геометрии уровня и окружения и т.д., то есть может иметь размер несколько листов формата А4, размер шрифта 10, хотя бы Ариал.

Вычитание по формуле x = x - y, это уровень я не знаю точно... вероятно 5 класса и базовых уравнений. Надо ли об этом писать статью... это другой вопрос.

Бывали, только не с играми. Лет 10 назад я разрабатывал мультиплеерный чит для КС 1.5 Сам я его нигде не пиарил да и не выкладывал, это делали другие люди, я просто разрабатывал и отсылал готовый чит на один из крупнейших американских читерских порталов, то есть 0 day релиз был только в США. Потом в течение дней 2-3 чит уходил в Европу, в основном на германские порталы по теме, которые также писали и обзоры для разных читов и моего в том числе. Далее как обычно, игроки в контру качали чит, обсуждали на форумах и т.д.

Сам я в распространении не участвовал и также поддержку пользователей не проводил, хотя в США чит считался одним из лучших в те времена и в своей категории, меня этот факт не сильно волновал (вообще то мне было плевать на отношение пользователей, я просто делал свое дело).

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

То есть факт обмена пользователей читом или мнениями я считал как должное, поэтому меня это не удивляло.

Сколько геометрии (треугольников) у вас на уровне (сам уровень и модели в нем) сейчас и каково быстродействие?

Я не россиянин, но обычно понимаю раздельную и четкую речь.

Лицензия все равно есть на него, то есть использовать его это значит - стать зависимым от прав третьего лица. Не подходит. Тем более для официального релиза.

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

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

В движок точно нет, в конвертер наврят ли, так как должны быть конвертеры этого формата в 3ds от сторонних разрабов.

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

Проблемы будут с моделлингом, так как сейчас есть некоторые ограничения на геометрию уровня и на модели. Эти ограничения не количественные, а организационные. Сейчас получение уровня из 3ds формата требует наличия отдельных обьектов геометрии уровня (то есть уровень не может быть одним целым обьектом), которые должны быть обьединены в группы по текстурному признаку. За счет этого идет сильная экономия вызовов при рендере, так как в таких условиях вызов биндов текстур сведен к минимуму, без потери качества. То есть требуется вручную сформировать структуру уровня, так как в автоматическом режиме полностью корректно этого сделать нельзя было бы - компьютер не человек все-таки. По обьектам ограничения это тоже на геометрию - крайне желательно чтобы обьект был либо как одно целое, либо если он состоит из нескольких частей то допускается не больше одной текстуры на одну часть. Это значит что моделиться все должно определенным образом, и главное - текстуриться, то есть моделлер должен собрать все текстуры обьекта в атлас и маппить именно атлас. Пихать в обьект по 5, 10 и т.д. текстур - недопустимо, поскольку просаживает быстродействие, особенно если таких обьектов сотни.

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

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

Поэтому в плане удобства могу сказать только одно - моделлинг сейчас (даже выдирание чужого контента) это проблемное дело и требует ручной работы, обьем может быть разным - но на пересборку карты кс_милития я потратил около 8 часов. (и это только одной карты, без моделей).

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

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

Не помню, были шейдеры в CSS или нет, но во всяком случае без них CSS и мой движок будут выглядеть примерно одинаково, поскольку все ресурсы оттуда взяты в максимальном качестве, скрины я делал при анизотропной фильтрации (8х) без антиалиасинга и без вертикальной синхронизации. Чтобы было лучше, есть в принципе два варианта - достать более полигональные модели и более лучшие текстуры - например из Call Of Duty MW2 или даже просто MW, поскольку они все же лучше, плюс второе - это пост-обработка. Вообще я хотел бы как то собраться и достать моделей из COD MW, поскольку сам по себе движок такие модели и текстуры тоже потянет.

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

Пока что делал только физику для автотранспорта, для обьектов думаю делать самую простую. В основном большинство обьектов будут статичные, примерно как в играх COD. Делать возможность брать в руки и бросать вещи, как в HL2 или Crysis я не планирую. Основное что будет более-менее физическим - это разбитие стекла и также уничтожение транспорта и тому подобных обьектов.

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

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

Отдельные для уровня, моделей, анимированных моделей и текстур (4 формата на все). Возможные исходные форматы (из которых можно получить файлы в формате движка) это 3DS, SMD и TGA.

Большей частью для того чтобы у нас форуме были проекты, сделанные на своих движках с графикой уровня класса В (года так 2003-2005). Раньше не выкладывал поскольку собирал движок заново, обновлял форматы - за счет этого теперь анимации и модели на уровне ХЛ2 или КСС по качеству, раньше было на уровне ХЛ/КС. Также оптимизирован и переработан рендеринг и т.д. и т.п. То есть сейчас уже есть что-то, что уже можно хоть как-то показать.

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

Спс )

Скрины в JPG от 300 до 700 Кб

Ну как видишь )

Нет, это непосредственно слово, просто написано капсом.

Примерно с 2007 года, но с учетом того что работал я далеко не каждый день и не в течении всего дня, с большими иногда перерывами, то может быть год от силы наберется. Строк сколько я не измерял, около 100 .cpp и .h файлов практически без комментов.

Именно движок, поскольку при помощи ГУИ или скриптов ничего сделать нельзя, нужно писать код и компилить новую версию.

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

Попозже скрины подправлю, а то CrazyDazeGrout не все в jpeg сделал.

ОК, позже сделаю (думаю сегодня), и обновлю этот пост.

Да, именно. Проверить поменялось ли железо, что оно может т.д. А там пользователь сам настроит как захочет. То есть все бинды и настройки должны быть динамичны и настраиваемы.

You decide =)

Насчет ДХ я не в курсе, я с ГЛ работаю.

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