Пользователь
Несмотря на то, что универсального алгоритма проектирования игровой экономики сформулировать не получится: уж слишком разные механики в разных играх, - мы можем попробовать сформулировать один из подходов, которым можно руководствоваться, начиная работу над экономикой вашей игры. Проектирование экономики F2P и премиум игр сильно отличается. В этой статье мы попробуем разобраться в том, как подходить к созданию игр, распространяющихся по модели Free-To-Play.
Эту статью Ника Коленды я перевёл ещё в конце 2016 года. И не просто перевёл, а ещё и сопроводил комментариями от лица бренда, под которым проектирую интерфейсы все эти годы.
Статья до сих пор актуальна и будет полезна как новичкам, только погружающимся в проектирование интерфейсов, так и опытным специалистам в качестве систематизации уже имеющихся знаний.
Свои старые комментарии я немного освежил и оформил в виде цитат.
Оригинал статьи с годами исчез по изначальной ссылке и превратился в нечто более сложное. Поэтому, к сожалению, сослаться на неё я больше не могу.
Попытка налоговой взыскать в совокупности 51% от цены проданной квартиры, налог 88 млн руб. с полученной прибыли меньше 10 млн руб. «благодаря» автообмену с зарубежным банком, а также арест заграничных счетов в ОАЭ – в этой статье мы собрали самые жуткие истории из жизни, с которыми налоговые юристы сталкивались на практике.
Всем привет! Год потихоньку подходит к концу, так что самое время вспомнить, о чём мы писали. Собрали в одном материале самые интересные статьи из нашего блога и удобно сгруппировали их по темам — от геймдизайна до серверной разработки. Отличная возможность вернуться и перечитать полезные материалы или наверстать, если вы вдруг что-то пропустили.
Советы, которые я давал тут и тут для геймдизайнеров, пока, являются самыми популярными моими статьями. Приятно видеть, что мой опыт может быть кому-то полезен и после публикации этих материалов в личку стали приходить просьбы с написанием продолжения… Интересно, что все запросы для новых статей были сосредоточены только вокруг монетизации и так как эта тема является достаточно сложной, то я решил начать с советов, которые могут увеличить прибыль от ваших игр.
…мономифа.
Возможно вы уже слышали о мономифе, но не знали, что это он. Или не думали, что его структуру можно и нужно применять для разработки ваших незабываемых игр. В любом случае сегодня мы разберёмся как с помощью этого нехитрого инструмента упростить создание квеста или сцены и сделать их такими, чтобы игроки ещё долго рассказывали о них. И начнём мы с истории.
Привет, Хабр! Это статья о том как наша небольшая команда реализовывала свой ECS в рамках Unity проекта. Если вас заинтересовало как строилась архитектура, откуда брались те или иные решения, и какой она у нас получилась, или если вам просто интересно, как оно всё выглядит там, под капотом, вы можете посмотреть всё нажав на кнопку "Читать далее".
Привет, Хабр! В этой статье я расскажу всё, что знаю про Entity-Component-System и попытаюсь развеять различные предубеждения об этом подходе. Здесь вы найдете много слов о преимуществах и недостатках ECS, об особенностях этого подхода, о том как с ним подружиться, о потенциальных граблях, о полезных практиках, а также в отдельном разделе коротко посмотрим на ECS фреймворки для Unity/C#.
С ростом проекта в него приходит постоянно приходит новая аудитория: как матерые игроки, так и новички в жанре. Закинуть всех в один матч можно, но первым будет скучно, а вторым — сложно. В итоге всех можно потерять уже на старте.
Боты — не только хороший способ восполнить недостающих игроков в комнате и быстрее начать матч, но и отличная возможность для онбординга новичков. Нам они понадобились, чтобы обучать новичков в тренировочных матчах и давать им нужный пользовательский опыт. Настоящий, живой, который при этом мы могли бы контролировать.
В этой статье расскажу, как мы добавляли ботов в свой шутер, настраивали логику, динамическое изменения скилла и многое другое. Все подробности под катом.
В своей книге «Сид Мейер: Жизнь в мире компьютерных игр» знаменитый разработчик рассказывает о ключевых моментах карьеры, много шутит и через всю книгу дает советы и лайфхаки по разработке игр. А в этой статье основные из них — перевод под катом.
В экосистеме Node.js существует довольно много библиотек и фреймворков, которые пользуются определенной популярностью в сообществе. Но ни один из инструментов не решил главную проблему, с которой сталкиваются разработчики, когда пытаются писать бэкенд на Node.js. Это проблема выбора архитектуры.
Хочу обратить ваше внимание на относительно молодой фреймворк Nest.js. Из коробки он предлагает заранее предопределенную архитектуру, которая заточена под максимально удобную поддержку и масштабируемость вашего приложения. Заложенные архитектурные подходы проверены временем и давно используются в других, более зрелых платформах: Java(Spring), Python(Django), PHP(Laravel) и прочих.
Авторы Nest.js не скрывают, что их вдохновил один из популярных фреймворков для клиентских приложений — Angular.js, а его авторы ориентировались на походы, используемые в Java и C#. Если вы знакомы с Angular.js, то увидите в Nest.js много схожих идей.
Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.
«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.
Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.
Определение Докера в Википедии звучит так:
программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы; позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, а также предоставляет среду по управлению контейнерами.
Ого! Как много информации.
В процессе прохождения игр пользователи стремятся к победе посредством достижения целей и задач, определяемых многими факторами. Навыки, мотивация, ресурсы и мощность аватара здесь играют решающую роль. Сравнение этих элементов — важная задача геймдизайна для достижения честного геймплея.
Стоит заметить, что термин «честность» здесь более уместен, чем «баланс», ведь последний чаще можно истолковать неверно. Честность подразумевается в том смысле, что опыт игроков должен быть выдержанным и правдоподобным. Честный геймплей должен быть приятным и увлекательным, даже если он не совсем четко сбалансирован. Идеальный баланс, в свою очередь, может сделать игру более скучной. По словам ведущего дизайнера Overwatch Джеффа Каплана:
Восприятие баланса гораздо важнее, чем сам баланс.
Во многих играх можно добиться хорошего игрового опыта, не задействуя при этом слишком много элементов, механик и правил. Это не означает, что такие игры обязательно будут простыми — но их можно понять, изучив меньшее число сущностей. В шашках, в примеру, всего четыре правила, но это не делает их простыми.
Иными словами, во многих играх имеется широкий спектр элементов, дающих им больше возможностей и альтернатив. Сами по себе они не делают игры сложными и не подразумевают, что их сложнее освоить. Более того: многие из этих элементов могут даже не приниматься игроком во внимание в ходе игры. Однако достижение ощущения честности игры в данном случае может оказаться более сложной задачей, ведь при большем числе элементов их сложнее настроить для достижения согласованного, приятного и увлекательного опыта.
Во всех описанных случаях могут быть разные стратегии и отправные точки, которые можно использовать для достижения этой самой честности. Одна из них, на которой мы и сфокусируемся в данной статье, — мощность (Power).
Близится 2021 год, а значит, минуло почти 4 года с момента, когда я присоединился к разработке Pathfinder:Kingmaker в качестве разработчика интерфейсов. За это время игра превратилась из маленького прототипа с минимальным функционалом в огромную, сложную систему. Игра пережила релиз, год активного багофикса и поддержки DLC, а также портирование на консоль. И теперь, когда разработку этого проекта можно считать завершенной, пришло время оглянуться и попробовать собрать ретроспективу того, как проектировались и создавались интерфейсы.
Все больше и больше область применения языка программирования javascript отходит от движения кнопочками в браузере да перекраски фона в сторону сложных и объемных веб-приложений. Уже во всю по миру шагает технология WebGL, позволяющая отображать трехмерные сцены в браузере прямо на языке js, а вместе с ней и усложняются задачи.
Производительность пользовательских машин продолжает расти, а вместе с ней и язык обзаводится новыми выразительными средствами, позволяющими ускорять вычисления. И пока WebAssembly где-то там в далеком и светлом будущем, asm.js застрял в болоте и свернул с пути, в ближайшее время изначально как часть es2015, ныне как отдельный стандарт выходит поддержка векторных операций в JS.
Все, кому интересно, что такое SIMD и векторные исчисления, как ими пользоваться в js, а так же что дает их использование — прошу под кат.
Привет! Меня зовут Иван Греков, я работаю UI-разработчиком в frontend-команде Badoo. Главные задачи нашей команды — создание новых и поддержка существующих пользовательских интерфейсов для сайтов и приложений Badoo и Bumble.
Когда в конце 2019 года мы начали параллельно работать над несколькими проектами, мы задумались над повышением стабильности кода и возможностью его многократного использования. Для этого мы решили переписать наши 630 React UI-компонентов на TypeScript. Я расскажу о том, как мы работали над ними без перерыва в доставке фич и как организовали поэтапный переход на TypeScript для UI-разработчиков, которым этот язык был в новинку.