Добрый день, гамин. Продублирую и тут пост, ну в общем не совсем по тематике инди игр, но так как я тут плотно сидел лет 10 назад, и много добрых знакомых, то вай нот.
Реалтайм глобал иллюминейшн на цпу. С физикой и растеризатором на цпу.
Хочется сравнить с люменом уе5 или подобным ртх рассчётом освещения, поэтому там в треде предлагаю --к за вставление готовой сцены в уе5: gamedev.ru/code/forum/?id=283134 Для сравнения и для челленджа, где освещение лучше реализует принцип глобал иллюминейшн.
Немного странный вопрос, но… насколько я знаю, в RPG Maker можно делать скриптинг через менюшки, а можно — через Ruby. Интересно, а много ли разработчиков игр на этом движке пользуется именно Ruby? Не разработчиков плагинов, а именно тех, кто в итоге делает саму игру, или всё общение с Ruby обычно ограничивается скачиванием плагина на Ruby?
Как вам этот язык? Удобный для изучения? Или наоборот какой-то непонятный ужас, куда лучше не соваться?
Всем привет.Есть движок на j2me с открытым исходным кодом,но работает из рук вон плохо выдает 1−2 фпс на симбиан.Нужно как я понял добавить поддержку аппаратного ускорения gpu такой имеется у смартфонов типа n95.Автор движка забил на него.Есть здесь кто умеет писать код на Яве помогите.
Думаю запилить обучалку по крутым нововведениям GML 2.3+, так как кажется ими не все ещё прониклись (а некоторые вообще сидят на GMS1). Кому-то было бы интересно?
Привет, Gamin. Меня зовут Коля и я хочу рассказать тебе о проблеме, с который ты можешь столкнуться при разработке ритм-игры (и с которой точно столкнешься, если разработка будет под мобильные устройства). Ну и о её решении тоже поведаю, конечно.
В марте 2019 я выпустил в Steam свою первую ритм-игру Lofi Ping Pong. Это настольный теннис, в котором мяч надо отбивать в такт треку. Летом 2020 мне захотелось отдохнуть от разработки второй музыкальной поделки, так что решил портировать Пинг понг на мобилки и Switch. Тут-то и появились сложности — мяч вдруг начал лететь отрывисто, «заикаться». Чтобы вкратце разобраться с недугом, требуется вступление.
Здравствуйте! Недавно я опять начал пытаться запилить свою первую игрушку, и мне очень хотелось бы почитать от сидящих на этом сайте людей, как именно они подходили к разбиению своей игры (игр) на составные части и осуществляли взаимодействие между ними.
На какие именно основные составные части происходило разбиение всей игровой логики? Как организовывался переход между основным игровым процессом и меню? Как реализовывалась пауза? Инвентарь? Какую общую структуру имел код, относящийся к поведению противников? К взаимодействию игрока с n различных предметов и сущностей на игровом уровне?
Был бы очень рад, если бы вы поделились своим опытом ♡
Немножко предыстории. Я ооочень давно познакомилась с замечательным игроконструктором Game Maker. Каждый апдейт, с 4.0 в 2001 году и до 6.1 в 2005, я встречала с нетерпением — чего же нового привнёс нам Марк Овермарс. Пусть за всё это время из-под моих лапок ни одной мало-мальски законченной игры не вышло, GM надолго стал одним из моих основных компьютерных развлечений, а скриптовый Game Maker Language — пожалуй, первым языком программирования.
Впоследствии по ряду причин — учёба, работа, другие увлечения — новые версии, созданные новыми разработчиками, прошли мимо. И когда меня на старости лет снова потянуло в геймдев, оказалось, за это время среда разработки очень сильно развилась в профессиональную сторону, похорошела, обросла множеством удобных фишечек. А вот язык остался практически на том же уровне, что и в начале нулевых. По сути, единственное крупное обновление произошло совсем недавно, в версии GMS 2.3. И даже оно, привнося несколько новых и действительно крутых возможностей, не исправляет имманентных проблем, лежащих в корне дизайна языка и его стандартной библиотеки.
Вообще говоря, даже немножко шаря в дизайне языков программирования, к Game Maker Language уже можно предъявить много объективных претензий, но это тема отдельной длинной статьи; а эта целенаправленно посвящена одному из самых больных мест — и чем проект крупнее, тем оно больнее. GML предоставляет множество способов наделать ошибок, но неохотно помогает их находить:
Случайно в ютубе наткнулся рубрику Coding Adventure, где разработчик (Sebastian Lague) с комментариями (на английском, конечно) реализует всякие штуки на Unity3D с помощью шейдеров и не только. — Шейдер атмосферы вокруг планет — Процедурные облака — Порталы как в Portal (оказывается это нифига не просто) — RayMarching — Генератор планет — и даже нейронные сети и прочее
Иногда залезает так глубоко в тему, что страшно становится.
В ходе невероятно длительного обсуждения того, как делать разные фичи для игры в GameMaker Studio 1.4.9999, мы с Хейзером придумали систему универсального редактирования сцен, которая позволяет расставлять объекты по слоям автоматически.
Господа разработчики, поделитесь, как вы реализуете систему диалогов (вопрос тем, кто этим занимается)? Как скармливаете определённый диалог в ту или иную ситуацию? Я что-то сделал, но очень недоволен результатом.
Как это работает у меня.
Есть сцена, которая выводит, проигрывает диалоги и завершает показ. Я ей скармливаю массив с текстом. Далее я хочу, чтобы у каждого npc был свой набор диалогов — создал csv файл и несколько строк диалогов, каждому npc прописал массив, с индексами строк соответствующего cvs файла. И завёл некий счётчик, который будет выбирать индекс диалогов, а тот в свою очередь будет брать нужную строку в csv файле.
З. Ы. Удобно то, что в одной строке csv файла можно выстроить диалог, разделив предложения запятыми тем самым получая длинные диалоги.
И мне кажется, что можно проще.
З. Ы. Ы. Подсмотрел ещё вариант — использовать nodegrath и graphedit (Godot). Единственно нужно писать плагин или что-то типа того.
Что заставляет людей играть в игры или делать их ?
Поделитесь своим личным мнением или примером из личного опыта.
Расскажу о себе, так сказать для затравки.
Одной из первых моих игр на ПК была игра ugh! Там нужно управлять древним вертолетом, который перевозит пассажиров с этажа на этаж, а действие происходит в каменном веке. Игра веселая и прикольная, можно играть вдвоем.
На примере данной игры можно сказать, что в игры играют не ради самой игры, а чтобы весело провести время.
[ Раз уж пошёл разговор про эргономику игры… Это моя статья, написанная в далёком 2005 году для внутренних нужд Qplaze, компании, разрабатывавшей мобильные игры под Java ME. Кое-что, разумеется, устарело, но современные меню управляются не только мышью, но и клавиатурой с джойстиком — и там всё точно так же. Современные комментарии пишу курсивом в квадратных скобках. ]
Эту статью побудил меня написать такой эпизод. При проталкивании игры Real Tournament через тестеров вдруг — когда были сданы почти все «средние» телефоны — нашли ошибку где-то в системе меню. Бывает же!
Здесь я не буду говорить о логике и физике игры. Все ошибки, которые я буду упоминать, связаны с «оснасткой» игры — системой меню, сохранением и так далее. Итак, начнём!
Задумался, как например в EUIV и подобных играх хранят данные карты, конкретно границы провинций?
Просто списком кривых Безье или что-то более сложное? Получается, что границы будут дублироваться в базе для каждых соседствующих провинций. Мне сложно представить, какой геморрой это составлять в редакторе.
И ещё интересно: как они работают с координатами? Ведь речь идёт про глобус по сути.
Думаю, многие знают о метроидваниях не по наслышке. Одной из характерных черт (но необязательных) является игровой мир, поделённый на комнаты. Вот пара классических примеров:
Super Metroid
Metroid Fusion
Metroid Zero Mission
AM2R
Samus Returns
И немного оффтопом карта из Metroid Prime:
Castlevania Circle of the moon
Castlevania Harmony Of Dissonance
Castlevania Aria Of Sorrow
Castlevania Symphony of the night
Hollow Knight
Ori and the Blind Forest
Environmental Station Alpha
Valdis Story
Sundered
Song of Deep
Insanely Twisted Shadow Planet
Axiom Verge
Hero Core
Как видно из примеров, делают по-разному. Есть карты совсем упрощённые — геометрически простые комнаты. Есть карты, показывающие рельеф. Геометрические комнаты могут быть упрощены до комбинации квадратов или же иметь косые углы. Я думаю, что это детали и что если каждой комнате сопоставить картинку то можно рисовать вместо прямоугольников эту картинку.
И комнаты могут иметь чисто прямоугольные формы. Т.к. я ещё новичок в такого рода делах, то меня это абсолютно устраивает, хотя я почти уверен, что мой метод можно легко расширить на непрямоугольные комнаты.
Что такое комната? В Game Maker Studio это ассет, сцена, в которой разработчик расставляет объекты. Она имеет определённые размеры и ещё ряд настроек несущественных в данном посте. Можно добавлять объекты в комнату в рантайме и даже собирать уровни или загружать если они были созданы заранее в другом редакторе. Но это парсинг данных и всё такое. Поэтому вариант догрузки нужной комнаты встык — это не мой вариант. Можно пофантазировать как это могло бы быть и выяснилось бы что там свои геморрои — например нужно хранить связи входов и выходов, их нужно помечать прям внутри комнат, что влечёт ещё один менеджмент и обнаруживает очередной камень преткновения в реализации.
Так что в данном посте я рассматриваю набор заранее созданных комнат и переходов между ними.
Последние обновления