Объект экземпляр класса?

ayazer, хорошо, благодарю за уточнение.
Да, я заметил оба тега, но свой комментарий писал только относительно C++, опираясь только на код в вопросе и прошлые вопросы автора.

Указатель или Индекс элемента?

IslamuMilana, тебе стоит это все описать в вопросе, а не в комментариях к нему.

Указатель или Индекс элемента?

IslamuMilana , прошу обратить внимание на П3.2 регламента работы сервиса.
Сейчас твой вопрос не получается понять.

Объект экземпляр класса?

ayazer,

1) объявление объекта (без инициализации)

А можно поподробнее по этому пункту? Какое именно поведение будет выбрано для объекта при такой записи и какое состояние у объекта будет на следующей строчке по коду?

Если конвертировать Python в C++, то Python будет весить меньше и работать с большей скоростью как C++?

Rostikttty, что именно тебе не понятно в пункте 3.6, что ты обязан соблюдать нормы русского языка и не писать капсом?

Если конвертировать Python в C++, то Python будет весить меньше и работать с большей скоростью как C++?

Rostikttty , прошу обратить повторное внимание на П3.2 и П3.6 регламента работы сервиса.

Что это за всплывающая кнопка и можно ли её реализовать на WinAPI?

NQUARE,

QTranslate называется, интересно - гуглите.

Нет, так вопросы не задаются.
П3.2 регламента работы сервиса: свой вопрос необходимо формулировать максимально однозначно и информативно. "интересно - гуглите" - не дает ни информации, ни однозначности.
П3.3: формулировать свой вопрос следует в вежливой форме.

Что это за всплывающая кнопка и можно ли её реализовать на WinAPI?

NQUARE, если твой вопрос решен с помощью данного ответа, тебе стоит пометить ответ как решение.

Как внедрить в ядро ОС на Си C++?

Роман Ващенко, расскажи, что такое точка входа?

Инициализация элемента к нулю?

xorknown, да, верно, это предварительное объявление функции, а не определение переменной.
Оно не просто совпадает с fwd функцией и оно компилируется. Это и есть форвард и этим форвардом функции даже можно успешно пользоваться.

maaGames,

HWND window = HWND(); и HWND window(); - это одно и то же

Нет, это не одно и то же. Первое - это copy initialization[?], а второе - это function forward declaration[?] с именем window, без параметров и типом результата HWND.

Выше написали, кстати, неверно. int i = int(); и int i; делают кардинально разные вещи: в первом случае инициализация копией, во втором - инициализация по умолчанию. Первый случай гарантированно инициализирует объект, а второй - нет.
По своему эффекту код int i = int(); будет эквивалентен int i{};.
oftywave , я могу на эту тему написать развернутый ответ, но это потребует времени, которого у меня сейчас нет. Если коротко, у тебя хорошая привычка, код в твоем примере позволяет инициализировать переменную некоторым инициальным значением. Для указателей таким значением, кстати, выбран именно nullptr.

Инициализация элемента к нулю?

maaGames , а подскажи, чем именно является написанная тобой строчка?
HWND window();
Это декларация, оно видно. Что этим кодом декларируется?

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

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 говорит о том, что код попытался обратиться за пределы стандартного контейнера. Исключение было сгенерировано на той строчке, на которой ошибка и присутствует.
Тебе стоит просто отладить свой код.