С тем количеством миллионов, на которое Гугл может «попасть» при нарушении какого-нибудь «европейского законодательства», вполне понятна их дотошность. Им проще запретить что-либо, чем в перспективе иметь с этим проблемы.
Это потому что большинство игр никак не мотивируют саппортов. Даже при раздаче плюшек группе чаще учитывают, кто больше урона нанес. В то время как самый полезный член группы мог за рейд вообще урона не нанести…
Но это уже не столько проблема баланса, сколько гейм-дизайна в принципе.
К сожалению, я плохо себе представляю изменение прямоугольников других персонажей (как союзных, так и враждебных). Как это вообще работает? Ладно, если вы четко знаете, сколько персонажей в игре и какие у них прямоугольники (то есть, какой тип персонажа — это важно знать, так как у разных типов может быть разная восприимчивость/сопротивляемость к различным воздействиям). Но если их произвольное количество? Как сбалансировать персонажа, который (например) уменьшает урон врагов, если их больше пяти, но при этом получает повышенный урон, если враг всего один? Это уже походит на магию какую-то. Явно, без условностей не обойтись. Например: параметры «сопротивляемость к урону вилкой» и «сопротивляемость к урону пылесосом» имеют одинаковую ценность, а значит при равных значениях взаимно балансируют друг друга. Ну или что-то в этом роде (когда-то видел учебный ролик, в которой базовой идеей было выразить все параметры персонажа через какие-то общие единицы и посчитать суммарную «стоимость» — нечто сродни подходу, описываемому в данной статье).
Так или иначе, в конечном итоге всё друг с другом перемножается (подмигивающий смайлик).
Я имел в виду характеристики, которые не сводятся к урону или времени жизни. На ум приходят различные взаимодействия персонажей: бафы, дебафы, хилы и тому подобное. Теперь, когда я думаю об этом, возможны граничные случаи, при которых персонаж вообще не наносит урона, но при этом является "сбалансированной" единицей.
Подход упрощённый, но отнюдь не наивный. Просто здесь рассматриваются лишь две характеристики, в то время как в реальных играх их несколько десятков. Но если каждую из них выразить в численном виде, перемножить между собой (то есть, найти объем многомерного параллелепипеда) и сравнить, то мы как раз и получим, что при равенстве значений (объемов) объекты сбалансированы, а при неравенстве — нет.
Статья интересная. Даже появилось желание применить подобный подход в своей игре (от необходимости балансировать которую мне хочется запереться в шкафу без кофе и печенек и громко выть от тоски). Я даже выписывал вопросы и замечания по ходу прочтения (чего обычно не делаю). Вот такие например:
Это типичные классы персонажей в RPG.
Понятие «длины» палки (силы урона) вводится слишком резко, внимание на нем не сконцентрировано в должной мере, отчего переход от черных фигур к цветным разных размеров становится понятен только после третьего прочтения (да, я тугодум, но все же). Здесь же сразу добавляется и другая характеристика — ширина прямоугольника. Хотя про нее уже говорилось, но мне кажется, визуально отметить границы палок было бы полезно.
Подумайте, что это за персонаж:
Эй, мы тут цветные прямоугольники рассматривали, и не договаривались, что имеем дело с графиками зависимости силы урона от времени. И хотя этот факт логично вытекает из принятых абстракций, незнакомый с математикой человек здесь впадет в ступор и будет долго хлопать глазами (это не «берсерк», извините, — это буква «L», упавшая на спину, когда у нее полноги отрубили). Сами оси на рисунках таки появляются (куда ж без них), но гораздо позже, чем хотелось бы.
Но что, если у нас в руках Потрошитель Гоблинов, который наносит им двойной урон?
В этом моменте я всерьез начал думать, что подход с палками и площадями хорош в начале разработки, а не когда игра уже сделана и ее (внезапно!) нужно балансировать. Тогда есть возможность двигаться от простого к сложному, постепенно наращивая детали и усложняя математическую модель (да, в «статье без математики» поразительно много математики — автор пытается завуалировать ее применение наглядными картинками, но суть от этого не меняется. Это ни в коей мере не является критикой, так как мы работаем с точными системами и сбалансировать игру вообще без математики ну никак не получится). Так вот, в реальной жизни урон не будет постоянной величиной. И еоличество гоблинов на уровне тоже. А значит вам (нам, им, всем) придется иметь дело с вероятностями, распределениями и прочими муторными вещами (за которые я в ВУЗе на экзамене получил тройку и не решился ее пересдавать). В лучшем случае, вы будете умножать ваши длины и ширины (эммм… такого слова нет) на проценты (а это уже математика). В худшем же случае… рядом со мной в шкафу есть еще одно место.
В шутере нам надо знать сколько процентов от карты составляют коридоры, а сколько — тесные комнаты
Ну да, так и есть — к готовой игре подход уже неприменим (либо с нуля переделывать). Как посчитать процент «корридорности» корридора, чтобы понять эффективность дробовика? Как учесть взаимное расположение двух (пусть вначале двух) игроков на карте, если точек спауна N? (тут я хотел формулу вставить — ну эту, из комбинаторики, но вовремя вспомнил, где нахожусь и что за люди зашли почитать эту статью). А если игроков больше двух? А если оружия больше двух? А если уровень трехмерный? А если есть оружие, которое дает AoE? А ежели дождь во время усушки, а?. Сложность модели растет в геометрической прогрессии — успевай только памперсы менять. Вы должны быть готовы к серьезной, кропотливой работе, делать которую трудно, но совершенно необходимо (иначе ваша игра быстро всем надоест).
Теперь среднюю силу силу дробовика снова можно посчитать как сумму площадей прямоугольников:
Автор это знает, но стесняется сказать (чтоб не отпугивать народ): персонажи шутеров не перемещаются по карте рывками, а потому на соответствующем графике (можно я все же буду говорить «график», а?) никаких «ступенек» не будет — а будет плавная «волна», выражаемая некоей функцией. В конце автор честно признается: чтобы высчитать площадь, необходимо взять интеграл этой функции в нужных пределах (добро пожаловать в мир математики).
— Товарищ майор, вот вы в академии учили высшую математику. Она вам когда-то в жизни пригодилась?
— Да. Один раз у меня танк в болоте застрял. Я согнул лом интегралом и вытащил.
Просьба не закидывать кирпичами, я ни в коей мере не критикую статью — наоборот, она мне очень понравилась (добавил в избранное, буду перечитывать). Не тем, что учит балансировать игру без математики, а тем, что позволяет понять математику в простой и наглядной форме, показать начинающим гейм-дизайнерам, что в ней нет ничего страшного и сложного. Автор (который, видно, много знает по теме) не отмахивается от новичков со словами «ну вы, это, наймите тестировщиков, они там все потестируют», а честно пытается на пальцах объяснить довольно-таки непростые вещи. Кто знает, может это побудит кого-то пойти подучиться и заняться вычислениями уже всерьез (а значит, научиться «понимать игру», как об этом поэтично сказано в конце статьи).
Это прекрасно! В молодости тоже баловался подобными играми, но данные приходилось записывать на листок. Потом зачеркивать. Были б в то время Гугл-таблицы, жизнь была куда бы интереснее.
Насколько реален вариант (не для существующих игр, а в принципе, как концепция), при котором пользователи сами вводят данные в таблицу? Например, по количеству пользователей создаются столбцы (или строки) для ввода данных и защищаются от ввода для всех, кроме нужного пользователя (при помощи «Защищенные листы и диапазоны»). Точно так же можно защищать отдельные листы (например, пока не закончен первый год, данные второго не видны никому, кроме ведущего-администратора). В итоге, игроки сами видят, как введенные ими (и их соперниками) данные влияют на общее состояние системы.
Настраивать все это будет, конечно, проблематично (особенно при большом количестве человек) — но можно макросы написать. А еще подумать, как ограничить количество операций ввода данных (чтобы у пользователей не возникало желания подправить ввод, если они видят, что результаты их не устраивают).
И это прекрасно, вы не находите? Особенно фраза «все свои проекты», которая доказывает, что на момент перехода эти проекты у вас были.
Категоричного отношения ни в статье, ни в комментариях высказано не было (не пойму, почему сложилось такое мнение). К сожалению, люди, которые пишут про движки, не уточняют, какую конкретно часть функциональности с их помощью удалось реализовать. Уверен, ни один продвинутый движок не способен придумать за вас интересную игру. Вместе с тем готовую интересную игру несложно перенести на продвинутый движок.
Потому в статье и не делается упор на работу с движками.
Ну дык, если вы читали readme.txt, я об этом предупреждал. В качестве временного решения переключитесь на вкладку «Advanced» и нажмите кнопку «Generate script». Сохраните полученный sh-файл где-нибудь и запускайте из терминала — должно работать.
К сожалению, у меня нет мака, чтобы опробовать на нем разные решения. Открыть из командной строки терминал и передать в него команду на выполнение почему-то получилось только через osascript:
osascript -e "tell application \"Terminal\" to do script \"<COMMAND>\""
Но из кода java-приложения запустить эту команду не выходит (видимо, из-за двойных кавычек и необходимости их экранировать).
Если кто-то может оказать помощь в этом вопросе, буду несказанно благодарен.
Я отнюдь не против использования готовых движков. Наоборот, они дают огромное преимущество в скорости и качестве по сравнению с собственными велосипедами (особенно если разработчик имеет хорошие навыки работы с ними). Но сам по себе движок — не панацея. Да, он поможет настроить игровой цикл, обеспечит графический вывод, ввод, взаимодействие различных объектов, физику там… Ну и всё. Основную логику работы все равно придется писать самому (и это хорошо, иначе все игры были бы похожи одна на другую).
Вот вам простой пример. Скачал как-то на мобилку интересную игру (обойдемся без конкретных названий). Весит 64Мб. Работает с тормозами и батарейку кушает как голодный африканский крокодил. А игры-то: пара статичных двухмерных спрайтиков по экрану перемещается без особых эффектов и анимации — казалось бы, чему тут тормозить?
А все потому что разработчик решил свою игру на Unity написать — ну и потянулась вся эта махина в его проект. Я с Unity крепко не работал, не знаю, может так и надо. Может, разработчик не позаботился об оптимизации и чего-то важного не сделал (читай: плохо знает инструмент), но в одном уверен: реализуй он такую же функциональность на обычном canvas'е (стандартными средствами), игра бы весила 300кб и летала быстрее, чем армейский вертолет (такой опыт у меня был, я знаю о чем говорю).
Это я все к чему? Не нужно, как мне кажется, забивать гвозди микроскопом. Если пишете клон сапера, Unreal Engine вам, скорее всего, не нужен. А даже если и нужен, то будьте людьми, не забывайте об оптимизации.
(Ну или читайте отзывы игроков на странице магазина и как-то реагируйте.)
«Просто» не надо — их и так уже полно. Создайте игру, от которой вам лично будет тепло на душе. Даже если она будет неудачной, никому не понравится и прибылей не принесет.
Знаете, с 2003 года прошло много времени, теперь мне некоторые мысли гораздо проще выражать на английском языке (хотя и русский перевод в игре частично присутствует).
Игра не готова, она в процессе (замечания и предложения весьма приветствуются). Полезные ссылки есть в конце статьи в одноименном разделе (такая большая надпись ССЫЛКА!).
Но это уже не столько проблема баланса, сколько гейм-дизайна в принципе.
Так или иначе, в конечном итоге всё друг с другом перемножается (подмигивающий смайлик).
Я имел в виду характеристики, которые не сводятся к урону или времени жизни. На ум приходят различные взаимодействия персонажей: бафы, дебафы, хилы и тому подобное. Теперь, когда я думаю об этом, возможны граничные случаи, при которых персонаж вообще не наносит урона, но при этом является "сбалансированной" единицей.
Подход упрощённый, но отнюдь не наивный. Просто здесь рассматриваются лишь две характеристики, в то время как в реальных играх их несколько десятков. Но если каждую из них выразить в численном виде, перемножить между собой (то есть, найти объем многомерного параллелепипеда) и сравнить, то мы как раз и получим, что при равенстве значений (объемов) объекты сбалансированы, а при неравенстве — нет.
Просьба не закидывать кирпичами, я ни в коей мере не критикую статью — наоборот, она мне очень понравилась (добавил в избранное, буду перечитывать). Не тем, что учит балансировать игру без математики, а тем, что позволяет понять математику в простой и наглядной форме, показать начинающим гейм-дизайнерам, что в ней нет ничего страшного и сложного. Автор (который, видно, много знает по теме) не отмахивается от новичков со словами «ну вы, это, наймите тестировщиков, они там все потестируют», а честно пытается на пальцах объяснить довольно-таки непростые вещи. Кто знает, может это побудит кого-то пойти подучиться и заняться вычислениями уже всерьез (а значит, научиться «понимать игру», как об этом поэтично сказано в конце статьи).
С нетерпением жду продолжения.
Насколько реален вариант (не для существующих игр, а в принципе, как концепция), при котором пользователи сами вводят данные в таблицу? Например, по количеству пользователей создаются столбцы (или строки) для ввода данных и защищаются от ввода для всех, кроме нужного пользователя (при помощи «Защищенные листы и диапазоны»). Точно так же можно защищать отдельные листы (например, пока не закончен первый год, данные второго не видны никому, кроме ведущего-администратора). В итоге, игроки сами видят, как введенные ими (и их соперниками) данные влияют на общее состояние системы.
Настраивать все это будет, конечно, проблематично (особенно при большом количестве человек) — но можно макросы написать. А еще подумать, как ограничить количество операций ввода данных (чтобы у пользователей не возникало желания подправить ввод, если они видят, что результаты их не устраивают).
— Статья не про игровые движки!
Может хватит уже этих комментариев?
Если вы сохранили скрипт, например, себе на рабочий стол (с именем
dice.sh), то в терминале нужно написать следующее:Категоричного отношения ни в статье, ни в комментариях высказано не было (не пойму, почему сложилось такое мнение). К сожалению, люди, которые пишут про движки, не уточняют, какую конкретно часть функциональности с их помощью удалось реализовать. Уверен, ни один продвинутый движок не способен придумать за вас интересную игру. Вместе с тем готовую интересную игру несложно перенести на продвинутый движок.
Потому в статье и не делается упор на работу с движками.
Какую конкретно? Вот эту?:
/bin/bash dice.shНе должно. Приложение должно запускаться в текущей сессии терминала.
Пожалуйста, пришлите скрипт.
readme.txt, я об этом предупреждал. В качестве временного решения переключитесь на вкладку «Advanced» и нажмите кнопку «Generate script». Сохраните полученный sh-файл где-нибудь и запускайте из терминала — должно работать.К сожалению, у меня нет мака, чтобы опробовать на нем разные решения. Открыть из командной строки терминал и передать в него команду на выполнение почему-то получилось только через
osascript:Но из кода java-приложения запустить эту команду не выходит (видимо, из-за двойных кавычек и необходимости их экранировать).
Если кто-то может оказать помощь в этом вопросе, буду несказанно благодарен.
Поясню свою позицию.
Я отнюдь не против использования готовых движков. Наоборот, они дают огромное преимущество в скорости и качестве по сравнению с собственными велосипедами (особенно если разработчик имеет хорошие навыки работы с ними). Но сам по себе движок — не панацея. Да, он поможет настроить игровой цикл, обеспечит графический вывод, ввод, взаимодействие различных объектов, физику там… Ну и всё. Основную логику работы все равно придется писать самому (и это хорошо, иначе все игры были бы похожи одна на другую).
Вот вам простой пример. Скачал как-то на мобилку интересную игру (обойдемся без конкретных названий). Весит 64Мб. Работает с тормозами и батарейку кушает как голодный африканский крокодил. А игры-то: пара статичных двухмерных спрайтиков по экрану перемещается без особых эффектов и анимации — казалось бы, чему тут тормозить?
А все потому что разработчик решил свою игру на Unity написать — ну и потянулась вся эта махина в его проект. Я с Unity крепко не работал, не знаю, может так и надо. Может, разработчик не позаботился об оптимизации и чего-то важного не сделал (читай: плохо знает инструмент), но в одном уверен: реализуй он такую же функциональность на обычном canvas'е (стандартными средствами), игра бы весила 300кб и летала быстрее, чем армейский вертолет (такой опыт у меня был, я знаю о чем говорю).
Это я все к чему? Не нужно, как мне кажется, забивать гвозди микроскопом. Если пишете клон сапера, Unreal Engine вам, скорее всего, не нужен. А даже если и нужен, то будьте людьми, не забывайте об оптимизации.
(Ну или читайте отзывы игроков на странице магазина и как-то реагируйте.)
Затог будет что вспомнить в старости у камина.
Если честно, не понял, в чем разница. Сравните с полноценным «джавовским» аналогом:
и решите, что понятнее лично вам. Так и пишите.
Благо, синтаксис достаточно гибкий, чтобы разные варианты допускать.
Игра не готова, она в процессе (замечания и предложения весьма приветствуются). Полезные ссылки есть в конце статьи в одноименном разделе (такая большая надпись ССЫЛКА!).