Space Station 133D - ролевая sandbox игра, вдохновлённая Space Station 13. Находится в ранней стадии разработки.
69 26 067
0
28
7 лет назад
0
Открылся наш сайт - 2programm.ru . Новости будут в первую очередь публиковаться на нём.
Расскажи, пожалуйста, что за сайт.
А то п. 5 как бы.
0
10
7 лет назад
0
alexprey:
ZLOI_DED, хоть бы отступы для формы сделал
Да, блин, его пилить ещё нужно, а руки всё не доходят... \(._.)/
0
29
8 лет назад
0
ZLOI_DED, хоть бы отступы для формы сделал
0
10
8 лет назад
0
Открылся наш сайт - 2programm.ru . Новости будут в первую очередь публиковаться на нём.

Записки велосипедиста #2 - Внутренности игровых движков

Здравствуй, %username%!
Ты наверное задаёшься вопросом: "Причём тут велосипеды? Это же геймдев!". А я на это отвечу так: "Геймдев весь был и остаётся велосипедом". Это "Записки велосипедиста", в которых расскажу про свои "приключения", а также дам ссылки на интересные материалы для домашнего изучения. Итак, если заинтересовался - просим под кат!
12 4 441
0
24
8 лет назад
0
Кет, сам по себе хендл мало о чем говорит - должны быть все три составляющие - хендл, привязанные к хендлам компоненты-данные и глобальные системы-логика. Я не исключаю, что близы могут пользоваться принципами Entity System, вроде даже даты разработки попадают примерно на времена возникновения этой концепции, но у меня нет совершенно никаких подтверждений тому, что это действительно так.
0
33
8 лет назад
0
"Сущность" в ней это всего-навсего числовой идентификатор и связанный с ним контейнер для "компонентов", представленных в виде данных
Это же типа как handle в Варкрафте?
2
10
8 лет назад
2
prog:
ZLOI_DED, Entity System в чистом виде штука довольно сложная для восприятия. "Сущность" в ней это всего-навсего числовой идентификатор и связанный с ним контейнер для "компонентов", представленных в виде данных, а весь код вынесен в глобальные "системы", которые выбирают интересующие их сущности по набору компонентов и выполняют с ними различные действия. При этом, например, событие нанесения урона цели тоже может быть сущностью - в компоненты этой сущности заносятся такие параметры как источник урона, тип, количество и, конечно, цель, затем соответствующая система выбирает все сущности с компонентами нанесения урона и применяет этот урон к цели, учитывая компоненты цели, которые могут содержать, например, общую защиту от урона или сопротивляемость какому-то конкретному типу урона. После обработки, естественно, сущность для нанесения урона уничтожается. Это не просто менеджер сцены или какая-то отдельная подсистема, это подход к построению архитектуры всей игровой логики. Я не предлагаю подробно писать об этом, особенно если ты сам с этим еще не сталкивался, но нельзя писать об игровых движках и не упомянуть эту тему.
Хорошо написал, мне понравилось)
Я понял о чём ты и это в действительности основывается на менеджменте сцены (всё-таки верну это название... оно правильнее будет), системе событий и устройстве ядра.
Просто я не предполагал управление сущностями вне какого-либо контекста, от которого они зависят, поэтому и поместил их внутрь управления сценой.
Если ты имеешь ввиду подход к построению игровой логики, а не конкретную систему движка, то это материал для ещё одного номера, в котором надо обозреть также и другие подходы, сравнить их, определить преимущества и недостатки каждого и т.п.
Так что благодарю, обязательно упомяну об этом подходе в одном из следующих номеров)
2
24
8 лет назад
2
ZLOI_DED, Entity System в чистом виде штука довольно сложная для восприятия. "Сущность" в ней это всего-навсего числовой идентификатор и связанный с ним контейнер для "компонентов", представленных в виде данных, а весь код вынесен в глобальные "системы", которые выбирают интересующие их сущности по набору компонентов и выполняют с ними различные действия. При этом, например, событие нанесения урона цели тоже может быть сущностью - в компоненты этой сущности заносятся такие параметры как источник урона, тип, количество и, конечно, цель, затем соответствующая система выбирает все сущности с компонентами нанесения урона и применяет этот урон к цели, учитывая компоненты цели, которые могут содержать, например, общую защиту от урона или сопротивляемость какому-то конкретному типу урона. После обработки, естественно, сущность для нанесения урона уничтожается. Это не просто менеджер сцены или какая-то отдельная подсистема, это подход к построению архитектуры всей игровой логики. Я не предлагаю подробно писать об этом, особенно если ты сам с этим еще не сталкивался, но нельзя писать об игровых движках и не упомянуть эту тему.
0
10
8 лет назад
Отредактирован ZLOI_DED
0
prog:
Entity System - я подразумевал как часть менеджера сцены. Отдельно обычно не существует.
Не имеет прямого отношения к сцене, не путать с аналогичной терминологией в юнити. Речь о data-driven организации игровой логики и соответствующем представлении всех игровых объектов. Сцена с её геометрией строится на основе данных из Entity System, но при этом Entity System может содержать не отображаемые на сцене данные и даже существовать отдельно от сцены в случае сервера. Сливать воедино объекты на сцене и игровую логику это дурной тон и больно кусается при масштабировании проекта - даже в движках позволяющих такое, желательно в объектах сцены оставлять только логику, связанную с отображением, а все остальное выносить отдельно.
Система анимаций вынесена отдельно, т.к. она занимается не связанной с физ. движком деятельностью.
Но ведь система анимаций это, как правило, тоже часть визуализатора, как и шейдеры.
Всё что является игровой сущностью должно находится на сцене (не обязательно иметь свойства нужные для отображения и пр.). Поэтому я обобщил в менеджер сцены. Сцена логическая, а не визуальная или физическая или какая-нибудь ещё.
А вообще можно переименовать в менеджер игровых сущностей, да, согласен.
А если система анимаций влияет на что-то кроме визуального результата, возвращаемого игроку? Тут не всё так просто.
alexprey:
Хорошо. А что интересно? Как взаимодействуют клиент и сервер, какие протоколы используются, в чём их преимущества или всё сразу?)
Да, интересует именно архитектура взаимодействия)
Ок, обязательно напишу про это :)
0
29
8 лет назад
0
Хорошо. А что интересно? Как взаимодействуют клиент и сервер, какие протоколы используются, в чём их преимущества или всё сразу?)
Да, интересует именно архитектура взаимодействия)