отсюда и по ссылкам в статье по первоисточникам, короче)

отсюда и по ссылкам в статье по первоисточникам, короче)

грасиас, амиго)

Остался не раскрытым вопрос, зачем пушке знать статы игроков

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

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

пока смотрю видяшки на тему архитектур в играх.... и меня прикалывают аргументы что "ООП не работает потому что нам надо множественное наследование"

но это одна видяшка из 4-х такое заявляла)

о, уже обсуждали новость что юбисофт открывают два новых офиса в украине?

пример на котором человеку можно было объяснить =) но он ушел =(

ну тот пример описывает огромный кусок механики на таком проще сказать ой все чем сказать как лучше

лучше взять простое и наращивать бизнес требования

о, уже обсуждали новость что юбисофт открывают два новых офиса в украине?

сколько там тел будет работать?

сколько там тел будет работать?

не знаю, уже вакансия на с++ деву выложили

вроде открывают офис в одессе, а на доу на одессу только 3 вакансии

а киеве 8

ну так киевскому офису десять лет

в Одессе вроде за год 60 рыл взять собираются

а так до 120 набрать

https://jobs.dou.ua/companies/ubisoft/vacancies/?from=widget_company

пока не густо_

)

смотри на оф сайте

там в Одессу вроде 8-10 штук было

но разрабы - лид плюсер и вроде девопс нужен

интересно, пыхеры будут нужны? ?

я думаю это последнее что им нужно

((

там наверняка 3д аниматоры тестеры и с++

в основном будут

я думаю это последнее что им нужно

предпоследнее перед жсерами

та кто его знает. зачем то же офис в индии открыли

помоему вы сильно оффтопите

/stat@combot

combot.org/chat/-1001071233926

пример на котором человеку можно было объяснить =) но он ушел =(

что ты хотел объяснить?)

то что гетеры не нужны =)

что ты хотел объяснить?)

почему во многих источниках про ECS очень много говорят за то что "наследование не эффективно и потому ECS", ну то есть приводится идея что в ECS ты можешь определенные характеристики (сущности) биндить компонентам, импортировать характеристики из других компонентов и т.д..... ну то есть вопрос у меня в общем то - чем это от композиции отличается (или агрегации?)

+ откуда взялась идея что сущности это pure data?

в играх очень хорошо ложится шаблон стратегии

то что гетеры не нужны =)

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

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

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

это даже мне было понятно =)

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

другие проперти режутся интерфейсами

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

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

архитектура там сложнее только в плане связанности

ну и количества объектов

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

нет, там вы проектируете поведение а не характеристики, как на сайтах

там моделирование мира

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

может я конечно там кусок пропустил

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

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

меня интересует другое - почему люди считают что объекты сложными должны быть?))) я наоборот считаю что объекты должны быть как можно меньше.

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

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

потому, что разная предметная область

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

когда появляются классы User на 30 полей и т.д. - я считаю что это "непонимание ООП"

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

когда люди говорят что вот у нас есть персонаж, есть мерчент, есть монстр в игре и "у нас проблема потому что есть общие штуки но нет множественного наследования" - я считаю что это полное непонимание ООП

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

можешь пояснить мысль? ну то есть "ооп класс" это просто модуль который экспоузит какой-то публичный интерфейс и стэйт внутри неприкосновенен?

или стэйт передается алгоритму на вход (ФП)

вылезло уведомление о сообщении, но собщения нет..

тмм было написано можешь пояснить...

Sergey Protko, [24.03.18 11:56] [In reply to Uiiuviiw] можешь пояснить мысль? ну то есть "ооп класс" это просто модуль который экспоузит какой-то публичный интерфейс и стэйт внутри неприкосновенен? Sergey Protko, [24.03.18 11:57] или стэйт передается алгоритму на вход (ФП)

вообще что бы ты понимал - этот чат изначально создавался как эдакое "поболтать что же такое ООП потому что то что другие выдают за ООП ничем от структурного программирования не отличается"

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

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

я предлагаю не делать одну "сущность" юзера с методом "передвинься" а представить юзера как систему объектов.

ну то есть само понятие объекта как по мне второстепенно, важно кто хранит и работает со стэйтом

и это может быть не юзер, хотя положение в пространстве может быть юзера

или это может быть объект который хранит все положения юзеров в пространстве, а может еще как.... ну то есть не так в лоб что есть "юзер"

но объект физика это и есть состояние и хранит его класс чела

давай отойдем на секундочку от классов

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

давай пофантазируем

у вас моделька юзер а у меня юзер сборщик моделек состовляющего юзер

представим себе что "объект" это компьютер в сети (лэтенси сети невилируем), стэйт каждого комьютера свой и изолированный, передавать данные между компами дорого, потому лучше что бы каждый комп что-то считал и слал сообщения другим (в том числе pub/sub)

у вас моделька юзер а у меня юзер сборщик моделек состовляющего юзер

такой прием называется pugna не надо так

у вас моделька юзер а у меня юзер сборщик моделек состовляющего юзер

ну у меня как раз таки нет модельки юзера))

у меня есть маленькие модельки в совокупности представляющие юзера

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

ну если игры на акторах полностью строить то мы бы досих пор в марио играли. производительность падает с сотни раз

это про игры. про ооп это нормально, наверное, я не очень понимаю акторов

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

вызов метода и подписка круто

мне вот rx нравится

ну если игры на акторах полностью строить то мы бы досих пор в марио играли. производительность падает с сотни раз

Если бы делали игры на акторах, то хорайзонт на калькуляторе работал бы, А так...(

Если бы делали игры на акторах, то хорайзонт на калькуляторе работал бы, А так...(

на куче калькуляторов)

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

Глупо думать что акторы это про двустороннюю связь

на куче калькуляторов)

?

так многие объясняют

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

но экторы как раз таки про односторонние сообщения

в большей степени, просто имея односторонние можно сделать двусторонние

туда вызов от туда события?