Документация Melonity

Написание хороших скриптов ​

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

Это не абстрактные правила TypeScript. Это рекомендации, основанные на реальном рабочем процессе написания сценариев Melonity.

Храните логику сценария внутри пространства имен ​

Не распыляйте логику сценария по глобальной области действия сценария. Храните переменные, помощники и callbacks внутри выделенного пространства имен.

Если другому скрипту действительно нужен доступ к части вашей логики, экспортируйте только то, что должно быть общедоступным.

Хороший
тс
позволять MyScript: ScriptDescription = {};

пространство имен мойскрипт {
	позволять включено = ЛОЖЬ;

	экспорт функция IsEnabled(): логическое значение {
		возвращаться включено;
	}

	МойСкрипт.OnScriptLoad = () => {
		включено = истинный;
	};

	RegisterScript(МойСкрипт, 'Пример');
}
Избегать
тс
позволять MyScript: ScriptDescription = {};
позволять включено = ЛОЖЬ;

функция isEnabled(): логическое значение {
	возвращаться включено;
}

МойСкрипт.OnScriptLoad = () => {
	включено = истинный;
};

RegisterScript(МойСкрипт, 'Пример');

Сохраняйте состояние menu простым ​

Избегайте разделения одной части состояния на несколько переменных, когда достаточно одного четкого значения.

Хороший
тс
позволять включено = Menu.AddToggle(PATH, 'Давать возможность', ЛОЖЬ)
	.OnChange(состояние => {
		включено = состояние.новое значение;
	})
	.GetValue();
Избегать
тс
позволять включено = Menu.AddToggle(PATH, 'Давать возможность', ЛОЖЬ)
	.OnChange(состояние => {
		включенное значение = состояние.новое значение;
	});

позволять включенное значение = включено.GetValue();

В первой версии состояние сценария легко читается. Вторая версия работает, но усложняет понимание логики.

Совет

Если вам нужен и объект опции menu, и текущее значение, используйте понятные имена, например enabledOption и enabled.

Масштабировать значения рендеринга до текущего разрешения ​

Жестко закодированные значения рендеринга обычно выглядят корректно только на том мониторе, на котором они были созданы.

Font размеры, позиции, отступы и размеры элементов должны масштабироваться относительно текущего разрешения экрана.

Пример
тс
константа соотношение = высота экрана / 1080;
константа размер шрифта = Математика.пол(14 * соотношение);
константа смещениеX = 20 * соотношение;
константа смещениеY = 12 * соотношение;

Это делает макет более последовательным при разных разрешениях.

Пересчитать значения, зависящие от разрешения, в OnScreenSizeChange ​

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

При изменении разрешения пересчитывайте шрифты, смещения и значения кэшированного макета внутри. OnScreenSizeChange.

Пример
тс
позволять шрифт: Font;
позволять соотношение = 1;

позволять MyScript: ScriptDescription = {};

пространство имен мойскрипт {
	МойСкрипт.OnScreenSizeChange = (_ширина, высота) => {
		соотношение = высота / 1080;
		шрифт = Renderer.LoadFont('Тахома', Матем.пол(14 * соотношение), Enum.FontWeight.BOLD);
	};

	RegisterScript(МойСкрипт, 'Пример');
}

IMPORTANT

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

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

Не звони EntitySystem.GetLocalHero() каждый OnUpdate если вы можете кэшировать результат при запуске игры.

Лучший подход
тс
позволять MyScript: ScriptDescription = {};

пространство имен мойскрипт {
	позволять мойГерой: Hero | нулевой = нулевой;
	позволять включено = истинный;

	MyScript.OnGameStart = МойСкрипт.OnScriptLoad = () => {
		мойГерой = EntitySystem.GetLocalHero();
	};

	МойСкрипт.OnGameEnd = () => {
		мойГерой = нулевой;
	};

	МойСкрипт.OnUpdate = () => {
		если (!включено || !myHero) {
			возвращаться;
		}

		// Логика скрипта
	};

	RegisterScript(МойСкрипт, 'Пример');
}

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

Держать OnDraw сосредоточился на рендеринге ​

OnDraw называется каждый кадр. При более высоком FPS запускается чаще.

Из-за этого:

  • продолжайте рендеринг кода внутри OnDraw
  • переместить тяжелую логику в OnUpdate
  • кэшировать значения, когда это возможно

Это снижает вероятность падения FPS и упрощает отладку пути рендеринга.

Отдавайте предпочтение оговоркам о ранней защите ​

Предложения защиты делают сценарий callbacks более удобным для чтения и расширения.

Хороший
тс
МойСкрипт.OnUpdate = () => {
	если (!включено || !myHero) {
		возвращаться;
	}

	// Основная логика
};

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

Сначала проверьте консоль, если пользовательский интерфейс или рендеринг прерываются. ​

Если menu выглядит сломанным, рендеринг работает неправильно или что-то визуальное перестает работать, сначала откройте консоль.

Использовать:

текст
F10

Во многих случаях ошибку легче выявить с консоли, чем гадать по видимым симптомам.

Краткое содержание ​

Хорошие сценарии Melonity обычно следуют нескольким простым правилам:

  • сохранять логику организованной внутри пространства имен
  • сохраняйте состояние простым и читаемым
  • масштабирование пользовательского интерфейса и рендеринг в соответствии с разрешением
  • обновлять кэшированные значения, зависящие от экрана, при изменении размера экрана
  • кэшировать стабильные игровые объекты вместо того, чтобы запрашивать их каждый тик
  • использовать OnDraw только для рендеринга работы
  • проверяйте консоль перед слепой отладкой