Подскажите пожалуйста уроки Годота! Где сразу всё основное игровое ядро в одном проекте:
1) глобальные переменные и глобальные функции доступные откуда угодно
2) игровая камера следящая за игроком и с границами уровня
3) перезагрузки/загрузки уровня (и затенения экрана при переходе с уровня на уровень)
4) выход в главное меню
5) игровой HUD
6) кнопки меню
7) меню паузы
+меньше строк кода для нуба
- 30 сентября 2019, 12:35
- 01
Кстати вот список изменений альфы 3.2, самое примечательное, что к новой системе визуальных шейдеров приложил руку наш соотечественник...
видел недавно, что появилась альфа) наверное ещё сырая, пока решил не качать)
все ещё гуглю уроки по годоту, нужны такие же простые как тот урок, что ты мне давал про собирание монеток, всё просто и в то же время чтобы много объёма информации было.
А ещё недавно список альтернативного кода на юнити писал, перехожу с JS на C#
и написал альтернативные часто используемые строки, такой бы список ещё бы собрать на Годот,
чтобы точно определиться переходить на юнити C# или забить и лучше перейти на Годот,
всё равно в обоих случаях придётся с нуля весь игровой движок перелопачивать:
это для чего?
Этот код он привел для меня, чтобы я очередной раз убедился в правильности выбора gdscript, а не эти все сишарпные страшные конструкции...
тут каждая строка это отдельный несвязанный код, как бы шпаргалка)
строки на JS с символом
//
, а остальные на C#Думаю потом такую же шпаргалку на Godot написать, например тот же SendMessage пока неизвестно
как в годоте записывается, но займусь этим позже.
Похоже на годотовские сигналы и слоты.
Я тоже люблю более простой язык типа Lua и вроде как GDscript похож немного.)
Однако во всех уроках, что мне попадаются по годоту, нет нормального примера менеджера уровней, чтобы была большая группа уровней, но не привязывая к кнопке переход на уровень, мне нужны переходы в духе Fallout 1-2 или старых ролевых игр, где может быть несколько переходов между собой.
PS то есть мне нужно понять как и где хранить большое количество уровней, чтобы всегда был доступ к ним,
ну и плюс было бы неплохо на плавную перезагрузку уровня посмотреть, с затенением экрана или чего-то в подобном духе, а то почти во всех примерах уровень один единственный, это не очень хорошо
Их не обязательно хранить. Есть функция preload, подгружаешь карту/сцену/уровень и в нужный момент подсовываешь ее. Если говорить о перезагрузке, то это всего лишь одна единственная функция, которая перезагружает текущую активную сцену. Затенение экрана, ну это вообще проще пареной репы - либо используешь аниматионплеер, либо твин и манипулируешь альфаканалом ноды texturerect. У ютубера PIGDEV по этому поводу что-то есть, за прошлый год.
Вроде preload только константных имён (то есть понадобится написать по строке кода на каждый уровень)? =)
load использовать
Смысл то понятен ведь. Можно заморочиться и использовать ResourceLoader и ResourceSaver
Предлагаешь Алексу написать загрузчик уровней на C++?
Предлагаю воспользоваться документацией к данному движку...
Упс, перепутал с ResourceFormatLoader.
лол, сверху ещё надо С++ изучать?)
Ну если у тебя сетка из уровней, то и сделай, например, массив массивов (по аналогии с сеткой) и туда складывай.
Или ты имеешь в виду в каком формате уровней тебе лучше их дизайнить?
ну вот например в юнити Application.loadLevel операция загружает уровень из заранее прописанного уровня,
я так понял в Годоте некуда заранее прописывать уровни и нужно самому эти библиотеки составлять,
так вот как делать такие библиотеки
Можно по имени переключать, положи их в одну директорию, и делай get_tree().change_scene("res://path/to/scene.tscn"), где путь склеиваешь из постоянной директории и переменного названия уровня.
Вот ещё какой-то пример есть для посложнее, но это к Антонке, наверное, мне такое не пригождалось ещё.
Спасибо) может так даже можно инвентарь и например кастомизацию сделать, точнее их Базы Данных
инвентарь и подобные ему вещи делаются через Dictionary (это как я у людей видел).
а Dictionary легко показать в инспекторе, чтоб редактировать яйчейки? а то в юнити это либо очень сложно, либо нереально для меня)
конкретно про инвентарь лучше искать на ютубе, а если конкретно про Dictionary то в инспекторе редактировать только ключи...
Для инспектора переменную надо пометить в скрипте как export, а в самом инспекторе там немного муторно, да - выбираешь тип ключа, пишешь чему равно, потом выбираешь тип значения, пишешь чему равно и нажимаешь добавить (и так для каждого элемента, по ходу).
Это для юнити, чтоб C# учить, я с 2012-го всё время писал на JS, а в 2017-м JS отменили, и я только недавно решил переучиваться. Часто используемые строки на C# написал, чтоб потом все свои скрипты постепенно переписать, заглядывая в эту шпаргалку, чтоб побыстрее было.
автозаполнения тебе не хватает?
у тебя есть проекты с 2012 года которые стоит поддерживать?
Автозаполнение не работает на Notepad++, Visual Studio слишком долго открывается и не хочу этим пользоваться из-за этого, а в Visual Studio Code не могу настроить правильно чтоб открывался весь юнити проект, чтобы и строку ошибки показывал и заполнение было, хз в чём проблема.
Пилю долгострой, постепенно наращивая материал с 2012-го года, точнее ядро проекта начал пилить тогда. Но чтобы с нуля новый чистый проект написать, мне немного сложно с ходу около 10 скриптов с 5000 строк в среднем придётся написать + 20 скриптов по 100-300 строк + мелочь. Я постепенно это буду делать, по чуть-чуть, убирая ненужное, переписывая с JS на C#.
Я не особо силён в алгоритмы, как художник я бы вообще с радостью бы не трогал сложное программирование,
только бы уровневые скрипты писал, если б кто-то за меня код ядра игры написал, но иначе никак без денег приходится самому пилить и учиться непрофильным вещам.
Вроде был ещё глюкавый форк monodevelop раньше, или его уже упразднили в пользу vs и vsc?
чойто он глюкавый?
То панель отвалится, то проект раздвоится...
У меня такого не было, но медленно открывался файл, целых 3-5 секунд, я за это время забывал что хотел написать в коде, лол :D, а в notepad++ мгновенно открывалось и выбрал его вместо monodevelop, чтоб мгновенно правки делать.
Просто с 2012 (начиная с "Человек на луне" конкурс на гамине) по 2017-го год, участвуя в разных конкурсах, я постепенно наращивал разные скрипты, меняя обёртку проекта, но оставляя и усложняя ядро проекта.
Добавил кастомизацию персонажей, инвентарь, перки, ачивки, интерактивные предметы,
свой мини псевдо язык чтоб на уровнях быстро код писать без компиляции, транспорт и его кастомизацию,
оружие и экипировка, различные жидкости типа болота и воды чтоб в них можно было тонуть,
смену погоды и дня и ночи, AI врагов и средненькую боёвку, карту мира и систему переходов на локациях.
И всё это было как назло на JS, а потом юнити внезапно говорит: "Мы перестаём поддерживать Java Script!")
Шикарно! Я как раз хотел забить на все свои наработки!
Хотя это всё было топорно, но зато своё родное, и придётся много времени потратить, чтобы всё это переписать.
Пытаюсь придумать как упростить эту задачу, типа такой шпаргалки, а автозаполнением я никогда
не пользовался, и скорее с непривычки больше буду тупить. Да и не могу настроить ни один редактор на автозаполнение, чтоб работал в юнити, а медленный Visual Studio мне и даром не нужен, он только открывается на моём ноуте около 30-60 секунд, а notepad++ за секунду.
Либо второй вариант, забить на юнити и перейти на годот, я пока не решил)
хмм, но ведь открыть студию надо всего один раз за день. И целый день пользоваться удобствами современной IDE. И возможностью запускать скрипт тут же, через две секунды компиляции. Это, конеш, твое дело совершенно, но ведь ты все равно открываешь скрипты через студию чтобы добавить туда код или отсмотреть ошибки, не?
Ну просто я открыл, поработал, потом закрыл всё, ушёл, опять прихожу поработать, а открывать придётся заново долго, как-то это неприятный оттенок оставляет, не могу описать, почему мне так не комфортно, отчего редактор текстовых файлов так долго открывается, ведь текстовые файлы должны мгновенно открываться.
Ну перестанет поддерживать и что с того, тебе же сейчас в данном виде движок подходит? Некоторые до сих пор юзают ветку Godot 2.1, которая кстати этим летом обновилась...
Ну тут я пока про юнити говорил) В Годоте пока не делал долгострой, обидно будет, если и там потом что-то отменят, если опять "повезёт" выбрать не правильное решение)
Например хотелось бы точно быть уверенным, что в годоте потом не откажутся от GDScript,
как в юнити от UnityScript отказались, ибо хочется то новыми версиями пользоваться, там ведь могут сделать новые прикольные фишки в редакторе, которые будут недоступны в старых версиях.
А я медленно код пишу, за это время может многое измениться.
И я тебе про юнити говорю. Тебе же не обязательно последнюю версию качать?
В новой юньке сделали вложенные префабы, это просто крутая фича,
то есть как в годоте стало, префабы стали как ноды, могут вкладываться друг в друга.
Ну и другие фичи для 2д добавляют постепенно.
А в моей старой версии этого нет, я решил постепенно на C# шарп переучиваться,
чтоб долгострой свой переписать.
они с каждой новой версией умудряются столько крутых фич присобачить, что непереходить практически невозможно
Я понимаю твои "муки выбора", но если оглядеться, то вокруг множество людей делают игры и на Годо, и на Юнити, и на чем угодно - вроде им что-то удаётся, значит опасения, возможно, преувеличены. Есть игры практически на любом движке из существующих, так что это говорит о том, что хотя бы одну игру точно можно сделать)
Ты тут периодически скидываешь всякие свои наработки - они очень достойно выглядят. Причем по уровню это не поделки, а реально солидные штуки (к примеру даже по гифкам с понями это видно). Так что я думаю, что надо просто брать и делать. Даже если какой-то из движков прекратят поддерживать - можно доделать проект, а следующий начать на другом, к примеру. Я так думаю.
Согласен, по-моему, у Алекса характерный для начинающих программистов глюк "я открыл, что есть новый вид рефакторинга (языка, движка), пойду всё отрефакторю (оближу, подвину)".
Мне кстати очень хочется с нуля ядро игры переписать, я недавно придумал как сделать лучше основу ядра, но там совершенно иной способ работы, и получается придётся забить на старые наработки.
Меня терзают такие вопросы:
1) остаться на старой версии с JS и своими скриптами, или писать по новой на C#?
2) перейти на годот или остаться на юнити, если решил переписывать движок?!
3) GDScript будет ли поддерживаться через 5-7 лет в годоте? если решил перейти на годот
+ какие там ещё подводные камни есть?
4) Если остаться на юнити и перейти на C#, стоит ли оставить структуру прошлого ядра игры не меняя ничего кардинально, или взять и на основе своего нового опыта переписать вообще всё с нуля, и это намного дольше?!
голова едет кругом от неопределённости :D
А почему 5-7 лет? Может через 5-7 лет сменится не одно поколение железа и софта, кто знает. Вообще может всё тотально поменяется. Я думаю, что раз ты сейчас делаешь проект, и много чего сделано, и оно вроде ок - то почему его не закончить на нынешнем движке?
А по поводу подводных камней - посмотреть что за игры делают на движке, и если функционал этих игр схож с функционалом твоих игр - то какая разница какие, если решения есть.
ну я просто хочу стабильности)
То есть написать сложное ядро игры (у меня это всегда идёт медленно),
и после этого не трогая его и только меняя обёртку пилить разные игры долгое время
на этом ядре, как с Битси или Аксмой где только добавляешь контент не трогая ядро проекта.
В идеале мне бы какой-нибудь конструктор,
где всё уже готово и плавные переходы уровней и прочее,
вставляй только свои арты, уровни и интерактив.
Ну вот ты же сам видишь, что нынче творится. Другой стабильности не завезли) И не предвидится. Только свой движок. Да и то - кто знает, что с железом сделают через N лет.
Просто мне кажется, что на все размышления может времени и сил уйти больше, чем на фактическое написание этих всех тобою описанных штук, и даже на их переделку на другом движке/языке и так далее. Я сам когда выбирал язык для своих наколеночных поделок, то думал в чем же делать, хотя в итоге понял, что нужно было взять ЧТО-ТО, что хоть кто-то пользует - и делать. Проблемы они в другом крылись, как правило. Всё равно в ходе "эксплуатации" движка только станет понятно, как оно на самом деле.
Впрочем, наверно на большой проект этот опыт экстраполировать было бы неверно.
По поводу конструкторов - в Юнити же, вроде как, есть всякие "надстройки", которые существенно упрощают процесс разработки типовых игр. Не помню названий, ибо не пользую Юнити. Точно было для "квестов" готовое решение, к примеру. Ну и так далее.
Правда Список требований к ядру игры у меня большой, чтобы уже все скрипты и механики были готовы, это всё постепенно добавляю в свой долгострой:
1) путешествие по карте мира, с возможностью плавать в воде на лодке или своим ходом
2) случайные встречи на карте, с заранее видимыми фигурками, враги или торговцы например
3) инвентарь в меню, по типу Зельды или Beyond Oasis, можно выбросить, съесть, сильно ограниченное количество слотов
4) продажа и покупка вещей, крафтинг, алхимия и готовка, рецепты
5) диалоговая система с возможностью видеть лицо персонажа, его имени, и с выбором
6) транспорт и его кастомизация (летающий, плавающий, сухопутный, подводный)
7) возможность подбирать и швырять предметы типа вазы, ящика, бочки как в Зельде
8) экипировка оружия (в моём текущем ядре я только не успел лук и бумеранг сделать)
9) покупка, смена и хранение одежды в отдельном шкафу по типу GTA
10) смена причёски, смена части тела, цвет глаз, уши, хвост, разная кастомизация героя
11) свой дом и компаньоны живущие в этом доме (только наполовину реализовал на JS)
12) компаньоны могут помогать в бою (это я пока ещё не реализовал на JS Unity)
13) смена времени суток, праздники в особые дни и украшения в городах, смена погоды
14) смена времён года (не реализовал пока)
15) расписание неписей, закрытие магазинов по ночам, система сна и ожидания времени (пока криво у меня на старом движке работает)
16) плавная перезагрузка между уровнями, показ карты и текущей локации в паузе
17) сдаться в плен или после гибели переместиться в особое место, если убили пауки,
то очнуться в паутине, если погиб упав в пропасть, то очнулся в аду или бездне,
можно прописывать свои ситуации как угодно скриптами, я назвал эту переменную DeadLevel,
загрузка уровня если убивает конкретный непись или опасность
18) перекладывание инвентаря в ящики для хранения (у меня пока там очень криво всё)
19) смена уровней сложности, прокачка
В текущей сборке у меня где-то 100-150 скриптов, но я подумал, что если почистить хорошо,
можно оставить где-то около 40-50, если переписать сначала всё, но это так долго(
Вот бы найти сразу готовый конструктор, который всё это сразу умеет с полпинка)
эти фичи делаются для тебя или для игроков?
для игроков, кто хотел бы смесь Rune Factory, Zelda, Metroid в одну кучу, я ещё не уверен, может быть таких игроков единицы) но всегда хотелось смешать всё что нравится в разных играх в один проект
мне как игроку большая часть не нужна, остальная часть непонятно как повлияет на мой опыт.
Допустим "случайные встречи на карте, с заранее видимыми фигурками" - это понятно, это работает
"возможность подбирать и швырять предметы" - а для чего? Это должен быть элемент игровой механики. как самостоятельная фича - сомнительно.
"покупка, смена и хранение одежды в отдельном шкафу по типу GTA" - безотносительно экономики, заработка, траты денег и всяческих статов - лишняя ненужная вешщь
"смена времён года" - просто начерта вообще?
То есть весь список смотрится как набигающие домики. Будто у тебя нет цельного плана, драматургии геймплея, видения основных долгосрочных механик развлечения игрока, а есть просто подсмотренный список красивостей. Либо опциональных, декоративных типа "плавная перезагрузка между уровнями, показ карты и текущей локации в паузе" которые, конечно, стоит выкинуть если они сберегут хотя бы пару недель разработки. Либо критически важных, основных, от которых можно рассчитывать необходимость или ненужность вообще всех остальных элементов. Но при этом совершенно непродуманных. Типа "смена уровней сложности, прокачка". Либо просто противоречивых саих по себе: "случайные встречи на карте, с заранее видимыми фигурками"
Я не разработчик, не могу указывать что правильно что нет. Но с точки зрения болтуна-игрока все эти вещи не стоят >семи лет разработки. И чем быстрее ты избавишься от всего этого балласта, и спроектируешь маленькую вещь, которую сможешь таки реализовать за конечное время - тем лучше. Начни с критических нужд игрока, а красивости добавишь когда игра будет практически готова.
если те интересно, могу как игрок отметить те вещи которые не считаю хоть сколько то ценными в играх, и которые считаю сильно опциональными
В целом соглашусь, главное ключевая фича.
Но я всегда хотел создать свой мир с блекджеком и прочими прелестями в игре.
Смена погоды и смена сезонов мне ещё нравилось с Rune Factory и Harvest Moon, и хотелось бы это лицезреть в Скайриме например, хотя конечно это реально спорная фича, так как целевого смысла у ней мало, скорее просто добавить немного "романтики", "души" или новых оттенков проекту
ну тут вначале случайно генерируются на карте фигурки рядом с героем, и если замедлил ход, то можешь выбрать встречаться или обойти, как бы и случайная встреча и не случайная, если не переть напролом по карте мира)
Фишка по части смены одежды, это тоже для души, как бы кастомизация, есть часть аудитории, которые не принимают игры, где нет кастомизации. Хотя её практическое применение тоже минимальное. Но так сложно отказаться от этой фичи.
"я всегда хотел" вот собсно и оно :)
но это инди, тут такой поход - святое
Это да!)
Короче хочу создать смесь Rings of Power, Zelda, Beyond Oasis, Metroid и TES, но не GTA, мне не обязательно чтобы транспортом владел кто-то помимо меня, мне хватит только своего транспорта.
И вместо открытого мира мне достаточно классической карты как в Mount n Blade или JRPG с большими фигурками и условным видом, но чтобы вода была не "стенкой", а можно было спокойно там поплавать или даже утонуть.
Жаль что на все эти механики нужно много времени потратить.
ДаркДес!
пока пилю на старом движке юнити, но вдруг там какие-то критические баги, а версия больше не исправляется, я так "удачно" попал между версиями, которую не обновляют в юнити,
обновляют версию 2017 и 2019-ую, а в версии 2018.2 последний раз была поддержка JS,
вот я на ней и застрял) назад не откатишь, все префабы сломаются, вперёд не откатишь
нужен C#, и переписать все скрипты на новый язык
Ты же делаешь 5 игр, не обязательно переносить их все. И не обязательно их все разрабатывать 5-7 лет. И, наверное, не везде нужна одинаково большая часть от твоего готового ядра.
пока только 2 проекта делаю, я хотел допилить движок и потом на нём до 5-6 игр состряпать)
но повезёт, если хотя бы 1-2 проекта соберу с такими темпами)
Хотел в разных сеттингах игры сделать и посмотреть понравится ли кому что-то из этого:
1) готика, ужасы и безумие
2) эротика
3) космическая тематика
4) мир боевых единоборств и магии с летающими островами, кораблями и фениксами
5) мир фурри, тупо сеттинг Зверотопии или около того
6) ну я хотел бы про поней сделать RPG в духе TES и Зельды
но на всё нужно время, жаль что нет конструктора сложных игр)
придётся отказываться от большей части идей
А ты скетчи нарисуй для всех вариантов сеттинга и собери фидбек. Глядишь, половина вариантов и отвалится ("блин, снова ужасы", "не клёвый у тебя, Алекс, космос", "единоборства слишком неправдоподобные, художника на мыло").