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
Спасибо этой статье, освоил на троечку 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).
Можно сделать таблицу из значений, содержащих функции.