Получение комфортной скорости прокачки и ограничение нагиба за бабло
Выгодными являются 14 и 7 (по макс. опыту), особенно с учётом в какую глубину можно забуриться. «Играешь бесплатно — создаёшь движуху».
Комфортными являются 3:30 и 1:45 пакеты: это время «после работы».
А вот часовой и получасовой пакет это уже для буратины: он превращает игру в сессионку и позволяет играть в неё перед И после работы, получая до 10 или 6 х1 часов опыта каждый день тратя 2 или 1 час соответственно.
Цель: обеспечить работу формулы «деньги или время».
Таком случае она достигается за счёт «выгорания лимита» получения опыта в день.
За счёт подбора наиболее подходящего бустера игрок может ограничиться наиболее выгодным вариантом и сделать некий «план на день».
Что позволит контролировать время проводимое за квестами, планировать расписание и так далее.
Предполагается, что использовать можно будет «на лету», а не месячная абонентка.
Ну так и не берите вы бустер х6, а возьмите х4 и будет вам счастье. К тому же он выгоднее.
Но главная фишка именно в том, что после гонки за экспой наступает момент релакса. Это как если бы в «Мафии» в процессе игры были не только сюжетные миссии, но и «рутинные», где игрок выполняет всю ту же работу («крышевание», мероприятия), где в некоторых местах прикопаны сюжетные сценки, возможно — триггеры, какие-то задания. Это время для приостановки гонки и наслаждения достигнутым уровнем.
Так тогда бери и бустер (более выгодный под тебя) и дейлик не на 15 минут, а на сколько-там-надо-часов.
В общем, завтра сделаешь выбор правильнее, а сегодня — тайм ту релакс: побродить по рынку, например.
Может я что-то где-то упустил, но есть одна мысль:
Если мы принимаем, что:
— Игрок может иметь разный денежно-временной фон (деньги/время)
— Игрок должен иметь немного времени на сон в любом случае
то:
не будет ли решением этой ситуации «плавающие рейты», т.е.:
игрок без бустера набирает опыт 14 часов, но с рейтом 1х.
с бустером на х2 — 7 часов с рейтом 2х
с бустером х3 — 3,5 часа с рейтом 3х.
с бустером х4 — 1:45 с 4х рейтом.
с бустером х5 — 55 минут с 5х рейтом.
с бустером х6 — 27 минут с 6х рейтом.
Таким образом: получаем баланс «время-деньги» (ибо ма~аленький изъянчик схемы: 6х30=3 часа), где можно бесплатно тягать 14 часов или чуть закинув — «всего лишь 7», но при этом игрок ограждается от перенапряжения: при всём желании эффективной игры особенно вкусными являются 2х и 3х бустеры, а для «китов» — 5х и 6х бустеры.
По истечению бустера персонаж требует отдыха (5 часов хотябы), после чего — снова в бой (а у игрока есть время подремать).
Таким образом «буратины» получают возможность сбагрить слишком хрустящие купюры а обычные игроки — докачаться до такого же уровня с чувством проходя игру.
Чип в мозгу был только у одного, у всех остальных — внешняя фазированная решётка с 2 приёмопередатчиками.
ИМХО, уже ожно воспроизвести (только вот насчёт ускорения, имхо, фантазия автора.).
PS: обработка скриптов через .NET framework — зло и даже в Accel World на нём залагивали систему.
Возможно, «группы негативно относятся к новичкам» => «группы = зло».
В общем, этим игрокам за пристов поиграть надо бы. Может тогда что у них и выйдет.
Задам, наверное, очень запоздавший вопрос:
А какой размер общества лично ты считаешь минимально допустимым для ММО? Я имею в виду: при каком количестве игроков «окукливание» общества станет для тебя приемлемым? 10, 50, 100, 1000?
1. Все данные оригинальные хранятся на серверах. Если клиент стал доверенным сервером и получил право эмитировать голду, то у меня серьёзные вопросы к жалующейся администрации.
2. Все данные хранятся на серверах. Потому и А, и Б посылают намерение сделать «скилл, сила, направление», потому проблема не возникает изначально.
А вообще я как-то плохо представляю эти пляски вокруг лагов =)
В целом с динамическими клиенто-серверами боюсь будет слишком уж много технических сложностей. Не представляю картину, как будет происходить обсчет нетипичных ситуаций.
Вот например зашли люди на сервер созданный кем либо, а унего кот наступил на кнопку пилота и комп вырубился. Где в этот момент взять все данные о персонажах и их изменениях?
В целом: верим последнему доверенному-подтверждённому. По идее, если сервер входит в домен/узел/проч, то он по умолчанию обменивается инфой с другими серверами (и игроками, которые так же могут синхронизировать данные).
Опять таки кто-то просто из научного интереса или целенаправленно вредя берет и начинает слать фейковые данные промежуточных обсчетов, которые ему доверили. Как это определить и исправить? Придется один пакет обсчитывать минимум трижды, на разных машинах, после определять истинные и ложный?
Во-первых, вопрос «что ему доверять»? Если ему доверять только перегонять шифрованные пакеты, то от MITM-атаки защищает сам процесс входа: Клиент и Сервер договариваются о ключе шифрования, только после этого пакет передаётся Дежурному, уже запароленный.
В случае вскрытия шифрования — меняем шифрование или делаем пул разных методов, из которых выбираем динамически.
Просто помимо отработки нажатия/не нажатия кнопки у рандомного игрока придется обсчитать все сопутствующие действия, произвести изменения окружения, пересчет всех состояний, а это возможно только при доступе к сопутствующим данным. Следовательно если грубо говоря игрок вбежал в толпу из 20 игроков и пыхнул какую-то АОЕшку, то нам нужно передать не просто данные о его мане, наличии скила, текущем статусе «не метрв», шмоте и тд, но и данные о всем, что в эту АОЕшку попало. Мы собираем из базы и шлем инфу по сети, трижды, там ее принимают и просчитывают, возвращая нам текущие значения, после воздействия АОЕ. Мы получаем три копии (ну или хотя бы первые две), сравниваем их от и до и после этого вносим изменения в рабочие данные.
В данном примере у нас и так 20 игроков, которым передаётся этот же объём данных.
Ну, ИМХО, семеро одного не ждут, а с другой стороны — зачем обсчитывать всё за один такт? Примечание: не оптимизированная логика русского языка, в коде это будет несколько иначе!
<code>1. Soket()>>BQ() Принимаем <em>намерение</em> использовать скилл и атрибуты (сила, смещение, проч.)
2. Проверяем валидность.
2а. BQ()>>BOT() Втыкаем строку действий в ИИ.
2б. ИИ пробегается по строке, разгребая входящие: какие в исполнение, какие - в игнор (не свободен кэш).
2в. BOT()>>MQ() ИИ очищает кэш и отправляет проверенные команды.
3. Проводим действия.
3а. MQ()>>BOT() ИИ отвечающий за поддержку карты принимает данные.
3б. ИИ пробегается по строке, разгребая входящие: какие в исполнение, какие - в игнор (не свободен кэш).
3в. BOT()>>MAP() ИИ сохраняет обработанные данные в архив и направляет данные обратно боту (BOT>>MQ)
4. ИИ принимает данные.
4а. MQ()>>BOT() ИИ принимает данные согласно <strong><em>своих ограничений</em></strong>. Т.е. слепое тело проигнорирует изменения графики, глухое - звук и т.д.
4б. BOT()>>BQ() ИИ подготавливает данные "наверх" и заливает в буфер.
5. BQ()>>Soket() Очередь доходит до службы сокетов и она отправляет данные дальше.
</code>
Если на каком-то этапе обработка превышает разумные пределы — она приостанавливается (данные сохраняются для дальнейшего обсчёта) для следующего такта.
Хм, а может и не 8 тактов получается…
Как-то все очень уж долго получается, как мне думается. Особенно если данные, которые мы пересчитываем лежат на опять таки пользовательском сервере и могут быть исковерканы, либо приходящие пакеты могут ложно помечаться как фейловые и в результате мы получим дополнительные непонятки при игровом процессе, которые найти будет крайне сложно.
Вообще-то, «пользовательский сервер» может быть не признаваем официальным. Как «Wurm Online», «Minecraft», например.
Ещё его можно проверять на попытки инъекций — просто сравнивая контрольные суммы всех или некоторых строк данных. CRC, кстати, можно ещё и шифровать.
Этот ИИ можно подгружать, опять же «на лету», не держа на харде клиента.
Но в любом случае сравнение данных (особенно — с рандомным элементом) — это адъ.
Что же до ресурсоёмкости — ещё на 120Мгц 80486 вполне годно шёл WarCraft2 с лимитом юнитов в 128 штук (или 256, не помню) на карту. Не думаю, что их обсчёт был бесплатен, да и АОЕ там вполне себе присутствовало. На Dendy, кстати, были хорошие игры серии «Nekketsu!» (熱血 — горячая кровь, яп.). Рекомендую посмотреть на ю-тюбе футбол (Goal3), хоккей, а так же моногатари спешл средневековом сеттинге (там вообще был открытый мир с бандами в реальном времени, карта с возможностью быстрого перемещения, АОЕ тачкой/другом/врагом по морде). Мощность Dendy сегодня ниже, чем у чипа в самой дешёвой клавиатуре, наверное.
Нагрузка-то да, но сколько будет идти данных в одном пакете? Если не делать воксельный мир, где передаваться будет сразу тонна данных, то достаточно передать только данные изменения состояния, т.е. байт 20-30 на пакет максимум. Да игровой чат больше отъест!
Можно было бы соединить клиентов напрямую — но это деанон лютый, так делать не надо бы.
Что же касается «бэкапа» — это вопрос только к объёму ОЗУ, а с другой стороны — если ловить быстро, не давать возможности неправомерных воздействий и т.д. — то в целом это уже паранойя, ИМХО. Не то чтобы в ней было что-то плохое (кроме ресурсоёмкости), но это как проверка «IF 1=1 THEN» — да, это иногда срабатывает, но всё-таки не всегда это нужно.
Вроде как ещё на Celeron 300Mhz, 128Мб ОЗУ под Win98SE вполне сносно шёл Stronghold, где лучники стреляли по координатам и могли промахнуться, а иногда шёл выбор в какого из врагов попала стрела — и, в целом, всё было очень даже ничего.
Потому лично мне кажется лучше игрока оповещать пост-фактум, а вот алгоритмы ИИ подготовить к предсказанию действий игрока, чтобы игрок мог полагаться на «рефлексы» своего виртуального тела. Таким образом, иногда будет достаточно выдать игроку свёрочные данные, чтобы его не глючило).
Да, будет фейл с задержкой в 8 тактов на изменение состояния цели, т.е. до 1,6с. в худшем случае (ИМХО, 0.16 максимум), что в любом случае приемлемо: в первом случае для чего-то в духе RagnarokOnline, во втором — уже почти для всего. Если же нагрузка на сервер будет менее .01с/такт, то и вовсе задержка падает до .08, чем уже можно просто пренебречь.
(В случае, если игроки на разных серверах в одном мире — да, там ещё начнётся диалог между серверами, что даст ещё +8 тактов).
Проблема только в том, что писать придётся:
а) монолит (по крайней мере, в процессе выполнения)
б) не объектный код (т.к. создание объектов вызывает циклы выделения-очистки памяти), а то и вовсе — экономить на спичках и писать всё в едином адресном пространстве, чтобы избежать любых приколов компилятора.
А это сейчас — моветон-с.
Хорошо ответить постараюсь завтра, если буду рядом с компьютером.
А многабукафф это хорошо. Это поиск слабых мест в реализации.
Вот например зашли люди на сервер созданный кем либо, а унего кот наступил на кнопку пилота и комп вырубился. Где в этот момент взять все данные о персонажах и их изменениях?
Так это ещё что! А если он погиб на недоверенном сервере? Или если он погиб, но пришёл на другой сервер? Эх, забыл я про пермасмерть упомянуть заранее.
Я не про игру «в целом», а про конкретное место — голдонагиб vs платная уравниловка.
Выгодными являются 14 и 7 (по макс. опыту), особенно с учётом в какую глубину можно забуриться. «Играешь бесплатно — создаёшь движуху».
Комфортными являются 3:30 и 1:45 пакеты: это время «после работы».
А вот часовой и получасовой пакет это уже для буратины: он превращает игру в сессионку и позволяет играть в неё перед И после работы, получая до 10 или 6 х1 часов опыта каждый день тратя 2 или 1 час соответственно.
Таком случае она достигается за счёт «выгорания лимита» получения опыта в день.
За счёт подбора наиболее подходящего бустера игрок может ограничиться наиболее выгодным вариантом и сделать некий «план на день».
Что позволит контролировать время проводимое за квестами, планировать расписание и так далее.
Предполагается, что использовать можно будет «на лету», а не месячная абонентка.
Но главная фишка именно в том, что после гонки за экспой наступает момент релакса. Это как если бы в «Мафии» в процессе игры были не только сюжетные миссии, но и «рутинные», где игрок выполняет всю ту же работу («крышевание», мероприятия), где в некоторых местах прикопаны сюжетные сценки, возможно — триггеры, какие-то задания. Это время для приостановки гонки и наслаждения достигнутым уровнем.
В общем, завтра сделаешь выбор правильнее, а сегодня — тайм ту релакс: побродить по рынку, например.
Если мы принимаем, что:
— Игрок может иметь разный денежно-временной фон (деньги/время)
— Игрок должен иметь немного времени на сон в любом случае
то:
не будет ли решением этой ситуации «плавающие рейты», т.е.:
игрок без бустера набирает опыт 14 часов, но с рейтом 1х.
с бустером на х2 — 7 часов с рейтом 2х
с бустером х3 — 3,5 часа с рейтом 3х.
с бустером х4 — 1:45 с 4х рейтом.
с бустером х5 — 55 минут с 5х рейтом.
с бустером х6 — 27 минут с 6х рейтом.
Таким образом: получаем баланс «время-деньги» (ибо ма~аленький изъянчик схемы: 6х30=3 часа), где можно бесплатно тягать 14 часов или чуть закинув — «всего лишь 7», но при этом игрок ограждается от перенапряжения: при всём желании эффективной игры особенно вкусными являются 2х и 3х бустеры, а для «китов» — 5х и 6х бустеры.
По истечению бустера персонаж требует отдыха (5 часов хотябы), после чего — снова в бой (а у игрока есть время подремать).
Таким образом «буратины» получают возможность сбагрить слишком хрустящие купюры а обычные игроки — докачаться до такого же уровня с чувством проходя игру.
ИМХО, уже ожно воспроизвести (только вот насчёт ускорения, имхо, фантазия автора.).
PS: обработка скриптов через .NET framework — зло и даже в Accel World на нём залагивали систему.
Как насчёт месяцок посаппортить пристом в Lucent Hearts, Ragnarok Online, Tree of Savior? Просто посаппортить, нахаляву.
В общем, этим игрокам за пристов поиграть надо бы. Может тогда что у них и выйдет.
Хотя так давно уже никто не бредит.
А какой размер общества лично ты считаешь минимально допустимым для ММО? Я имею в виду: при каком количестве игроков «окукливание» общества станет для тебя приемлемым? 10, 50, 100, 1000?
2. Все данные хранятся на серверах. Потому и А, и Б посылают намерение сделать «скилл, сила, направление», потому проблема не возникает изначально.
А вообще я как-то плохо представляю эти пляски вокруг лагов =)
Во-первых, вопрос «что ему доверять»? Если ему доверять только перегонять шифрованные пакеты, то от MITM-атаки защищает сам процесс входа: Клиент и Сервер договариваются о ключе шифрования, только после этого пакет передаётся Дежурному, уже запароленный.
В случае вскрытия шифрования — меняем шифрование или делаем пул разных методов, из которых выбираем динамически.
В данном примере у нас и так 20 игроков, которым передаётся этот же объём данных.
Ну, ИМХО, семеро одного не ждут, а с другой стороны — зачем обсчитывать всё за один такт?
Примечание: не оптимизированная логика русского языка, в коде это будет несколько иначе!
Если на каком-то этапе обработка превышает разумные пределы — она приостанавливается (данные сохраняются для дальнейшего обсчёта) для следующего такта.
Хм, а может и не 8 тактов получается…
Вообще-то, «пользовательский сервер» может быть не признаваем официальным. Как «Wurm Online», «Minecraft», например.
Ещё его можно проверять на попытки инъекций — просто сравнивая контрольные суммы всех или некоторых строк данных. CRC, кстати, можно ещё и шифровать.
Этот ИИ можно подгружать, опять же «на лету», не держа на харде клиента.
Но в любом случае сравнение данных (особенно — с рандомным элементом) — это адъ.
Что же до ресурсоёмкости — ещё на 120Мгц 80486 вполне годно шёл WarCraft2 с лимитом юнитов в 128 штук (или 256, не помню) на карту. Не думаю, что их обсчёт был бесплатен, да и АОЕ там вполне себе присутствовало. На Dendy, кстати, были хорошие игры серии «Nekketsu!» (熱血 — горячая кровь, яп.). Рекомендую посмотреть на ю-тюбе футбол (Goal3), хоккей, а так же моногатари спешл средневековом сеттинге (там вообще был открытый мир с бандами в реальном времени, карта с возможностью быстрого перемещения, АОЕ тачкой/другом/врагом по морде). Мощность Dendy сегодня ниже, чем у чипа в самой дешёвой клавиатуре, наверное.
Можно было бы соединить клиентов напрямую — но это деанон лютый, так делать не надо бы.
Что же касается «бэкапа» — это вопрос только к объёму ОЗУ, а с другой стороны — если ловить быстро, не давать возможности неправомерных воздействий и т.д. — то в целом это уже паранойя, ИМХО. Не то чтобы в ней было что-то плохое (кроме ресурсоёмкости), но это как проверка «IF 1=1 THEN» — да, это иногда срабатывает, но всё-таки не всегда это нужно.
Вроде как ещё на Celeron 300Mhz, 128Мб ОЗУ под Win98SE вполне сносно шёл Stronghold, где лучники стреляли по координатам и могли промахнуться, а иногда шёл выбор в какого из врагов попала стрела — и, в целом, всё было очень даже ничего.
Потому лично мне кажется лучше игрока оповещать пост-фактум, а вот алгоритмы ИИ подготовить к предсказанию действий игрока, чтобы игрок мог полагаться на «рефлексы» своего виртуального тела. Таким образом, иногда будет достаточно выдать игроку свёрочные данные, чтобы его не глючило).
Да, будет фейл с задержкой в 8 тактов на изменение состояния цели, т.е. до 1,6с. в худшем случае (ИМХО, 0.16 максимум), что в любом случае приемлемо: в первом случае для чего-то в духе RagnarokOnline, во втором — уже почти для всего. Если же нагрузка на сервер будет менее .01с/такт, то и вовсе задержка падает до .08, чем уже можно просто пренебречь.
(В случае, если игроки на разных серверах в одном мире — да, там ещё начнётся диалог между серверами, что даст ещё +8 тактов).
Проблема только в том, что писать придётся:
а) монолит (по крайней мере, в процессе выполнения)
б) не объектный код (т.к. создание объектов вызывает циклы выделения-очистки памяти), а то и вовсе — экономить на спичках и писать всё в едином адресном пространстве, чтобы избежать любых приколов компилятора.
А это сейчас — моветон-с.
А многабукафф это хорошо. Это поиск слабых мест в реализации.
Так это ещё что! А если он погиб на недоверенном сервере? Или если он погиб, но пришёл на другой сервер? Эх, забыл я про пермасмерть упомянуть заранее.