Adicionando funcionalidade de script para aplicações .NET

votos
62

Eu tenho um pequeno jogo escrito em C #. Ele usa um banco de dados como back-end. É um jogo de cartas , e eu queria implementar a função dos cartões como um script.

O que quero dizer é que eu têm essencialmente uma interface, ICardque uma classe implementa cartão ( public class Card056 : ICard) e que contém a função que são chamados pelo jogo.

Agora, para fazer a coisa passível de manutenção / moddable, eu gostaria de ter a classe para cada cartão como código fonte no banco de dados e, essencialmente, compilá-lo na primeira utilização. Então, quando eu tenho que adicionar / alterar um cartão, eu vou adicioná-lo ao banco de dados e dizer a minha candidatura para refrescar, sem necessidade de qualquer implantação de montagem (especialmente desde que estaríamos falando de cerca de 1 montagem por cartão, o que significa centenas de assembléias) .

Isso é possível? Registrar uma classe a partir de um arquivo de origem e, em seguida, instanciar-lo, etc.

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

A linguagem é C #, mas bônus extra se é possível escrever o script em qualquer linguagem .NET.

Publicado 02/08/2008 em 00:22
fonte usuário
Em outras línguas...                            


9 respostas

votos
37

Oleg Shilo C # solução Script (no Projeto Código ) é realmente uma ótima introdução para fornecer capacidades de script em sua aplicação.

Uma abordagem diferente seria considerar uma linguagem que é construído especificamente para criação de scripts, como IronRuby , IronPython , ou Lua .

IronPython e IronRuby estão disponíveis hoje.

Para um guia para a incorporação de IronPython leia Como incorporar script apoio IronPython em seu aplicativo existente em 10 passos .

Lua é uma linguagem de script comumente usado em jogos. Há um compilador Lua for .NET, disponível em CodePlex - http://www.codeplex.com/Nua

Essa base de código é uma ótima leitura, se você quer aprender sobre a construção de um compilador em .NET.

Um ângulo completamente diferente é tentar PowerShell . Existem inúmeros exemplos de incorporar PowerShell em um aplicativo - aqui está um projeto minucioso sobre o tema: Powershell Tunnel

Respondeu 02/08/2008 em 02:49
fonte usuário

votos
7

Você pode ser capaz de usar IronRuby para isso.

Caso contrário, eu sugiro que você tem um diretório onde você coloca os conjuntos pré-compilados. Então você pode ter uma referência no banco de dados para a montagem e classe, e usar a reflexão para carregar as montagens adequadas em tempo de execução.

Se você realmente quer compilar em tempo de execução, você poderia usar o CodeDOM, então você pode usar a reflexão para carregar o assembly dinâmico. Artigo MSDN que poderia ajudar .

Respondeu 02/08/2008 em 05:18
fonte usuário

votos
6

Se você não quiser usar o DLR você pode usar Boo (que tem um intérprete) ou você poderia considerar o projeto Script.NET (S #) no CodePlex . Com a solução Boo você pode escolher entre scripts compilados ou usando o intérprete, e Boo faz uma linguagem de script bom, tem uma sintaxe flexível e uma linguagem extensível através de sua arquitetura compilador aberto. Script.NET parece bom também, embora, e você poderia facilmente estender essa linguagem, bem como seu um projeto de código aberto e usa um compilador Generator muito amigável ( Irony.net ).

Respondeu 06/08/2008 em 17:28
fonte usuário

votos
5

Estou usando LuaInterface1.3 + Lua 5.0 para um 1.1 NET.

O problema com Boo é que cada vez que você analisar / compilação / eval seu código na mosca, ele cria um conjunto de classes vaia assim que você vai ter vazamentos de memória.

Lua no outro lado, não faz isso, por isso é muito, muito estável e funciona maravilhoso (I pode passar objetos de C # para Lua e para trás).

Até agora eu não colocá-lo em PROD ainda, mas parece muito promissor.

Eu tinha problemas de vazamento de memória em PROD usando LuaInterface + Lua 5.0 , portanto, eu usei Lua 5.2 e vinculado diretamente em C # com DllImport. Os vazamentos de memória estavam dentro da biblioteca LuaInterface.

Lua 5.2: a partir http://luabinaries.sourceforge.net e http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

Uma vez eu fiz isso, todos os meus vazamentos de memória foram embora e a aplicação era muito estável.

Respondeu 17/07/2012 em 18:08
fonte usuário

votos
5

Eu sugiro usar LuaInterface como ele aplicou integralmente Lua, onde parece que Nua não está completa e, provavelmente, não implementar algumas funcionalidades muito úteis (co-rotinas, etc).

Se você quiser usar alguns dos módulos Lua pré-embalados fora, eu sugiro usar algo ao longo das linhas de 1.5.x em oposição à série 2.x que constrói código totalmente gerenciado e não pode expor a API C necessário.

Respondeu 17/09/2008 em 02:41
fonte usuário

votos
5

Você pode usar qualquer um dos idiomas DLR, que fornecem uma maneira de acolher muito facilmente sua própria plataforma de script. No entanto, você não tem que usar uma linguagem de script para isso. Você pode usar C # e compilá-lo com o provedor de código C #. Contanto que você carregá-lo em seu próprio AppDomain, você pode carregar e descarregá-lo para o conteúdo do seu coração.

Respondeu 02/08/2008 em 07:16
fonte usuário

votos
4

A principal aplicação que minha divisão vende faz algo muito semelhante para fornecer personalizações cliente (o que significa que eu não posso postar qualquer fonte). Nós temos uma aplicação C # que carrega scripts de VB.NET dinâmicos (embora qualquer linguagem .NET pode ser facilmente suportado - VB foi escolhido porque a equipe de personalização veio de um fundo ASP).

CodeDom usando do .NET que compilar os scripts do banco de dados, usando o VB CodeDomProvider(irritantemente o padrão é NET 2, se você quiser apoiar 3,5 características que você precisa passar um dicionário com "CompilerVersion" = "v3.5" para seu construtor ). Use o CodeDomProvider.CompileAssemblyFromSourcemétodo de compilá-lo (você pode passar configurações para forçá-lo para compilar apenas na memória.

Isso resultaria em centenas de assembléias em memória, mas você pode colocar todo o código das classes dinâmicas juntos em um único assembly, e recompilar todo o lote quando qualquer mudança. Isto tem a vantagem de que você pode adicionar um sinalizador para compilar em disco com um APO para quando você está testando, o que lhe permite depurar através do código dinâmico.

Respondeu 10/08/2008 em 16:24
fonte usuário

votos
4

Sim, eu pensei sobre isso, mas eu logo descobri que um outro Domain-Specific-Language (DSL) seria um pouco demais.

Essencialmente, eles precisam interagir com a minha gamestate de maneiras possivelmente imprevisíveis. Por exemplo, um cartão pode ter uma regra "Quando este cartões de entrar em jogo, todos os seus asseclas mortos-vivos ganhar +3 ataque contra os inimigos voadores, exceto quando o inimigo é abençoado". Como jogos de cartas negociação são baseado em turnos, o gamestate Manager irá disparar OnStageX eventos e deixe os cartões de modificar outros cartões ou o gamestate de qualquer maneira as necessidades do cartão.

Se eu tentar criar uma DSL, eu tenho que implementar uma bastante grande conjunto de recursos e possivelmente atualizar constantemente, o que desloca o trabalho de manutenção para outra parte sem realmente removê-lo.

É por isso que eu queria ficar com uma "real" linguagem .NET para essencialmente ser capaz de simplesmente disparar o evento e deixar o cartão de manipular o gamestate de qualquer maneira (dentro dos limites da segurança de acesso de código).

Respondeu 02/08/2008 em 00:49
fonte usuário

votos
3

A próxima versão do .NET (5,0?) Teve um monte de falar sobre a abertura do "compilador como um serviço", que faria coisas como avaliação roteiro direta possível.

Respondeu 27/11/2010 em 03:12
fonte usuário

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