KO3bMA, скажем так: UDK работает со скелетной анимацией. Еще там есть такая вещь как AnimTree, позволяющая смешивать анимации (таким образом куда проще сделать, скажем, анимацию, когда игрок одновременно бежит и стреляет - достаточно смешать анимацию бега и стрельбы), там же есть и Bone Controllers - управление определенными частями модели с кода (перемещение и деформация, например, повернуть голову персонажа в нужную сторону).
(это был пример возможностей и простоты реализации
Опять таки, возникает вопрос - нужны ли подобные возможности в игре? Насколько это выгодно с точки зрения производительности? Ведь, если ты сделаешь объект из нескольких объектов, еще и задашь им взаимодействие, игре придется просчитывать это все на ходу. Есть куда более простые методы реализации оного, при этом менее грузящие комп.
Tiodor, вот я теперь тоже так думаю. Не стоит нагружать игру микроконтролем. А вот насчет ресурсов я до сих пор сомневаюсь. Давать ресурсы за убийство, или все таки сделать специальное здание (как в PvZ)?
xDanteZx, не в моих привычках писать статьи о конкретно моих методах. Способности можно создать достаточно большим количеством способов, и не факт, что я использую лучший из них. Кроме того, сейчас я делаю ТД, и там этого способностей не запланировано. А если есть что рассказать, я и так это рассказываю (просто не в виде статьи), у меня специально есть отдел "Технические подробности" в конце ресурсов моего проекта.
Vampir1991, вполне можно реализовать режим как в PvZ (там было нужно направлять на укрепление растений зомби, при этом правильно продумывать, кого куда).
xDanteZx, есть такая штука, как fractured mesh, если ей задать параметр "взрыв", то куски полетят очень даже рандомно. Верней, соответственно своему положению в модели; было бы странно, если деталь на левой стороне полетела вправо.
KO3bMA, не пойму, так тебе нужен нормальный движок для игр, или подобие гаррис-мода? Зачем в игре управляемый физикой вентилятор? И транспорт, и всякие вентиляторы, и прочие вещи можно просто сделать анимированными моделями.
KO3bMA, Actor - это любой объект на уровне, при чем, необязательно видимый (источники света, и даже контроллеры игроков - такие же акторы, как и статик меши или браши). Вентилятор можно реализовать несколькими методами, в зависимости от того, для чего конкретно он нужен. В принципе, в движке реально реализовать управление физическим объектом через скрипт, в том числе, и задать ему постоянное вращение.
KO3bMA, со всех пунктов проблемы только с 3 пунктом. Описанное тобой - уже какой-то гаррис мод, а не редактор объектов. И да, интересно посмотреть, как это выглядит в игре. По остальным пунктам.
Если разобраться, то проблем не возникает.
Любой объект в игре может быть превращен в K-Actor - объект с полноценной физикой. Настройки довольно гибкие - например, можно закрепить актор на оси, сделав вывеску или калитку. Для физики скелетал мешей есть отдельный редактор, позволяющий разбить модель на части, рассчитать между ними взаимодействие и назначить каждой части физический вес.
Зачем браши? Есть террейн - поверхность, с которой ты можешь делать что угодно, подобно редактору рельефа в варике.
А также продвинутый редактор материалов, позволяющий создавать в том числе и шейдеры (например, cell-shading), система смешивания анимаций, удобная тулза для создания синематиков, редактор систем частиц, визуальный редактор игровой логики, позволяющий сделать очень многое без знания программирования, продвинутые звуковые эффекты и т.д..
KO3bMA, начнем с того, что язык этот процентов на 70 идентичен с Си, и изучать его не составит труда, если ты знаешь плюсы или шарп. Или наоборот, ты можешь начать изучение языков программирования с UnrealScript. Ну а сравнение с другими движками - сомневаюсь, что этот Neoaxis обладает настолько же продвинутым инструментарием, как UDK.
Сюжет чем-то напомнил To the Moon.
Тьфу, не заметил одну из первых строчек. Но все равно, сходство слишком на лицо. Очень вероятно обвинение в плагиате.
Karp1989, тебе не кажется, что ты что-то путаешь? По твоей ссылке обычная стратегия, дота имеет с ней столько же общего, как с вариком. Может, ты имел ввиду вот это? Ну и заготовкой под РПГ это можно назвать очень грубо.
Доделал хайполи для ног, теперь берусь за корпус.
Закончил какую-никакую хай-поли. Кончено, полностью назвать ее хайполи нельзя, так как это всего лишь доработанная лоу-поли. Но создавать модель с нуля мне было бы проблемно. В общем, скрины в самом посте.
Окей, кукинг нормалей показал, что каждую часть лучше "варить" отдельно.
Tiodor, Cinos, опять таки, не путайте движок и инструментарий. Да, на Unreal Engine инструментарий в принципе тот же, но в играх с полноценной лицензией вполне могли менять элементы движка.
По сабжу, ближайший вариант дал SSrunX, тем не менее, я думаю, наиболее точной будет эта ссылка. Кроме этого, на официальном форуме можно найти несколько интересных игр, которые близятся к концу разработки, или уже выпущены. Наиболее интересными я считаю Routine и Recruits.
KO3bMA, по правде, не знаю, будет ли польза в UDK от навыка, полученного в конструкторах. Для левел-дизайна куда больше подойдет скилл того же мапмейкинга старкрафтовского или вариковского, для игровой логики, если через Кисмет, понадобится навык работы с триггерами, а если через скрипты - то навык обычного ООП. Ну а остальное - это уже на месте учится (физика для моделей, источники частиц, различные кинематографические элементы).
У меня последовательность знакомства с UDK шла в таком порядке: первые пробы в редакторе уровней методом тыка - тутор по дизайну от Eat3D (все необходимые фишки) - тутор по Кисмету оттуда же - пара туторов по материалам - книжка по скриптам - куча туторов и статей по скриптам. Ну и остальное уже в ходе создания различных наработок.
KO3bMA, ответ на вопрос "с чего начать" сильно зависит от того, в каком именно направлении ты хочешь заниматься - создание контента, левел-дизайн, игровая логика.
Tiodor, думаю, ты меня не до конца понял. Я советую сделать систему отрядов, как в Disciples или Героях (но, соответственно, без самых героев), то есть, ты управляешь отрядом как одним юнитом, перемещая его по карте, а уже когда твой отряд встречается с другим отрядом, основной геймплей ставится на паузу (хотя не обязательно), а сражение происходит в отдельном окошке, между бойцами двух отрядов, при этом, другие отряды в бой вступать не могут. Лимит я советовал ввести именно на количество бойцов в отрядах, самых же отрядов может быть много.
Видео с Pocket Kingdom (качество не очень; на Симбе в то время не было нормальных записывающих прог)
Непосредственно бои на 03:20, 06:52, 08:19, 10:11. Правда, у игрока перекачанные юниты, так что враг очень быстро выносится.
Просто так можно наклипать 10000 воинов и поместить их в одну точку, соотственно атака будет огромной и бороться с ними бессмысленно)
Никто не мешает поставить лимит. Более того, огромные числа абсолютно не впишутся в игру. Как ты представляешь себе тысячную армию на крохотных островках, да еще и с постройками? В том же Pocket Kingdom в отряд помещалось максимум 4 юнита. А насчет "поместить в одну точку", я ж говорю - достаточно сделать битвы автоматическими, и у игрока не будет никакой возможности поместить всех юнитов в одну точку. И еще, даже если твои юниты могут скучковаться и атаковать одного врага, не стоит забывать, что в вражеском отряде может случиться абсолютно та же ситуация. А если у них впереди только один юнит, значит, сзади еще есть парочка магов или лучников, которые тоже будут атаковать первого твоего.
Tiodor, просто менее полигональные сферки в Модо выглядят не совсем как сферки(( В общем, я обнаружил, что делать нормали с хайполи для лоуполи можно и в самом Модо, что меня не может не радовать, так как я немного не въехал в методику Hard Surface в Браше.
Группировать воинов в отряды, которые считаются за одного воина и только увеличивают здоровье или как?
Посмотри Pocket Kingdoms, стратежка с элементами РПГ для NGage. Там ты создаешь отряды с разных юнитов, у каждого свои свойства, а бой происходит в реальном времени, с видом сбоку, и без участия игрока (за исключением общего параметра поведения юнита - защита, атака, поддержка и т.д.); ясное дело, что юнит может проходит сквозь другого юнита, а их порядок влияет, например, в кого в первую очередь попадет стрела или фаерболл. Анонимный минусовщик не дремлет. Может, это своеобразное проявление фанатства?
Ред. lentinant
» Unreal Engine / Unreal Engine
» Game Forge: Refraction / Постройка и ресурсы
» Unreal Engine / Unreal Engine
» Game Forge: Refraction / Частичная смена концепта: Рабочие и постройка
» Unreal Engine / Unreal Engine
» Unreal Engine / Unreal Engine
» Unreal Engine / Unreal Engine
Ред. lentinant
» Unreal Engine / Unreal Engine
» Unreal Engine / Unreal Engine
» Аниме / Обсуждение аниме и манги
» Unreal Engine / Крыша и башни
» Unreal Engine / Unreal Engine
Ред. lentinant
» Кельтское Ателье / Пост добра и мечты
Тьфу, не заметил одну из первых строчек. Но все равно, сходство слишком на лицо. Очень вероятно обвинение в плагиате.
» Unreal Engine / Unreal Engine
» lentinant'ов блог / Работник (WIP)
Закончил какую-никакую хай-поли. Кончено, полностью назвать ее хайполи нельзя, так как это всего лишь доработанная лоу-поли. Но создавать модель с нуля мне было бы проблемно. В общем, скрины в самом посте.
Окей, кукинг нормалей показал, что каждую часть лучше "варить" отдельно.
» Unreal Engine / В чём проблема
» Unreal Engine / Unreal Engine
Ред. lentinant
» T-Games / The Shatters
» Unreal Engine / Какие игры делали на UDK?
» Unreal Engine / Unreal Engine
У меня последовательность знакомства с UDK шла в таком порядке: первые пробы в редакторе уровней методом тыка - тутор по дизайну от Eat3D (все необходимые фишки) - тутор по Кисмету оттуда же - пара туторов по материалам - книжка по скриптам - куча туторов и статей по скриптам. Ну и остальное уже в ходе создания различных наработок.
» Unreal Engine / Unreal Engine
» T-Games / The Shatters
» T-Games / The Shatters
» lentinant'ов блог / Работник (WIP)
» T-Games / The Shatters
Анонимный минусовщик не дремлет. Может, это своеобразное проявление фанатства?