Буду готов после 17 марта. Сейчас к сожалению, не могу😕 Это я отметился, вдруг кто солидарен со мной будет.

Я бы поучаствовал

Чем дальше в будущее, тем больше оно неопределенно. Я проголосовал за 13-14, но так же готов отдать голос за 6-8.

Не уверен, буду ли участвовать, но если вдруг, то я за ближайшие дни.

PS: не забудьте рассылку сделать, если таки сообразите этот сабантуй... А то с такими моментальными объявлениями всё время кто-то в комментах жалеет, что не попал в нужное место и нужное время.

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

Есть инструментарий...

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

Это единственно правильно-верные слова. У "правильного" разработчика должен быть свой набор всяких заготовок, кусков кода/сниппетов и прочего. Так можно избавить себя от нытья на форумах, что плагин устарел, разработчик умер и прочих +100500 причин.

даже простое появление диалогового окна не так легко делается, я его неделю делал на юнити и GMS

в ГМС кстати его сделать проще. Но почему проще? Может сам движок проще, а может всё дело в опыте (или том и другом).

Отвечая заодно и на твоё сообщение, что "Так что лучше вообще всё самому делать", то да. Если это тебе необходимо и ты понимаешь в теории что хочешь создать этим.

Нужно набирать базу своих скриптов и "систем", даже от движка это не особо зависит (хотя какие-то могут иметь это встроенным, например, fade screen). А набивается такая база внезапно только из прототипов как минимум, а лучше из игр.

в ГМС кстати его сделать проще. Но почему проще? Может сам движок проще, а может всё дело в опыте (или том и другом).

У меня что-то похожее есть в GameMaker, но это всё ещё не достаточно просто как в Bitsy:

// Из другого объекта например посылаем функцию "хозяину" диалога, где хранятся ответы,
// у каждого из объектов NPC или меню свои ответы могут быть:
MyNPC.MakeAnswer("Hi");

// Есть функция в объекте, которая принимает ответы на диалог, например NPC или объект меню
function MakeAnswer(_name) {
	CloseMenu(1); // Закрываем старое меню или диалог
	switch(_name) {
		case "Hi":  Talk("Hello...",id,0,0,0); NextState = "Hi2"; break;
		case "Hi2": Talk("...and good bye!",id,0,0,0); break;
	}
}

// А если хочется больше текста написать,
// то при Update/Step проверяется если не открыты никакие меню, включая диалоги,
// то инициируется MakeAnswer ещё раз и разговор продолжается:
// Check Next State for StateMachine of Dialogue Menus
function CheckNextState() {
	if (NextState == "") exit;
	if (Game.Menu) exit; // Если игровое меню или диалог есть, то выходим отсюда
	var _next = NextState; // временная переменная, чтоб сразу обнулить NextState
	NextState = ""; // Обнуляем NextState навсякий случай, это продолжение разговора
	MakeAnswer( _next );
}

Тут также есть и выборы, просто в switch больше ответов сделать и вначале открыть меню с вариантами ответов и в зависимости от ответа посылать разные сигналы:

MyNPC.MakeAnswer(MyAnswer);

я хз,

в Годоте тоже этого нет, но наверное есть на всё плагины

Есть. Троечка хороших точно. Так что не звезди. Могу пруффы скинуть. Устареть они могут с выходом Godot 4.0, но даже в этом случае ветка 3.2 будет поддерживаться, как 2.6 сейчас. Если ошибаюсь, поправьте.

Fade скрин делается двумя нодами: texture_rect и tween + плюс скрипт с двумя функциями fade_in и fade_out. Проблемы вообще нет. Сохраняешь как сцену и потом используешь в других проектах. Проблема надумана и не стоит внимания. В сети решений полно. Скину пруфф, если нужно.

Давай вспоминай, готов поговорить конструктивно в части Godot.

я fade'ы делаю одной нодой, color rect, остальное кодом)

Можно вообще тупо кодом через draw. Просто tween здорово интерполирует ключевые кадры, при этом можно использовать различные функции и получать красивые эффекты... А для точного контроля, чтобы по времени еще, можно и AnimationPlayer использовать...

Вот мне в Годоте интересна функция draw, правда я замучаюсь одновременно копаться в 3-х движках, так что на Годот перейду, если полностью откажусь от Юньки, лол. Мне в Юнити не нравится, что нельзя рисовать напрямую через draw, без лишнего создания объекта просто для того чтобы лишний спрайт появился,
вот в GMS это вообще хорошо сделано, можно одним объектом сразу тонну спрайтов рисовать не создавая их в памяти как физические объекты, а просто отрисовывая как пиксели сразу на экране.

Устареть они могут с выходом Godot 4.0

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

но даже в этом случае ветка 3.2 будет поддерживаться, как 2.6 сейчас

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

А вывод какой? Писать все самому и тогда не нужно будет плакать и жаловаться...

что ты такое делаешь что без плагинов сторонних никак? системы диалогов вроде не такая уж и большая сложность чтоб самому не сделать...

Я хочу соединить: сильно упрощённый Maunt & Blade + Dragon Quest+Rune Factory+Monster Hunter+Добавить свою ролевую систему+Смену суток погоды и времени года+Beat'em'Up и это всё в 2d,

Система диалогов простая (недели 1-2 работы, если был уже опыт, а то в первый раз потратил на это месяц ибо не особо хорош в программировании), но тут много других систем, которых только предстоит сделать.

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

Куда уж лучше то???? За тебя движок точно делать игры не будет...

Для 2д игр, годот можно использовать ещё года 2-3 точно.
А 4 не будет отличаться прям кардинально, легче будет проапрейдиться если нужно будет что-то новое.
А вот Юнити за это время может поменять направление развития ещё 3 раза =D

я в принципе не призываю менять движок а предлагаю способ организации, чтоб было лучше чем бесконечные switch и if else как выше в комментах

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

Хотелось бы, конечно, Гаминатор, но сгодится и КОД.

Лично мне участвовать сейчас не охота, но джем проводите, почему бы и нет.