Я использую Java и Jython, и после некоторых исследований я обнаружил, что предоставление сценариям прямого доступа к интерфейсу движка может быть ошибкой, так как это тесно связывает их.
Похоже, что большинство сценариев, которые позволяют модам создавать и управлять объектами, делают это посредством какой-то абстракции. Существуют ли эти абстракции по этой причине, или это просто для того, чтобы не программисты могли модифицировать игру?
Ответы:
Оба, в общем. Ваши сценарии должны взаимодействовать с абстрактным или, по крайней мере, промежуточным уровнем функциональности, а не с самим движком.
Во-первых, это дает вам дополнительную меру контроля и безопасности. Он позволяет вам легко, четко определить интерфейс, который скрипту разрешено иметь с вашей игрой, и, таким образом, что он может испортить, а также позволяет вам в дальнейшем добавлять дополнительные проверки безопасности в промежуточное звено, которые не обязательно будут подходящими в сам фактический функциональный слой.
Во-вторых, он позволяет упростить интерфейс, доступный для скриптов, чтобы он был более дружественным к программисту или более простым в использовании.
Это действительно обеспечивает немного изоляции от соединения между ними, но это часто не что большой сделки , потому что сценарии всегда будут связаны с интерфейсами они могут взаимодействовать с, по самой своей природе. Другие два пункта гораздо более выгодны.
Я также думаю, что это поможет вам, если вы хотите внести изменения в двигатель. Вы можете делать их, не беспокоясь о необходимости изменить все ваши скрипты, так как движок изменился. Вам просто нужно изменить слой абстракции, упомянутый Джошем.
Создание слоя между ядром игры и скриптами, используемыми для создания модификаций, на мой взгляд, необходимо.
Используя этот метод, вы получаете несколько преимуществ:
Проще для моддеров.
Хорошая причина сделать это, как вы упоминали, более простые способы создания модов. Написание меньшего количества строк кода повышает читабельность и сводит к минимуму понимание проблем при программировании новичков. В идеале этот API должен представлять собой набор методов для изменения чего-либо на высоком уровне игры . Например, это означает: порождать сущность, не зная, как она на самом деле порождается , или отображать изображение одним вызовом, который принимает в качестве параметра только имя изображения.
Вы, как программист, также извлекаете из этого выгоду, так как вы можете писать больше за меньшее время, чем нужно для Java.
Безопасность.
Важно не допустить, чтобы люди контролировали всю игру. Мне было бы все равно, если бы игра была однопользовательской, но мне было бы интересно, когда в игре появилось какое-то многопользовательское действие. Даже если это только таблица рекордов.
Другие люди всегда разочаровываются, когда кто-то побеждает из-за мошенничества (например, изменение позиции, более конкретно: изменение позиции и прямое ограничение флага). Помочь игрокам сделать это - ваша главная задача здесь.
Имейте в виду, что читер всегда может декомпилировать, изменять код, перекомпилировать и играть с этим клиентом, поэтому добавляйте проверки на стороне сервера. Как правило, предоставляемая «безопасность» - это еще один, не 100% безопасный способ усложнить жизнь читерам.