раньше в книжках по ооп писали как раз про то что к играм ооп шикарно заходит) и литам нет стейта, поведения, отношений между объектами?

или объектов нет а есть аргументы?)

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

я же написал что взаимосвязи не такие типа о передам пару аргументов и збс

а про ивенты не написал)

а так и есть

ну так может быть сравнить чем отличаются подходы в "остальном мире" от подходов в гейм деве? тема то интересная

возьмем какой Entity-Component-System (или что там нынче популярно у вас) и будем разбираться)

го статью хД

это тоже не правда. ооп к играм только в виде хелловворлд подходит, за исключением некоторых моментов

это тоже не правда. ооп к играм только в виде хелловворлд подходит, за исключением некоторых моментов

а что подходит лучше? процедурщина?

ФП?

ФП :)

ecs

при чем тут процедурщина)

ecs+oop

ecs

это ж теплое и мягкое, ECS можно делать хоть на фп хоть на ооп

но второго мало

при чем тут процедурщина)

весь вопрос как происходит работа со стэйтом

и вся разница только в этом

(это если мы сравниваем процедурщину и ФП/ООП/ActorModel)

но второго мало

ну так вот - ECS - расскажи тупым как это работает примерно. Что есть component?

нет, не совсем.... компонент это карта а не обьект

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

и нет смысла с этим бороться

и могу ли я воспринимать систему в терминах ECS как "процесс" ? как взаимодействие процессов этих происходит?

нет, не совсем.... компонент это карта а не обьект

ну я и не говорю что это объект)

для меня система это объект

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

точно так же как у тебя про инт почти все знают

но тут может быть я не прав - слишком поверхностно знакомился да и давно

сам процесс моделирования отличается от ооп

сам процесс моделирования отличается от ооп

процесс моделирования в ООП отличается в зависимости от того как кто ооп интерпритирует))

ентити это не ооп, но близк

если есть возможность кратко объяснить основную суть различий, по твоему мнению - будет хорошо

ентити это не ооп, но близк

по каким критериям это не ооп и по каким близко?

ентити это не ооп, но близк

а что такое ООП?)

с телефона тяжело спорить

а то для некоторых C++ это ооп

или джава

а что такое ООП?)

хороший вопрос

там нет ссылок

с телефона тяжело спорить

как будет удобно можем продолжить, но я предлагаю пока отбросить "ооп или не ооп" и сосредоточиться на сути.

нет инкапсуляции

нет инкапсуляции

то есть нет границ и модульности?

все есть одна огомная система и все общее?

я имею доступ отовсюду ко всему

мне казалось что уже лет 20 никто так игры не пишет...

я имею доступ отовсюду ко всему

то есть в изоляции компоненты разрабатывать невозможно?

ну или даже по другому - хоть какая-то декомпозиция же есть?

черт с ним с доступом

я имею доступ отовсюду ко всему

не ну эт ты загнул наверн)

есть сущности просто стейт и есть компонент -контейнер который хранит свойства сущностей

ну да загнул, но компоненты как карты собираются

ну да загнул, но компоненты как карты собираются

то есть стэйт группируется по компонентам?

да

у меня лично вообще такая шняга еще что часть классов и структур одинаковые для клиента и сервака, это еще один фактор в пользу того сделать некоторые объекты просто с данными, с минимумом поведения

поля сущностей групперуются в компоненты

там нет ссылок

можно подробнее? ты про референсы на объекты? то есть все by value? все имутабельное (копирование при записи)

да

мутабельно

но это от яп зависит

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

ну например стата может быть контейнером с данными без поведения, при этом стата по разному влияет на разных персонажей верно? например у него есть стата - регенерация на 50% здоровья, но один тип персонажа регенирируется за час, другой за сутки, и там где тебе надо использовать регенерацию в коде ты берешь персонажа, спрашиваешь у него стату и спрашиваешь какой тип этого персонажа и сам решаешь снаружи как конкретно этого чувака регенерировать верно?

смотря где

а не говоришь ему регенерируйся братан так как ты можешь )

ну например стата может быть контейнером с данными без поведения, при этом стата по разному влияет на разных персонажей верно? например у него есть стата - регенерация на 50% здоровья, но один тип персонажа регенирируется за час, другой за сутки, и там где тебе надо использовать регенерацию в коде ты берешь персонажа, спрашиваешь у него стату и спрашиваешь какой тип этого персонажа и сам решаешь снаружи как конкретно этого чувака регенерировать верно?

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

ну вот этот пример можно усложнить?

типа ты в такой то зоне карты регенерироваться будешь сто лет?

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

иначе игру не сделаешь

ну вот этот пример можно усложнить?

давай я голосом запишу ответ, влом писать

можно подробнее? ты про референсы на объекты? то есть все by value? все имутабельное (копирование при записи)

в юнити и ссылки и значения, там на сишарпе пишется, собственно просто + компонентная система с апдейтами

допустим на юнити когда делаешь тот же трансформ, чуть ли не каждым компонентом юзается, и что, это не считается макаронами

классно в вебе, туда стринг, сюда стринг

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

я описываю пуре ecs все по разному ее реализуют. но там не иммутабельности и все это разруливается за счет приоритетов изменения

и будет так же страшно и легче все наружу высунуть и юзать там где надо через геттеры

а так да, строки туда сюда гоняем)

ссылок нет в плане точечной нотации, за исключением сущностей.

ссылок нет в плане точечной нотации, за исключением сущностей.

это где так

в экс, компонент имеет метод get

не, я про то что ты говоришь без ссылок

не понял наверно о чем ты

компонент это как контейнер с объектами которые являются полями сущностей

я о том что ооп не любит когда так делают

и в юните компонент это скорее нода чем компонент

сложна

я о том что ооп не любит когда так делают

хз кто там чего любит и чего не любит но вижу что ECS бывает что юзают с actor model

актор модель же события шлет?

сообщения скорее, хотя разница незначительна

короче вы тут решайте что как назвать, а я пошел по делам)

в чистой ентити нет событий там цикл. хотя сделать что угодно можно

в чистой ентити нет событий там цикл. хотя сделать что угодно можно

обычно компонент делают эктором

во всяком случае я такое читал

значит те кто среагирует на изменение не относятся к системе

там цикл

блин жаль отвлеклись все от пушек, по моему хороший был пример =)

Господа, прошу прощения, дайте кошерную ссылочку про эти пресловутые экторы почитать. Наверное, где-то было уже, но разве ж теперь тут сыщешь.