Подскажите уроки Годота! Где сразу всё

Подскажите пожалуйста уроки Годота! Где сразу всё основное игровое ядро в одном проекте:
1) глобальные переменные и глобальные функции доступные откуда угодно
2) игровая камера следящая за игроком и с границами уровня
3) перезагрузки/загрузки уровня (и затенения экрана при переходе с уровня на уровень)
4) выход в главное меню
5) игровой HUD
6) кнопки меню
7) меню паузы
+меньше строк кода для нуба

alexsilent
30 сентября 2019, 12:35
0
1

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

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

По сути, это просто джентльменский набор, который должен быть сразу готов в нормальном конструкторе, чтобы не париться художнику или слабому программисту, но редко какой движок предоставляет упрощённую такую структуру, которая нужна для 95% игровых проектов. А жаль, получается что мы вместо того, чтобы заниматься разработкой игры, вначале долго создаём благоприятную среду для того чтобы подготовиться к разработке игры, и только после этого начинаем делать игру. Из-за этого хочется плюнуть и пересесть на какой-нибудь простой конструктор, где уже готовы многие моменты, тот же самый плавный визуальный переход/затенение при загрузке уровня или границы уровня за которые камера не выйдет.

Вроде в годо все это есть.

Это хорошо, не знал, поищу инфу, а в юнити приходилось своими руками создавать

Годо в разы проще юнити. Я его плохо знаю, так тыкал немного но:
1 - Есть глобальные скрипты, можно данные там хранить, можно часто используемые функции хранить.
2 - в сандартной камере есть большинство настроек вроде
3 - затенение как и в юнити думаю анимациями можно сделать =)
4 - переход по сценам вообще там лёгкое занятие
Вообще там меньше кода нужно чем в юнити. Но само удобство редактора такое себе после юнити...

Можно пройти туториал "your first game" на сайте, чтобы понять основы. Дальше смотреть на примерах, их много есть, при запуске годота можно загрузить.

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

Например у меня такие вопросы:
1) нормально ли если добавлять много глобальных переменных и функций в скрипте автозагрузки?
прям сотни или даже тысячи функций и переменных или лучше разбить на несколько автозагрузочных скриптов? (+ плюс как потом эти глобальные переменные сохранять и туда сюда манипулировать данными при загрузки и сохранении)
2) автозагрузка включается раньше всех скриптов? или надо где-то указывать порядок запуска скриптов, в юнити всегда возникала проблема какой скрипт запустится первый, из-за этого было сотни багов у меня,
потому-что скрипты в хаотичном порядке запускались
3) нужна ли вторая камера для HUD? в юнити очень нужна, чтоб косяков не было
4) как сделать большую библиотеку предметов? чтобы из любого уровня всегда можно было создать любой предмет, например вещи в меню
5) как сделать простой fade эффект во время перезагрузки уровня? нужна ли вторая камера для этого?
ну думаю это можно нагуглить, но бывают более специфичные вопросы, которые сложно набрать в гугле)

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

1. Да, это нормально, но для удобства можно разбить на несколько файлов. Туда, суда манипулировать можно при прямом обращении к ним. Автозагрузка - это просто область, с переменными, функциями, которая загружается первой, с запуском приложения, и все ее содержимое доступно из любой точки проекта. У проекта есть еще свое глобальное хранилище, содержимое которого мы также можем использовать, а получить доступ к нему можно используя ProjectSettings.get_setting(name), где name - это имя требуемого параметра. Вообще в версии 3.2 столько всего будет нового, что это просто небо и земля по сравнению с версией 3.1, а в четвертой воопче Vulkan буит, так что стоит глянуть...
3.Вторая камера для HUD не нужна, там есть нода CanvasLayer, которая всегда становится сверху! Эта же нода имеет параметр SCALE, чтобы можно было масштабировать ее как угодно. Я не видел проекты, чтобы использовались две камеры, но читал вопросы на reddit, и не понял для чего может пригодятся вторая камера (касательно 2D проектов).
5. FADE в большинстве случаев это просто маска: текстура или спрайт, который меняет альфа канал (modulate). и нафига тебе камеры? ты же не парнуху снимаешь с разных ракурсов. Это если ты, делаешь игру а-ля Резидент Эвил для PS, то тут уж сам бог рекомендовал камеры юзать.

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

для 2д тоже применение нашлось бы.

Вопрос! КАКОЕ? =D Единственное, что приходит в голову - отображение 3D объекта в 2D мире.

то есть в принципе можно худ и таким образом сделать

зачем? этот велосипед ещё завести нужно будет ведь...

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

4. Хорошая статья по поводу добавления и удаления сущностей: http://gamedevdad.net/post/2018/12/godot-ecs-project/

Но это же целый подход! Для библиотеки предметов сгодится класс Resource (аналог ScriptableObject в Unity).

Спасибо) Буду разбираться!

ГОДОТ - это набор сцен управляемый скриптами. Есть сцена fade, сцена HUD и т.п. Имея эти сцены (читай модули) ты словно играешь в конструктор лего - захотел поставил модуль, захотел убрал его и т.п. Тебе нужно сначала создать, по урокам, простую игру, прям очень простую из серии "your first game" и только после этого, ты сразу поймешь, как добавить фэйд и другие приблуды для твоей игры. Вот как создашь простую игру, так сразу поймешь что к чему и что тебе нужно в данный момент, а сейчас ты хочешь полететь в космос, но не знаешь как управлять космическим кораблем…

Ты не думал пойти работать евангелистом? :)

Не берут...

Stravaganza.ru + смотри исходники моего с @anim86 проекта на прошлый Громинатор. Там все хорошо комментировал. С глобальными переменными все просто: создаешь скрип (_G.gd), объявляешь все, что нужно, в настройках проекта кидаешь его в автозагрузку и из любого места пишешь: _G.моя_переменная

А вообще самые хорошие уроки - это документация. Я серьезно. Потому как структуру, ядро игры ты реализуешь сам, именно так, как тебе удобно, поэтому здесь четкого шаблона. Я например глобальные переменные не использую, а вместо этого пользуюсь классами и сигналами.

вот например:

jRPG: проект, а уроки платно
казуальная RPG: проект, уроки
шмап: проект, урок
платформер: уроки, а проект платно

GDQuest крутой
У него еще в активной разработке платформер https://github.com/GDquest/godot-platformer-2d

Официальная документация же
https://docs.godotengine.org/en/3.1/getting_started/step_by_step/your_first_game.html

А еще я у себя в закладках это нашел: http://www.informit.com/store/godot-engine-game-development-in-24-hours-sams-teach-9780134835099 - книга от одного из создателей движка
http://kidscancode.org/godot_recipes/2d/ - рецепты разных штук

Кстати вот список изменений альфы 3.2, самое примечательное, что к новой системе визуальных шейдеров приложил руку наш соотечественник...

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

А ещё недавно список альтернативного кода на юнити писал, перехожу с JS на C#
и написал альтернативные часто используемые строки, такой бы список ещё бы собрать на Годот,
чтобы точно определиться переходить на юнити C# или забить и лучше перейти на Годот,
всё равно в обоих случаях придётся с нуля весь игровой движок перелопачивать:

// SYSTEM / SPECIAL OPERATORS
	//@TextArea (5,20)
		[TextArea(5,20)]
	//@Range (1,20)
		[Range(1,20)]
	//@Header ("Main Options")
		[Header("Health Settings")]
	//@HideInInspector
		[HideInInspector]
	//@script ExecuteInEditMode()
		[ExecuteInEditMode]
	//@ContextMenuItem ("Female", "SetFemale")
		[ContextMenu("Female", "SetFemale")]
	//if (Application.isPlaying) {}
		if (Application.isPlaying) {}
	//RequireComponent
		[RequireComponent(typeof(Rigidbody))]
		
// VARIABLES, STRINGS, CLASSES, LOOP, FUNCTIONS
	//var Code : String = "";
		string Code = "";
	//class Codes {var Word : String[];}
		[System.Serializable]
		public class Codes {public String[] Word;}
	//static var GlobalInt : int[] = new int[10];
		static int[] GlobalInt = new int[10];
	//var words : String[] = Code.Split("\n"[0]);
		public string[] words = "asasaddsf".Split("a"[0]);
	//words2 = words2.Replace("\t", ""); // remove TAB char
		public string words2 = "asasaddsf".Replace("a"," OK ");
	//if (words2.IndexOf("$") > -1) {}
		if (words2.IndexOf("$") > -1) {}
	//for (var a : int = 0; a < words.length; a++) {
		for (int a = 0; a < words.Length; a++) {}
	//for (var a : int = words.length - 1; a >= 0; a--)  {
		for (int a = words.Length - 1; a >= 0; a--) {}
	//for (var n : int in list) {}
		foreach(int n in list) {print("n: "+n);}
	//Random.Range(-5,5);
		Random.Range(-5,5)
	//function GrabFloat(name : String) : float {}
		float GrabFloat(string name) {}
	//SendMessage("MyAwake", null, SendMessageOptions.DontRequireReceiver)
		SendMessage("MyAwake", null, SendMessageOptions.DontRequireReceiver);
	//BroadcastMessage("Rename",Text,SendMessageOptions.DontRequireReceiver);
		BroadcastMessage("MyAwake",null,SendMessageOptions.DontRequireReceiver);
	//switch (Global.DAYS%7) {}
		switch (DAYS%3) {
			case 0: print("DAYS: "+"first");break;
			case 1: print("DAYS: "+"second");break;
			default: print("DAYS: "+"other");break;
		}
		
// GAME OBJECTS, TRANSFORM
	//transform.position.x += 1;
		transform.position += new Vector3(2,2,0);
	//var Last : GameObject = Instantiate(obj,Vector3(0,0,3.5),Quaternion.identity) as GameObject;
		GameObject Last = Instantiate(obj,new Vector3(0,0,3.5f),Quaternion.identity);
	//Last.transform.parent = transform;
		Last.transform.parent = transform;
	//Last.transform.localPosition = Vector3(0,0,3.5);
		Last.transform.localPosition = new Vector3(0,0,3.5f);
	// var t : Transform = obj.transform.Find("Item");
		Transform t = obj.transform.Find("Item");
	//DestroyImmediate(gameObject);
		DestroyImmediate(gameObject);
	//DontDestroyOnLoad(gameObject);
		DontDestroyOnLoad(gameObject);
		
// COMPONENTS
	//@script AddComponentMenu ("Alex Code/Scripter v2")
		[AddComponentMenu("Alex Code/Scripter v3")]
	//var ase : AudioSource = obj.AddComponent.<AudioSource>();
		AudioSource ase = obj.AddComponent(typeof(AudioSource)) as AudioSource;
	//GetComponent.<SpriteRenderer>()
		SpriteRenderer rend = GetComponent<SpriteRenderer>();
	/*var trs : Component[] = ImageDraw.GetComponentsInChildren (Transform);
	for (var tr : Transform in trs) {tr.gameObject.layer = 5;}*/
		Component[] trs = transform.GetComponentsInChildren<Transform>();
		foreach (Transform tr in trs) {
			tr.gameObject.layer = 5;
		}
		
// LEVELS, SCENES
	//Application.LoadLevel("level");
		using UnityEngine.SceneManagement;
		SceneManager.LoadScene("level");
	//Application.loadedLevelName
		SceneManager.GetActiveScene().name
		///////
		Scene scene = SceneManager.GetActiveScene();
		Debug.Log("Active Scene is '" + scene.name + "'.");
		
// ARRAYS (STATIC, LIST, DICTIONARY)
	//Static Array Init
		public int[] array = new int[5];
	//Static Array Get
		array[0] = 10;
	//Static Array Init
		public int[] Array;
	//Static Array Length
		array.Length()
	//List Init
		public List<int> list = new List<int>();
	//List Add
		list.Add(10);
	//List Remove
		list.RemoveAt(0);
	//List Push
		list.Insert(0,7); // push first position
	//List Clear
		list.Clear();
	//List Length
		list.Count
	//Dictionary Init
		public Dictionary<string,int> dict = new Dictionary<string,int>();
	//Dictionary Add
		dict.Add("hi1", 11);
	//Dictionary Get
		dict["hi1"]
	//Dictionary Remove
		dict.Remove("hi1");
	//Dictionary Clear
		dict.Clear();
	//Dictionary Length
		dict.Count

это для чего?

Этот код он привел для меня, чтобы я очередной раз убедился в правильности выбора gdscript, а не эти все сишарпные страшные конструкции...

тут каждая строка это отдельный несвязанный код, как бы шпаргалка)

строки на JS с символом // , а остальные на C#

Думаю потом такую же шпаргалку на Godot написать, например тот же SendMessage пока неизвестно
как в годоте записывается, но займусь этим позже.

например тот же 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 и Зельды

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

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

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

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