Мне всегда было очень интересно, в чем отличие скабрезненьких велосипеда и костылей от гордо звучащего промышленного решения? Где та самая грань, по пересечении которой велосипед становится промышленным решением, а костыли — надежными подходами? :)
У меня такое впечатление, что весь этот пункт 2.4 нацелен исключительно на ограничение бесконтрольного использования Unity, как основы для медиаконтента, в целях игрового стримминга и использования в SaaS решениях.
Через SaaS можно предоставлять бесконтрольный доступ к Unity IDE для разработки множества проектов множеством коллективов, используя при этом всего одну лицензию от поставщика SaaS услуг. Ясно-понятно что такое поедение как бы не докладывает денежку в карман самих разработчиков Unity. Бесконтрольно так не докладывает.
В прошлом, я точно помню, была практика отчислять в пользу Unity небольшой процент с каждой копии игры свыше $100k годового дохода. Сейчас FAQ говорит об обратном.
Так вот. Бесконтрольное использование игрового стримминга полностью скрывает от Unity как доходы с продажи игры, так и количество проданных копий. Это точно так же ведет к серьезному и бесконтрольному недокладу денежек в карман Unity.
Еще пункт 2.4 не запрещает, а говорит о том, что SaaS или игровой стримминг надо согласовывать отдельно. Это нормальная практика. При работе с некоторыми издательствами тоже надо согласовывать разные моменты действий разработчиков. SCE и MS в принципе желают быть в курсе процессов издания игр на своих консолях. Открытость и прозрачность процессов — это не плохо.
В таком рассмотрении пункт 2.4 выглядит полностью оправданным. Компания просто защищается от злонамеренной эксплуатации своего продукта. Под вопросом остается риторика Improbable. О чем таком компании не смогли договориться между собой? По моему обе компании темнят в отношении друг друга…
Unity — это полноценная экосистема разработки приложений. Рендеринг там — не главное. Можно и без него. Собственно, именно так сервера на юньке и работают — ничего не рисуя/озвучивая, но обрабатывая механики и игровую логику.
В целом, в узких кругах широкого сообщества принято считать что сервер на Unity нужен не более чем для прототипирования реального сервера. Unity слишком неповоротлив для решения серверных задач.
Для случая SpatialOs и Unity все выглядит таким образом.
SpOs — это среда запуска процесса игры и доставки ему параметров его работы. SpOs запускает безголовую (headless) версию игры, в которой отключен рендеринг изображений и звуков, передает процессу игры настройки его работы и далее подключает к нему сетевой интерфейс для обмена данными с клиентами.
А я ведь не в ролях людей увидел что-то знакомое. Роли там разные, это верно. Общее — это работа с информацией.
Человек приходит с ясной целью визионера в той или иной области. Будь то средние или долгосрочные планы развития или же планы по внесению ясности в информационное поле проекта. С течением времени трудовой конформизм (или что-либо еще) может привести человека к тому, что человек начинает заниматься не совсем тем, чем ему хотелось бы заниматься.
У нас не принято говорить о трудовых конфликтах, о противостоянии мнений, о разногласиях в трудовом коллективе. Часто от человека можно видеть исполнительность вопреки его несогласию с совершаемыми действиями. Часто это называется профессионализмом. Снаружи коллектив должен выглядеть монолитным, где каждый человек согласен и поддерживает общее направление движения. Вскрытие внутреннего раздора — это гарантированный скандал.
Смута в информационном поле AoC может быть случайным стечением обстоятельств, следствием поспешной выдачи неструктурированной информации. А еще это может быть целенаправленным процессом для сокрытия реального положения вещей. И если так, то видение Маргарет со временем может поменяться.
Еще в работе КМ есть один очень неприятный момент: "- Ребята, мне нужна вот такая вот информация для подачи сообществу, где мне ее взять? — Ну смотри, сейчас вот части информации пока нет, а вот эту пока нельзя разглашать. Пока мы тебе ничего дать не можем, но мы верим что ты выкрутишься". Информацию от КМ нередко закрывают. И в результате КМ чуть ли не сам выдумывает недостающие участки информации. Где-то он ходит прямо по отделам разработки и тихонько спрашивает кусочки информации у исполнителей, чтобы уж совсем на голом месте не фантазировать. А на выдаче или ничего, или материал с пометкой что в будущем всё будет еще уточняться.
Я не испытываю воодушевления от появления КМ у AoC. Я просто наблюдаю.
Клево будет если у Маргарет все получится и ее деятельность будет чаще снимать вопросы, чем способствовать возникновению новых. :)
Эта новость почему-то напомнила мне историю Чайки. Начало показалось довольно знакомым, хотя я не могу назвать информационное поле EVE Online того периода хаосом.
Кто-то может подсказать — украшение у нее на шее реально завязывается на узелок или сзади обычный карабинчик?
Я, как бы, просто оставлю это здесь. Без пояснений. :)
Вопрос был адресован абсолютно всем. Иначе его незачем писать вне личной переписки.
Вопрос никак не относился к теме данной заметки, стало быть и размещать его в комментариях к ней никаких оснований нет.
простите НО как вот относиться мне лично к вам после такого ??
Относиться стоит с позиции того что я на анализ каждого твоего сообщения, в среднем, потратил примерно по 2 минуты. Более 25 минут в целом. Каждый комментарий был прочитал минимум 2 раза и проанализирован.
В первую очередь «данный» комментарий предназначен каждому привыкшему думать своей головой человеку. Дабы мнение свое составить на основе фактов. А относится он к теме заметки настолько же, насколько к ней относится любой другой комментарий как выше по ветке, так и в целом.
Твой данный комментарий выглядит крайне подозрительно на фоне отсутствия подобных вопросов к другим комментариям в данной заметке.
ECS — это просто инструмент. Дело в том, что для того чтобы кто-то хотя-бы просто задумался об использовании инструмента, этот инструмент этому кому-то надо именно продать за интерес. У тебя в руках итак довольно много инструментов, каждый из которых изрядно перегружен в информационном плане. А семейство CO/ES парадигм настолько информационно перегружено, что его буквально надо захваливать чтобы продать кому-либо. CO/ES требуют кардинальной перестройки мышления инженера. Первичное непонимание этих парадигм — это рядовая реакция. :)
Можно начать с малого. Сперва можно понять, что функциональность может существовать отдельно от данных. Такой подход позволяет нелинейно наращивать функциональность вокруг набора данных, не меняя при этом уже созданную функциональность или сами данные.
На следующем шаге можно свыкнуться с тем, что довольно часто монолитность данных искусственна, что в прошлом она была подчинена требованиям функционального интерфейса. А когда функциональный интерфейс отделен от данных, его требования перестают довлеть над данными. Появляется возможность декомпозиции данных.
Когда данные декомпозированы, формальная классификация объектов теряет свое качество. Теперь объект может быть классифицирован через композицию данных. В это же самое время, над композицией данных становится возможным выполнение некоторого внешнего функционального интерфейса. Но самое интересное в том, что композиция данных может свободно меняться во время жизни объекта — что меняет как его классификацию, так и набор доступных функциональных интерфейсов.
Теперь все разнообразие объектов определяются только композицией своих данных, связанных вместе через абстрактный идентификатор сущности, и набором универсальных функциональных интерфейсов, каждый из которых понимает только часть общей композиции данных сущности, думая что предоставленная часть композиции — это и есть вся сущность.
Лично яб с радостью еще один плюсик заметке поставил бы только за отсылку к статьям Адама Мартина (T-Machine). :)
Любому инженеру, решившему понять семейство ES парадигм, в первую очередь стоит обратиться к статьям и wiki этого человека. Адам занимается развитием этого семейства еще с начала нулевых. Тема CO/ES/ECS является очень старой. Без это всего реализация таких игр как, например, Prototype, стала бы крайне затруднительной.
William_Godwin , мне вот что стало интересно. Какую реализацию компонентного подхода вы решили выбрать для своего проекта?
У тебя получилась крайне спорная дихотомия. Или оно не нужно клиентам, или владельцы бы не выбрасывали продукт.
А что если старый продукт нужно выбросить для того, чтобы следующий твой продукт начал бы приносить больше прибыли? Суть в этом.
Меняются технологии, меняются взгляды, меняются методы оплаты. Продукт, созданный из расчета на одну модель оплаты, вряд ли может быть перестроен на другую модель. Потому что после перестройки на другую модель оплаты продукт может оказаться уже немного другим. Или совсем другим.
Игры создают не программисты.… Программисты создают движок и инструментарий, и только лишь. Но не игру.
На самом деле это «немного» не так.
Не так давно, еще где-то в районе 1995 года, игровому дизайнеру Рафу Костеру потребовалось сперва изучить неизвестный ему язык скриптов (для которого на тот момент и машины виртуальной еще не существовало), затем набить на этом языке дизайн механик и квестов, а после завершения создания виртуальной машины — переписать все заново.
Квесты, предметы, монстры, расположение и поведение НПЦ, навыки и даже связи между локациями в игре Ragnarok Online создаются средствами специального языка для виртуальной машины сервера eAthena.
Я могу очень много таких примеров привести, но не в них суть.
Существует подход под названием DDP (Data-Driven Programming). В рамках этого подхода программа разбивается на уровни ответственности. Чем ниже — тем ближе к кремнию. Чем выше — тем ближе к человеку. Ответственность растет от человека, где она минимальна, в сторону кремния, где ответственность максимально высокая.
Код с высоким уровнем ответственности создается в виде разрозненных и атомарных блоков логики. На среднем уровне задаются правила объединения блоков кода с низкого уровня. А на верхнем уровне правила среднего уровня используются как операторы для написания конкретной бизнес-логики.
При этом, начиная со среднего уровня код программы перестает быть исключительно текстовым: в код включаются машины состояний, графы переходов, деревья поведений, разного рода таблицы с данными, включая даже изображения карт многомерных распределений или карт шумов.
Разве многопоточный код со struct-ами на чистом С или даже ассемблере выглядит проще и понятнее?
Да, значительно проще в том случае, когда применяется DOD или семейство CO/ES парадигм.
DOD (Data Oriented Design) напрямую дает поточную изоляцию памяти, что выливается как в неблокирующие операции, так и в т.н. positive sharing (положительную работу предсказателя и постоянную актуальность данных в L1).
Семейство CO (Component Oriented) и ES (Entity System) парадигм предлагает набор решений для широкого ряда проблем, в том числе и описанных в данной статье.
Было бы, как минимум, цивилизованно, если бы вы с той же тщательностью, с которой я раскладывал по полочкам вашу систему, попробовали проанализировать нашу и указали бы, где же в игровой части нашего проекта продаются преимущества за донат.
За тщательный анализ подобных вещей мне обычно платят деньги. Я этим ровно на хлеб зарабатываю.
Видимо, обоснование на ветер брошенных слов — это DLC за $50. Этакая клево поставленная точка монетизации в игровом цикле нашего общения. Неплохо придумано, хоть и зря.
Дальнейшее обсуждение я готов вести с людьми, понимающими индустрию не только с позиции игрока.
А чего бы в более прямой и открытой форме не привнести это самое понимание игровой индустрии? Да так, чтоб без замалчивающих контрвопросов, недосказанности и намеков. Это ведь очень полезные знания, когда они передаются в открытой форме.
Того и глядишь, с твоей помощью твои же собственные условия и выполнились бы.
Да, игроки за что-то обычно платят. Это понимаю я. Это понимаешь ты. Это понимает каждый нас читающий. Каждый читающий понимает это по-своему.
Еще я хорошо понимаю и то, насколько хорошо честная и открытая позиция сказывается на взаимном понимании.
Давай попробуем наладить взаимное понимание в плане оплаты в F2P модели.
Пожалуй, да. F2P с микротранзакциями показывают лучшие результаты. А подскажи пожалуйста вот что.
F2P — это ведь Free to Play. Переводится как: «Бесплатно играть». Если игровой процесс в игре бесплатен (это ведь ты сам выбрал такую модель распространения игры), то за что игрок будет денежно вознаграждать тебя?
Более детально мой вопрос выглядит так.
Модель F2P говорит о том, что весь игровой процесс изначально полностью бесплатен абсолютно для всех лояльных игроков. Т.е. цену своим стараниям по разработке всего этого игрового процесса мы ставим в 0 условных попугайчиков. Арт, игровые механики, поддержка работы серверов, работа команды разработки, все рекламные кампании — вся эта работа просто дарится игрокам на безвозмездной основе. Это подразумевает термин F2P.
Ок, дарим игру безвозмездно, хорошо. Это клевое решение, яб так не смог. Но если вся игра подарена игроку бесплатно, то за что игрок будет платить разработчику деньги?
Ведь F2P показывает лучшие финансовые результаты.
Эта цитата ведь относится к вот этому вопросу из этого твоего комментария?
можете назвать мне список фритуплей проектов, в которых вы платили деньги и которые оставили у вас такое отношение?
Если так, то этом случае лично мне бы хотелось попросить некоторые уточнения.
Действительно ли тебе хочется услышать о том, получал ли кто-либо удовольствие от микротранзакций, от покупки и открытия лутбоксов, от покупки внутриигровых ценностей за реальные деньги?
Или тебе интересно узнать о том, существует ли с точки зрения кого-либо хоть одна удачная F2P игра и согласился ли этот кто-либо выразить свою поддержку такой игре любым из доступных способов передачи разработчикам денег?
Через SaaS можно предоставлять бесконтрольный доступ к Unity IDE для разработки множества проектов множеством коллективов, используя при этом всего одну лицензию от поставщика SaaS услуг. Ясно-понятно что такое поедение как бы не докладывает денежку в карман самих разработчиков Unity. Бесконтрольно так не докладывает.
В прошлом, я точно помню, была практика отчислять в пользу Unity небольшой процент с каждой копии игры свыше $100k годового дохода. Сейчас FAQ говорит об обратном.
Так вот. Бесконтрольное использование игрового стримминга полностью скрывает от Unity как доходы с продажи игры, так и количество проданных копий. Это точно так же ведет к серьезному и бесконтрольному недокладу денежек в карман Unity.
Еще пункт 2.4 не запрещает, а говорит о том, что SaaS или игровой стримминг надо согласовывать отдельно. Это нормальная практика. При работе с некоторыми издательствами тоже надо согласовывать разные моменты действий разработчиков. SCE и MS в принципе желают быть в курсе процессов издания игр на своих консолях. Открытость и прозрачность процессов — это не плохо.
В таком рассмотрении пункт 2.4 выглядит полностью оправданным. Компания просто защищается от злонамеренной эксплуатации своего продукта. Под вопросом остается риторика Improbable. О чем таком компании не смогли договориться между собой? По моему обе компании темнят в отношении друг друга…
В целом, в узких кругах широкого сообщества принято считать что сервер на Unity нужен не более чем для прототипирования реального сервера. Unity слишком неповоротлив для решения серверных задач.
Для случая SpatialOs и Unity все выглядит таким образом.
SpOs — это среда запуска процесса игры и доставки ему параметров его работы. SpOs запускает безголовую (headless) версию игры, в которой отключен рендеринг изображений и звуков, передает процессу игры настройки его работы и далее подключает к нему сетевой интерфейс для обмена данными с клиентами.
Человек приходит с ясной целью визионера в той или иной области. Будь то средние или долгосрочные планы развития или же планы по внесению ясности в информационное поле проекта. С течением времени трудовой конформизм (или что-либо еще) может привести человека к тому, что человек начинает заниматься не совсем тем, чем ему хотелось бы заниматься.
У нас не принято говорить о трудовых конфликтах, о противостоянии мнений, о разногласиях в трудовом коллективе. Часто от человека можно видеть исполнительность вопреки его несогласию с совершаемыми действиями. Часто это называется профессионализмом. Снаружи коллектив должен выглядеть монолитным, где каждый человек согласен и поддерживает общее направление движения. Вскрытие внутреннего раздора — это гарантированный скандал.
Смута в информационном поле AoC может быть случайным стечением обстоятельств, следствием поспешной выдачи неструктурированной информации. А еще это может быть целенаправленным процессом для сокрытия реального положения вещей. И если так, то видение Маргарет со временем может поменяться.
Еще в работе КМ есть один очень неприятный момент: "- Ребята, мне нужна вот такая вот информация для подачи сообществу, где мне ее взять? — Ну смотри, сейчас вот части информации пока нет, а вот эту пока нельзя разглашать. Пока мы тебе ничего дать не можем, но мы верим что ты выкрутишься". Информацию от КМ нередко закрывают. И в результате КМ чуть ли не сам выдумывает недостающие участки информации. Где-то он ходит прямо по отделам разработки и тихонько спрашивает кусочки информации у исполнителей, чтобы уж совсем на голом месте не фантазировать. А на выдаче или ничего, или материал с пометкой что в будущем всё будет еще уточняться.
Я не испытываю воодушевления от появления КМ у AoC. Я просто наблюдаю.
Клево будет если у Маргарет все получится и ее деятельность будет чаще снимать вопросы, чем способствовать возникновению новых. :)
Я, как бы, просто оставлю это здесь. Без пояснений. :)
Вопрос никак не относился к теме данной заметки, стало быть и размещать его в комментариях к ней никаких оснований нет.
Относиться стоит с позиции того что я на анализ каждого твоего сообщения, в среднем, потратил примерно по 2 минуты. Более 25 минут в целом. Каждый комментарий был прочитал минимум 2 раза и проанализирован.
Твой данный комментарий выглядит крайне подозрительно на фоне отсутствия подобных вопросов к другим комментариям в данной заметке.
Можно начать с малого. Сперва можно понять, что функциональность может существовать отдельно от данных. Такой подход позволяет нелинейно наращивать функциональность вокруг набора данных, не меняя при этом уже созданную функциональность или сами данные.
На следующем шаге можно свыкнуться с тем, что довольно часто монолитность данных искусственна, что в прошлом она была подчинена требованиям функционального интерфейса. А когда функциональный интерфейс отделен от данных, его требования перестают довлеть над данными. Появляется возможность декомпозиции данных.
Когда данные декомпозированы, формальная классификация объектов теряет свое качество. Теперь объект может быть классифицирован через композицию данных. В это же самое время, над композицией данных становится возможным выполнение некоторого внешнего функционального интерфейса. Но самое интересное в том, что композиция данных может свободно меняться во время жизни объекта — что меняет как его классификацию, так и набор доступных функциональных интерфейсов.
Теперь все разнообразие объектов определяются только композицией своих данных, связанных вместе через абстрактный идентификатор сущности, и набором универсальных функциональных интерфейсов, каждый из которых понимает только часть общей композиции данных сущности, думая что предоставленная часть композиции — это и есть вся сущность.
Любому инженеру, решившему понять семейство ES парадигм, в первую очередь стоит обратиться к статьям и wiki этого человека. Адам занимается развитием этого семейства еще с начала нулевых. Тема CO/ES/ECS является очень старой. Без это всего реализация таких игр как, например, Prototype, стала бы крайне затруднительной.
William_Godwin , мне вот что стало интересно. Какую реализацию компонентного подхода вы решили выбрать для своего проекта?
А что если старый продукт нужно выбросить для того, чтобы следующий твой продукт начал бы приносить больше прибыли? Суть в этом.
Меняются технологии, меняются взгляды, меняются методы оплаты. Продукт, созданный из расчета на одну модель оплаты, вряд ли может быть перестроен на другую модель. Потому что после перестройки на другую модель оплаты продукт может оказаться уже немного другим. Или совсем другим.
Не так давно, еще где-то в районе 1995 года, игровому дизайнеру Рафу Костеру потребовалось сперва изучить неизвестный ему язык скриптов (для которого на тот момент и машины виртуальной еще не существовало), затем набить на этом языке дизайн механик и квестов, а после завершения создания виртуальной машины — переписать все заново.
Квесты, предметы, монстры, расположение и поведение НПЦ, навыки и даже связи между локациями в игре Ragnarok Online создаются средствами специального языка для виртуальной машины сервера eAthena.
Я могу очень много таких примеров привести, но не в них суть.
Существует подход под названием DDP (Data-Driven Programming). В рамках этого подхода программа разбивается на уровни ответственности. Чем ниже — тем ближе к кремнию. Чем выше — тем ближе к человеку. Ответственность растет от человека, где она минимальна, в сторону кремния, где ответственность максимально высокая.
Код с высоким уровнем ответственности создается в виде разрозненных и атомарных блоков логики. На среднем уровне задаются правила объединения блоков кода с низкого уровня. А на верхнем уровне правила среднего уровня используются как операторы для написания конкретной бизнес-логики.
При этом, начиная со среднего уровня код программы перестает быть исключительно текстовым: в код включаются машины состояний, графы переходов, деревья поведений, разного рода таблицы с данными, включая даже изображения карт многомерных распределений или карт шумов.
DOD (Data Oriented Design) напрямую дает поточную изоляцию памяти, что выливается как в неблокирующие операции, так и в т.н. positive sharing (положительную работу предсказателя и постоянную актуальность данных в L1).
Семейство CO (Component Oriented) и ES (Entity System) парадигм предлагает набор решений для широкого ряда проблем, в том числе и описанных в данной статье.
А вот контрвопрос явно для замалчивания своего ответа.
Вот вопрос _по_существу_.
А вот намеки в качестве развернутого ответа.
Вот вопрос _по_существу_.
В виде цитаты, для большей выразительности.
Вопрос задан в ответ на откровенный вброс:
А вот недомолвки и намеки.
Тоже в виде цитаты, для большей выразительности.
Видимо, обоснование на ветер брошенных слов — это DLC за $50. Этакая клево поставленная точка монетизации в игровом цикле нашего общения. Неплохо придумано, хоть и зря.
Того и глядишь, с твоей помощью твои же собственные условия и выполнились бы.
Еще я хорошо понимаю и то, насколько хорошо честная и открытая позиция сказывается на взаимном понимании.
Давай попробуем наладить взаимное понимание в плане оплаты в F2P модели.
F2P — это ведь Free to Play. Переводится как: «Бесплатно играть». Если игровой процесс в игре бесплатен (это ведь ты сам выбрал такую модель распространения игры), то за что игрок будет денежно вознаграждать тебя?
Более детально мой вопрос выглядит так.
Модель F2P говорит о том, что весь игровой процесс изначально полностью бесплатен абсолютно для всех лояльных игроков. Т.е. цену своим стараниям по разработке всего этого игрового процесса мы ставим в 0 условных попугайчиков. Арт, игровые механики, поддержка работы серверов, работа команды разработки, все рекламные кампании — вся эта работа просто дарится игрокам на безвозмездной основе. Это подразумевает термин F2P.
Ок, дарим игру безвозмездно, хорошо. Это клевое решение, яб так не смог. Но если вся игра подарена игроку бесплатно, то за что игрок будет платить разработчику деньги?
Ведь F2P показывает лучшие финансовые результаты.
Если так, то этом случае лично мне бы хотелось попросить некоторые уточнения.
Действительно ли тебе хочется услышать о том, получал ли кто-либо удовольствие от микротранзакций, от покупки и открытия лутбоксов, от покупки внутриигровых ценностей за реальные деньги?
Или тебе интересно узнать о том, существует ли с точки зрения кого-либо хоть одна удачная F2P игра и согласился ли этот кто-либо выразить свою поддержку такой игре любым из доступных способов передачи разработчикам денег?