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

голоса
62

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

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

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

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

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

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

Задан 02/08/2008 в 00:22
источник пользователем
На других языках...                            


9 ответов

голоса
37

Олег Шило в C # решение Script (в Проекте Кодекса ) действительно является прекрасным введением в предоставлении возможности скрипта в вашем приложении.

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

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

Для руководства для встраивания IronPython чтения Как встроить поддержку скриптов IronPython в существующем приложении 10 простых шагов .

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

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

Другой угол в целом заключается в попытке PowerShell . Есть множество примеров внедрения PowerShell в приложение - вот тщательный проект на тему: Powershell Tunnel

Ответил 02/08/2008 в 02:49
источник пользователем

голоса
7

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

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

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

Ответил 02/08/2008 в 05:18
источник пользователем

голоса
6

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

Ответил 06/08/2008 в 17:28
источник пользователем

голоса
5

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

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

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

До сих пор я не положил его в PROD еще, но представляется весьма перспективным.

Я есть проблемы утечки памяти в PROD с использованием LuaInterface + Lua 5.0 , поэтому я использовал Луа 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

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

Ответил 17/07/2012 в 18:08
источник пользователем

голоса
5

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

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

Ответил 17/09/2008 в 02:41
источник пользователем

голоса
5

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

Ответил 02/08/2008 в 07:16
источник пользователем

голоса
4

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

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

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

Ответил 10/08/2008 в 16:24
источник пользователем

голоса
4

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

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

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

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

Ответил 02/08/2008 в 00:49
источник пользователем

голоса
3

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

Ответил 27/11/2010 в 03:12
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more