Календарь эвентов на Гамине 2024

Заполняем календарь с событиями на 2024 год:

даты
событие
статус
организаторы
анонс старт окончание
17/02 18/02 КОД 22 ✓ scorched
08/03 15/03 07/04 Гаминатор 27 ✓ Luca_Nia
05/05 13/05 24/06 Гамин-коллаб ✓ Ilya873
21/07 28/07 11/08 Конкурс симуляторов ✓ Ilya873
?/12 ? ??? ?

(версия на гугл-диске: https://docs.google.com/spreadsheets/d/1Xr3g7arNHLUg1s_pyXjTCigm4zAA8elZqg1lIL8qLEQ, кто хочет права на редактирование — напишите мне в личку, выдам)

Организаторы, пишите, что и когда хотите проводить. Если какие-то даты будут сдвигаться — это нормально. Календарь нужен чтобы хотя бы примерно представлять, когда и какие события планируются.

Также пишите, в каких еще событиях вы хотели бы поучаствовать — внесу в голосовалку.

Любые предложения (по абсолютно любому поводу) приветствуются.

  • Ил
  • 03 февраля 2024, 21:58
  • 0

Какие эвенты хотим? (помимо Гаминатора и КОДа):

Результаты
Empty Vote

Другие посты из этого блога

146 комментариев

Хм, а может как-то отмечать, какие события уже прошли? ̄ _(ツ)_/ ̄ Чтоб наглядно было!

Добавил в таблицу столбец "статус", а также ссылки для прошедших / текущих мероприятий.

Дофига народу проголосовало за коллаб-игру на годоте, а в календаре ничего нету. Проведите кто-нибудь...

image.png

А где текст "Делайте"!? Не канон!

Я не могу проводить, потому что хочу участвовать.

Но, возможно, понадобится лидер, который начнёт и сделает больше всех ^_^'

Для годот-коллаба еще надо подумать как объединять проекты. Вроде ниче сложного-то нет, но могут возникнуть казусы непредвиденные.

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

Кто-то должен заняться этим (не я, я еще плохо годот знаю).

Надо создать репозиторий в гитхаб и всем Гамином в разных ветках делать, а потом смержим)

Хочется от таких предложений назвать тебя "извергом", а человека кто это будет сливать "героем" =D

В Godot Engine можно сделать всё проще - через "пакеты, моды". Игра пакуется в один файл с расширением pck. Эти файлы можно загружать динамически. Т.е. формируется лаунчер, который запускает выбранный пакет (выбирается через интерфейс или при прохождении уровня сообщается о завершении, и загружается следующий пакет). От разработчика пакета нужен сам файл и настройками к нему (какую сцену запускать, как называется, опять же можно в виде файл указанного заранее формата), а лаунчер обрабатывает настройки и в нужный момент подгружает пакет.
Главное не забудьте использовать одну версию движка. )))

Сразу видно, что я не годотовец :))

Круто, что в годоте есть такой функционал! Тогда все действительно проще)

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

Я не предлагаю игровые механики (я вообще участвовать не планирую), я говорю о реализации интеграции всех проектов. Есть разные варианты объединения этого с точки зрения "игры":

  1. (Твоё предложение) Локация, перемещаясь по которой сталкиваешься с мини-играми. Тут надо организатору "оболочку" делать.
  2. Последовательность уровней: запустили первую игру, как только она заканчивается, запускается следующая.
  3. Список из "кусков". Выбирай любой, без автоматического запуска следующей (как указано в пункте 2), выходим в меню.

Тут как решит организатор и/или участники.

Вижу в этом недостаток - чтобы сделать эту коллаб-игру, нужно сделать несколько игр.

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

Но противоречий, в принципе, тоже нет. Если кто-то умеет сделать мини-игру, то её можно тоже прилепить к общей игре. :)

Единого представления ещё никто не установил. Но если так, то git и валерьянка в помощь...

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

Я видел такой формат: формируется группа разработчиков в некоторой последовательности.
Первый разработчик делает игру за ограниченное время и передает ее следующему, но следующий не знает (кроме организатора), что он получит.
Следующий разработчик дорабатывает игру, добавляет что-то свое, может убрать ненужное - полная свобода с полученной игрой (естественно в рамках солидарности не портить все, что делал предыдущий). Тоже за ограниченное время и передает ее следующему. И так, пока не достигнем последнего разработчика. После конца можно вскрыть дневники и узнать, кто что добавлял и с чем столкнулся.

(естественно в рамках солидарности не портить все, что делал предыдущий)

Вот это самое важное!

Вообще формат очень любопытный.Сто останется в результате от изначального варианта. (￢‿￢ )

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

Если можно будет участвовать, присылая от себя какие-то файлы — спрайты, анимации, мелодии, диалоги — то можно поучаствовать очень большому количеству людей, в том числе и без знания движка. Это звучит довольно жизнеутверждающе!

А это всё адекватно работать ведь будет, если внутри имена скриптов\сцен одинаковые? У меня эти вопросы были если к исходникам давать доступ, но если pck использовать, то вероятно там свой "контейнер" изолированный.

Но если такими уровнями-паками делать, то наверно это не так интересно, когда все изменяют друг у друга что-то (на ютубе даже видео по такому челленджу были, кажется)

Думаю, да. Честно, сам не пробовал, но это логично про "контейнер". А во-вторых, ты же не все пакеты будешь грузить сразу: один выгрузил, другой загрузил и т.п.

Но если такими уровнями-паками делать, то наверно это не так интересно, когда все изменяют друг у друга что-то (на ютубе даже видео по такому челленджу были, кажется)

Если делать совместно одну игру, то тут "одни правила", если что-то аналогичное Гамин-коллабу, то другие. Определится сначала с целью надо тогда.

А что с глобальными переменными и нодами? Как там это всё сочетается?

Я писал, что сам не пробовал. Минут 20 и всё уже можно опробовать и потестировать. Но если учесть, что в конкретный момент времени будет загружен пакет лаунчера и один пакет игры, то проблем нет.

Идея интересная. Но непонятно как ты будешь грузить .pck пакеты. Насколько мне известно каждый пакет жестко привязан к exe файлу. Привязка на уровне когда ты делаешь сборку проекта. То есть получается чтобы реализовать твою идею надо или иметь в gd скриптах возможность работы с разными .pck пакетами, либо менять что-то в самом движке (exe который работает с пакетом). По пакетам есть такая инфа - https://docs.godotengine.org/en/3.1/getting_started/workflow/export/exporting_pcks.html

Главный вопрос - ну вот ты загрузил .pck, а что будет дальше? Там в этом же доке есть инфа, но очень краткая. Из неё следует, что нужно знать структуру внутри .pck, какие там файлы сцен и прочее. Если это сторонний .pck то без этой инфы он бесполезен. И плюс насколько можно судить - работат эта нетривиальная. Поскольку даже в оф. мануале всего пара строк. Остальное нужно додумывать самостоятельно.

По итогу: твоя идея класс, но по факту ты её реализовать не сможешь. Потому что участвовать не собираешься. Конечно никто не запрещает решить вопрос. И если решишь будет круто и тогда идея станет реальностью. Хотя сомневаюсь, что это так просто. Нужно пробовать.

Намного проще, как тут предлагали выше иметь общий проект, в котором каждый делал бы какую-то часть. Тогда и не надо таких заморочек. Но конечно будут другие заморочки - организационные. Кто и что и как делает в проекте. yak ;)

Читал этот туториал и выделил для себя моменты:

Если кто-то хочет поддерживать моды для своей игры, им потребуется, чтобы их пользователи создавали файлы, экспортируемые аналогичным образом. Предполагая, что исходная игра ожидает определенной структуры ресурсов PCK и/или определенного интерфейса для своих скриптов, то либо...

  1. Разработчик должен опубликовать документацию по этим ожидаемым структурам/интерфейсам, ожидать, что моддеры установят Godot Engine, а затем также ожидать, что эти моддеры будут соответствовать заданному в документации API при создании мод-контента для игры (чтобы он работал). Затем пользователи будут использовать встроенные инструменты экспорта Godot для создания файла PCK, как описано выше.

  2. Разработчик использует Godot для создания GUI-инструмента для добавления в проект своего точного содержимого API. Этот инструмент Godot должен работать на сборке движка с поддержкой инструментов или иметь доступ к нему (распространяемому вместе с исходными файлами игры или, возможно, в них). Затем инструмент может использовать исполняемый файл Godot для экспорта PCK файла из командной строки с помощью OS.execute(). Сама игра не должна использовать инструментальную сборку движка (в целях безопасности), поэтому лучше держать инструмент для моддинга и игру отдельно.

И

По умолчанию, если вы импортируете файл с тем же путем/именем, что и файл, который уже есть в вашем проекте, импортированный файл заменит его. На это следует обратить внимание при создании DLC или модов. Вы можете решить эту проблему, используя инструмент, который изолирует моды в определенной подпапке модов. Однако это также способ создания патчей для собственной игры. PCK-файл такого типа может исправить содержимое ранее загруженного PCK.

Чтобы отказаться от этого поведения, передайте false в качестве второго аргумента функции ProjectSettings.load_resource_pack().

Выходит, что вроде можно сделать коллаб-игры в виде модов. Только стоит учесть пути к файлам (создать внутри каталога res:// каталог с названием игры, чтобы не перезаписать основу. Если я правильно все понял из прочитанного.

Идея интересная. Но непонятно как ты будешь грузить .pck пакеты. Насколько мне известно каждый пакет жестко привязан к exe файлу. Привязка на уровне когда ты делаешь сборку проекта.

Кому-то надо больше изучать движок... ВСЯ игра упаковывается в файл с расширением pck он никак не связан с исполняемым файлом. Есть в настройках сборки пункт Embed PCK, тогда пакет будет вшит в исполняемый файл (как это происходит в Love2D, например).
Движок компилируется в двух вариантах: с IDE и без ней. Первый вариант даёт нам полноценный инструмент, второй даёт на шаблон. Если запустить шаблон, без файла pck в той же папке (у него имя должно быть таким же как у исполняемого файла), то он выдаст ошибку. Скопируй туда файл любой игры и назови так же как исполняемый файл и запуститься игра. Тоже самое для версии с IDE, если рядом положить такой файл, он запуститься игра, а не редактор.

image.png

Поэтому игра никак не связанна с исполняемым файлов (по факту скомпилированным движком).

То есть получается чтобы реализовать твою идею надо или иметь в gd скриптах возможность работы с разными .pck пакетами, либо менять что-то в самом движке (exe который работает с пакетом). По пакетам есть такая инфа - https://docs.godotengine.org/en/3.1/getting_started/workflow/export/exporting_pcks.html

Главный вопрос - ну вот ты загрузил .pck, а что будет дальше? Там в этом же доке есть инфа, но очень краткая. Из неё следует, что нужно знать структуру внутри .pck, какие там файлы сцен и прочее. Если это сторонний .pck то без этой инфы он бесполезен. И плюс насколько можно судить - работат эта нетривиальная. Поскольку даже в оф. мануале всего пара строк. Остальное нужно додумывать самостоятельно.

Ничего переделывать не надо, именно на эту документацию я и скидывал ссылку ранее. Информации там достаточно.

func _your_function():
    # This could fail if, for example, mod.pck cannot be found.
    var success = ProjectSettings.load_resource_pack("res://mod.pck")

    if success:
        # Now one can use the assets as if they had them in the project from the start.
        var imported_scene = load("res://mod_scene.tscn")

Функция load что возвращает? Ответ: Resource. А что делается с таким типом? Теперь представь, что ты грузить этой функцией не из другого пакета, а просто из проекта (например, создаёшь врагов, карту, пули). Просто создаёшь экземпляр (imported_scene.instance()) и привязываешь его к любому узлу.
Кому-то проще писать и рассуждать, чем потратить 20 минут и попробовать.

Создаём "Игру 1", с простой сценой и скриптом:

image.pngimage.png

Создаём "Игру 2", но уже 3D сцена:

image.png

image.png

Создаём "Лаунчер":

image.png

extends Node2D

onready var layer_game_1: CanvasLayer = $layer_game_1
onready var layer_game_2: CanvasLayer = $layer_game_2
onready var layer_launch: CanvasLayer = $layer_launch

var game_1_instance
var game_2_instance

func load_game(pck_filename: String, scene_name: String) -> Resource:
	var success = ProjectSettings.load_resource_pack("res://"+pck_filename+".pck")

	if success:
		return load("res://"+ scene_name +".tscn")
	else:
		return null

func close_layer_game_1() -> void:
	layer_game_1.remove_child(game_1_instance)
	layer_launch.show()
#
func close_layer_game_2() -> void:
	layer_game_2.remove_child(game_2_instance)
	layer_launch.show()

func _on_bLoadGame1_pressed() -> void:
	var game_1 := load_game("game_1", "main")
	if game_1:
		layer_launch.hide()
		game_1_instance = game_1.instance()
		game_1_instance.connect('close_game', self, 'close_layer_game_1')
		layer_game_1.add_child(game_1_instance)


func _on_bLoadGame2_pressed() -> void:
	var game_2 := load_game("game_2", "main")
	if game_2:
		layer_launch.hide()
		game_2_instance = game_2.instance()
		game_2_instance.connect('close_game', self, 'close_layer_game_2')
		layer_game_2.add_child(game_2_instance)

Теперь игры выгружаем в виде пакетов и если хотите запускать "Лаунчер" из редактора, то копируем пакеты в корень проекта. Или после сборки в одну папку:

image.png

Ссылка на проекты: Launcher.zip

Всё. Экспериментируете, пробуйте. Разрабатывайте шаблон для модов и универсальные методы. Да, могут возникнуть проблемы с общими узлами, может и скриптами. Дольше текста столько писать, чем попробовать (реально 20 минут занимает)... Методы есть, а будете этим пользоваться или нет, ваши заботы, я указал на факт.

Я так понимаю, ты избежал повторения названия сцен main, каждый раз подгружая эти пакеты при нажатии кнопки и разгружая при закрытии (т.е. они исчезают при удалении экземпляра из res://)?

Да, избежал, но для наглядности. Будут ли проблемы? Возможно, надо пробовать. Я ведь в одну сцену гружу, а не переключаюсь через "менеджер сцен". В случае, одной сцены, проблемы могут быть, а случае перехода может и не будет.

Хотя я ошибся. Они не разгружаются, файл main.tscn просто перезаписывается каждый раз.

Все супер! Но есть одно но. Ты использовал маленькие проектики заранее известной структуры. Что будет если проекты будет немаленькие и в них какие-то особенности. Я конечно думаю, в теории может так все и получиться. Но на практике - боюсь что нет. Как минимум все должны будут использовать одну и ту же версию godot. Если будут разные - будут проблемы 100%. Как минимум структура проектов должна описываться по определенным правилам. Если будут делать кто как хочет и умеет - 100% возникнут какие-то проблемы.

По итогу - 20 минут ты проверял свою тестовую версию, в реале все чуть сложнее. Вот возьми реальные проекты сложные и большие, хотя бы свои и попробуй их так запускать. Если все будет работать без сучка без задоринки, тогда это будет иметь смысл. А пока все остается только теорией. Не более чем. yak :)

Большой или маленький проект смысла нет, потому что в своём проекте ты будешь вызывать свои сцены и скрипты, на лаунчер это влиять не будет, как и он на него. Запуск нужно стандартизировать, т.е. указать какую сцену запускать.

Моя цель не сделать за кого-то работу, а показать функционал движка, по пути пришлось объяснять как движок вообще работает. Без знаний, конечно, ничего не получится, а уж тем более основ. Ну, а если только сообщения писать, а не пытаться даже сделать, то...

Я вот чето подумала. Есть же OS.create_process() OS.execute() и т.п. То есть в принципе же можно запускать готовые игры из экзешников таким способом, только в них самих добавить загрузку корневой игры при выходе. И не надо будет никаких пакетов вскрывать 🤔

Это один из вариантов. Только причём тогда вообще Godot-коллаб? Так можно игру на любом движке запустить.

Я всё ещё не пойму, что у тут будет. Все делают одну игру по частям или набор игр... Я хотел лишь подсказать один из вариантов (да ещё и пример сделал). Я сторонний наблюдатель, так что развлекайтесь. =)

Вообще, я бы хотела хоррор-коллаб. Типа каждый пишет свою игру по тематике с какими-то общими особенностями и может ассетами, потом это объединяется всё одной оболочкой с менюшкой или с бродилкой внутри хаба.

И все это разумеется на Unity?

Ну вот способ с запуском удаленного экзешника позволил бы на чем угодно писать. Единственное что там иногда требуется доустанавливать какую-то фигню, или скажем у меня игры на анриал энгине вообще не запускаются, потому что драйвер видюхи старый. И вот ситуация, когда хаб запускается, а игра из него нет, - очень фиговая, потому что ломает погружение абсолютно.

Godot тоже не идеален в этом случае для всех. Например, Ил писал, что у него не работал мой проект (Windows сборка) на его машине.

Поэтому лучше всё равно на чем-то одном писать, чтобы железно либо запускалось, либо нет.

Сорян, но все зависит от окружения на машине пользователя. От тебя и твоей игры мало что зависит.

Например у юзера не установлен какой-то драйвер или вообще файлы directx. Это не проблема игры. И ты её никак не решишь своими силами. Максимум можно написать в readme.txt инструкцию что нужно игре. Но если юзер не захочет или не сможет - игра не будет работать не по твоей вине.

Блин, походу ты и есть тот самый мегаинформатик, да?

Вопросы к тебе:

Как минимум все должны будут использовать одну и ту же версию godot. Если будут разные - будут проблемы 100%.

А если делать общий проект, то не надо использовать одну и ту же версию движка?

Как минимум структура проектов должна описываться по определенным правилам.

При общем проекте таких требований нет?

Мне просто интересно, как ты представляешь такую организацию.

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

Все так.

В чём тогда аргументы?

Просто ты пишешь как будто все просто и реально за 20 минут можно интегрировать разные проекты. Сомневаюсь.

Я разве сказал, что всё можно сделать за 20 минут? Нет. Я сказал, что можно (и нужно) потратить 20 минут и попробовать как это работает. А не рассуждать "нетривиальность" задачи и плохой документации.

С неизвестной структурой, конечно, ничего не выйдет. Но тут вопрос о совместной работе и стандартизации, так что такой проблемы нет.

а потом смержим

Приключение на 20 минут, да?

Кстати могли бы протестировать такое в своём чате по годоту а то всё равно фигнёй маетесь там!

а то всё равно фигнёй маетесь там!

Да я, да мы да ууу! Ты чего вот не делаешь, а? Я уже сделал целых две игры: понг и арканоид!

Этот персонаж присоединится к вашему курсу молодого годотовца в следующем сезоне.

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

Сюжет: Безумный ИИ держит вас в плену. Прошло очень много времени с заточения и вы привыкли к ежедневным пыткам. Тогда ИИ придумывает новую игру. Он заставляет вас окунуться в различные симуляции (коллаб-игры), которые заставят испытать вас ужас, страх и страдание. Ему нравится смотреть, как вы реагируете. Сможете ли вы обмануть ИИ, найти баги (каждый разработчик мог оставить пасхалку, которой вы потом воспользуетесь в реальности, забрав ее из симуляции) в симуляциях и выбраться из плена?

Показать старые комментарии
Написать комментарий