О том как устроен прототип arpg Spheramyd и практиках использования игрового движка.

В предыдущей статье я разбирал проблемы Bonfire и причины, по которым он не очень подходит для сложных игр. Несмотря на то, что чистый Flame намного легче, там тоже не всё так гладко. В этой статье я поделюсь своими рецептами увеличения производительности игры и распишу причины, почему это работает. Хочу сразу заметить, что среди этих рецептов нет серебряных пуль, и маловероятно получить существенный буст, применив только что-то одно. Однако в комплексе они достаточно эффективно работают – проверено часами медитации над CPU-профайлером.

Прежде мы рассмотрели отделение логики отображения от графики, а также разные вспомогательные классы и менеджеры. Все вместе они образуют каркас наших приложений и были вынесены в отдельную библиотеку — Core Framework. Осталось еще разработать методику по написанию остальной логики. В нее входит бизнес-логики и правила игры, данные и их обработка, а также взаимодействие с сервером.

Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).

Недавно я решил создать свой сайт, и мне понадобилось выбрать парсер Markdown для отрисовки статей в блоге.

То, что начиналось как: «Окей, гугл, какой парсер выбрать?», – вылилось в полноценное исследование существующих реализаций парсеров.

О том, какие открытия меня ждали на этом пути, и будет данная статья.

В прошлой статье в частности я критиковал, что при создании игр неумело используют технологию MVC. Нет я не заядлый критик чего бы то не было, просто я не люблю когда подход или технологию применяют тогда, когда она не нужна. В этой статье, я расскажу один пример, когда эта технология просто необходима. Но внимание - для её реализации вам не нужен никакой фреймфорк, если вы еще не верите в свои силы - я научу вас создавать элегантные решения с минимумом трудозатрат, и тогда когда это нужно :)

По ссылке "Когда нужно MVC, как сделать Binding визуальных контроллов с методом (UNITY, C#, Разработка игр)" вы можете послушать меня, а кто хочет почитать прошу подкат.

Если вы давно хотели научиться делать игры, но не знали с чего начать, то рекомендуем попробовать Bitsy.

Это редактор полного цикла для создания простых игр и маленьких миров на основе html. Это значит, что ваша игра максимально доступна и не требовательна, ее легко можно опубликовать на Itch.io или любой другой бесплатной платформе и делиться с широким кругом игроков. По словам создателя движка, Адама Леду, цель Битси – “предоставить простой способ делать игры, в которых можно ходить, общаться с людьми и просто пребывать”. За пять лет существования движка вокруг него выросло живое и дружное сообщество. Было создано более 4000 игр. С помощью них люди рассказывали личные истории, создавали сложные фантастические миры, высказывались об актуальных событиях и делали многое другое. Вот далеко не исчерпывающий список наиболее интересных и необычных из этих игр. Подробней узнать об истории создания Битси можно здесь.

Битси очень дружелюбен для новичков. Этот движок разрабатывается для людей, не умеющих программировать или использовать сложный софт. Ваш персонаж может ходить, общаться с другими персонажами, поднимать условный ключ и открывать им  условную дверь – вот, пожалуй, и всё. Как видите, всё простенько, но в данном случае простота – это сила. Сила Битси – в его ограничениях: каждый пиксель, слово, цвет имеют большой вес. Нет ничего лишнего. С его помощью вы можете создать короткие сюжетные игры или маленькие приключения. Рассказать свою историю или поделиться важной идеей в интерактивной форме – избежав долгой и трудоемкой разработки. При этом многие умельцы делают с Битси невероятные вещи. В общем, главное ограничение разработчика игр – его фантазия.

Система навигации NavMesh позволяет объяснить игровым персонажам, как добраться до определённой точки уровня, избегая всевозможные препятствия и используя созданные игроком механики. Для работы с ней Unity предлагает следующие четыре компонента в работе которых мы попытаемся разобраться.

Statoscope — это инструмент для анализа webpack-бандлов, а я его автор и мейнтейнер. Он зародился в далеком 2016 году как эксперимент, а теперь это полноценный тулкит для просмотра, анализа и валидации сборки.

В ноябре на конференции HolyJS я выступил с докладом о Statoscope и провёл воркшоп по его использованию. Зрителям понравилось, так что мы с организаторами HolyJS решили, что доклад может пригодиться и читателям Хабра — поэтому сделали текстовую версию. Видеозапись тоже прилагаем.

Содержание

• Новая парадигма объектно-реляционного отображения
• Готовность к эксплуатации в критически важных приложениях
• Prisma может быть использовано в любом стеке
• Открытый исходный код и не только
• Как мы можем вам помочь?
• Начало работы с Prisma
• Приходите ради ORM, оставайтесь ради сообщества 💚

Новая парадигма для объектно-реляционного отображения

• Prisma Client: Автогенерируемый и типобезопасный клиент базы данных
• Prisma Migrate: Декларативное моделирование данных и миграции с возможностью пользовательского редактирования
• Prisma Studio: Современный пользовательский интерфейс для просмотра и редактирования данных

продолжение TypeScript Native (AOT) Compiler

Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?

Я хочу рассказать об архитектуре приложений на Electron: из чего они состоят как работают, какие имеют ограничения и требования.

Некоторое время назад мне пришла в голову интересная идея — превратить свои старые телефоны (их скопилось немало за десять лет) в серверы, в качестве альтернативы покупке Raspberry Pi.

На то было несколько причин: во-первых, у телефонов есть батарея, что для сервера практически бесплатный мини-UPS, во-вторых, внутренняя память смартфона (UFS) работает быстрее и надёжнее, чем SD-карта. В-третьих, у телефонов имеется экран, по которому можно отслеживать состояние сервера.

Ну и в-четвёртых, мне просто было жаль их выбрасывать. Консьюмеризм в наше время предписывает каждый год-два покупать новые смартфоны, производители блокируют возможности железа, которые им невыгодны, прекращают поддержку старых моделей, оставляя людей беспомощными. Миллионы смартфонов отправляются на свалку истории каждый год, хотя каждый из них это мощный компьютер.

TL;DR: в этом посте будут разобраны вопросы установки PostmarketOS на смартфон,
поднятия на нём в качестве примера Docker и веб-приложения в нём.

Рано или поздно, фронтенд - разработчик устает играть со своими фреймворками, устает докучать коллегам - бэкендерам, устает играть в девопс и начинает смотреть в сторону машинного обучения, дата - саенс и вот это вот все. Благо, каждый второй курс для тех кто хочет войти вайти способствует этому, крича на всех платформах, как это легко. Я тоже, насытившись перекладыванием данных из базы в API, а потом из API в таблицы и формы, решил взять небольшой отпуск и попробовать применить свои скилы фронтендера в машинном обучении. Благо, существуют такие люди как Daniel Shiffman и Charlie Gerard, которые своим примером помогают не бросить начатое, увидев первые страницы с математическими формулами.

В процессе прохождения игр пользователи стремятся к победе посредством достижения целей и задач, определяемых многими факторами. Навыки, мотивация, ресурсы и мощность аватара здесь играют решающую роль. Сравнение этих элементов — важная задача геймдизайна для достижения честного геймплея.

Стоит заметить, что термин «честность» здесь более уместен, чем «баланс», ведь последний чаще можно истолковать неверно. Честность подразумевается в том смысле, что опыт игроков должен быть выдержанным и правдоподобным. Честный геймплей должен быть приятным и увлекательным, даже если он не совсем четко сбалансирован. Идеальный баланс, в свою очередь, может сделать игру более скучной. По словам ведущего дизайнера Overwatch Джеффа Каплана:

Восприятие баланса гораздо важнее, чем сам баланс.

Во многих играх можно добиться хорошего игрового опыта, не задействуя при этом слишком много элементов, механик и правил. Это не означает, что такие игры обязательно будут простыми — но их можно понять, изучив меньшее число сущностей. В шашках, в примеру, всего четыре правила, но это не делает их простыми.

Иными словами, во многих играх имеется широкий спектр элементов, дающих им больше возможностей и альтернатив. Сами по себе они не делают игры сложными и не подразумевают, что их сложнее освоить. Более того: многие из этих элементов могут даже не приниматься игроком во внимание в ходе игры. Однако достижение ощущения честности игры в данном случае может оказаться более сложной задачей, ведь при большем числе элементов их сложнее настроить для достижения согласованного, приятного и увлекательного опыта.

Во всех описанных случаях могут быть разные стратегии и отправные точки, которые можно использовать для достижения этой самой честности. Одна из них, на которой мы и сфокусируемся в данной статье, — мощность (Power).

В этом туториале мы освоим паттерн проектирования “Команда” (Command) и реализуем его в Unity в рамках системы перемещения игрового объекта.

Запросы, приказы и команды: все мы знакомы с ними в реальной жизни; один человек отправляет запрос (или приказ, или команду) другому человеку выполнить (или не выполнять) некоторые задачи, которые ему поручены. В проектировании и разработке программного обеспечения это работает аналогичным образом: запрос одного компонента передается другому для выполнения определенных задач в рамках паттерна Команда.

Уже долгое время Unity3D — мой любимый инструмент разработки игр, которым я пользуюсь уже более 8 лет — и для профессиональных продуктов, и для личных проектов, и при обучении программированию и гейм-дизайну. Более того, я писал на Unity почти на всех гейм-джемах, в которых участвовал, благодаря чему получалось создавать основу игры всего за несколько часов.

Как вы, наверное, знаете, гейм-джем — это конкурс разработчиков игр, участники которого делают игру с нуля за короткий период времени. Гейм-джем обычно идет от 24 до 72 часов, но бывают и более длительные — например, GitHub Game Off, который длится весь ноябрь.

После участия в различных гейм-джемах, в том числе и с самодельным движком моей группы на C++ (к сожалению, он только на португальском языке), я составил список правил быстрого прототипирования, которые вскоре превратились в мой основной принцип разработки ПО: меньше кода — быстрее работа.

Основная идея — писать меньше кода (или, иначе говоря, держать меньшую кодовую базу) — решает две задачи:

Защита от ошибок: чем меньше размер кода, тем меньше вероятность сделать ошибку.

Экономия времени: при каждом изменении кода нужны обновления и тесты, что требует времени.

А для Unity есть и третья причина: каждое изменение в коде запускает обновление Unity, на что регулярно тратится некоторое количество времени.

В этой статье я расскажу о нескольких приемах, позволяющих легко реализовать этот принцип в Unity3D и таким образом ускорить прототипирование и создание игр в целом.