Почему прерывается компиляция?

Kalombyr,

Есть слабый комп с 1 ГГц процом и 512 Мб оперативки.

А ядер у этого проца сколько? Как распараллелена сборка проекта?

Как решить даную проблему?

DIASWORD, твой вопрос нарушает сразу П3.8 и П5.7 регламента работы сервиса.
Тебе следует убрать изображение с кодом и вставить код как текст в теге <code>. Ошибка пишется в окне отладки, ее тоже стоит вставить как код. Строку появления ошибки стоит пометить в тексте комментарием.
Сделать это все значительно проще чем делать скриншоты.

Как организовать структуру игры Монополия на ECS?

siRius32,

т.е. из всей игры, ecs лишь маленькая часть, которая обрабатывает правила игры?

Верно, именно так. Математическая модель игры может быть реализована разными способами, в том числе и в ООП стиле, где будут всякие типы, наследования, композиции, коллекции и все тому подобное.
ECS просто предлагает еще один подход к реализации математической модели.

получается есть класс игрок со ссылкой на сущность, в этой сущности все его данные и способности, а самим классом управляет уже не ecs, а другая система, в частности пользователь через ui, соответственно ai игроком управляет скрипт? ecs разве не может это делать?

Вопрос не в том, что может или не может делать ECS, а в том, зачем что-то добавлять в мир ECS. Если какое-либо поведение обосновано в рамках мира ECS, то это можно добавить. Важно просто следовать ограничениям и не размывать архитектуру.
Чем ИИ отличается от устройства ввода игрока? А ничем. ИИ для мат.модели лучше всего представить как еще одно устройство ввода/вывода, такое же как и игрок. Если создать строгое разделение методов контроля игрока и ИИ, это сделает сущности уникальными, а компоненты игрока и ИИ несвязными.
С другой стороны, если игрок и ИИ - это просто устройства ввода, они могут вводить свои команды в данные компонента перемещения своих сущностей. Далее этот компонент может обрабатывать система перемещения, для которой уже нет разницы между ИИ и игроком.

обезличивание сущностей значит игрок != entity, мы не можем сказать что у этой сущности такой то набор компонентов, значит это игрок?

Да. Мы можем сказать: рас у этой сущности такой набор компонент, то наверное это игрок. Но не точно.
Точно мы можем сказать только тогда, когда у игрока спросили его сущность.

Какие например свойства являются сущностями?

Собственно, ты сам все и описал:

сущность, в этой сущности все его данные и способности

Это будет, например, компонент движения или компонент пропуска хода, в котором записано сколько ходов еще пропустить. Это может быть компонент какой-нибудь способности. Это точно будет компонент денежного счета.

Говоря "лишь свойства игроков и активов являются сущностями" я не говорю что каждое свойство должно являться отдельной сущностью, я говорю что набор свойств является сущностью ECS-мира. Актив стоит на клетке и имеет точно такие же свойства, как и игроки, просто двигаться не может. Игрок может купить или продать актив, это действие не является внутренним по отношению к ECS и не обрабатывается системой. Системой ECS должны обрабатываться последствия покупки актива игроком - списание средств, добавление компонента владельца и.т.д. Т.е. системы реализуют правила игры.

События не могут быть сущностями, т.к. это механики игры. События - это одна или несколько систем событий, в зависимости от деталей событий. События с моментальным или отложенным эффектом, события с таймером или на количество ходов, события с условием и без условий.

Любую игру можно реализовать с помощью ECS. Важно просто правильно выстроить свое мышление относительно этой архитектуры. ECS может быть избыточен для некоторых игр, где не требуется массовость. Для маленьких количеств сущностей ECS часто является избыточным решением, ведь эта архитектура раскрывается там, где количество сущностей измеряется тысячами и сотнями тысяч.

Entity Component System + ООП подход?

siRius32,

Вообще, складывается такое ощущение, что на практике ECS удобнее использовать как каркас для игрового цикла, т.к. все системы прокручиваются в update, система может работать без сущностей, типа отрисовывать внешний ui, несколько групп систем, которые работают с определенным набором компонентов и сущностей, все это связывается через event'ы.

Да, верно. Но только отчасти.
ECS - это архитектура математической модели мира. Оставь отрисовку внешней относительно ECS логике. Сущности в мире ECS могут и не рисоваться вовсе. Это могут быть точки звукового сопровождения или точки интерактива, для которых доступно лишь взаимодействие.
Плюс, всегда стоит помнить о том, что дизайн ECS заточен на неблокирующее массовое распараллеливание, когда все системы начинают обрабатывать сущности сразу на нескольких ядрах процессора. Такой параллелизм выгоден только мат.модели, но не рендеру и прочим инструментам ввода/вывода.

Entity Component System + ООП подход?

siRius32,

получается в идеальном варианте, абсолютно любой компонент можно добавить/удалить абсолютно любой entity и система, которая использует этот компонент что то сделает, если же какой то компонент нельзя дать сущности, то что то не так значит надо пересматривать архитектуру?

Верно. Из этого правила сами собой выводятся множественные облегчения работы систем. Система может быть просто реакционной: надо компонент добавить - добавляю безотносительно сущности и того, сколько уже компонентов добавлено.

один непонятный момент, если пустой компонент наделяет сущность уже как бы флагом чего то, то для чего в компонент можно добавить кучу полей с информацией.

Сам компонент означает некоторое свойство, которым сущность может обладать. Например, это может быть свойство мертвого персонажа. Есть компонент - персонаж мертв. Такому компоненту не нужны данные, мертв - это как бы однозначно и без оговорок.

CharacterStateComponent - это пример очень плохо сформулированного компонента. Я вижу там мультикомпонент - этот компонент можно и нужно разделить на несколько: движение, навыки, привязка к локации, боевка, смерть и умирание. Процесс умирания и смерть - это два разных состояния игрока, это разные компоненты.

По данным в компонентах. Не всегда только лишь бинарного состояния компонента будет достаточно для работы системы. Компонент позиции на локации логически обязан иметь координаты в пространстве локации, чтобы система перемещения по локации могла двигать сущность по локации. Отдельно от компонента позиции должен быть компонент способности сущности двигаться. Потому что сущность может находиться на локации, но быть неспособна двигаться по ней. Свойство подвижности должно быть изымаемым относительно позиции на локации, т.е. должно быть отдельным компонентом. Это относится и к свойству атаковать, быть целью атаки, забираться по стенам, падать под действием гравитации и.т.д.

Любая система в любой момент времени может добавить или убрать компоненты сущности. Так, например, система жизни может увидеть что после работы системы урона очков жизни больше нет, значит пора сущности умирать. В этом случае система жизни добавляет компонент умирания и больше ничего не делает.
Далее, система умирания подхватывает сущность с компонентом умирания и удаляет у нее компоненты подвижности, здоровья, атаки, магии, компонент цели атаки или навыков, а так же добавляет компонент лута и компонент смерти. После этого система умирания удаляет и компонент умирания. Все, сущность умирла и не важно что это за сущность: сундук, моб или игрок.

Entity Component System + ООП подход?

siRius32, представь себе игру в шахматы. Там много фигур и одно поле. Если ты захочешь реализовать эту игру через ECS, все фигуры у тебя сразу станут серыми и однородными, появятся компоненты ортогонального и диагонального движения, компоненты движения только вперед и компоненты движения конем. Еще появится компонент атаки по направлению.
И вот давай вместе просто подумаем, какими компонентами в таком ECS-мире будет обладать сущность "состояние игры" или "игровое поле"?

А если попробовать все-таки сформулировать такие компоненты для таких сущностей, то зачем эти компоненты сущностям фигур? И зачем сущностям поля или состояния игры компоненты фигур? Это вносит в мир ECS неоднородность, набор компонентов становится несвязным. Для одних сущностей становятся характерны только один компоненты, а для других - только другие. Получается снова недоархитектура.
Такой ECS-мир является избыточным и, вероятно, должен быть разделен на несколько ECS миров, компоненты в которых будут связными.

Entity Component System + ООП подход?

siRius32, да, ты верно подходишь, на компоненты это все переписывать не надо. Я на эту тему ответил в твоем прошлом вопросе.
Дело в том, что ECS оперирует обезличенными сущностями с максимально средним набором компонент, где у каждой сущности есть вероятность обрести или утратить абсолютно любой компонент.
Внешние же, и уникальные, элементы должны остаться за пределами этого ECS мира. Они могут быть связаны через идентификатор сущности со своими свойствами внутри мира ECS.

ECS не является ответом на главный вопрос жизни, вселенной и всего такого. ECS просто дает возможность оперировать действительно огромными наборами сущностей с максимально усредненными наборами компонент и реализовывать для них максимально универсальную логику.

А проблема заключается в том, что ECS в любой момент должен иметь возможность распорядиться по-своему абсолютно каждой сущностью. Создать новую, удалить текущую, добавить компоненты, убрать компоненты. В этом гибкость подхода ECS. Более того, ECS изначально, как архитектура, спроектирован так, чтобы дать разработчику возможность неблокирующего массового распараллеливания симуляции мира. На все ядра сразу и сразу на 100%.
Когда ты замешиваешь ООП в ECS, часть опор архитектуры ECS рушится. В результате ты получаешь недоархитектуру, которой уже не так удобно пользоваться. Так всегда бывает с любым архитектурным шаблоном: ты не можешь пользоваться им с присущим ему удобством если сам же это удобство загубил.
Ты можешь получить внезапный удар в спину от невозможности больше удалять компоненты после их добавления. Или - невозможность оперировать жизнью компонентов после создания сущности. Или - недоступную более возможность массового распараллеливания.
Это все больно бьет по удобству использования ECS.
Это я говорю как участник двух Open Source разработок ECS библиотек и создатель трех собственных версий ECS.

Entity Component System + ООП подход?

siRius32, да, это плохой дизайн. Java не оставляет тебе шанса в отказе от ООП, но даже в Java можно реализовать правильный подход ECS.

Важным пунктом идеологии ECS является эфемерность сущности. В ней не должно быть логики, в ней не должно быть данных. Сущность - это что-то среднее между абстрактным указателем и хешем. И только системы должны иметь понимание семантики сущности. Доступ ко всем данным сущности и всю логику сущности должны реализовать именно системы.

Как решить проблему в visual studio 2019 c++?

JoJikRe , этот крестик - это сообщение об ошибке исполнения. std::out_of_range говорит о том, что код попытался обратиться за пределы стандартного контейнера. Исключение было сгенерировано на той строчке, на которой ошибка и присутствует.
Тебе стоит просто отладить свой код.

Вызов C++ функций в python?

newuser20, тебе нужно это все описать в своем вопросе. В комментариях к ответам эта информация бесполезна.

Вызов C++ функций в python?

newuser20, тебе стоит расписать больше, т.к. сейчас твой вопрос только вводит в заблуждение.
Сформулируй свой вопрос в более подробной форме, чтобы было понятно, какую именно функцию ты хочешь вызвать и какой результат получить.

Нужно ли инициализировать статические переменные?

oftywave, это уже выходит за рамки текущего вопроса. Оффтоп запрещен правилами.
Тебе будет лучше оформить это как свой новый вопрос. В этом случае ответить на него смогу не только я, но и другие люди тоже.

Как удалить символ из строки?

Руслан Тиляев , а чем удаление слова отличается от удаления символа?

Нужно ли инициализировать статические переменные?

oftywave, мои вопросы подразумевают некоторое знание, обладая котором в вопросе можно сориентироваться.
Хорошо что ты открыто говоришь о том, что не сориентировался.
С твоих слов статическая переменная ни чем не отличается от утекшей динамической памяти. Ее тоже один раз выделили и один раз проинициализировали, а потом она утекла и прожила до кона жизни процесса.

И, все-таки, это не верно. Тебе нужна информация о природе статического времени жизни: [1], [2]. Это как минимум.
Дополнительно, тебе стоит сразу понять проблему фиаско статической инициализации.

Статической переменную (или константу) делает расположение этой переменной в памяти с характеристикой статического времени жизни (static storage-duration).
Статический объект от глобального отличается тем, что определен с применением слова static, которое разрешает только внутреннее связывание (internal linkage) объекта в рамках текущего модуля трансляции. Глобальные объекты имеют внешнее связывание (external linkage) и могут быть использованы в других модулях трансляции. Возможность связывания - это именно то, что отличает глобальные объекты от динамической памяти. Для динамической памяти связывание недоступно.
Объекты в памяти статического времени жизни инициализируются до начала работы главной функции и деинициализируются после выхода из главной функции.
При этом, инициализация происходит в соответствии с общим правилом инициализации любого объекта любого типа. В случае с тривиальными типами инициализация объекта будет фиктивной. Тривиальные типы не имеют функционального конструктора по умолчанию и всегда должны быть явно инициализированы.

Все это должно говорить тебе о том, что если ты пропускаешь явную инициализацию глобального объекта, для его инициализации будет использован конструктор по умолчанию, который пуст для тривиальных типов, в следствии чего глобальные объекты тривиального типа, равно как и локальные, после инициализации будут содержать произвольный мусор.
Секция глобальных полей в бинарном образе может не содержать флаг очистки при своей разметке. Такое поведение бывает у оптимизированных приложений. В результате, используя в своем коде неинициализированные глобальные объекты ты вносишь в свою программу неопределенное поведение, как, в целом, и говорится в стандарте.

Нужно ли инициализировать статические переменные?

oftywave , что делает переменную статической, какие свойства добавляются переменной чтобы она стала статической?

Не выравниваются функциональные блоки?

oftywave,

это уже вкусовщина пошла

Имей в виду, что так зачастую говорят люди без понимания деталей разработки. Такие термины, как стратификация, декомпозиция, модульность и изоляция, означают отнюдь не вкусовщину. Как человеку начинающему, тебе пока простительно незнание важных архитектурных приемов создания поддерживаемого кода, но лучше с этим не засиживаться.

Между тем, тысяча с лишним строк в файле исходного кода - это средний объем кода в крупном проекте. И студия легко с этим объемом справляется. Я иногда работаю в файлах с тремя или пятью тысячами строк. Проблем не испытываю.
Проблема у тебя явно локальная. Будет хорошо если ты покажешь настройки Intellisense.

Как заставить ботов убегать от преследователей?

Magneto903, тебе стоит почитать про Navmesh building и Convex Hulling.
Результирующее навигационное пространство может содержать дополнительные свойства, в числе которых может быть свойство тупиковой ветви движения (ближе-дальше относительно тупика), свойство поверхности передвижения, свойство габаритов прохода.
Такие дополнительные свойства добавляются в пространство для того чтобы варьировать поведение разных аниматов в рамках единого навигационного пространства.

Влияет ли низкое напряжение сети на работу фотополимерного принтера?

Jek, тогда советую сделать тест на засветку. Просто берешь каплю на что-нибудь капаешь и кладешь под солнце.
Минуты засветки будет достаточно чтобы фотополимер полностью затвердел. Если не твердеет, значит он уже деградировал.
Китайская смола от Anicubic такая себе, быстро сепарируется и быстро деградирует.

Влияет ли низкое напряжение сети на работу фотополимерного принтера?

Jek , был ли принтер все время простоя включен в сеть? Встряхивал ли ты фотополимер перед заливкой в ванну для печати? Делал пробу фотополимера на засветку солнечным светом?

Что за файлы sources в папках с исходным кодом?

Сергей Карбивничий, я занимаюсь разработкой, в частности, под Win и XBox. И, нет, про структуру этого файла я ничего не знаю, да и не должен. Никогда даже не задумывался о том, что эти файлы должны для меня нести какой-либо смысл.
Но тебе сперва стоило бы провести более детальный поиск по файлам. Все вполне хорошо описывается прямо в этих файлах.