Pokemongol IGO: опыт создания игры-пародии
Чтобы пародия была по-настоящему действенной, уровень ее исполнения должен быть максимально приближен к оригиналу. Если вы придумали пародию на популярную песню, можно просто опубликовать измененный текст, но значительно эффектнее будет спеть ее, а еще лучше — снять клип, который также будет пародировать оригинальный. Кроме того, каждый новый уровень исполнения также открывает новые возможности для насмешек над оригиналом (или чем-то другим) — скажем, вы можете гротескно подать певческую манеру исполнителя или довести до абсурда стилистические изыски режиссера видео.
Собственно, так появилась Pokemongol IGO: вначале в голову просто пришло название, выросло из общего МОН в монголах и покемонах и намека (хотя и несколько запоздалого) на то, что покемоны внезапно снова нас поработили, как полумифические азиатские захватчики.
Я выложил шутку в Твиттер, но она «не выстрелила». Пора было переходить на следующий уровень. «Надо сделать фейковый скриншот или видео!» — решил я. Можно было, конечно, нарисовать его попиксельно, но я подумал, что аутентичнее будет взять какой-нибудь движок с закосом под старину. Поскольку PICO-8 был платным, я остановился на TIC-80. В него были встроены редакторы кода, спрайтов, карт, звуков и музыки — очень удобно. Пример кода по умолчанию выводит на экран анимированный спрайт и позволяет двигать его стрелочками, так что я первым делом нарисовал конного монгола с анимацией из двух кадров. Результат мне понравился, и я понял, что пародии — быть.
Я быстренько изобразил прикольный шрифт (люблю это дело еще со спектрумовских времен), а логотип сделал частью карты. Пунктирные линии, из которых он состоит, в дальнейшем стали границами между княжествами. Картинка должна была пародировать ключевой момент любой покемонной игры — выбор стартового монстрика. Разумеется, в моей версии место Бульбазавра, Чармандера и Пикачу заняли три бородатых баскака. Портреты я нарисовал от балды, руководствуясь двумя критериями: чтобы они все походили на спрайт наездника (до сих пор помню свое разочарование, когда увидел, что в оригинальной King’s Bounty обворожительная колдунья на карте выглядит точно так же, как ее железноголовые коллеги) и достаточно отличались друг от друга. В результате двое вышли… ну, такие баскаки и баскаки, а третий получился похожим на какого-то битла. Тут же созрел и гэг с именами: Ногай, Батый… и Ринго, почти как в фильме про жандармов из Сен-Тропеза.
Я долго думал, чем баскаки должны отличаться друг от друга: немного подкрутить им характеристики — один посильнее, другой побыстрее, третьему здоровья побольше, или дать каждому спецспособность, скажем, строить мосты через реки и… не знаю, у Ринго должно быть что-то музыкальное, наверное? И как это все сбалансировать? В итоге довольно долго они были по факту одинаковыми, и решение созрело лишь ближе к концу разработки.
Хотя твит, с которого все началось, был, как и все твиты, коротким, он достаточно емко описывал основной игровой цикл: отправляемся из Орды на Русь, собираем там дань и возвращаемся с ней обратно. Однако формулировка «дань СО ВСЕХ мы соберем» пустила меня по ложному следу — изначально я хотел, чтобы баскаку обязательно было нужно объехать все города. Но такое задание получалось слишком сложным и одноразовым: вот игрок осмотрел всю карту, нашел все населенные пункты, и, в принципе, стимула играть снова у него больше и нет. Поэтому я решил, что герой должен будет принести на каждом уровне фиксированную сумму, причем для того, чтобы ее собрать, будет не обязательно заезжать в каждый город: дань будет появляться с некоторой периодичностью, так что ее можно пытаться «фармить» — но при этом период ее появления достаточно велик, чтобы игрок устал ждать и попытался все-таки поискать счастья в других городах. Кроме того, если дань залеживается в городе, народ начинает роптать и появляются воины, затрудняющие нашу задачу. Кстати, поначалу я боялся, что воинов народится слишком много, и думал, не сделать ли им «эффект Вольтрона», чтобы при встрече они превращались в более мощного или быстрого богатыря, но потом решил не усложнять — и в этом аспекте, и в других. Так что тип воинов в игре один, и они ходят за баскаком стадами, как зомби (впрочем, чтобы придать им чуточку индивидуальности, я придумал для них простой генератор имен).
Тут надо сказать, что карту местности я срисовал с найденной в Интернете карты татаро-монгольского нашествия и немало с ней намучился, так как все плавные изгибы рек приходилось выкладывать по тайлам вручную (при этом левый и правый берег изображались двумя разными тайлами).
Чтобы скомпенсировать эту кропотливую работу, я оттянулся на дизайне городов: хотя для их оформления я использовал всего лишь около десятка тайлов, каждый выглядел по-своему. Без шуток не обошлось и тут: в пару к Смоленску (Smallensk) появился Бигэнск (Bigensk), выглядящие соответственно как строчная и заглавная N; Козельск приобрел очертания козлиной головы, а Москва — коровьей (Mos-COW).
С геймплейной точки зрения карта тоже получилась довольно интересной: большое княжество в центре, где за баскаком бегает целое войско, и закоулки с краев, где городов (а значит, и врагов) поменьше, но и разминуться с противниками труднее. Так что, хотя я и не хотел, чтобы игрок исследовал всю карту сразу, все-таки было бы неплохо, чтобы он сделал это постепенно. Нужны были какие-то дополнительные цели. Ну например… например, Ринго может… собирать музыкальную группу!
Присутствие в игре баскака-битла внезапно обрело смысл. В чем-то даже логично, что сборщик дани (tribute) хочет организовать трибьют-группу, чтобы выступать с песнями «Битлз». А Ивана, Павла и Георгия можно было рассовать по тем местам карты, куда игрок просто так не заходит — вот вам и мотивация для исследования.
Единственно, я почему-то решил, что это задание должно стать секретным, поэтому, пока вы не найдете первого псевдобитла, ничто в игре даже не намекает, что вы должны это сделать. Ну, не намекало — ближе к концу разработки я все-таки добавил в интерфейс вопросики туда, где должны появляться члены группы.
Точно так же в последние дни было добавлено и спецзадание для Батыя, уже более очевидное — ему я поручил собирать краеведческую информацию для баскацкого справочника. То есть задача обойти все города в конце концов вернулась в игру, но как дополнительная.
И все-таки Pokemongol IGO вышла недостаточно увлекательной. Хотя миссии Батыя и Ринго приятно разнообразят ее, основной цикл не очень-то мотивирует проводить за ней какое-то продолжительное время, чтобы наловчиться собирать дань, выработать оптимальную стратегию, пройти игру до конца (or die trying), а затем пытаться побить собственные рекорды. В общем-то, и пародия на покемонов у меня не получилась. Но все же вышло нечто, с одной стороны, довольно оригинальное, а с другой, в традициях «больших» игр восьмидесятых.
Возможно, новые знания, которые вы почерпнули из этой статьи, побудят вас дать «Покемонгольскому игу» второй шанс.
- 19 февраля 2019, 04:13
- 014
И как опыт разработки на TIC-80 ? Интересно?
Всё не могу понять почему панель интерфейса справа СТОЛЬ огромна, хотя там информации не так много)
Интересно. Удобно, что у выложенных игр можно посмотреть исходный код, я кое-что подглядел из Quest for Glory (https://tic.computer/play?cart=6). Lua до этого вообще не знал. Правда, так и не разобрался, как делать классы.
Но неудобно, что редактировать текст приходится в этом же интерфейсе (хотя можно включить шрифт половинной ширины, чтобы больше текста помещалось).
Меня еще привлекло, что готовый файл получается небольшой по сравнению с тем же Game Maker, например. Если без встроенного экзешника, вообще меньше 100 КБ. И веб-версию можно сделать (правда, там музычку иногда заедает).
Касательно панели: изначально думал, что там будет больше всего, а потом уже сложно было менять в коде все места, касающиеся ее размеров, размеров игрового поля и положения баскака на нем. С другой стороны, 1) если собрать 1000/2000 дани, то будет задействована практически вся ширина панели и 2) так поле обзора у баскака квадратное, то есть он видит во все стороны одинаково. Ну-у-у и это тоже элемент пародии.
Понятно! Если там полноценный Луа, то имитировать ООП можно с помощью метатаблиц.
А насколько базовая версия функциональна? Просто я помню, что там можно было за деньги получить "про" версию с большим объемом памяти или типа того.
Quest for Glory, кажется, использует классы, но я смотрел в этот код и так и не понял, как это работает.
Я не очень хороший программист и испорчен Game Maker'ом к тому же.
В про-версии обещают какие-то сменные "банки данных". В принципе, обычной для моих целей хватило, в той же Quest fot Glory даже меньшего объема файл.
Луа полноценный, версию можно посмотреть на офсайте.
Про-версию можно собрать из исходников на сайте разработчиков. Но и так неплохо - насколько я могу судить по играм на официальном сайте всем или почти всем разработчикам на TIC-80 хватает базовой версии.
В официальной документации можно найти плагин для Sublime Text с поддержкой TIC-80 - очень удобно.
Одна из самых простых реализаций классов на Lua - https://github.com/bartbes/love-misc-libs/blob/master/SECL/basic.lua
Конечно, если консоль позволяет использовать метатаблицы.
Она "простая" в смысле "короткая", но недостаточно простая для моего понимания.
Да, простая в плане длины кода и функциональности. Без метатаблиц классов в Lua не сделать, а малое количество символов будет полезно, если есть ограничение на размер кода в картридже.
Классы "из коробки" есть в moonscript или wren, на которых также можно писать в tic80
Я выбрал Lua по принципу "об этом языке я хоть что-то слышал".
Я вот тоже сейчас пытаюсь вникнуть в Lua, из-за того что тоже решил побаловаться в Tic-80, всё хорошо идёт, пока не натыкаюсь на классы. (ну и ещё на то что надо вручную писать коллизию, у меня сложности с математикой, но это не так важно, можно стырить кусок кода из любой игры с AABB проверкой)
Можно же и без классов программировать. Просто в Quest for Glory, откуда я списывал, они были, но я не понял, как они работают.
не ну если я хочу больше одного противника или например сокровищ каких-либо, то наверное нужен класс, хотя я не силён в Lua, и возможно там есть ещё средства
Далеко не обязательно надо иметь классы под это дело. Данные по каждой сущности храни в своей таблице, обрабатывай их по-разному в зависимости от "типа" сущности. Но можно и иначе придумать. Раньше без классов делали - и ничего. И тут не так важно - Луа или что.
Я пару дней поигрался в Tic80 и сделал монстров и интерактив в виде таблицы. Реально не нужны классы.
В целом можно сказать что я освоил на троечку Lua за эти пару дней) оказывается очень удобно изучать новый язык с таким удобным инструментом как Tic80, где компилятор мгновенный и все инструменты сразу в одном, не то что юнити
Думаю может стоит перейти даже на Love, раз я немного освоил Lua, или ещё куда-нибудь. Чтобы закрепить навыки. Или хотя бы в юнити поддержку Lua поставить
PS Lua реально крутая вещь
Ты сам пишешь, что в юнити тебя многое не устраивает: https://gamin.me/posts/20090?comment=245794#comment_245794 но при этом есть желание перейти на Love2D, в последнем этого даже в помине нет, и решать нужно либо готовыми либами, либо писать самому. В таких движках, как юнити, годот и гамак все решается буквально двумя кликами. Сначала определись, что ты реально хочешь - либо трахаться с кодом, либо играть с конструктором лего. ;)
Ну или поставить вопрос так: "я хочу сделать конкретно такую игру с такими фичами на таких платформах + я нуб в программировании, посоветуйте движок".
Можно и не переходить. Есть прослойка для Love, запускающая код картриджей .p8
для Piko-8?
Я с ним меньше знаком, чем с Tic80, но думаю общие принципы такие же. Может быть там только гамму нельзя менять, я не уверен...
Погуглю что за переслойка такая)
Например вот тут есть https://nusan.itch.io/combo-pool
или тут https://github.com/LIKO-12/LIKO-12
Можно скопировать весь код и вставить например в Notepad++, там подредактировать и вставить обратно.
(ctrl+A, ctrl+C, ctrl+V)
Жаль что с пикселями так не прокатывает.
С картинками тоже какой-то экспорт-импорт работает.
А текстовый редактор я использовал, чтобы быстро смотреть, что там у меня в другом месте кода написано (например, как переменные называются).
Там ещё есть dofile() для редактирования из внешнего редактора
Но ведь... https://en.wikipedia.org/wiki/Quest_for_Glory...
Иногда у игр бывают одинаковые названия...
См. также https://www.mobygames.com/game/unreal-
Серьёзно? Я только позавчера смотрел, вроде цена у Tic-80 была 5$ на itch io
ЗЫ Реально на офф сайте, есть какая-то лайт версия бесплатная.
Ну да, а на itch это, видимо, то, что позиционируется как демо-версия.
TIC-80 опенсорсный. Под лицензией MIT. То-есть при желании можно собрать себе любую версию. Этим tic реально подкупает. А pico-8 мне нравится тем, что имеет более жёсткие ограничения и меньшее разрешение... Но закрытый. :)
А мне как художнику хотелось бы побольше графического контента, хотя бы 2 полотна, и в TIC-80, это осуществили, по сравнению с Pico-8 в 2 раза больше пикселей для графики и больше места под левелдизайн, мне это больше нравится, хотя я тоже люблю ограничения.
Вчера вечером поюзал Tic 80, главный минус обоих движков, в том что у меня нет опыта в Lua, сегодня думаю погуглить документацию для Tic80, ибо первый раз вижу операторы % и // например, из-за этого не смог прочитать некоторые вещи в примерах кода.
Lua классный язык! Я уже не могу себе представить, чтоб я без него делал. :)
% остаток от деления. // -- целочисленное деление. Правда "//" это 5.3 уже фича.
Поигрался немножко.
1) Первое неприятное чувство с самого начала игры: "Куда идти? Почему ничего вокруг не интерактивно?"
Обычно, если в течении минуты не понятно, то я дропаю игру, но тут ради теста решил пересилить себя,
где-то примерно минуту шарахался вдоль реки и никак не мог найти путь или хоть одно интерактивное место,
ещё непонятно, работают ли кнопки Z и X.
Специально не читаю инструкции при тестировании, чтобы дать игре более точную оценку,
как бы в неё играли обычные люди, которым точно не хочется читать ничего, а сразу запустил и играешь,
сразу должно появиться понимание или отдача, ну или хотя бы какой-то интерактив.
2) Потом всё-таки нашёл города, игра более-менее оживилась, но часть аудитории точно потеряется вначале пути игры. )
3) Локация сделана интересно, в плане проработанности реки и городов)
4) Игре не хватает мини-карты или карты в меню, или какие-то начальные ориентиры.
PS Внезапно заинтересовался Tic-80, после этой статьи, хотя пока не нашёл нормальной оффлайн документации, у меня интернет нестабильный, но в целом выглядит всё довольно неплохо. Сообщество даже какие-то демки лепит, хотя не так бодро как в Pico-8, но всё же нормально)
Я когда посмотрел на реальную карту ига, подумал "Ого, чё-то далеко до столицы Орды переться", а потом решил, что это тоже будет фишка игры*. В столице можно лечиться, но каждый раз туда не попрешься, потому что на это уходит много времени. В пустыне я думал насажать ориентиров, нарисовал какой-то коровий череп, но он мне не понравился. Так что решил сделать классическую "зону, в которой хрен знает как ориентироваться", любимую, в частности, разработчиками старых квестов. В одной из юрт есть подсказка GO UPSTREAM (прямо как в Duke Nukem 3D), так что шарахаться вдоль реки была правильная идея, главное — правильно выбрать направление (и реку).
Аналогично, карту можно было бы сделать, но в играх восьмидесятых ее часто не было или она находилась в руководстве. Предполагается, что карта постепенно строится у игрока в голове. Конечно, это все работает, если ему интересно играть и переигрывать, а вот с такими зацепками у меня что-то не очень вышло :(
* На самом деле там, конечно, были региональные баскаки, но как-то же и в столицу денежный поток шел.
Просто получается так, что правильный путь на заднем дворе. То есть когда появляешься, то находишься от юрты чуть ниже, как бы игра намекает что надо идти в сторону от юрты ещё ниже. А получается надо вообще в другую сторону, это как сделать альтернативные гоночки, где надо ехать не вперёд , а назад) как в фильме "Первому игроку приготовиться" :D
А ещё если сранивать игры с картой и без карты, то в приоритете игры с картой, с ними ты чувствуешь контроль над игрой, вот к примеру игра на Мегадрайв "Rings of Power" - очень крутая, потому-что там есть карта, ты всегда держишь ориентир, где ты находишься, сравнивая с игрой "Phantasy Star" - часто не понимаешь куда идти вообще, хоть интерактивных точек на карте намного меньше.
Также ещё Zelda и Beyond Oasis в более выигрышном положении, чем большая часть JRPG без карты.
В DOS играх, тоже не любил долгий поиск пути, благо в некоторых играх, сама игра и есть карта, как например игра по властелину колец (забыл точное название, полустратегия)
в Beyond Oasis нет карты же. и в старых зелдах
Zelda 2 на восьмибитке - как бы большая часть игры и есть сама карта (хотя по ней сложно ориентироваться, ибо малая площадь захвачена), но я конечно имел ввиду игры начиная с Super Nintendo и Game Boy.
В Beyond Oasis на мегадрайве есть карта, даже есть флажок куда дальше идти, в меню паузы, хотя сама карта не детализированная, но общее направление можно понять по ней. (Но во второй части кажется убрали её, а я всё не мог понять, почему она мне меньше нравится, чем первая)
В первой Zelda карта и подсказки были в руководстве. Мне очень хотелось его сделать, но руки не дошли. Можно использовать карту, на которую я дал ссылку в этой статье (хотя в игре есть не все города и один вымышленный).
Да проще сделать ориентиры куда идти, пятнами крови, столбами, дорогой,
чем карту, карта - это слишком круто для мини-игры.
"большая часть игры и есть сама карта" - что это означает?
"Beyond Oasis на мегадрайве есть карта, даже есть флажок" - кек. я не знал, проходил так. думал еще, чего так непонятно куда идти-то.
ухты, вторая часть есть. не знал, спс
Ну с натяжкой можно назвать картой, то где ходишь вне городов и подземелий во второй Зельде. Хотя конечно я просто пытался отмазать Zelda 2, ибо нравится до сих пор. :)
По хорошему, конечно, нормальная карта в Зельде появилась только на SNES и Game Boy, не знаю какая из этих платформ раньше появилась.
Надо бы как-нибудь перепройти её снова ) Хотя она потеряла часть шарма, в отличии от первой части, но в целом неплохая игра. И эмулятор (пробовал 2 разных) как-то странно тупит, и делает косяки со звуком иногда, что режет слух.
>когда появляешься, то находишься от юрты чуть ниже, как бы игра намекает что надо идти в сторону от юрты ещё ниже
Резонно, но выход было удобнее рисовать снизу, а Русь исторически находилась сверху :(
Спасибо этой статье, освоил на троечку Lua. Поигравшись с Tic80 за несколько дней)
минусы Lua или я просто не нашёл альтернативу:
1) не нашёл count++ вот такой опции приращения
2) не нравится писать длинное then вместо { и вместо end }
3) не знаю есть ли функция switch но буду гуглить, я не люблю долгие раскладки elseif
Унарного инкремента, декремента и т.д. действительно нет. И switch нет!
блин жаль(
Ну если у тебя много опций планируется, то можно сделать таблицу с функциями вместо switch, и в качестве ключей использовать возможные значения проверяемой переменной. Или ещё что-то придумать!
а как это примерно можно записать?
switcher={
option1=1,
option2=2,
option3=3
}
ну допустим так, а как потом это использовать в условии?
ну типа
switcher={}
switcher[1]=function (*тут переменные входные, если надо*) *тут функция*
switcher[2]=*ещё функция*
и так далее
потом в момент "проверки" switcher[a](*тут переменные входные, если надо*)
ого какие можно вещи тут делать о_О
Спасибо! Вот это реально круто, что можно даже функции сюда вставлять
ещё похоже что такой опции тоже нет, а она очень полезная, люблю сокращённый код
count+=25
(я не знаю как она называется, ибо не программист и всё дохожу методом тыка, другими словами не знаю как это называется, но использую xD , может быть это тоже инкремент и декремент )
но в целом понравился динамический язык, тут многие вещи по крайней мере выглядят так
очень нравится простая инициализация сложных структур типа
body={
name='no name',
collider={},
animations={},
x=0,y=0,speedX=0,speedY=0
}
Вот бы можно было бы так просто инициализировать данные в Юнити например
ЗЫ Я ещё к Godot присматриваюсь, там вроде скрипт у годота динамический, может быть там можно делать необычные фокусы с данными
То есть тебе не нравится через инспектор (я про Unity, Godot) инициализировать данные?
нравится, только в Юнити раздражает компиляция долгая, в Годоте этой проблемы нет,
хотя главное что я имел ввиду, не обязательно указывать данные или можно менять их тип на лету,
в Годоте опять же это вроде как можно, но я мало пока Годот изучал
И вообще, работать в Tic80 приятнее и продуктивнее, чем в Юнити для меня:
1) разрешение статическое - это вообще шик, всегда знаешь сколько пикселей у тебя в запасе,
2) моментальная компиляция, в юнити с моими скриптами время на компиляцию всё больше и больше,
3) мне нравится отрисовка в реальном времени, в юнити нужно расставлять объекты, но мне нравится программно рисовать, то есть когда объект больше не нужно рисовать его не надо удалять, его просто не существует, и он может моментально исчезать и появляться где угодно и в каком угодно виде
Правда я слышал что в юнити тоже есть какая-то отрисовка, но вроде как она не поддерживается всеми видеокартами
4) все инструменты в одном, жаль в юнити так нельзя) я всё больше думаю, что мне пора переходить на Game Maker)
5) полный доступ к Тайлам карты в Tic80, легко и быстро на лету можно менять, сделано очень просто
в Юнити когда программируешь то у меня возникает коллапс, непонимаешь с чего начать делать ядро,
не годится для маленьких прототипов, и конкурсов, ибо я долго раскачиваюсь в юнити, а если взять готовый проект, то там проблема с очисткой от ненужного хлама предыдущего проекта.
не сделаны в юнити следующие вещи:
1) нет глобального места, где есть глобальные переменные, нужно самому делать скрипт , где будет всё храниться
>>поэтому нужно организовать самый главный скрипт, который будет всё контролировать
2) нет встроенного затенения экрана при загрузке нового уровня, также нет встроенного интерфейса, который бы показывал, что уровень загружается
>>Это тоже нужно самому делать, нужно чтобы камера была отдельная для интерфейса и также там повешать текстуру, которая будет затемняться при перезагрузке уровня и плюс там сделать спрайт или текст прогресса загрузки
3) нет нормального менеджера комнат, то есть чтобы уровни были в префабах, а не все 999 уровней были в отдельных уровнях, которые будут огромной кучей толпиться в графе в настройках Build путая разработчика, если уровней очень много
>> приходится самому делать менеджер
4) мало вспомогательных вещей, которые ускоряют разработку в юнити, всё больше наоборот задерживает,
например нет инструмента для наполнения уровня, тупо приходится обычные префабы из меню таскать вручную,
боясь случайно не туда префаб перекинуть, например в другую папку и потом ищи его :D
думаю, на следующий месяц заняться упрощением юнити, созданием инструментария стартовых файлов, для перключения уровня, хранения глобальных данных, чтобы было легко работать с ним, и хотя бы чуть приятнее, как в Tic80 или в Construct
По-моему сопоставлять Юнити и Тик80 и прочие фентези-консоли - это довольно странно) Как сравнивать перочинный нож и целый цех, оборудованный станками с ЧПУ, что-то такое)
Это да, только я сейчас говорю о состоянии потока) Когда программировал в Tic80 то реально был в процессе, а когда работаешь со сложным Юнити, то процесс замедляется, тормозит что-то вечно, забываешься или забываешь что хотел сделать, короче очень много отвлечения и процесс медленно движется.
то что в Tic80 я сделал за пару суток на незнакомом языке, не могу сделать в Юнити уже 4-й месяц подряд на знакомом... просто там это всё усложняется в разы, сделать стартовую структуру проекта, чтоб было нормальное переключения уровня, данные для игры и все готовые стартовые вещи для ядра проекта
Возможно просто стоит выбирать соответствующий задаче инструмент)
Если ты "в активном поиске", мне интернет еще вот такое подкинул:
http://superpowers-html5.com/index.en.html
Но этот я ещё не пробовал.
Я попробовал, но так и не смог оценить проект, он всё требовал скачивать с интернета что-то и потом ещё с разными другими вещами домогался, короче я отложил это до лучших времён, но примеры игр там хорошие)
Тут хз, много народа в Godot приходят с GM, может, стоит вообще пропустить этап GM :D
С другой стороны, я не очень понимаю концепцию "переходить". Ведь в джемах продуктивнее участвовать со всякими Tic, и даже если ты захочешь потом развить игру дальше, всё равно надо переписывать корявый код нормально (что с GM на GM, что с Tic на GM)
Я бы хотел пропустить этап с программированием вообще, раз уж так. Но пока как-то не удаётся.
Я тоже.
чем Godot подкупает, что там скриптинг прикольный, а Game Maker скрипт я ещё не видел,
Жаль примеров мало для Годота, маленьких но полноценных игр.
Например на pico-8 есть такие прикольные журналы
такой журнал читаешь и хочется сразу попробовать сделать игру, так как тут полный функционал маленькой игры сразу описан. Мне таких журналов для Годота и Юнити не хватает, где начинают с создания архитектуры игры, то над чем я долго парюсь в юнити, чтоб сделать так, чтобы одни скрипты не запускались раньше других пришлось нехило помучаться, или чтобы понять как хранить глобальные переменные.
У годота есть хорошая документация, но нигде не нашёл, чтобы начиналось с создания стартовой архитектуры проекта.
По годоту я пока только знаю, что нужен хотя бы один синглтон где будет основа всей игры.
Но наверное было бы глупо там же хранить все переменные глобальные, ибо в разных играх они разные, то есть нужен ещё один синглтон, но заменяемый (когда придёт время для другого проекта)
короче там столько нюансов, что я путаюсь с чего начать проект)
Понимаешь в чем дело. В годот любая сцена она самостоятельная. Т.е. создаем три сцены: игрок, enemy и map и четвертую под названием main, кидаем туда три первые и все. Прототип готов. Можно создать сцену игрока и в нее же поместить сцены карты и enemy. Можно в сцену карты запихнуть всех. Короче, как все будет работать определяешь ты и только ты. Начинаешь работать с чего хочешь, потому что в любой момент ты можешь разделить сцену на три, четыре и т.д. сцен, но поменьше. Я обычно начинаю с игрока: движение, анимации, коллизии, потом энтити: движение, анимации, реагирование на коллизии, потом окружение, потом эффекты...
Ага я понял концепцию. Сцены в Годоте - это Префабы в Юнити. То есть самостоятельный объект, что мне кстати больше нравится, чем в юнити, хотя там (в юнити) недавно добавили вложенные префабы и теперь можно почти также делать.
В целом я тоже обычно вначале делаю Hello World эксперименты, а когда изучил движок, то начинаю пилить персонажа и управление базовое, минус в том, что я потом (в юнити) за голову схватился, ибо там скрипты случайным образом стартовали (кто-то раньше, кто-то позже), и пришлось придумывать управляющую систему, которая бы сама вручную запускала скрипты по очереди, ибо был такой хаос, и теперь я стараюсь больше думать о стартовой архитектуре проекта, правда с годотом я мало знаком, и подводный камень только один встретил - сложно или невозможно делать PixelPerfect шрифт, при растяжении экрана с низким разрешением, шрифт колбасит
По шрифтам я же тебе показывал!!! Там только правильно подобрать нужный шрифт. Поиграй с ними, должно получится.
З.Ы. Я вот хотел замутить динамически загружающиеся карты, а уже почти игру сделал...
Можешь ещё defold попробовать. Не перегруженный функционалом движок и на Lua.
Горячая перезагрузка есть, смотрю тебе её не хватает. :)
Спасибо) Гляну
на него не стоит терять время, не хочу быть пропагандистом, но я также изучал defold и безрезультатно. И ради интереса посмотри сюда: https://github.com/collections/game-engines
Спасибо за ссылку)
А в чём отсутствие результатов? Просто я хочу найти очень удобный, желательно заточен под дизайнера,
то есть такие вещи как перезагрузка уровня и синглтон(место под глобальные переменные и главный управляющий скрипт) были готовы сразу, чтобы я не ломал голову, как сделать стартовую архитектуру игры, как ломаю в Юнити
но с лёгким программированием инструмент (Lua мне понравился), ещё главное чтобы там была возможность PixelPerfect с растяжением окна (не только в FullScreen режиме) и чтобы пиксели и соотношение экрана оставались прежними
ЗЫ Мне ещё интересно как много стартовых приготовлений нужно сделать, чтобы сделать простую игру на Годоте, то есть чтобы там было место под глобальные переменные и перезагрузка уровня уже была готова, как если бы это была Аксма, но не только для текстовых игр, то есть чтобы уже можно было начинать делать игру, а не только начинать готовиться к этому, но это уже потом посмотрю уроки
Я тебя понял, ты хочешь иметь готовый каркас, но этот каркас нужно сделать самому, это кропотливая и долгая работа. Все дело в сценах, я писал комментарий выше: ты дрочишь, как хочешь, вот сколько есть фантазии, вот именно на столько и извращаешься. К той системе которая тебе нужна подходить нужно постепенно - лично для меня сложно определить, что и как будет работать, потому что есть куча решений одного вопроса, захотел так сделал, а захотел эдак. К примеру: у меня есть основная сцена, я кинул в нее сцену игрока и врагов и пустую ноду. Как я меняю карты: предварительно загружены карты, и с помощью функции "свитч" (она в годот по другому называется) я добавляю пустой ноде нужную сцену с картой. И все это без автотюна, в смысле без синглтона. В будущем это будет fsm, возможно. Ах, да, а во время смены карты я пускаю другую сцену: затенение экрана. Если с английским хорошо, то на ютубе есть gdquest, и еще четыре канала, где очень хорошо объясняют процесс разработки.
Вот сейчас непонятно было.
Что именно? Про дрочку и фантазии?
Это ты рассказывал про годот или дефолд? В конце про автотюн / синглтон / fsm и далее тоже не понял.
Годот. Fsm - это конечные автоматы, автотюн - намеренная оговорка, дабы намекнуть, что не всегда необходим синглтон и зацикливаться на этом не стоит. А так согласен, мои объяснения туманны и расплывчаты...
Как человек, работающий в Game Maker уже 12 лет (окей, коммерчески только последние 4), недоумеваю с самой идеи о том что синглтон для чего-то может быть нужен или не нужен.
Но он при этом не нужен
1) На GDQuest кстати подписан) но там я лишь несколько видосов успел посмотреть)
2) По части работы всё от стартовой сцены прикольно, но есть одно НО,
как редактировать уровень и запускать мгновенно тот уровень для теста, который сейчас редактируешь?
В юнити я сделал синглтон, который есть в каждом уровне, и какой бы уровень я не редактировал, то стартовый подхват скрипта будет. Но если делать так, чтобы был первый стартовый уровень, куда загружались бы сцены, то пришлось бы каждый раз после исправлений какой-нибудь сцены вначале открывать стартовую сцену и потом ещё придумывать патч, как быстро попадать в ту локацию, которую только что редактировал. То есть несколько больше отвлечений при быстром тестировании придётся делать.
Хоть идея крутая про одну сцену, но похоже придётся использовать синглтон на всех уровнях, чтобы работать и стартовать сразу с любого уровня, который и редактируешь (это особенно важно, когда уровней куча)
Вместо тысячи слов, простейший (прям самый самый простейший) загрузчик уровней (см. спойлер). Я раньше создавал кучу сцен с уровнями, а сейчас решил написать загрузчик карты: сцены не меняются, а лишь удаляются/добавляются нужные сцены с картами.
Спасибо! Сохраню скрин, вдруг пригодится)
Я так то не программист, поэтому это все такой велосипед, который тыщустопятсот раз будет переделываться. Главное понимать логику, и как все работает в движке, и уже отталкиваться от этого...
Я тоже не программист, учу методом тыка всё. Мне дать учебник я ничего не пойму, а дать программу, где можно будет на ошибках учиться, то я выучусь)
Нажать F6.
antonka просто предложил запускать всё из первого стартового уровня, такая концепция наверное не сработает...
1) то есть вначале надо стартовый уровень открыть, запустить его, найти нужный уровень в игре или меню внутреигровом или через консоль в игре, а после теста, открыть заново тот уровень который редактировал и дальше править локацию, короче сложная комбинация
2) в моём варианте (где у каждого уровня лежит стартовый синглтон внутри) можно стартовать с любого уровня, хотя мне определённо нравится концепция начинать всё с одного уровня, но долго возиться при многократном тестировании уровней
или хз, я не уверен что делает F6 в Годоте) проверю)
Запускает текущую сцену.
Не знаю, зачем antonka пишет всякие ужасы :D
Какие именно?
Ну то есть зачем вообще всё это вот реализовывать:
- какие-то загрузчики-синглтоны, если можно тупо при редактировании сцены нажать F6, и сразу запустится она вместо стартовой по умолчанию?
😂😂😂
Эх, ребята. Алекс, не разбирается в Годот и поэтому усложняет все, и накручивает. Ты не понимаешь его и предлагаешь совершенно бестолковый вариант. F6 это не магическая кнопка, на которую кликнул и все завелось, само собралось, само распоковалось и инициализировалось. F6 это запуск текущей сцены и не более того, и если в сцене лежит тупо нода tilemap, то ты увидишь тупо тайлмапу. Как я понял Алекса, ему надо загрузить без проблем нужный готовый уровень со всеми настройками игрока, карты, которую он в текущий момент редактировал, камеры и прочими параметрами и чтобы все это работало, а не просто вывело на экран. Говоря уровень, я понимаю не просто тайлмапу, а именно уровень со шлюхами и виски.
Сам ты бестолковый.
Вот тебе сетап:
1) карта в сцене;
2) игрок и всё остальное интерактивное тоже в этой же сцене в виде инстанса (ака префаб в Unity).
Нажимаешь F6 при редактировании карты - получаешь полноценную игру, начинающуюся с этой карты. Для этого не нужны никакие свои загрузчики уровней (их можно сделать потом, если понадобятся).
Алекс не просил загрузку уровня при редактировании игрока, только при редактировании уровня, для этого F6 работает замечательно. Если не смог запомнить клавишу, то есть кнопка в том же углу, что и обычная кнопка Play, только правее от неё.
Только на днях делал простенький платформер в Godot на 5 уровней, и в синглтоне там только музыка (чтобы не начиналась заново каждый уровень).
Я просто использую куча глобальных переменных. Мне нужно хранить главное управляющее ядро игры, которая юзает важные скрипты и переменные, ну там работу с музыкой той же, потом состояние игры (пауза,затенение экрана, игра), трясение экрана (скорее всего не реализовано в Годоте/Юнити) потому тоже надо держать всегда в главном ядре скрипта (ибо придётся самому делать и всегда нужно иметь быстрый доступ к этому) и другие полезные функции, типа показа диалогов.
А вот ещё барьер экрана, то есть граница до куда нужно дойти камере, чтоб остановиться, в юнити это не предусмотрено в 2д играх. Короче дофига косметических операций, прежде чем сделать рабочий движок, и после чего уже можно игру начать делать.
Но в остальном да. Если б все функции были бы реализованы, то мне бы осталось только делать карту и интерактив. Всегда мечтал о таком движке, где всё уже сделано за меня, например в Stencyl уже реализовано трясение и затенение/смена экрана при переходе на другой уровень, правда там не реализованы быстрые диалоги.
А в Аксме вообще всё готово. Осталось только игру пилить (приготовления минимальные). Жаль что там только для новелл функционал)
Не видел такого универсального, каждый под разные жанры хорош.
Попробуй найти шаблон, например, GDquest тут слепил маленькую ARPG.
Синглтоны тоже загрузятся при тестировании сцены по F6. Я проверял. ;)
пошёл гуглить как делать синглтоны на годоте)
PS Я еще в юнити на яваскирпте написал свой скрипт для уровней. Чтоб не ждать компиляции, после каждого скриптинга мелких фич для уровня. Правда теперь придётся переписывать его на Си шарп, и тоже не хочется( но юниты от ява скрипта отказались
Godot ещё умеет отправлять изменения сцен и скриптов в уже запущенную игру (и не потерять их при выходе из игры, разумеется).
Кстати, во вконтакте есть группа с переводом букварей по Godot https://vk.com/godot_rus_docs
Синглтоны в годоте есть (так и называются), перезагрузка текущей сцены - одной строчкой.
Ну посмотрел я на defold страницу, и то что увидел мне пока понравилось, хотя там говорят какие-то проблемы с пиксельартом. Пока попробую ради эксперимента посмотрю, а там дальше будет видно.
count+=25 - в Godot такое имеется. GDScript - динамически типизированный язык, но возможна принудительная типизация. И словари есть:
Вот это очень круто)
Да, после C# это просто рай.
Заодно обрати внимание на Pixilang http://warmplace.ru/soft/pixilang/index_ru.php Вот там точно можно творить всякие штуки с данными.
выглядит странно, и непонятно, то ли движок для демосцен или может тут можно делать полнофункциональные пиксельные игры (а вот тогда это круто)
но навсякий случай добавлю в избранное и погуглю) Спасибо!)
Похоже на библиотеку для создания музыкальных/звуковых программ (по списку внизу страницы и по тому, что это от разработчиков SunVox).
Можно сделать таблицу из значений, содержащих функции.
Мне кажется, что проблема этой игры как пародии в том, что непонятно, что она пародирует. Шутки про Ринго и соответствие названий с формой некоторых городов довольно забавные, но они никак не вяжутся с покемонами. То же самое и с механикой - вот это "всю дань вместе соберём" хороша разве что на словах, ведь дань - это не существо, и дань против дани не сражается, а мы не тренеры дани, а хотелось бы. Игра совершенно ничего не потеряла бы, будь она просто про собирающих деньги баскаков. Элементы пародии смотрятся здесь как пасхалки, но не суть игры.
Ну да, о чем я и написал. Только общий формат похож: ходим по разным городам в большой стране и "что-то" собираем.
Я все-таки думаю, что основная механика довольно прикольная, но много народа, вероятно, отсеивается при первоначальных поисках Руси.
Какие-то нонейм фильмы про жандармов, какие-то отсылки к англюсику, дань какая-то с битлами, монголы с покемонами. А мне казалось что отсылки всем надоели сразу после второго фолаута.
Это не "отсылки к англюсику", а двуязычные каламбуры.
>А мне казалось что отсылки всем надоели сразу после второго фолаута.
А я когда во второй играл, не знал, что это отсылки. Сам не очень их люблю (как и нарочитые анахронизмы), но для шуточной игры мне показалось нормально.