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

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

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

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

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

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

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

1.08.2008 23:22:08
Забавно, я и мой друг некоторое время назад думали о написании торговой карточной игры на C #, разве у вас нет источника для этого? Интересует, как вы подошли к этому.
mattytommo 4.05.2012 09:34:41
@mattytommo Нет, ничего не осталось, это было на очень ранних стадиях и, по сути, просто работало, как я обрисовал выше. В настоящее время я смотрю на Рослина, чтобы сделать компиляцию на C #: blogs.msdn.com/b/csharpfaq/archive/2011/10/19/… - В качестве альтернативы, JavaScript использует Jint - jint.codeplex.com
Michael Stum♦ 4.05.2012 14:32:41
Ах, спасибо, но я больше искал реализацию самой торговой карточной игры и структуры, которую вы использовали, в отличие от скриптового движка. В любом случае спасибо :)
mattytommo 4.05.2012 14:44:15
9 ОТВЕТОВ
РЕШЕНИЕ

Решение 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

41
24.12.2019 07:28:19
Между прочим, я выбрал это в качестве принятого ответа, потому что я все равно хотел посмотреть на Python и IronPython, поэтому подход IronPython работает лучше всего для меня .
Michael Stum♦ 25.10.2008 15:08:04
LuaInterface - это интерпретатор lua, который также работает фантастически.
RCIX 27.10.2009 00:49:19
Я внедрил C # Script в систему документооборота в ноябре 2009 года. Он очень хорошо работал для нас.
David Robbins 10.01.2010 13:37:33

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

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

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

8
10.04.2019 12:12:30

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

7
24.12.2019 07:45:32

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

6
2.08.2008 06:16:23

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

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

5
17.09.2008 01:41:29

Я использую 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

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

5
31.08.2017 23:08:07

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

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

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

4
9.01.2010 22:58:08

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

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

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

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

4
26.11.2010 15:39:08
(Нет необходимости помечать это; хотя это должно быть обновление комментария / ответа, но это происходит раньше, чем те, что были опциями)
user1228 26.11.2010 18:00:00

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

3
27.11.2010 09:33:16
Да. Хотя Roslyn все еще на горизонте, Mono.CSharp (доступный на NuGet) упаковывает все те же функциональные возможности.
Eric Falsken 31.05.2013 16:00:57
Добавление обновления для сохранения актуальных параметров. Доступна платформа компилятора .NET («Roslyn»). Таким образом, это жизнеспособная альтернатива всем другим упомянутым. github.com/dotnet/roslyn .
Riv 18.03.2017 07:33:57