Разработка игр *

У фотореалистичных моделей есть множество применений: персонажи в играх, цифровые инфлюенсеры, цифровые помощники, CGI-персонажи и так далее. В перспективе любой человек сможет использовать своего цифрового двойника для взаимодействия с метавселенными. 

Художник по созданию цифровых двойников Марлон Нунез на конференции TBD Pro Art выступил с докладом о моделировании реалистичных персонажей. Он описал свой рабочий пайплайн, а также дал несколько советов, как сделать модели героев более правдоподобными. Кроме того, специалисты из студий MY.GAMES поделились опытом того, какие ограничения есть у современных конструкторов персонажей. 

Привет, Хабр!

Прошло лет 20 с выхода “первой русской ММОРПГ” Сферы, большинство ресурсов мертвы, база данных по игре доступна только частями в вебархиве, форумы закрыты, онлайн полтора человека. Самое время разбираться, как она устроена, правда?

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

Большинство игровых движков заточены под real-time игры. В них есть все: система физики, удобные инструменты для анимации, инновационные технологии рендера и еще куча всего. В каждом из них есть свои плюсы и минусы, однако, сколько я не гуглил, мне не удалось найти нормальный поддерживаемый движок, заточенный именно под пошаговый геймплей. Есть много различных дополнений, модулей и т.п., но прям чтобы отдельно - увы.

Поэтому я крепко задумался на тем, как бы я сделал подобное. Далее будет рассказ о том, до чего мне удалось дойти. От простых принципов до сложных моделей поведения и анимаций. Осторожно, многа букав.

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

Источник иллюстрации: Пикабу https://pikabu.ru/story/tekstovyie_kvestyi_i_knigiigryi_6206710

20 мая 1998 года Умберто Эко (1932 - 2016) выступил в МГУ со знаменитой лекцией «От Гутенберга к Интернету: текст и гипертекст». Недавно я перечитал ее, размышляя о том, сколько лет не был в библиотеке (и не представляю, что бы меня сейчас туда могло привести), что такое клиповое мышление. Наконец, представляет ли мой сын, что такое «Web 1.0» — то есть, статические сайты, где ничего нельзя написать самому, где нет ни контролов, ни GUI, ни какого-нибудь завалящего мэшапа.

Вот какие аспекты информационной эпохи, наступавшей в 1990-е и обрисованные Эко в той лекции, кажутся мне наиболее интересными:

1)      Интернет (компьютер) важнее телевидения, поскольку позволяет самому выбирать, что и в каком порядке читать – и, следовательно, поощряет мышление, поиск и избирательность.

2)      Клод Фролло из «Собора Парижской Богоматери» в конце XV века, через 20 лет после появления типографий, сетовал, что «книга убьет здание» — и оказался неправ. Умберто Эко в 1998 году, через 9 лет после появления первого веб-сайта, утверждал, что «интернет не убьет книги». Летом 2022 года я уже сомневаюсь, прав ли был Эко в этом тезисе.

3)      Эко подчеркивает важность поиска, который мы сейчас назвали бы «полнотекстовым» - и объясняет, почему для такого поиска необходим компьютер, тогда считавшийся еще вычислительной машиной, а не контент-каналом.

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

Из новостей: Google позволил разработчикам приложений использовать в Европе свои платёжные системы, Unity планирует наконец-то в ближайшее время пререлиз Entities 1.0, Epic Games присоединились к O3DE Development Foundation, Houdini 19.5.

Из интересностей: бесплатный генератор 3D-зданий в Blender, как сделать игру дружелюбной для спидранеров, знакомство с трассировкой лучей в DirectX, вебинар про архитектуру Unreal Engine 5.

Я немного упростил изначальную концепцию, хотя весь код всё еще доступен и работает.

Сама концепция: вы делаете игру, создаёте озвучку своими силами только на своём языке, а дальше отдельные переводы и озвучки вам делают сторонние люди, за деньги или без - договоритесь сами, пока что платить некуда :) .

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

Если во времена Half-Life 2 в моде были фототекстуры, то сегодня материалы поверхностей в 3D-графике реального времени воссоздаются с нуля. Для этого используются шейдеры, написанные программным кодом. Но не все художники владеют программированием! Специально для них в UNIGINE 2 есть визуальный редактор материалов, в котором большинство операций прозводится простым соединением узлов (нод) в граф. Так можно быстро прототипировать и создавать сложные материалы, которые не только имеют правдоподобный рельеф, но еще и взаимодействуют со светом как в жизни.

В этой статье расскажем про то, как устроены материалы в UNIGINE 2, а также как работает наш визуальный редактор материалов.

В прошлый раз мы отделили логику от инфраструктуры и разбили последнюю на четыре слоя: Server → Parser → Application → Repository. Классы инфраструктуры составляют основной фреймворк, который берет на себя всю рутинную работу, а нам предоставляет писать одну только логику.

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

Если сильно обобщить, то контроллеры занимаются преобразованием одних команд в другие с сопутствующим изменением состояния приложения (Repository). В зависимости от команды и текущего состояния пользователя Application выбирает соответствующий контроллер и передает ему ссылку на Repository. Контроллер обрабатывает команду, изменяет состояние хранилища и возвращает другие команды, которые должны быть отправлены инфраструктурой по назначению. В общей схеме контроллеры занимают промежуточное место между движком и хранилищем:

... → Application → Controller → Repository.

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

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

При такой организации кода отдельные игры — это лишь соответствующая настройка и использование классов из жанровой библиотеки. Идеальный проект тогда будет состоять вообще из одного main-скрипта в пару строк и yml-файла конфигурации.

О том, как писать классы такого уровня обобщения, чтобы исходный код проектов состоял всего из нескольких строк, как раз и пойдет речь в данной статье:

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

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

В качестве языка программирования выберем Python за его простоту и элегантность. Мы начнем в сокетов (asyncio), а закончим HTTP-сервером. Наша задача состоит в том, чтобы код логики не зависел от типа сервера и задействованных сетевых протоколов.

Не буду долго рассусоливать о том, что такое сборщик мусора и для чего он нужен (на эту тему уже есть достаточно статей). Но хочу отметить несколько важных деталей.

Недавно мы выпустили в Google Play и App Store бесплатную гиперказуальную мобильную игру — iDITORS. Внутри поста: мой личный опыт, бюджет, несколько советов и история разработки. Но должен предупредить вас — этот пост не об успехе и деньгах, а о дружбе и осуществлении мечты.

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

Как и в первой части нашего рассказа, мы поговорили с несколькими сотрудниками из наших студий о том, как они попали в геймдев: кто-то работал в банке, кто-то в МВД, а кто-то уже в детстве создавал 4Х-стратегии, но к разработке игр пришел через службу поддержки. Подробнее об этом — читайте ниже.

Где-то году в 2014 меня внезапно накрыла идея поиграть в старые игры для ZX Spectrum, в которые мы с друзьями шпилили в школе после (и вместо) уроков, менялись кассетами, переписывали их и создавали свои сборники. А также посмотреть и поиграть во все остальные игры, на которые не хватило времени или они вообще не заезжали на нашу «тучу» и даже в Россию. Но эта статья не про мемуары, а про то, что есть сейчас и что будет в будущем.

Я потерял много времени, пытаясь найти решение — как осуществить обмен данными между vue.js и Phaser. Этот вопрос заинтересовал меня, т.к. все что не касается игровой механики, намного удобнее и быстрее делать вне игрового движка, например: авторизация и вывод игровой статистики.

Поскольку у меня есть некоторый опыт работы с Vue.js, то я решил использовать его для этих целей.

Поскольку Phaser работает как отдельное приложение, то вы не можете передавать или извлекать информацию из него, для этого вам потребуется немного пофантазировать.

Я не мог найти, как передать какую-то переменную в Phaser через процесс инициализации игры или как достучаться из него во Vue. Казалось бы, у обоих инструментов есть большие комьюнити, но я нашел лишь много подобных вопросов на форумах или под видео на YouTube — и все они либо без ответа, либо содержат не рабочие или не полноценные ответы. Я решил написать эту короткую статью, потому что надеюсь помочь другим энтузиастам, которые находятся в самом начале пути.

Несколько месяцев назад мне захотелось сдуть пыль со своего аккаунта в Steam и поиграть в старые игры про программирование.

While True Learn в очередной раз показалась слишком скучной, я пару дней позалипал в TIS-100, реализуя свой многопоточный процессор, но в конечном итоге осознал, что интереснее не играть в игры про программирование, а самому писать такие игры.

В статье рассказываю, что из этого получилось и на чём я сломался. Под катом —гремучая смесь из ссылок, картинок, теории распределённых систем и способов визуализации Python в 2022 году.

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

Здравствуйте, в этой статье я постараюсь разобрать некоторые моменты в шахматных правил которые вызывают вопросы. Разъясню, почему возникают вопросы и предложу пути решения некоторых проблем.

Статья написана не с целью выставить существующие правила в негативном свете, а с целью обратить внимание на недоработки и существующие проблемы и логические конфликты в правилах.

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

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