ZLOI_DED, Entity System в чистом виде штука довольно сложная для восприятия. "Сущность" в ней это всего-навсего числовой идентификатор и связанный с ним контейнер для "компонентов", представленных в виде данных, а весь код вынесен в глобальные "системы", которые выбирают интересующие их сущности по набору компонентов и выполняют с ними различные действия. При этом, например, событие нанесения урона цели тоже может быть сущностью - в компоненты этой сущности заносятся такие параметры как источник урона, тип, количество и, конечно, цель, затем соответствующая система выбирает все сущности с компонентами нанесения урона и применяет этот урон к цели, учитывая компоненты цели, которые могут содержать, например, общую защиту от урона или сопротивляемость какому-то конкретному типу урона. После обработки, естественно, сущность для нанесения урона уничтожается. Это не просто менеджер сцены или какая-то отдельная подсистема, это подход к построению архитектуры всей игровой логики. Я не предлагаю подробно писать об этом, особенно если ты сам с этим еще не сталкивался, но нельзя писать об игровых движках и не упомянуть эту тему.
Хорошо написал, мне понравилось)
Я понял о чём ты и это в действительности основывается на менеджменте сцены (всё-таки верну это название... оно правильнее будет), системе событий и устройстве ядра.
Просто я не предполагал управление сущностями вне какого-либо контекста, от которого они зависят, поэтому и поместил их внутрь управления сценой.
Если ты имеешь ввиду подход к построению игровой логики, а не конкретную систему движка, то это материал для ещё одного номера, в котором надо обозреть также и другие подходы, сравнить их, определить преимущества и недостатки каждого и т.п.
Так что благодарю, обязательно упомяну об этом подходе в одном из следующих номеров)
Entity System - я подразумевал как часть менеджера сцены. Отдельно обычно не существует.
Не имеет прямого отношения к сцене, не путать с аналогичной терминологией в юнити. Речь о data-driven организации игровой логики и соответствующем представлении всех игровых объектов. Сцена с её геометрией строится на основе данных из Entity System, но при этом Entity System может содержать не отображаемые на сцене данные и даже существовать отдельно от сцены в случае сервера. Сливать воедино объекты на сцене и игровую логику это дурной тон и больно кусается при масштабировании проекта - даже в движках позволяющих такое, желательно в объектах сцены оставлять только логику, связанную с отображением, а все остальное выносить отдельно.
Система анимаций вынесена отдельно, т.к. она занимается не связанной с физ. движком деятельностью.
Но ведь система анимаций это, как правило, тоже часть визуализатора, как и шейдеры.
Всё что является игровой сущностью должно находится на сцене (не обязательно иметь свойства нужные для отображения и пр.). Поэтому я обобщил в менеджер сцены. Сцена логическая, а не визуальная или физическая или какая-нибудь ещё.
А вообще можно переименовать в менеджер игровых сущностей, да, согласен.
А если система анимаций влияет на что-то кроме визуального результата, возвращаемого игроку? Тут не всё так просто.
Не упомянуты такие вещи, как Entity System (хотя далеко не все ими пользуются, конечно - сложная штука), многопоточность, система работы с шейдерами (странно видеть отдельно сетевую систему, систему анимаций и систему загрузки ассетов, но не видеть отдельную систему для работы с шейдерами). Кроме того, универсальная система событий далеко не всегда есть в наличии "из коробки", например готовая реализация может использоваться только для обработки пользовательского ввода, а дальше уже как хочешь, так и выкручивайся. Сетевая компонента тоже часто представлена не полноценным движком, а на уровне вспомогательной библиотеки. Также ни слова не сказано про специальные форматы для ассетов, которыми грешат практически все движки.
Вроде все, что с первого раза на глаза попалось, завтра перечитаю еще раз.
Entity System - я подразумевал как часть менеджера сцены. Отдельно обычно не существует.
Многопоточность - относится к устройству контроллера игрового процесса (ядру). Отдельно выделить нельзя.
Система работы с шейдерами - это часть визуализатора.
Про систему событий и сетевой движок... я специально сказал что данный список можно выделить очень часто. Т.е. не все так делают, но большинство.
Про спец. форматы - это обзорный номер. Не знаю почему они ими "грешат", но это так или иначе часть системы ассетов.
Благодарю)
система работы с шейдерами (странно видеть отдельно сетевую систему, систему анимаций и систему загрузки ассетов, но не видеть отдельную систему для работы с шейдерами)
Сперва подумал, что что тут странного, но раз система анимаций вынесена. То вопрос действительно остается открытым. ZLOI_DED:
Очень интересно узнать про реализацию сетевого движка.
Система анимаций вынесена отдельно, т.к. она занимается не связанной с физ. движком деятельностью.
А вот шейдеры привязаны к визуализатору и поэтому выделить их в отдельную систему не получается.
Хорошо. А что интересно? Как взаимодействуют клиент и сервер, какие протоколы используются, в чём их преимущества или всё сразу?)
Спасибо за фидбек!)
P.S. На самом деле здесь разделение систем даже более теоритическое чем то, какое бы вы делали в действительности. Т.к. смысла например, выносить систему событий из ядра, нет, но по сути это отдельная система, отдельный топик о котором можно говорить. :)
Kozinaka, берем любой движок с открытым кодом и получаем такой-же результат за гораздо меньшее время - что-то в нем придется переписать с нуля под свои нужды и видение мира, но остальные фичи останутся как есть или с минимальными изменениями.
Такой подход возможен, если тебя устраивает всё, что ты не собираешься переписывать и процент того, что ты не собираешься переписывать достаточно мал.
Приложи к статье к примеру успешные проекты со своим движком/инди-проекты и т.д
Этот движок, который я сейчас делаю... Ну скажем на нём есть демки, но они совершенно не заслуживают вашего внимания, друзья.
По какой-то причине я забыл добавить аналогичные примеры из индустрии и привёл их (списком) в статье.
Время, потраченное на его создание, окупится позже в виде экономии времени на отладке, улучшении и поддержке игры.
Лол
Личный опыт - да, просто чтобы знать как изнутри работают/могут работать другие движки. Все остальное того не стоит. Разве что если у вас супер специфические задачи (вроде майнкрафта/феза там).
Я так и написал в статье :)
0 - Наиболее эффективный способ обучения.
1, 3, 4 - Проблемы с супер специфическими задачами гораздо легче решать.
2, 6 - Разве это не так? Если игра будет не одна или игра планируется как долгосрочный проект?
5 - Так это вообще здорово.
Просто каждый оценивает для себя. ИМХО, если уверен, что хватит времени и энтузиазма - значит надо делать свой движок.
Для гейм-дев программера - это маст трай.
Я приболел чутка, но постараюсь в самое ближайшее время выложить новый номер :)
Благодарю за фидбек!
По теме производительности...
Я тут играл в Infinity... Карта вроде классная, но лагала как кот в дверном проёме когда ему открыли дверь. Особенно из-за анимированного курсора и прочей подобной херни, которую отключить конечно же невозможно. К тому же на той карте была совсем не удобная система боя и как-то поизвращались там с выделением впринципе, от чего сильно пригорало. Я конечно же за атмосферность, но постарайтесь не накосячить также как в той карте. Сделайте например настройку графики через команды:
-gfxGrassAnim on/off
и т.д. Спасибо! Проект действительно интересный и стоит времени!
Bariy vad, бред ZLOI_DED, джнгп сам выносит переменные в блок глобал ZLOI_DED, короче скрины с ошибкой и строкой на которую ругается в студию
В том то и ананас, что никто ни на что не ругается. Он просто берёт и не запускается. А всё что я сказал выше - мои наблюдения в сравнении.
Ещё важное замечание. JassHelper на старой карте сам выдаёт ошибки. На новых - херушки... Что за аншлаг? o_0
100% проблема в JassHelper'е! Не у меня одного такая фигня. На хайвворкшопе есть подобные темы, но там он хотя бы запускается, а у меня даже не запускается.
А я ландом занимался... не хотелось бы карту с нуля переделывать... Может есть у кого какие идеи?
UPD: Решилось установкой новой версии JassHelper и пересохранением карты через Сохранить как...
Возможно хотели присвоить локальной переменной значение глобальной?
Редактор UMSWE 5.0. Highlighter - TESH 0.7.
Этот редактор что из себя представляет?
Вы не так меня поняли. В моей предыдущей карте все триггеры были как-бы слиты в один и рассматривались синтакс-чекером так же (инициализация варика, кастом код, уже заключённый в global/endglobal, код предшествующих триггеров и код текущего триггера, в котором допущена специальная очепятка), а на новых картах - ничего подобного.
Флажки которые я смог найти все так же выставлены, так что смысла мало имеет.
Если не ошибаюсь то редактор прямо у нас на xgm распространяется.
Jass New Gen Pack 5d Exp2
Здесь нужно знать чё за фишка... а я вот забыл.
Ну в свою карту, где ты играешь не против игроков, а против крипов в любом случае не особо интересно играть, поэтому я так и не сделал не одной крупной пве карты.
"ИИ не должен побеждать игрока, он должен красиво ему отдаваться."
P.S. ZLOI_DED, если это возможно, сможешь выложить алгоритм действий поподробнее?
Делаем весы по следующему принципу: профит от выполнения задачи / сложность выполнения.
Т.е. для аттаки можно, к примеру, сделать так: кол-во монет за убийство / расстояние до врага.
executeTask()
{
switch (task)
{
case Attack:
if (target != null)
{
followAndAttack(target);
}
break;...
}
}
Базово именно так. Дальше можно всячески усложнить, добавив кучу разных других весов. Единственная сложность - калибровка. Тебе прийдётся запустить её с сотню раз, чтобы откалибровать весы, но это того стоит.
Как калибровать:
Сделай либо сисаут либо вывод прямо на экран весов.
Создавай ситуации и смотри как меняются весы.
Делай выводы и изменяй формулы (напр. эти олухи постоянно обирают монетки, когда должны воевать - увеличить профит от аттаки каким-нибудь модификатором или уменьшить профит от сбора монет. Эти глупцы постоянно деруться, когда должны убегать при лоу хп - увеличить мод побега или уменьшить мод аттаки).
...
PROFIT!
Ручная калибровка медленнее чем то что с нейронными сетями, но быстрее в том плане, что ты видишь лучше что поменять надо.
Сейчас как раз делал ИИ для демки. Циклы для подобного - полная жопа. Пытался детерминировать логику максимально, но всеравно выходили либо зацикливания (один тик я хочу пассать, один тик я бегу от гопников, а потом опять пассать), либо неправильные решения (вокруг куча гопников а я ссу). И тут я пришёл к гениальной мысли: сделать по теме синаптических весов из нейронных сетей. Саму нейросеть не реализовывать, но вот именно эту фишку взять. Т.с. берёшь входы и создаёшь весы выходов, составляя их по формулам из входов. Лучший вес выигрывает, задавая задачу на тик, а чтобы не было зацикливания - переопределение таска идёт лишь при определённых условиях (напр. поведение сильно изменилось, противник умер и т.д.). И дебажить можно легко! Вышло неплохо - всем рекомендую :3
Внезапно замолчавший, но с крайне притягательной идеей Space Station 133.
Сессия, депрессия, движок, агрессия, демку недопилил, ремнём не допороли, не хватило полироли. Извиняйте =]
Есть такая беда: я пока ещё работаю над движком, а не над игрой и даже представить не могу это как неповторимую идею, т.к. игра базируется на вселенной Space Station 13. Мог бы показать тек-демо движка, но оно было не доделано, ибо зачёты. А недоделанное до логического конца я показывать не люблю) А сейчас... сессия. Послезавтра экзамен по физике. Обожаю физику.
Тем не менее, я искренне рад тому, что вы вкладываете столько в XGM. Рано или поздно это всё вернётся вам сполна!
Было бы интересно узнать когда следующий конкурс... возможно к этому времени я смогу показать что-нибудь достойное этого мероприятия.
Спасибо!
Wow! Сначала они осилили кастом геймс, который у меня едва дышит... Все сразу понапилили карт с варика. Круто! Играем! Теперь они переходят на Source 2 и... копипастят овер 9000 строк кода и выкладывают наравне с Dota Test.
Вангую частые фиксы ещё полгода-год, активную кампанию по переходу на новый двиг от Гейба и просьбы маленьких мальчиков купить им новый камень, и амуду-карточку. Вот только переход значительной части аудитории на "Reborn" затянется.
По поводу патчей... ТыжПрограммист! В Valve приди - порядок наведи!
как насчёт минимапы в правом верхнем углу экрана? в виде HUD радара
Довольно часто складывается ситуация что тебе не видно в какой части карты находятся другие черви, думаю это было бы полезно).
Это и так видно - обрати внимание на маркеры по краям.
» Space Station 133D / Главная страница
» Space Station 133D / Главная страница
» Space Universe / Главная страница
» Space Station 133D / Записки велосипедиста #2 - Внутренности игровых движков
Я понял о чём ты и это в действительности основывается на менеджменте сцены (всё-таки верну это название... оно правильнее будет), системе событий и устройстве ядра.
Просто я не предполагал управление сущностями вне какого-либо контекста, от которого они зависят, поэтому и поместил их внутрь управления сценой.
Если ты имеешь ввиду подход к построению игровой логики, а не конкретную систему движка, то это материал для ещё одного номера, в котором надо обозреть также и другие подходы, сравнить их, определить преимущества и недостатки каждого и т.п.
Так что благодарю, обязательно упомяну об этом подходе в одном из следующих номеров)
Отредактирован ZLOI_DED
» Space Station 133D / Записки велосипедиста #2 - Внутренности игровых движков
А вообще можно переименовать в менеджер игровых сущностей, да, согласен.
Отредактирован ZLOI_DED
» Space Station 133D / Записки велосипедиста #2 - Внутренности игровых движков
Многопоточность - относится к устройству контроллера игрового процесса (ядру). Отдельно выделить нельзя.
Система работы с шейдерами - это часть визуализатора.
Про систему событий и сетевой движок... я специально сказал что данный список можно выделить очень часто. Т.е. не все так делают, но большинство.
Про спец. форматы - это обзорный номер. Не знаю почему они ими "грешат", но это так или иначе часть системы ассетов.
Благодарю)
А вот шейдеры привязаны к визуализатору и поэтому выделить их в отдельную систему не получается.
Хорошо. А что интересно? Как взаимодействуют клиент и сервер, какие протоколы используются, в чём их преимущества или всё сразу?)
» Space Station 133D / Записки велосипедиста #1 - Философия игровых движков
Продолжение уже в процессе)
Отредактирован ZLOI_DED
» Space Station 133D / Записки велосипедиста #1 - Философия игровых движков
По какой-то причине я забыл добавить аналогичные примеры из индустрии и привёл их (списком) в статье.
0 - Наиболее эффективный способ обучения.
1, 3, 4 - Проблемы с супер специфическими задачами гораздо легче решать.
2, 6 - Разве это не так? Если игра будет не одна или игра планируется как долгосрочный проект?
5 - Так это вообще здорово.
Просто каждый оценивает для себя. ИМХО, если уверен, что хватит времени и энтузиазма - значит надо делать свой движок.
Для гейм-дев программера - это маст трай.
Благодарю за фидбек!
» Armocar Smash / Последняя Демо Сборка
» Администрация XGM / Хай! Это не СПАМ! Защитите сайт от эксплойтов 100% бесплатно!!!
Можете конечно и не обрабатывать. Моё дело сообщить)
» Администрация XGM / Хай! Это не СПАМ! Защитите сайт от эксплойтов 100% бесплатно!!!
» S.T.A.L.K.E.R. ORPG / Главная страница
Я тут играл в Infinity... Карта вроде классная, но лагала как кот в дверном проёме когда ему открыли дверь. Особенно из-за анимированного курсора и прочей подобной херни, которую отключить конечно же невозможно. К тому же на той карте была совсем не удобная система боя и как-то поизвращались там с выделением впринципе, от чего сильно пригорало. Я конечно же за атмосферность, но постарайтесь не накосячить также как в той карте. Сделайте например настройку графики через команды:
-gfxGrassAnim on/off
и т.д. Спасибо! Проект действительно интересный и стоит времени!
Отредактирован ZLOI_DED
» WarCraft 3 / Нестандартный код ломает карту
100% проблема в JassHelper'е! Не у меня одного такая фигня. На хайвворкшопе есть подобные темы, но там он хотя бы запускается, а у меня даже не запускается.
UPD: Решилось установкой новой версии JassHelper и пересохранением карты через Сохранить как...
» Волна Армии / Волна Армии 3.3.1#L6 Релиз-кандидат 6e
А.. ну ясно.
» WarCraft 3 / Нестандартный код ломает карту
Флажки которые я смог найти все так же выставлены, так что смысла мало имеет.
Если не ошибаюсь то редактор прямо у нас на xgm распространяется.
Jass New Gen Pack 5d Exp2
Здесь нужно знать чё за фишка... а я вот забыл.
Отредактирован ZLOI_DED
» S.T.A.L.K.E.R. ORPG / Главная страница
» 3D Арт и VR / Релиз Blender 2.75
» WarCraft 3 / Вопрос по опыту в создании ИИ
» WarCraft 3 / Вопрос по опыту в создании ИИ
Отредактирован ZLOI_DED
» WarCraft 3 / Вопрос по опыту в создании ИИ
Т.е. для аттаки можно, к примеру, сделать так: кол-во монет за убийство / расстояние до врага.
Idle, Attack...
}
{
setTask();
executeTask();
}
{
float idleWeight = 0f;
float attackWeight = 0f;
if (enemies.size() > 0)
{
Enemy e = getNearestEnemy();
Vector2f diff = new Vector2f(Math.abs(e.getLocation().x-getLocation().x), Math.abs(e.getLocation().y-getLocation().y));
attackWeight = 1f / diff.length();
target = e;
}
if (currWeight == 0 ||
task == Task.Attack && (target == null || target.isDead() || currWeight-attackWeight>.1f))
if (maxWeight == attackWeight) {
task = Task.Attack;
} else {
task = Task.Idle;
}
}
currWeight = maxWeight;
{
switch (task)
{
case Attack:
if (target != null)
{
followAndAttack(target);
}
break;...
}
}
Как калибровать:
Отредактирован ZLOI_DED
» WarCraft 3 / Вопрос по опыту в создании ИИ
» XGM Конкурсы / Этап IV (19.06 - 22.06)
Было бы интересно узнать когда следующий конкурс... возможно к этому времени я смогу показать что-нибудь достойное этого мероприятия.
Спасибо!
» Dota 2 / Dota 2 Reborn. Всё о глобальном обновлении на движке Source 2
Вангую частые фиксы ещё полгода-год, активную кампанию по переходу на новый двиг от Гейба и просьбы маленьких мальчиков купить им новый камень, и амуду-карточку. Вот только переход значительной части аудитории на "Reborn" затянется.
По поводу патчей... ТыжПрограммист! В Valve приди - порядок наведи!
» Несыть / Альфа версия 3.5а