Добавление функций сценариев в приложения .NET

Question

У меня есть небольшая игра, написанная на C #. Он использует базу данных в качестве бэк-энда. Это торговая карточная игра , и я хотел реализовать функцию карт в виде скрипта.

Я имею в виду, что у меня по существу есть интерфейс ICard, который реализует класс карты (public class Card056: ICard) и который содержит функцию, вызываемую игрой.

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

Это возможно? Зарегистрировать класс из исходного файла, а затем создать его экземпляр и т. Д.

ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);

Язык C #, но дополнительный бонус, если возможно написать скрипт на любом языке .NET.

Answer 1

Решение C # Script Олега Шило (в The Code Project ) действительно является отличным введением в предоставление возможностей сценариев в вашем приложении.

Другой подход заключается в рассмотрении языка, специально созданного для сценариев, например IronRuby , IronPython или Lua .

IronPython и IronRuby доступны уже сегодня.

Руководство по внедрению IronPython читайте Как встроить поддержку сценариев IronPython в существующее приложение за 10 простых шагов .

Lua - это язык сценариев, обычно используемый в играх. Существует компилятор Lua для .NET, доступный от CodePlex - http://www.codeplex.com/Nua

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

Другой угол - попробовать PowerShell . Существует множество примеров встраивания PowerShell в приложение - вот подробный проект на эту тему: Powershell Tunnel

Answer 2

Вы можете использовать IronRuby для этого.

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

Если вы действительно хотите компилировать во время выполнения, вы можете использовать CodeDOM, тогда вы можете использовать отражение для загрузки динамической сборки. Статья документации Microsoft, которая может помочь .

Answer 3

Если вы не хотите использовать DLR, вы можете использовать Boo (у которого есть интерпретатор) или вы можете рассмотреть проект Script.NET (S #) в CodePlex, С помощью решения Boo вы можете выбирать между скомпилированными сценариями или с помощью интерпретатора, а Boo делает хороший язык сценариев, имеет гибкий синтаксис и расширяемый язык благодаря своей архитектуре открытого компилятора. Script.NET также выглядит неплохо, и вы можете легко расширить этот язык, а также проект с открытым исходным кодом и использовать очень удобный Генератор компиляторов ( Irony.net ).

Answer 4

Я использую LuaInterface1.3 + Lua 5.0 для приложения NET 1.1.

Проблема с Boo в том, что каждый раз, когда вы анализируете / компилируете / проверяете свой код на лету, он создает набор классов boo, поэтому вы получаете утечки памяти.

С другой стороны, Lua этого не делает, поэтому он очень стабильный и прекрасно работает (я могу передавать объекты из C # в Lua и обратно).

Пока что я еще не включил его в PROD, но кажется очень многообещающим.

У меня были проблемы с утечкой памяти в PROD при использовании LuaInterface + Lua 5.0 , поэтому я использовал Lua 5.2 и напрямую связался с C # с помощью DllImport. Утечки памяти были внутри библиотеки LuaInterface.

Lua 5.2: от http://luabinaries.sourceforge.net и http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

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

Answer 5

Я бы предложил использовать LuaInterface , поскольку он полностью реализовал Lua, когда кажется, что Nua не завершена и, вероятно, не реализует некоторые очень полезные функции (сопрограммы и т. Д.).

Если вы хотите использовать некоторые из внешних упакованных модулей Lua, я бы предложил использовать что-то вроде 1.5.x в отличие от серии 2.x, которая создает полностью управляемый код и не может предоставить необходимый C API.

Answer 6

Вы можете использовать любой из языков DLR, который позволяет действительно легко разместить собственную платформу сценариев. Однако вам не нужно использовать язык сценариев для этого. Вы можете использовать C # и скомпилировать его с поставщиком кода C #. Пока вы загружаете его в свой собственный домен приложений, вы можете загружать и выгружать его в свое удовольствие.

Answer 7

Основное приложение, которое продает мое подразделение, делает что-то очень похожее для настройки клиента (что означает, что я не могу публиковать источники). У нас есть приложение на C #, которое загружает динамические сценарии VB.NET (хотя любой язык .NET можно было легко поддерживать - VB был выбран, потому что команда по настройке исходила из ASP).

Используя CodeDom в .NET, мы компилируем скрипты из базы данных, используя VB CodeDomProvider (досадно, что по умолчанию используется .NET 2, если вы хотите поддерживать функции 3.5, вам нужно передать словарь с "CompilerVersion" = "v3 .5 "своему конструктору). Используйте метод CodeDomProvider.CompileAssemblyFromSource для его компиляции (вы можете передать настройки, чтобы заставить его компилироваться только в памяти.

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

Answer 8

Да, я думал об этом, но вскоре понял, что другого предметно-ориентированного языка (DSL) будет слишком много.

По сути, им нужно взаимодействовать с моим игровым состоянием, возможно, непредсказуемым образом. Например, у карты может быть правило: «Когда эти карты входят в игру, все ваши миньоны-нежити получают +3 атаки против летающих врагов, кроме случаев, когда враг благословен». Поскольку игры с карточными играми основаны на поворотах, GameState Manager будет запускать события OnStageX и позволять карточкам изменять другие карточки или GameState так, как нужно карточке.

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

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

Answer 9

В следующей версии .NET (5.0?) Было много разговоров об открытии «компилятора как сервиса», который сделал бы возможным прямое вычисление сценария.