Dodanie funkcjonalności skryptów do aplikacji .NET

głosy
62

Mam małą grę napisany w języku C #. Wykorzystuje bazę danych jako back-end. Jest to gra w karty handlowym , i chciałem realizować funkcję karty jako skrypt.

Chodzi mi o to, że zasadniczo mieć interfejs ICard, który A implements klasy karta ( public class Card056 : ICard) i który zawiera funkcje, które są wywoływane przez grę.

Teraz, aby sprawa utrzymaniu / modyfikowalne, chciałbym mieć klasę dla każdej karty jako kod źródłowy w bazie danych i zasadniczo skompilować go przy pierwszym użyciu. Więc kiedy muszę dodać / zmienić kartę, po prostu dodaj je do bazy danych i powiedz mojej aplikacji do odświeżenia, bez potrzeby wdrażania montażowej (zwłaszcza, że ​​będzie rozmawiać o 1 zespół za kartę, co oznacza setki zespołów) ,

Czy to jest możliwe? Zarejestruj klasę z pliku źródłowego, a następnie oznacz ją itp

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

Język C # ale dodatkowy bonus, jeśli to możliwe, aby napisać skrypt w dowolnym języku .NET.

Utwórz 02/08/2008 o 00:22
źródło użytkownik
W innych językach...                            


9 odpowiedzi

głosy
37

Oleg Shilo w C # rozwiązanie Script (The Code Project ) jest naprawdę wspaniałe wprowadzenie do zapewnienia zdolności skryptów w aplikacji.

Inne podejście byłoby rozważyć język, który jest zbudowany specjalnie do obsługi skryptów, takich jak IronRuby , IronPython lub Lua .

IronPython i IronRuby są zarówno dostępne już dziś.

Dla przewodnika do osadzania IronPython czytać Jak osadzić obsługę skryptów IronPython w istniejącej aplikacji w 10 prostych krokach .

Lua jest językiem skryptowym powszechnie stosowany w grach. Jest kompilator Lua NET, dostępny od CodePlex - http://www.codeplex.com/Nua

Że codebase jest wielki przeczytać, jeśli chcesz dowiedzieć się o budowie kompilator w .NET.

Zupełnie inny kąt jest próba PowerShell . Istnieją liczne przykłady osadzania PowerShell do aplikacji - oto dokładny projekt na temat: PowerShell Tunnel

Odpowiedział 02/08/2008 o 02:49
źródło użytkownik

głosy
7

Możesz być w stanie użyć IronRuby za to.

W przeciwnym razie sugeruję masz katalog, w którym umieścić zespoły skompilowane. Wtedy można mieć odniesienie w DB do zespołu i klasy, i użyć refleksji załadować odpowiednie zespoły w czasie wykonywania.

Jeśli naprawdę chcesz kompilować w czasie wykonywania można użyć CodeDOM, a następnie można użyć refleksji załadować dynamiczny montaż. MSDN artykuł, który może pomóc .

Odpowiedział 02/08/2008 o 05:18
źródło użytkownik

głosy
6

Jeśli nie chcesz korzystać z DLR można użyć Boo (który ma tłumacza) lub można rozważyć ten Script.NET (S #) projekt na CodePlex . Dzięki rozwiązaniu Boo można wybierać pomiędzy opracowanych skryptów lub korzystania z tłumacza i Boo sprawia piękny język skryptowy, posiada elastyczną składnię i języka rozszerzalnej poprzez swoją otwartą architekturę kompilatora. Script.NET wygląda zbyt miły, choć i można łatwo przedłużyć ten język jak również jego projekt open source i używa bardzo przyjazny Compiler Generator ( Irony.net ).

Odpowiedział 06/08/2008 o 17:28
źródło użytkownik

głosy
5

Używam LuaInterface1.3 + Lua 5,0 dla NET 1.1 aplikacji.

Problem z Boo jest to, że za każdym razem, gdy analizować / kompilacji / eval kodu w locie, tworzy zestaw klas boo tak dostaniesz wycieków pamięci.

Lua w drugiej strony, tego nie robi, więc jest to bardzo stabilny i działa wspaniałe (mogę przekazać obiekty z C # Lua i do tyłu).

Do tej pory nie wprowadziły go w PROD jeszcze, ale wydaje się bardzo obiecujący.

Ja miałem problemy wycieki pamięci w PROD wykorzystaniem LuaInterface + Lua 5,0 , dlatego użyłem Lua 5,2 i związane bezpośrednio z C # DllImport. Przecieki pamięci były wewnątrz biblioteki LuaInterface.

Lua 5,2: od http://luabinaries.sourceforge.net i http://sourceforge.net/projects/luabinaries/files/5.2/Windows%20Libraries/Dynamic/lua-5.2_Win32_dll7_lib.zip/download

Kiedy już to zrobił, wszyscy moi wycieki pamięci zniknęły, a aplikacja była bardzo stabilna.

Odpowiedział 17/07/2012 o 18:08
źródło użytkownik

głosy
5

Sugeruję użyciu LuaInterface gdyż w pełni wdrożyła Lua, gdzie wydaje się, że Nua nie jest kompletna i nie może realizować kilka bardzo przydatnych funkcji (współprogram, etc).

Jeśli chcesz korzystać z niektórych zewnętrznych modułów opakowanej Lua, polecam użyciu coś wzdłuż linii 1.5.x, w przeciwieństwie do serii 2.x, która buduje w pełni zarządzanego kodu i nie może narażać niezbędną C API.

Odpowiedział 17/09/2008 o 02:41
źródło użytkownik

głosy
5

Można użyć dowolnego z języków DLR, które zapewniają sposób bardzo łatwo gościć własną platformę skryptów. Jednak nie trzeba używać języka skryptowego do tego. Można użyć C # i skompilować go z dostawcą kodu C #. Tak długo, jak załadować go w jego własnym AppDomain, można załadować i rozładować go do syta.

Odpowiedział 02/08/2008 o 07:16
źródło użytkownik

głosy
4

Główny wniosek, że mój podział sprzedaje robi coś bardzo podobnego do zapewnienia dostosowywać klienta (co oznacza, że ​​nie można zakładać żadnego źródła). Mamy aplikacji C #, który obciążeń dynamicznych skryptów VB.NET (chociaż każdy język .NET może być łatwo obsługiwane - VB został wybrany, ponieważ zespół dostosowywania pochodził z tłem ASP).

Korzystanie .NET za CodeDom możemy skompilować skrypty z bazy danych przy użyciu VB CodeDomProvider(irytująco odpowiada wartości .NET 2, jeśli chcesz wesprzeć 3.5 Cechy trzeba przekazać słownika z „CompilerVersion” = „v3.5” do jego konstruktora ). Użyj CodeDomProvider.CompileAssemblyFromSourcemetody, aby go skompilować (można przejść do ustawień zmusić go do kompilacji tylko w pamięci.

Spowodowałoby to setki zespołów w pamięci, ale można umieścić cały kod dynamiczny klasa ta razem w jednym zespole i przekompilować dużo kiedy jakakolwiek zmiana. Ma to tę zaletę, że można dodać flagę kompilacji na dysku z WPB , gdy testujesz, co pozwala na debugowanie poprzez kod dynamiczny.

Odpowiedział 10/08/2008 o 16:24
źródło użytkownik

głosy
4

Tak, myślałem o tym, ale szybko zorientowali się, że inny Domain-Specific-Language (DSL) byłoby trochę za dużo.

Zasadniczo, muszą współdziałać z moim gamestate ewentualnie w nieprzewidywalny sposób. Na przykład, karta może mieć regułę „kiedy to karty wchodzą do gry, wszystkie nieumarłych sługusów zyskać +3 atak na wrogów pływające, z wyjątkiem gdy wróg jest błogosławiony”. Jak kolekcjonerskich gier karcianych są turowa The GameState Manager będzie ogień OnStageX wydarzenia i pozwól karty modyfikować inne karty lub GameState w jakikolwiek sposób potrzeb kart.

Gdy próbuję utworzyć DSL, muszę wdrożyć dość duży zestaw funkcji i być stale aktualizować, który przesuwa prac konserwacyjnych do innej części bez faktycznie usunięcie go.

Dlatego chciałem zatrzymać się z „prawdziwego” języka .NET do zasadniczo być w stanie po prostu ognia zdarzenie i niech karta manipulować gamestate w jakikolwiek sposób (w granicach od zabezpieczeń dostępu kodu).

Odpowiedział 02/08/2008 o 00:49
źródło użytkownik

głosy
3

Kolejna wersja .NET (5.0?) Miał dużo mówi się o otwarciu „kompilator jako usługa”, która stałaby rzeczy jak oceny bezpośredni skryptu możliwe.

Odpowiedział 27/11/2010 o 03:12
źródło użytkownik

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