Дядя Миша писал: с одной стороны порог вхождения достаточно высокий
Цитата:
Дядя Миша писал: Ему надо дать набор объектов на все случаи жизни, а так же скриптовых монстров, пушек и предметов
Необычный подход. Но с другой стороны я подозреваю, что это намного проще будет, чем учить с нуля тот же LUA и пытаться что-то делать на нем.
Цитата:
Дядя Миша писал: тем больше проблем возникает в дальнейшем и язык приходится регулярно дополнять новыми конструкциями
В UE очень много нодов для блупринтов. Получается довольно противоречивая ситуация: пользователю на деле за глаза где-то ~100-150 самых основных, но разработчикам движка приходится делать огромное количество их видов, чтоб максимально покрыть самые экзотические потребности при разработке продукта.
Цитата:
Дядя Миша писал: Для примера приведу описание пушки из порта Камрадов
Лаконично, мне нравится. В идеале бы еще в виде графического оформления прямо в рабочей среде, чтоб в txt руками не писать. Ну это так, мысли вслух.
__________________
To start the match, Let's draw the sketch, Then add some magic from your heart!
Take gold and blue, Take silver too and put a sparkle in your art!
I love that dress, I love It, YES!!! I love the way It makes me feel.
I love the shoes, I love to choose, It was a dream and now It's real!
Не обязательно делать готовые пушки и монстров, достаточно просто библиотеку функций которые можно использовать как ноды.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша писал: 3. Я исхожу из соображения, что дизайнер вообще не будет ничего программировать. Ему надо дать набор объектов на все случаи жизни, а так же скриптовых монстров, пушек и предметов. Это объекты, которые пишутся в простейшем скриптовом файле, логику которого можно освоить за 10 минут. Для примера приведу описание пушки из порта Камрадов
Задумка максимально похвальная, однако тебе придется писать 100500 вещей, как ты сказал на все случаи жизни. Только для пушки - хитскан, прожектайл, разделение на типы - мили/дальнобойная, и т.д. Не жалеешь ты себя, Дядь Миш, золотой ты человек
Поэтому, как дизайнер, не умеющий кодить, поддержу FiEctro. Не в плане функций, а в плане нодов.
Вот был в свое время UDK с его UScript, и даже мне там было несложно наследовать оружие от родного, хотя норот говорил, что это плюсы только с синтаксисом жабаскрипта. То есть мощный язык.
__________________
Самолетами!
Пароходами!
С боем взяв плацкарты
Едут мужики!
Самолетами!
Пароводами!
Убивать людей Едут мужики!
Читаю тему дальше. FiEctro категорически не понимает того, о чём я пишу. Ну оно и неудивительно. Если рассматривать движок как абстракцию в ваккууме, то его представления о том, как это всё должно быть - правильные. Вот только, когда по этим правильным представлениям создаёшь реальную программу, она начинает логать даже на карте коробке и занимает работой все восемь ядер.
Дядя Миша писал: Читаю тему дальше. FiEctro категорически не понимает того, о чём я пишу. Ну оно и неудивительно. Если рассматривать движок как абстракцию в ваккууме, то его представления о том, как это всё должно быть - правильные. Вот только, когда по этим правильным представлениям создаёшь реальную программу, она начинает логать даже на карте коробке и занимает работой все восемь ядер.
Что именно и где. И почему оно не логает на карте коробке в других движках?
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Что именно и где. И почему оно не логает на карте коробке в других движках?
Ага, отлично! Пост был создан для привлечения внимания, я знал что ты откликнешься. Но тогда почему я тебе уже вторую неделю пишу приватки, а ты не реагируешь? Вот как это пони-мать?
Так товарищи. Настало время открыть вам страшную правду. Я не настоящий пограммист, как некоторые думают. Настоящему пограммисту вообще всё равно какой код писать. Они в любую задачу погружаются с интересом и работают над ней. Им главное - новизна ощущений. По принципу "О! а я с таким ещё не работал! Интересно!". Ну вот по этому критерию я совсем не настоящий Нет у меня желания обмазываться каждой новинкой и погружаться в неё. В действительности существовал ряд направлений в которых мне было очень интересно ковыряться и разбираться, но достаточно ограниченный. Перечислю его здесь:
1. Зеркала, порталы, вообщем многопроходный рендеринг - как вы помните это я в первую очередь удовлетворил ещё в старом ксаш-моде.
2. Динамическое освещение, тени, отложенный рендеринг - реализовал в P2.
3. Компиляция уровней в BSP, наложение лайтмапы - аналогично реализовано в P2 и так же созданы с нуля компиляторы XashNT
4. Гибкая и мощная система материалов - создано в XashNT
5. Поиск пути, динамическая генерация препятствий - создано в XashNT
6. Собственный язык программирования, виртуальная машина - создано в XashNT
7. Звуковой движок - в планах
8. Абстрактный сетевой движок с дельта-калькулятором и предиктингом - в планах
9. Собственный редактор уровней и моделей - в планах
10. Реализация реалтайм-радиосити - в планах
Собственно, по факту полной реализации пунктов из этого списка я полностью утрачу интерес к программированию ради самого программирования. Ну это когда человек создаёт разные интересные штуки на чистом энтузиазме, а не делает что-то в рамках поставленной задачи наотъебись.
Дядя Миша писал: Ага, отлично! Пост был создан для привлечения внимания, я знал что ты откликнешься. Но тогда почему я тебе уже вторую неделю пишу приватки, а ты не реагируешь? Вот как это пони-мать?
Оу. Ну мне обычно когда приватные сообщения приходят - форум показывает попап окошко, сейчас ничего не показывает. Пиши лучше в дискорд или телеграм. А так конечно гляну сейчас и отвечу.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Переписал игровой таймер. Не сказать чтобы он стал прямо лучше прежнего, но все другие варианты - ещё хуже. Я помню как мучался с этим в старом ксаше. Но зато он теперь микросекундный, с высоким разрешением.
Т.е. проблем с плавающей точкой не будет и одновременно не будет проблем вызванных низким разрешением таймера.
И в связи с этим у меня возник вот какой интересный вопрос - а надо ли ограничивать фпс? Ну то есть клиент-сервер тикают синхронно, это не меняется. А вот надо ли душить фпс рендеринга и если да, то зачем?
Средствами драйвера он прекрасно приводится к частоте кадровой развертки, достаточно включить vsync. Раньше фпс ограничивали, чтобы исключить влияние физики. Сейчас это может понадобиться разве что для исключения перегрева видеокарты. Но для это как раз и служит vsync.
Вот такие у меня соображения, что не нужен этот ограничитель вовсе.
А вы расскажите как обстоят дела в Унреале и Юните с этим. Ну и вообще ваши мысли по этому поводу.
Ну чтож, поскольку с таймером разобрался - вырисовываю будущий сетевой движок. Это довольно сложная тема и скорее всего я буду его создавать неспешно и параллельно с другими задачами, т.к. надо всё как следует продумать и предусмотреть.
Добавлено сегодня в 13:07:
Пока что приму за основу следующее допущение:
Абсолютно у каждого объекта есть шесть (на данный момент) полей, которые будут переданы на клиент средствами самого движка, независимо от пользовательских настроек. Хотя эти поля и приходят из виртуальной машины, движок требует их наличие для правильной работы.
На самом деле полей больше, но для передачи на клиент достаточно и этих.
для куллинга
entity->world_mins
entity->world_maxs
связь между объектом и его моделью
entity->modelindex
абсолютная трансформация объекта
entity->transform
то что раньше хранилось в pev->effects
entity->renderflags
индекс камеры - trigger_camera, func_portal, func_monitor - всё такого рода
по умолчанию ссылается сама на себя, т.е. по идее всегда валидная
entity->viewentity
Всё это обладает хорошим уровнем абстрагированности, и менять тут ничего не понадобится.
Так же существует набор параметров для анимационно-зависимой модели. Анимация это довольно широкий набор, он годится как для спрайтов, так и для вершинной и скелетной анимации, кол-во передаваемых параметров, соответственно тоже варьируется в зависимости от. Список этих параметров уточню позже, но аналогично - в движке жестко прописаны сетевые настройки передачи. Да собственно, пользователю и не надо это настраивать.
И наконец кастомный набор переменных - то, чего так не хватало пользователям старого ксаша, когда край как надо было передать очередной параметр в шейдер и внезапно выяснялось, что в entity_state_t уже всё заюзано и что с этим делать - решительно непонятно. Те, кто делал себе локальную копию движка - начинал его расширять под свои нужды, но понятно что это ломало совместимость. Весьма неудобно.
Переданные на клиент переменные будут в первую очередь использованы для интерполяции и передачи в рендерер. Во вторую - для потенциального предиктинга, но предиктинг это отдельная задача и пока я не разберусь с сетью, у меня ещё не вырисовывается картинка, как именно он будет выглядеть.
Дядя Миша писал: А вы расскажите как обстоят дела в Унреале и Юните с этим.
Там уже есть движковые эвенты с определенным порядком выполнения. На их базе можно таймер сделать на любой вкус. Так же поддерживаются потоки и асинхронные функции.
Awake - вызывается при загрузке скрипта объекта
Start - вызывается при первом кадре рендеринга
FixedUpdate - вызывается по фиксированному таймеру и синхронизирован с физикой
Update - вызывается каждый кадр
Блок Карутинов для создания всяких таймеров
Блок аниматора для отслеживания вызовов аниматора и эвентов
LateUpdate - вызывается в последнюю очередь когда всё уже отрисовано
Кстати в Юнити есть ещё один прикол о котором Кармак мог только мечтать, буферные сцены, т.е. ты можешь перенести объекты в некую "буферную сцену" (DontDestroyOnLoad) (хотя они по прежнему будут отображаться на обычной), загрузить новую сцену и выгрузить туда объекты с прошлой сцены сохраняя их состояние. В кваках же почему то загрузка новой карты перезапускает всю клиент серверную часть целиком что дико неудобно.
Ещё бы хотелось видеть такую сущность как RealTime texture это по сути такая текстура которую можно заполнять и обновлять через код. А потом в дальнейшем её использовать как обычную текстуру или UI.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
FiEctro писал: Awake - вызывается при загрузке скрипта объекта
Start - вызывается при первом кадре рендеринга
FixedUpdate - вызывается по фиксированному таймеру и синхронизирован с физикой
Update - вызывается каждый кадр
Блок Карутинов для создания всяких таймеров
Блок аниматора для отслеживания вызовов аниматора и эвентов
LateUpdate - вызывается в последнюю очередь когда всё уже отрисовано
А когда объект удаляется?
Цитата:
FiEctro писал: Кстати в Юнити есть ещё один прикол о котором Кармак мог только мечтать, буферные сцены, т.е. ты можешь перенести объекты в некую "буферную сцену" (DontDestroyOnLoad) (хотя они по прежнему будут отображаться на обычной), загрузить новую сцену и выгрузить туда объекты с прошлой сцены сохраняя их состояние. В кваках же почему то загрузка новой карты перезапускает всю клиент серверную часть целиком что дико неудобно.
У меня это есть, но особо не тестировалось. Там на данный момент осталось одно ограничение - мир предполагается на индексе 1. Не то чтобы это был косяк моей архитектуры - скорее тяжёлое наследие Xash3D, ещё не везде отредактировал. Ну да мне пока и не требуется.
То есть можно загрузить сразу несколько уровней и они никак не будут между собой конфликтовать. Но непонятно, как разграничивать энтити.
Да и памяти оно жрёт, понятное дело.
Цитата:
FiEctro писал: Ещё бы хотелось видеть такую сущность как RealTime texture это по сути такая текстура которую можно заполнять и обновлять через код
| IP: 
04-06-2024 10:45
Нет у меня желания обмазываться каждой новинкой и погружаться в неё. В действительности существовал ряд направлений в которых мне было очень интересно ковыряться и разбираться, но достаточно ограниченный. Перечислю его здесь:
