Додавання функціональності сценаріїв до програм .NET

У мене є маленька гра, написана на C #. Він використовує базу даних як фонову. Це торгова карткова гра , і я хотів реалізувати функцію карт як сценарій.

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

Тепер, щоб зробити те, що можна підтримувати / модифікувати, я хотів би мати клас для кожної картки як вихідний код у базі даних і по суті скомпілювати його при першому використанні. Тому, коли мені потрібно додати / змінити картку, я просто додаю її в базу даних і скажу моєму додатку, щоб оновився, не потребуючи розгортання збірки (тим більше, що ми говоримо про 1 збірку на карту, що означає сотні збірок) .

Це можливо? Зареєструйте клас із вихідного файлу, а потім створіть його інстанцію тощо.

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

Мовою є C #, але додатковий бонус, якщо можливо написати сценарій будь-якою мовою .NET.

Рішення C # Script Олега Шило (у проекті The Code ) справді є чудовим вступом до надання можливостей сценарію у вашому додатку.

Іншим підходом було б розглядати мову, спеціально створену для сценаріїв, таку як IronRuby , IronPython або Lua .

IronPython та IronRuby доступні сьогодні.

Посібник із вбудовування IronPython читайте в статті Як вбудувати підтримку сценарію IronPython у існуючу програму за 10 простих кроків .

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

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

Взагалі інший кут - це спробувати PowerShell . Є безліч прикладів вбудовування PowerShell в додаток - ось детальний проект на тему: Powershell Tunnel

Ви можете використовувати IronRuby для цього.

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

Якщо ви дійсно хочете скомпілювати під час виконання, ви можете використовувати CodeDOM, тоді ви можете використовувати відображення для завантаження динамічної збірки. Стаття документації Microsoft, яка може допомогти .

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

Ви можете скористатися будь-якою з мов DLR, які забезпечують можливість дійсно легко розмістити власну платформу сценаріїв. Однак для цього не потрібно використовувати мову сценаріїв. Ви можете використовувати C # та скомпілювати його з постачальником кодів C #. Поки ви завантажуєте його у власний AppDomain, ви можете завантажувати та розвантажувати його до душі.

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

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

Я використовую LuaInterface1.3 + Lua 5.0 для програми NET 1.1.

Проблема 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

Як тільки я це зробив, усі мої витоки пам’яті зникли, і програма була дуже стабільною.

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

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

Це призведе до сотень збірок в пам'яті, але ви можете об'єднати всі коди динамічних класів в одну збірку і перекомпілювати весь пакет при будь-яких змінах. Це має ту перевагу, що ви можете додати прапор для компіляції на диску з PDB під час тестування, дозволяючи налагоджувати динамічний код.

Так, я думав про це, але незабаром зрозумів, що іншої доменної мови (DSL) буде занадто багато.

По суті, їм потрібно взаємодіяти з моїм ігровим статусом можливо непередбачуваними способами. Наприклад, на карті може бути правило "Коли ці карти вступають у гру, всі ваші нежиті отримують +3 атаки проти літаючих ворогів, за винятком випадків, коли ворог благословен". Оскільки торгові карткові ігри покрокові, GameState Manager запускатиме події OnStageX і дозволить карткам модифікувати інші карти або GameState будь-яким способом, необхідним картці.

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

Ось чому я хотів дотримуватися "справжньої" мови .NET, щоб, по суті, мати можливість просто запускати подію і дозволяти картці маніпулювати ігровим станом будь-яким способом (у межах безпеки доступу до коду).

У наступній версії .NET (5.0?) Було багато розмов про відкриття "компілятора як служби", що зробить можливим такі речі, як безпосередня оцінка сценаріїв.