Привет, Хабр!
После долгого перерыва — снова Сфера. Прошлые статьи (раз, два) были про то, как войти в игру и в ней остаться на всю жизнь. Гулять по миру, конечно, интересно, но быстро надоедает: делать в нем нечего, монстров и NPC нет, даже в озере утонуть не выйдет. Начнем нашу дорогу в темное средневековье там же, где начинается сама игра — в стартовом данже.
Проблема: чтобы собрать UE из сурсов, достаточно 2х команд; чтобы собрать UE докер-образ, достаточно 1 команды. А чтобы собрать godot из сурсов с поддержкой c# на линукс и с возможностью экспортировать проект в web, надо прочитать 5+ статей и потратить кучу времени на понимание оных. Чтобы вы могли не тратить своё время, я собрал всю необходимую информацию в одной статье. Здесь приведены краткие инструкции по сборке godot движка из сурсов на debain 11 (64bit).
Не являюсь гуру Godot, не претендую на абсолютные знания и не имею докторскую степень по чему-либо. Всячески приветствую советы по улучшению кода и прочим идеям. Следовать урокам исключительно на свой страх и риск.
Урок Серия уроков будет посвящена созданию простой RPG в 1bit пиксель-арт стиле, где я постараюсь рассмотреть всю ту боль и страдания, с которыми обычно встречаются новички - джиттер, расплывающиеся пиксели, борьба с разрешением и прочее.
Больше функционала для минималистичного прототипа игры: объекты уровня, враги, апгрейд управления, глобальный скрипт и статичные выстрелы.
По довольно немногочисленным просьбам выкладываю исходник очень простенькой игровой 3D заготовки на движке Godot, вместе с пошаговым описанием того, как собрать подобный прототип самостоятельно. Вероятно, это первая часть и последует продолжение.
Привет, Хабр!
Продолжаем собирать эмулятор Сферы на коленке. В прошлой части мы справились с логином и выбором персонажа, на очереди: вход в игру, загрузка инвентаря, пинг. Научимся оставаться в игровом мире дольше чем на 10 секунд после запуска и попробуем не сойти с ума в процессе – пришло время разбираться, как Сфера передает координаты.
После этой статьи на нашем эмуляторе можно будет гулять по миру и загружать персонажа в любой его точке, даже на других материках и в общих подземельях.
Представьте, что вы пишете свою десктопную мультиплеерную игру мечты, а потом вам захотелось, чтобы ваш проект также работал и в вебе. К сожалению, в интернете можно найти кучу гайдов по созданию только десктопного мультиплеера на Godot, но не браузерного мультиплеера, даже официальная документация самого движка никак не поможет и не предоставит простых примеров. У вас быстро опустятся руки и вы забьёте на эту затею, потому что ваш проект так и не заработает в браузере.
К счастью, эта проблема легко решается!
Вам может сказочно повезти, если поисковик выдаст этот пост на Reddit. Мне вот повезло, поэтому спешу рассказать и другим. Моя статья будет не столько переводом этого поста (и материалов, на которые она ссылается) на русский язык, сколько пересказом от моего лица с имеющимся опытом разработки + дополнительно поведаю о некоторых вещах, что не были упомянуты в посте.
Написал некоторый разбор того, как внутренне устроена конкретная игра для джема на движке Godot.
Доброго времени суток.
В сегодняшней статье речь пойдёт о разработке проекта для 72-х часового конкурса игр.
Всем привет, последние года три мое основное хобби – создание игр. Не могу сказать, что я добилась чего-то сверхъестественного, но в Steam есть две мои игры (горжусь самим фактом доведенных до конца проектов, но сейчас многое в них уже поменяла бы). И обе эти игры сделаны на движке Unity.
Почему на нем?
Когда не знаешь ничего о создании игр и только начинаешь погружаться в тему, именно он всплывает первым как очевидный вариант для ознакомления. О нем много информации, куча курсов, уроков, в том числе и на русском, даже книги выпускают и переводят. Он бесплатный, в конце концов, а в сети можно найти множество примеров успешных проектов, сделанных на Unity. В общем выбор казался очевидным. И в целом меня все устраивало, хоть и были недостатки. Однако свою третью игру я начала делать на движке Godot. Здесь я расскажу причины, а также поделюсь своими первыми наблюдениями о плюсах и минусах этого перехода.
Привет!
Недавно начал экспериментировать с процедурной генерацией и получил некоторые наработки, с которыми и хотелось бы поделится. Примеры я буду показывать на движке Godot, однако при надобности код можно перенести на любой другой современный движок.
Освещение применяют, наверное, во всех играх всех сортов. Во многих современных движках для этого есть встроенные инструменты, однако если хочется просто взять и просто сделать какой нибудь пошаговый Dungeon Crawler, то движок по типу Unity будет только мешать.
Применять сложные технологии для освещения ячеек дело неблагородное, уйдет много времени, сил, да и не факт что в таком случае это оправдано. Для написания простой пошаговой игры нужно нечто более простое, чем явно непростые инструменты во главе с шейдером. В общем, как вы могли догадаться, сегодня поговорим о простом алгоритме освещения тайловых карт.
Всем привет. С вами я, stalker320, и сегодня я хотел бы рассказать про написание служебных скриптов, запускающихся в редакторе. Всем желающим прочесть - добро пожаловать под кат.
Тайловость в играх – очень распространенное явление, особенно в играх инди сегмента. Чаще всего используют квадратные тайлы – в них проще всего задать необходимые данные, будь то карта уровня или инвентарь. Однако на квадратных и прямоугольных формах возможности подобной системы не ограничиваются.
В топовых играх конца девяностых - начала нулевых часто можно увидеть шестиугольную сетку заместо квадратной – в то время это смотрелось очень интересно, в особенности в сочетании с изометрией. Именно о работе с такими сетками и пойдет речь.
Всем привет, меня зовут Вячеслав и я программист, ну а конкретно сейчас я занимаюсь геймдевом на GodotEngine, и параллельно веду свой телеграмм канал, в котором пишу заметки по созданию своей игры на этом движке и подкидываю новичкам материал для изучения Годо.
А теперь перейдём к делу, а почему бы нам сделать простой инвентарь с Drag&Drop`ом и бонусом от меня?
Тайлы - пожалуй один из самых удобных способов построения игровой логики. Все происходит максимально дискретно, никаких тебе физик с просчетом коллизий и прочими трудностями.
Огромное множество игр на самом деле содержат тайлы - так просто проще представлять игровой мир. Такая упорядоченность помогает геймдизайнерам строить игровые механики, упрощает жизнь художников и делает код программистов понятнее. Самих видов тайлов тоже огромное количество - сегодня поговорим о прямоугольных и изометрических.
Иногда случается такое, что движок попросту ограничивает нескончаемый поток идей. Так, однажды и мне захотелось рисовать откуда угодно, что угодно и где угодно. Об этом и пойдет речь.
Для начала представим такую тривиальную задачу: по клику мыши нужно рисовать некоторый примитив, который задает пользователь, например, нажатием клавиш. Звучит просто, однако с Godot это может вызвать головную боль.
Недавно я начала заниматься разработкой игр на Godot и столкнулась с проблемой - мне понадобилась возможность реализовать мультиплеер с независимым сервером, при этом ещё и с возможностью игры из браузера. В Godot уже есть разные варианты реализации мультиплеера - но для ускорения разработки и во избежание ошибок при ручной сериализации/десериализации я решила попробовать связать клиент на Godot и сервер на Kotlin через вебсокеты и описывать их взаимодействие в формате protobuf.
Всех, кому интересна эта тема, прошу под кат.
