Если бы я был профильным геймдев разработчиком (и знал бы, что такое ECS и как с ним работать), я бы 100% так поступил. Но я самоучка, у меня вообще нет продакшн опыта, аббревиатуру ECS я увидел впервые 3 месяца назад, поэтому для меня этот проект во многом еще и про то, чтобы научиться и понять, как оно работает.
Это как с анализом данных - можно юзать фреймворки, даже не особо глубоко понимая статистику, но лучше (кмк), если ты понимаешь, как именно все эти функции работают и почему именно так Хотя может кому-то проще учиться на фреймворках, я не спорю.
плюс для интерполяции (плавного перемещения), цепляю еще такие данные
private float[] interp;
private int[] lastCell;
тут прогресс интерполяции от 0 до 1 и предыдущая ячейка (у меня ячеестый грид и я все привязываю к ячейкам пока что. Пока не делаю перемещение внутри ячейки). И да, тут есть дублирование предыдущей ячейки, но я пока забил на него.
В отдельных сущностях хранятся данные самих действий и запросов типа статуса, способа перемещения, идентификатора задачи, целевой клетки.
На порядок систем это не повлияло. Тут же поменялась структура хранения данных, а не логика. Хотя я, поменял порядок одной из вспомогательных систем, но это не связано с переходом на ECS. Добавил возможность указать порядок при регистрации в менеджере. Сигнатура в итоге такая public void Register(ITickable tickable, TickPhase phase = TickPhase.Logic, int order = 1000000);
Это 100%. Я просто преследую цель, в том числе, научиться программировать, поэтому было интересно руками все собрать. А так, если бы я преследовал коммерческую цель, то, конечно, пилить все с нуля, это спорно
Реальность такова, что в серьезных командах, где бюджет ограничен (я не говорю про госуху - там обычно бюджет в несколько раз перекрывает траты и никто не парится за оценки) принято планировать разработку.
Так что какое число ни назови столько и будешь работать до следующего такого вопроса 😁
Работать вы будете до тех пор, пока фичу не сдадите заказчику. Сдается она обычно по ТЗ. А ваши оценки нужны для того, чтобы менеджер мог спланировать работу. Если разработчик систематически недооценивает работу, это показатель: 1. Его неумении декомпозировать задачу (если аналитика при этом нормальная) 2. Не понимании конечного результата (тут обычно аналитика не нормальная) 3. Отсутствия опыта подобных работ (обычно еще есть проблема п1)
Если вас спросить, за сколько вы сделаете вывод Hello World на вашем языке программирования, вы же сможете достаточно точно назвать срок? Ну я надеюсь.
Но я, конечно, не претендую на то, что я тут самый умный. Я писать код начал в начале 2024го, так что может действительно есть какой-то другой и простой путь.
а что такое перемещение к объекту? Под капотом так или иначе все равно вычисляются координаты и объект двигается от одной точки с координатами x1, y1 до другой точки с координатами x2, y2. Разница только в том, что координаты x2, y2 не постоянные. NavMesh со своим SetDestination здесь не подойдет, тк у меня в целевой модели массовая симуляция, я протестировал ее на +- 1000 агентах и это треш даже без перемещения. Просто тупая анимация 1000 NPC в кадре уже сбивает FPS до 15 на моем Lenovo Legion 5pro. Так что как-то так. А если хочется оптимизировать - то это только что-то самописное и, обычно, на основе А*.
Но, если у вас простой кейс с несколькими NPC в кадре, - тогда то, что я пишу в своих статьях про экономический симулятор - это действительно будет оверхед.
ой нет, я бы умер такое делать. Это примерно такой базовый функционал как у меня + еще осмысленные диалоги с полноценными репликами. В массовых симуляторах конкретные текстовки не важны, в них диалог - это скорее способ изменить силу социальной связи между NPC (условно Core-модуль генерирует событие старта/завершения "реплики", а на стороне игры изменяется, например, в положительную или отрицательную сторону связь между этими NPC и, например, создаются или скрываются баблы (пузыри над головой)). В кач-ве примера можно посмотреть на RimWorld тот же. Там вроде как есть механика разговора между NPC, но она не основная и проходит в фоне. То, о чем вы говорите имеет смысл не в экономических симуляторах или симуляторах колоний, где куча безликих NPC, а где есть управляемые "герои" и диалог - это одна из основных механик. Типа как в HeavyRain или Detroit Become Human - там от них ещё сюжетные развилки разные. Вот в этом случае да, надо делать осмысленные реплики.
А когда как такового сюжета нет и "беседа" проходит просто в фоне - это оверкилл. Но и даже в этом случае это реализуется не так просто.
Короче просто кейс не тот, но я понял, что я не попал в ваши ожидания. (мне до этого еще как до Луны)
В экономических симуляторах и симуляторах колоний диалог - это не основная механика, и в нем нет "реплик" по типу как в Skyrim или The Sims, потому что NPC слишком много. Механика общения в экономических симуляторах и симуляторах колоний реализуется по-другому. Мне казалось, что в разделе с заголовком "Кейс" и "Концепт решения" я обозначил ключевые аспекты, часть из которых затем раскрыл детальнее. В любом случае, спасибо вам за обратную связь. Можете ещё оставить комментарий как раз как ответ на моё предложение Ради эксперимента попробуйте представить себе эту механику и прикиньте оценки трудозатрат: за сколько вы бы её реализовали, а также примерный концепт решения Мне интересно узнать ваш концепт, как вы представляете эту механику
Алексей, поделитесь, пожалуйста, какими ИИ-инструментами вы пользовались для графической составляющей? Хочу понять, почему вы так категоричны. Поделитесь своим опытом, пожалуйста.
Я, в целом, согласен, что пока еще нужен человек, чтобы привести все к единому стилю (и то, я пока даже не пробовал делать такой запрос в ИИ-модели). Но все равно вы делаете основную часть, а затем доделываете тюнинг - приводите стили к одному виду. По сути, это те же ассеты, но только их делают художники вам под конкретные механики и конкретные нужды.
Спасибо за обратную связь, я пока еще не освоился с оптимальным размером статей. С одной стороны хочется рассказать сразу все, с другой - я помню себя на старте, поначалу вообще ничего не понятно, и хочется сделать какую-то минимальную вещь, чтобы оно в принципе работало, посидеть с этим пару часов потыкаться, а потом уже дальше продвигаться. Но, наверно, можно было бы развитие тоже здесь уместить, просто это вышло бы минут на 20 в сумме.
Ой, я тоже такое помню на одной из работ - про совмещение ПМ и БА А на счет геймдева - мне кажется, это интересно, особенно после работы над какими-то проектами для всяких министерств))
Спасибо за ссылку на ресурс, во-первых, это очень полезно даже сейчас. Очень подробное и структурированное изложение
вот этот момент очень интересует. есть ли коллизии между юнитами? есть ли динамически перестраиваемое окружение?
Смотрите, коллизий пока нет. И я не уверен, буду ли их делать - с одной стороны это реалистично, с другой - толпа, которая будет тупить в дверях и проходах...Ну не знаю. Может одной из условностей будет прохождение юнитов сквозь друг друга, типа как в одном известном симуляторе больницы. Плюс ко всему, я отказался от GameObject-ов для NPC ради буста производительности и коллайдеры и всю механику придётся писать самому.
С динамическим окружением сейчас есть только 2 кейса:
NPC получил путь, а потом игрок разместил на его пути какой-то объект => стоимость ребра меняется на макс (не проходимое) => обновляется кэш стоимостей рёбер => срабатывает событие, что стоимость пути изменилась, и NPC запрашивает его еще раз. Это все работает асинхронно в фоновых потоках, чтобы не блокировать UI.
NPC хотят подойти друг к другу. Здесь асинхронно у меня сделать не получилось, потому что позиция агентов смещается и они могут получить не действительный путь, поэтому конкретно в таком кейсе я сделал синхронный метод, который отдаёт маршрут в том же кадре
Но вся "фишка" оптимизации по сути в кешировании стоимостей и работе А* на чистых int-индексах. Я в будущем запилю статейку на тему того, как строил сервис поиска пути. Самый первый варик, который я написал отдавал маршрут за 20 минут...ну в общем, там было много нюансов
Сомнительно, но ладно. Хотя это и может быть полезно для переездов, но сомневаюсь, что оно сможет переехать на какой-нибудь Godot даже с заменой зависимых типов.
Тут я немного криво написал, простите. Я имел в виду не игровую логику, а базовую логику. Ну, например, тот же сервис поиска пути - там вообще нет никакого упоминания Vector3Int или даже Guid-ов, он работает тупо на индексах Сервис NPC - тут я вдохновился ECS-подходом и сделал данные в структурах, где тоже нет никакого упоминания (не везде конечно, где-то я накостылял, но это не принципиально) движковых типов данных Библиотека (если ее так можно назвать) для графов, которую я использую как для поиска пути - для грида, так и для взаимодействия NPC между собой, чтобы собирать "знакомства" - она тоже ничего не знает про игровые типы данных.
А чисто игровая, геймплейная логика - она связана с Unity, конечно
Если бы я был профильным геймдев разработчиком (и знал бы, что такое ECS и как с ним работать), я бы 100% так поступил.
Но я самоучка, у меня вообще нет продакшн опыта, аббревиатуру ECS я увидел впервые 3 месяца назад, поэтому для меня этот проект во многом еще и про то, чтобы научиться и понять, как оно работает.
Это как с анализом данных - можно юзать фреймворки, даже не особо глубоко понимая статистику, но лучше (кмк), если ты понимаешь, как именно все эти функции работают и почему именно так
Хотя может кому-то проще учиться на фреймворках, я не спорю.
Например, для перемещения, я храню у агента (NPC) вот такой набор
плюс для интерполяции (плавного перемещения), цепляю еще такие данные
тут прогресс интерполяции от 0 до 1 и предыдущая ячейка (у меня ячеестый грид и я все привязываю к ячейкам пока что. Пока не делаю перемещение внутри ячейки). И да, тут есть дублирование предыдущей ячейки, но я пока забил на него.
В отдельных сущностях хранятся данные самих действий и запросов типа статуса, способа перемещения, идентификатора задачи, целевой клетки.
На порядок систем это не повлияло. Тут же поменялась структура хранения данных, а не логика. Хотя я, поменял порядок одной из вспомогательных систем, но это не связано с переходом на ECS. Добавил возможность указать порядок при регистрации в менеджере. Сигнатура в итоге такая
public void Register(ITickable tickable, TickPhase phase = TickPhase.Logic, int order = 1000000);Не знаю, насколько ответил на вопрос)))
Это 100%. Я просто преследую цель, в том числе, научиться программировать, поэтому было интересно руками все собрать. А так, если бы я преследовал коммерческую цель, то, конечно, пилить все с нуля, это спорно
Все может быть, но результат в точности такой, какой я ожидаю
Объекты располагаются в дискретных ячейках
Реальность такова, что в серьезных командах, где бюджет ограничен (я не говорю про госуху - там обычно бюджет в несколько раз перекрывает траты и никто не парится за оценки) принято планировать разработку.
Работать вы будете до тех пор, пока фичу не сдадите заказчику. Сдается она обычно по ТЗ. А ваши оценки нужны для того, чтобы менеджер мог спланировать работу.
Если разработчик систематически недооценивает работу, это показатель:
1. Его неумении декомпозировать задачу (если аналитика при этом нормальная)
2. Не понимании конечного результата (тут обычно аналитика не нормальная)
3. Отсутствия опыта подобных работ (обычно еще есть проблема п1)
Если вас спросить, за сколько вы сделаете вывод Hello World на вашем языке программирования, вы же сможете достаточно точно назвать срок? Ну я надеюсь.
Ну, если вы за 12 лет разработки, как вы пишете у себя в профиле, по-прежнему так относитесь к оценке работ.....
Но я, конечно, не претендую на то, что я тут самый умный. Я писать код начал в начале 2024го, так что может действительно есть какой-то другой и простой путь.
а что такое перемещение к объекту? Под капотом так или иначе все равно вычисляются координаты и объект двигается от одной точки с координатами x1, y1 до другой точки с координатами x2, y2.
Разница только в том, что координаты x2, y2 не постоянные.
NavMesh со своим SetDestination здесь не подойдет, тк у меня в целевой модели массовая симуляция, я протестировал ее на +- 1000 агентах и это треш даже без перемещения. Просто тупая анимация 1000 NPC в кадре уже сбивает FPS до 15 на моем Lenovo Legion 5pro. Так что как-то так. А если хочется оптимизировать - то это только что-то самописное и, обычно, на основе А*.
Но, если у вас простой кейс с несколькими NPC в кадре, - тогда то, что я пишу в своих статьях про экономический симулятор - это действительно будет оверхед.
ой нет, я бы умер такое делать. Это примерно такой базовый функционал как у меня + еще осмысленные диалоги с полноценными репликами. В массовых симуляторах конкретные текстовки не важны, в них диалог - это скорее способ изменить силу социальной связи между NPC (условно Core-модуль генерирует событие старта/завершения "реплики", а на стороне игры изменяется, например, в положительную или отрицательную сторону связь между этими NPC и, например, создаются или скрываются баблы (пузыри над головой)). В кач-ве примера можно посмотреть на RimWorld тот же. Там вроде как есть механика разговора между NPC, но она не основная и проходит в фоне.
То, о чем вы говорите имеет смысл не в экономических симуляторах или симуляторах колоний, где куча безликих NPC, а где есть управляемые "герои" и диалог - это одна из основных механик. Типа как в HeavyRain или Detroit Become Human - там от них ещё сюжетные развилки разные. Вот в этом случае да, надо делать осмысленные реплики.
А когда как такового сюжета нет и "беседа" проходит просто в фоне - это оверкилл. Но и даже в этом случае это реализуется не так просто.
Короче просто кейс не тот, но я понял, что я не попал в ваши ожидания. (мне до этого еще как до Луны)
В экономических симуляторах и симуляторах колоний диалог - это не основная механика, и в нем нет "реплик" по типу как в Skyrim или The Sims, потому что NPC слишком много. Механика общения в экономических симуляторах и симуляторах колоний реализуется по-другому.
Мне казалось, что в разделе с заголовком "Кейс" и "Концепт решения" я обозначил ключевые аспекты, часть из которых затем раскрыл детальнее.
В любом случае, спасибо вам за обратную связь. Можете ещё оставить комментарий как раз как ответ на моё предложение
Ради эксперимента попробуйте представить себе эту механику и прикиньте оценки трудозатрат: за сколько вы бы её реализовали, а также примерный концепт решения
Мне интересно узнать ваш концепт, как вы представляете эту механику
Operation Flashpoint: Cold War Crisis
Алексей, поделитесь, пожалуйста, какими ИИ-инструментами вы пользовались для графической составляющей? Хочу понять, почему вы так категоричны. Поделитесь своим опытом, пожалуйста.
Я, в целом, согласен, что пока еще нужен человек, чтобы привести все к единому стилю (и то, я пока даже не пробовал делать такой запрос в ИИ-модели). Но все равно вы делаете основную часть, а затем доделываете тюнинг - приводите стили к одному виду. По сути, это те же ассеты, но только их делают художники вам под конкретные механики и конкретные нужды.
Спасибо за обратную связь, я пока еще не освоился с оптимальным размером статей. С одной стороны хочется рассказать сразу все, с другой - я помню себя на старте, поначалу вообще ничего не понятно, и хочется сделать какую-то минимальную вещь, чтобы оно в принципе работало, посидеть с этим пару часов потыкаться, а потом уже дальше продвигаться.
Но, наверно, можно было бы развитие тоже здесь уместить, просто это вышло бы минут на 20 в сумме.
А о чем вам было бы интересно узнать?
Ой, я тоже такое помню на одной из работ - про совмещение ПМ и БА
А на счет геймдева - мне кажется, это интересно, особенно после работы над какими-то проектами для всяких министерств))
Спасибо за ссылку на ресурс, во-первых, это очень полезно даже сейчас. Очень подробное и структурированное изложение
Смотрите, коллизий пока нет. И я не уверен, буду ли их делать - с одной стороны это реалистично, с другой - толпа, которая будет тупить в дверях и проходах...Ну не знаю. Может одной из условностей будет прохождение юнитов сквозь друг друга, типа как в одном известном симуляторе больницы. Плюс ко всему, я отказался от GameObject-ов для NPC ради буста производительности и коллайдеры и всю механику придётся писать самому.
С динамическим окружением сейчас есть только 2 кейса:
NPC получил путь, а потом игрок разместил на его пути какой-то объект => стоимость ребра меняется на макс (не проходимое) => обновляется кэш стоимостей рёбер => срабатывает событие, что стоимость пути изменилась, и NPC запрашивает его еще раз. Это все работает асинхронно в фоновых потоках, чтобы не блокировать UI.
NPC хотят подойти друг к другу. Здесь асинхронно у меня сделать не получилось, потому что позиция агентов смещается и они могут получить не действительный путь, поэтому конкретно в таком кейсе я сделал синхронный метод, который отдаёт маршрут в том же кадре
Но вся "фишка" оптимизации по сути в кешировании стоимостей и работе А* на чистых int-индексах. Я в будущем запилю статейку на тему того, как строил сервис поиска пути.
Самый первый варик, который я написал отдавал маршрут за 20 минут...ну в общем, там было много нюансов
Тут я немного криво написал, простите. Я имел в виду не игровую логику, а базовую логику.
Ну, например, тот же сервис поиска пути - там вообще нет никакого упоминания Vector3Int или даже Guid-ов, он работает тупо на индексах
Сервис NPC - тут я вдохновился ECS-подходом и сделал данные в структурах, где тоже нет никакого упоминания (не везде конечно, где-то я накостылял, но это не принципиально) движковых типов данных
Библиотека (если ее так можно назвать) для графов, которую я использую как для поиска пути - для грида, так и для взаимодействия NPC между собой, чтобы собирать "знакомства" - она тоже ничего не знает про игровые типы данных.
А чисто игровая, геймплейная логика - она связана с Unity, конечно