Так речь о том, чтобы вводить эти механики не отдельно друг от друга, а в комплексе. Как и карма, сами по себе, отдельно они неполноценны, на мой взгляд.
Если ганкеры и гриферы приходят и уходят, то это значит, что в игре последствия и ответственность за действия н етак уж ярко выражены. Самый первый барьер, это деньги, которые этот грифер\ганкер потратил н аигру, далее, если он решается на нарушение заонов в игре, то это самое время он проводит либо в ограничении своей деятельности и в прятках, либо в тюрьме, а потом в ограничеиях. Да, он нанесет какой-то урон, но потом он либо совсем уйдет из игры, либо изменится, либо будет в том довольно малом проценте людей, коорым такой геймплей почему-то понравится, но даж епротив них имеются определенные меры в предлагаемой мной схеме.
Так или иначе, такие люди даже в кажущейся идеальной системе будут всегда, но, как мне кажется, если их число постоянно оттекает из игры, в отличии от других ММО их масса не будет накапливаться и тем более не будет становиться критической. Мне кажется это и есть та самая точка баланса.
С ХиХ же получается как-то зуб за зуб, а хочется чего-то цивилизованного.
А разве тот факт, что можно вот так вот просто обмануть людей абсолютно без последствий, не является дырой? Я это вижу так: у нас есть абсолютно бесконтрольное PvP и лазейки с грифингом, игрокам это не очень нравится, ок, давайте просто разделим серверы, пусть они там сами разберутся.
Как по мне, это проблема отсутствия вообще любых механик, которые регулировали бы какие-то взаимодействия между игроками. Честно, в меня может полетят тапки, но их мир пока выглядит пустым не только визуально, но и геймплейно… Может я и не прав, но эта ситуация мне кажется подтверджением. Хотя, может дело в разрозненности отдельных механик. Понятно, что создатели творят какую-то дичь именно в плане подталкивания к такому вот поведению, но у них ведь явно есть геймдизайнерская дыра, разве нет?
Вообщем, я, похоже, вовремя решил написать заметку))
Да, осталось столько всего, на что времени не хватило, как минимум мне точно)) Я и так не раз перебивал всех, так что не решался еще больше забить эфир своими долгими «цоканьями»… Что вообще на меня нашло, не знаю))
Юнити, в случае spatial, всегда на серверной стороне, т.к. это скорее прослойка, чем полноценный сервер, движок создает авторитарный сервер, который реплицирует все расчеты на клиеты. Онлайн игры так и работают. Так бы можно было просто неаписать: «не рендерите в облаке», если речь именно о том самом стриминге.
Так причем тут стриминг? Там же и то и другое. То что называется SpatialOS, это система которая ведет расчеты в облаке виртуальных машин, то есть это облачный сервис, а стриминговые сервисы просто используют данную технологию, т.к. она дает сервису возможность масштабирования при изменении нагрузки.
В случае этого текста, либо юнити просто не умеет корректно составлять ЛС, либо действительно все так, как мы это поняли.
Явно собрались пилить свое облако иил что-то подобное.
А на месте разрабов, с таким отношением, как бы не было сложно, чтоб таких вот казусов н ебыло я б перешел на тот же Armory 3D. Свободный софт всегда застрахован от таких вот… кхм… глупостей.
Причем тут чье-то понимание, если есть конкретное описание парадигмы? Ну и java это вообще отдельная тема, никто не будет, если он понимает что делает, писать на этом языке ММО-песочницу.
NoSQL тут не причем, речь про реляционную модель как таковую, то есть логические связи, а не физические. К слову, 5к человек онлайн означает, что у вас в DB записей гигантское количество, т.к. игру купило раз в 100 больше людей.
Насчет NoSQL я бы не торопился, особенно когда у вас есть многопоточный слон, а вам нужна больше даже не скорость записи а скорость чтения селекта и т.п в условиях очень больших таблиц. у сервера ММО свой запросы.
Так что, лучше писать, как проще, и уже когда игровая схема взлетит, тогда и заниматься оптимизацией производительности.
Если вы сайт пилите, может это и прокатит, но писать как попало ММО, а потом все переделывать это какой-то мазохизм, простите.
Хмммм… Утверждение со школьникакми неоднозначное. Ну да, есть в анриале блупринты и можно без знаний, вроде как, программирования что-то состряпать. Не думаю, что это показатель.
Для работы с этой парадигмой нужно просто подругому мыслить, но очень многие люди, которые переходили с OOD на DoD говорят, что проекирование, написание и отладка стала где-то двже в разы проще. Блольшое количесто вещей етсть, за которые теперь вообще не нужно беспохоиться, как например настройка доступа к данным при добавлении многопоточности. Теперь просто разделяешь все данные на кучки и параллельно обрабатываешь: скорость есть, а головной боли нет.)))
Это логично, если учесть, что веся логика представляет из себя отдельные изолированные блоки, которые занимаются исключительно своим делом, добавляй себе и добавляй.
Могу тольуо сказать, что вы сделали неправильные выводы. Это странно, ведь довольно конкретно говорится во всех предоставленых документах, презентациях с того же cppcon за многие годы, особенно если смотреть того же Мфйкла Эктона, что:
1)Перечисляются конкретные признаки ООП (объекты это еще не ООП)
2)Объясняется, что использование объектов именно такими методами замедляет работу процессора с данными в 400-700 раз (сами инструкции выполняются со скоростью меньше наносекунды, основным узким местом всегда были и остаются данные)
Если вы утверждаете, что код становится сложнее, то вы точно не поняли как это работает. Ну а впихивать или пытаться подружить DoD с OOD, как это делали в презентации разработчики из Unity, как я писал еще в комментариях к прошлой заметке — плохая идея.
А ООП для хайлоад давно умер, если конечно вы не хотите поспорить с эффективностью реляционной модели данных))
На тот момент неочень разбирались в теме, эта либа была очень быстрой по синтетике, это был современный стандарт C++, ну и велосипедостроение это, возможно интересно, но не очень продуктивно.
Есть ли какие-то, эгхм, простые примеры, side-by-side сравнение OOP vs DoD в виде кода?
эгхм
И для расширения тематики огромный список разнообразных полезных материалов по DoD.
Поначалу понравилось, а потом начали так расхваливать ECS, будто пытаетесь мне её продать.
Ни разу) Я пытался показать преимущества, которые и делают ECS и DoD лучшим выбором для ММО.
Если сущности изолированы, как они будут взаимодействовать между собой?
Сущности не изолированы, скорее даже наоборот, в отличии от ООП у вас вообще нет никакого сокрытия данных. Изолированы и независимы друг от друга системы, а если вам нужно какое-то взаимодействие, то оно осуществляется через изменения компонентов и только так.
Я так и не понял разницу между добавлением поля в сущности и добавлением поля в обычном объекте. Что там, что там одна строчка кода для поля плюс логика обработки.
у сущности нет полей, это просто ID. Вы же, я думаю, видите разницу между созданием объекта с переменной и записью данных в конкретную ячейку таблицы в базе данных.
Чем это отличается от объектов в JavaScript и других динамических языках? Там тоже можно добавлять любые свойства в процессе выполнения программы…
Нарушением принципов локальности данных. С мапой вопрос в том, что она куда проще устроена чем таблицы в стиле RMD.
В конце статьи ссылка на статью, написанную 11 лет назад, что ECS — это будущее. Теперь это будущее уже наступает?
Ну, все сразу не делается ведь. А вообще, можно такой вопрос задать создателям SpatialOS. Что-то мне подсказывает, что они просто умеют в рекламу.))
Мы не стали делать вид, что написание действительно быстрой и удобной ECS нам под силу, так что выбрали очень многообещающий открытый проект, вот ссылочка. Товарища можно поддержать на птреоне, ато там с поддержкой что-то совсем все грустно(
* Если ганкеры и гриферы приходят чаще, чем уходят, то это значит, что в игре последствия и ответственность за действия не так уж ярко выражены.
Если ганкеры и гриферы приходят и уходят, то это значит, что в игре последствия и ответственность за действия н етак уж ярко выражены. Самый первый барьер, это деньги, которые этот грифер\ганкер потратил н аигру, далее, если он решается на нарушение заонов в игре, то это самое время он проводит либо в ограничении своей деятельности и в прятках, либо в тюрьме, а потом в ограничеиях. Да, он нанесет какой-то урон, но потом он либо совсем уйдет из игры, либо изменится, либо будет в том довольно малом проценте людей, коорым такой геймплей почему-то понравится, но даж епротив них имеются определенные меры в предлагаемой мной схеме.
Так или иначе, такие люди даже в кажущейся идеальной системе будут всегда, но, как мне кажется, если их число постоянно оттекает из игры, в отличии от других ММО их масса не будет накапливаться и тем более не будет становиться критической. Мне кажется это и есть та самая точка баланса.
С ХиХ же получается как-то зуб за зуб, а хочется чего-то цивилизованного.
Вообщем, я, похоже, вовремя решил написать заметку))
Конечно, после колонны как-то прям дааа)) Вообщем, надо попробовать, спсибо!)
В случае этого текста, либо юнити просто не умеет корректно составлять ЛС, либо действительно все так, как мы это поняли.
А на месте разрабов, с таким отношением, как бы не было сложно, чтоб таких вот казусов н ебыло я б перешел на тот же Armory 3D. Свободный софт всегда застрахован от таких вот… кхм… глупостей.
NoSQL тут не причем, речь про реляционную модель как таковую, то есть логические связи, а не физические. К слову, 5к человек онлайн означает, что у вас в DB записей гигантское количество, т.к. игру купило раз в 100 больше людей.
Насчет NoSQL я бы не торопился, особенно когда у вас есть многопоточный слон, а вам нужна больше даже не скорость записи а скорость чтения селекта и т.п в условиях очень больших таблиц. у сервера ММО свой запросы.
Если вы сайт пилите, может это и прокатит, но писать как попало ММО, а потом все переделывать это какой-то мазохизм, простите.
Для работы с этой парадигмой нужно просто подругому мыслить, но очень многие люди, которые переходили с OOD на DoD говорят, что проекирование, написание и отладка стала где-то двже в разы проще. Блольшое количесто вещей етсть, за которые теперь вообще не нужно беспохоиться, как например настройка доступа к данным при добавлении многопоточности. Теперь просто разделяешь все данные на кучки и параллельно обрабатываешь: скорость есть, а головной боли нет.)))
Это логично, если учесть, что веся логика представляет из себя отдельные изолированные блоки, которые занимаются исключительно своим делом, добавляй себе и добавляй.
1)Перечисляются конкретные признаки ООП (объекты это еще не ООП)
2)Объясняется, что использование объектов именно такими методами замедляет работу процессора с данными в 400-700 раз (сами инструкции выполняются со скоростью меньше наносекунды, основным узким местом всегда были и остаются данные)
Если вы утверждаете, что код становится сложнее, то вы точно не поняли как это работает. Ну а впихивать или пытаться подружить DoD с OOD, как это делали в презентации разработчики из Unity, как я писал еще в комментариях к прошлой заметке — плохая идея.
А ООП для хайлоад давно умер, если конечно вы не хотите поспорить с эффективностью реляционной модели данных))
Вот, даже юнити
эгхм
Сущности не изолированы, скорее даже наоборот, в отличии от ООП у вас вообще нет никакого сокрытия данных. Изолированы и независимы друг от друга системы, а если вам нужно какое-то взаимодействие, то оно осуществляется через изменения компонентов и только так.
у сущности нет полей, это просто ID. Вы же, я думаю, видите разницу между созданием объекта с переменной и записью данных в конкретную ячейку таблицы в базе данных.
Нарушением принципов локальности данных. С мапой вопрос в том, что она куда проще устроена чем таблицы в стиле RMD.
Ну, все сразу не делается ведь. А вообще, можно такой вопрос задать создателям SpatialOS. Что-то мне подсказывает, что они просто умеют в рекламу.))
Посмотрим на технологии. ^_^