My<cod/>.net
Добавление функциональности сценариев в приложения .NET
У меня есть небольшая игра, написанная в C#., она использует базу данных в качестве бэк-энда. Это это была торговая карточная игра, и я хотел реализовать функцию карт в виде скрипта.
Я имею в виду, что у меня по существу есть интерфейс , ICard, который реализует класс карт ( public class Card056: ICard ) и который содержит функцию, вызываемую игрой.
Теперь, чтобы сделать вещь maintainable/moddable,, я хотел бы иметь класс для каждой карты в качестве исходного кода в базе данных и по существу скомпилировать его при первом использовании. Поэтому, когда мне нужно добавить/изменить карту, я просто добавлю ее в базу данных и скажу своему приложению обновить, не требуя никаких assembly deployment (тем более, что мы будем говорить о 1 assembly на карту, что означает сотни сборок).
Разве это возможно? Зарегистрируйте класс из исходного файла, а затем создайте его экземпляр и т. д.
ICard Cards[current] = new MyGame.CardLibrary.Card056();
Cards[current].OnEnterPlay(ref currentGameState);
Язык C#, но дополнительный бонус, если есть возможность написать сценарий на любом языке .NET.
Решение Олега Шило C# Script (в проекте Code) действительно является отличным введением в предоставление возможностей скрипта в вашем приложении.
Другой подход заключается в рассмотрении языка, который специально создан для сценариев, таких как IronRuby , IronPython или Lua .
IronPython и IronRuby доступны сегодня.
Для получения руководства по встраиванию IronPython прочитайте Как встроить поддержку скриптов IronPython в существующее приложение за 10 простых шагов .
Lua-это язык сценариев, обычно используемый в играх. Существует компилятор Lua для .NET, доступный из CodePlex -- http://www.codeplex.com/Nua
Эта кодовая база является отличным чтением, если вы хотите узнать о создании компилятора .NET.
Совсем другой угол зрения-это попробовать PowerShell . Существует множество примеров внедрения PowerShell в приложение - вот подробный проект по этой теме: Powershell туннель
Вы могли бы использовать для этого IronRuby.
В противном случае я бы предложил вам иметь каталог, в котором вы размещаете предварительно скомпилированные сборки. Затем вы можете иметь ссылку в DB на assembly и класс и использовать отражение для загрузки соответствующих сборок во время выполнения.
Если вы действительно хотите выполнить компиляцию во время выполнения, вы можете использовать CodeDOM, а затем использовать отражение для загрузки динамического assembly. Статья документации Microsoft, которая может помочь .
Если вы не хотите использовать DLR, вы можете использовать Boo (который имеет интерпретатор) или вы можете рассмотреть проект Script.NET (S#) на CodePlex . С помощью решения Boo вы можете выбирать между скомпилированными скриптами или с помощью интерпретатора, и Boo делает хороший язык сценариев, имеет гибкий синтаксис и расширяемый язык через свою открытую архитектуру компилятора. Script.NET тоже выглядит неплохо, и вы можете легко расширить этот язык, а также его проект с открытым исходным кодом и использовать очень дружественный генератор компиляторов ( Irony.net ).
Вы можете использовать любой из языков DLR, которые предоставляют возможность действительно легко разместить свою собственную скриптовую платформу. Однако для этого не обязательно использовать язык сценариев. Вы можете использовать C# и скомпилировать его с помощью поставщика кода C#. Пока вы загружаете его в свой собственный AppDomain, вы можете загружать и выгружать его в свое удовольствие.
Я бы предложил использовать LuaInterface , поскольку он полностью реализовал Lua, где, как представляется, Nua не является полным и, вероятно, не реализует некоторые очень полезные функции (coroutines и т. д.).
Если вы хотите использовать некоторые из внешних готовых модулей Lua, я бы предложил использовать что-то вроде 1.5.x в отличие от серии 2.x, которая строит полностью управляемый код и не может предоставить необходимый C API.
Я использую LuaInterface1.3 + Lua 5.0 для NET 1.1 приложения.
Проблема с Boo заключается в том, что каждый раз, когда вы parse/compile/eval свой код на лету, он создает набор классов 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
Как только я это сделал, все мои утечки памяти исчезли, и приложение было очень стабильным.
Да, я думал об этом, но вскоре понял, что еще один Domain-Specific-Language (DSL) будет немного чересчур.
По сути, они должны взаимодействовать с моим геймстейтом, возможно, непредсказуемым образом. Например, у карты может быть правило: "когда эти карты входят в игру, все ваши немертвые миньоны получают +3 атаки против летающих врагов, за исключением тех случаев, когда враг благословлен". Поскольку торговые карточные игры являются пошаговыми, менеджер GameState будет запускать события OnStageX и разрешать картам изменять другие карты или GameState в любом случае, в котором нуждается карта.
Если я попытаюсь создать DSL, мне придется реализовать довольно большой набор функций и, возможно, постоянно обновлять его, что переносит работу по обслуживанию на другую часть, фактически не удаляя ее.
Вот почему я хотел остаться с языком "real" .NET, чтобы по существу иметь возможность просто запустить событие и позволить карте манипулировать gamestate любым способом (в пределах безопасности доступа к коду).
Основное приложение, которое продает мой отдел, делает что-то очень похожее на предоставление клиентских настроек (что означает, что я не могу опубликовать какой-либо источник). У нас есть приложение C#, которое загружает динамические скрипты VB.NET (хотя любой язык .NET может быть легко поддержан - VB был выбран потому, что команда настройки исходила из фона ASP).
Используя .NET's CodeDom, мы компилируем скрипты из базы данных, используя VB CodeDomProvider (досадно, что по умолчанию он имеет значение .NET 2, Если вы хотите поддерживать функции 3.5, вам нужно передать словарь с "CompilerVersion" = " v3.5 " его конструктору). Используйте метод CodeDomProvider.CompileAssemblyFromSource для его компиляции (вы можете передать настройки, чтобы заставить его компилироваться только в памяти.
Это привело бы к сотням сборок в памяти, но вы могли бы собрать весь код динамических классов вместе в один assembly и перекомпилировать всю партию при любом изменении. Это имеет то преимущество, что вы можете добавить флаг для компиляции на диске с PDB для тестирования, что позволит вам отлаживать динамический код.