Xml som scriptspråk...

[TheSpaceMan]

Arbetar vidare på min planetssystems generator, men jag vill ha den med scriptbar, fast samtidigt vill jag inte dra in ett helt annat språk/script till, vill heller inte skriva en helt egen parser.

Dessutom har jag alltid funderat på om det går att göra ett vettigt scriptspråk av xml.

Så det är nu fallet.
Tänkte knuffa ut alla mina system som xml data i vilket fall, så då kan man lika gärna ett scriptsystem som xml.

Det kommer just nu mest bygga på dynamiska variablar med sträng namn och värden av dom vanliga typerna.

Får se vad som händer av det. Borde inte vara så svårt.

[sirGustav]

Jag skrev ett script-språk för ett ganska bra tag sedan vars första-parnings steg var tinyxml. Dock är det kanske fel att kalla det script-språk eftersom allt vad det gjorde var att anropa redan registrerade C++ "funktioner" och det fanns inga variabler, eller någon form beräkningar. "Språket" gick mer ut på att scripta npc's och "funktionerna" kunde exekvera i flera minuter medan spelet körde på i flera fps

Annars så finns alltid tinyscheme

[wc-duck]

ARGH! Scripta i xml låter bara jobbigt och konstigt! Har provat det en gång och det blev väll "sisådär" för att vara snäll mot mig själv.

Håller på att välja scriptspråk till mitt hobby-projekt just nu och det lutar åt GameMonkey tror jag. Jag skulle rekomendera ett riktigt scriptspråk när du ändå är i farten, skulle gissa på att du vinner på det i längden.

[dooz]

Mmm, jag håller nog med ovanstående. Min känsla nu är att XML är datalagrningens IBM, eller nåt, och att det valdes som standard av en massa stora företag, folk skrev gigantiska libbar för att hantera skiten, och det är egentligen inget man ska använda i sina egna projekt.

Jag kom till någon form av insikt när jag kodade en app där jag skulle vara slug och spara GUI positioner och sånt i XML. Det började smärtfritt, tills jag insåg att jag egentligen behövde i princip variabler (säg att du har en uträkning för att komma fram till en viss position, så vill du använda den uträkning (fast namngiven som en variabel) på flera ställen i XML-filen) i min XML. Jag hajade aldrig vilken återvändsgränd jag gått in i, utan skrev istället en enkel calculator som kunde beräkna uttrycket som stod som attribut i mina XML-noder.

Jag snackade sen med en polare om detta, och eftersom han inte hade skrivit en massa dumkod för att lösa ett problem som berodde på att jag försökte använda ett data-lagringsspråk för att göra mer, frågade han tvärt "varför länkar du inte med Lua istället, och bara sparar din data som Lua kod". Det var lite av en uppenbarelse

I dagsläget så använder jag Python och JSON för kod resp. data, men det är inget som jag är 100% såld på, utan helt enkelt det bästa jag hittat/haft tid att kolla på. Som alla andra är jag egentligen också kär i Scheme och hyller det som det bästa språket, men jag kommer att gå över till det först när jag börjat lyssna på Ramones, och kan hävda att allting var bättre förr

[Mattias Gustavsson]

Det här med script-språk är ingen lätt sak, och det finns inget standardsvar som passar alla situationer.

Det viktigtaste i sammanhanget är att väldigt precis definiera vad man vill få ut av scriptspråket, vad man vill använda det till, och först därefter se till vilken lösning som passar bäst i just detta specifika fall(oavsett om det är en egenkonstruerad, off-the-shelf eller ett mellanting). Man kommer inte att använda samma scriptspråk till alla projekt, och man kommer inte att använda samma format för att lagra all data för sitt projekt.

Det är viktigt att skilja mellan data-definition och scriptning. Att använda ett fullfjädrat script-språk i ett sammanhang där man egentligen bara är ute efter att definiera data är en säker väg till kaos - speciellt om man är flera personer inblandade. När jag jobbade på Tycoon City: New York, fick jag surt erfara effekterna av detta, vilket kanske var rätt åt mig eftersom det var jag som valt att använda LUA flera år tidigare, den första vändan jag jobbade på företaget. Med tiden hade det hela växt till ett riktigt monster, så det var näst-intill omöjligt att göra nåt så enkelt som att debugga inladdningen av en modell och dess material, i alla hopp mellan lua-kod och host-funktioner. Och laddningen var hur långsam som helst - tror det tog ca 15 minuter att ladda upp en level.

Att definiera data externt, utanför källkoden, kan förstås vara praktiskt ibland... Om man är flera personer som jobbar på projektet, och en del av dem inte är programmerare, t.ex. Men det är viktigt att tänka på vad det är för data, och hur man vill jobba med den... Om datamängden är stor, eller den inte behöver kunna redigeras för hand, då är ju ett binärt format det bästa - snabbare laddning är trevligt bara det. Att ha en specialskriven editor för att redigera datafiler är ett måste om man har störe team med många som jobbar med det - annars kommer det garanterat att uppstå fel. Men för de tillfällen då man inte har resurser för att skriva och underhålla en specialeditor, och behöver externt lagrad data som kan editeras för hand, är ju nån slags text-baserat format lösningen. Man kan ju använda något enkelt, som gamla ini-filer, men det blir knöligt att uttrycka hierarkiska samband. XML är en kanonbra lösning för detta, då det är en standardiserad form för att uttrycka data och dess relationer. XML är dock ett långsamt format, och blir ännu värre om man använder DOM-läsare som TinyXML, som läser in hela filen och skapar en trädstruktur. Använd en SAX parser istället, som läser lite i taget och låter anroparen sköta lagringen. Mer om det här: http://www.tophatarcade.com/dev/article ... medata.php

När jag jobbade med Hospital Tycoon, så använde vi XML som scriptspråk. Vi började med att använda det för att låta våra designers beskriva patientbehandlingsprocesserna (vilken ordning olika behandlingssteg skulle utföras). De behövde dock mer och mer kontroll, till den grad att de ville kunna ange positioner och animationer för alla aktörer (patient/personal/maskiner/behandlingsrum etc) i en process, och göra saker som att upprepa vissa steg tills ett visst villkor var uppfyllt. Dessa utökade krav kom steg för steg (eftersom mycket av designarbetet gjordes on-the-fly, då vi var sena med projektet innan vi hade börjat på det), så vi gick från enkel, strukturerad databeskrivning, till ett primitivt med kraftfullt scriptspråk. Det fungerade i slutändan ganska bra, men det var svårt att debugga, och vi behövde hela tiden fixa till olika speciallösningar. Så hade det varit bättre att t.ex. använda LUA? Antagligen inte, eftersom ingen av de som skrev scripten var programmerare - de hade fullt upp med att lära sig dom väldigt specifika "kommandon" som vi skapade specifikt för deras behov i vårt "script"-språk - att de dessutom skulle ha behövt lära sig ens ett minimum av specifika LUA koncept hade varit orimligt inom den tid vi hade.

Om jag hade vetat i början vart vi skulle hamna med script-språket på Hospital Tycoon, då skulle jag antingen ha tilldelat en av mina programmerare till att vara exklusivt patientprocess-programmerare under hela projektet - att jobba direkt med designersarna och skriva processerna i C++, eller också ha valt att skriva ett eget, specialiserat scriptspråk för att hantera patientprocesser. För om man ska ha ett scriptspråk för att låta icke-programmerare kontrollera funktionalitet, då ska det vara ett språk som är specifikt anpassat för ändamålet i fråga. Ett generellt script-språk som t.ex. LUA är något man programmerar i, och därför kräver programmerare, och det kommer aldrig att bli lika anpassat för en specifik problemdomän, och därmed inte heller lika lätt att använda för icke-programmerare, som ett specialskrivet språk.

Det är ju också så, att script-språk har sällan eller aldrig samma kraftfulla debugging möjligheter som t.ex. Visual Studio, så innan man bestämmer sig för att ha externt definierad kod (snarare än bara externt definierad data), bör man ta sig en rejäl funderare på varför, och vem som i så fall ska skriva koden. När jag jobbade på Heart of Empire:Rome, så hade vi samma LUA-drivna spelmotor som för Tycoon City:New York - men vi hade inga scriptare anställda för projektet, så det blev programmerarna som fick skriva den spel-specifika koden i LUA. Och dom verkligen hatade det, eftersom dom inte hade samma debugging möjligheter som i C++, och eftersom de inte var lika hemma i LUA som språk. I det fallet fanns det ingen som helst fördel att använda LUA för att scripta scenarion - det hade varit mycket bättre att bara "hårdkoda" dem i spelkoden. Tycoon City-projektet, som ju använde samma motor, använde dock inte LUA för att scripta scenarion (utan bara som datalagringsformat) - där använde man istället Visio (diagramritningsprogram från office-paketet) för att rita upp flödesscheman över scenarion, som sen lästes in av spelet och tolkades om till instruktioner - detta funkade mycket bättre, då designersarna själva kunde arbeta med det.

Om man bara är en ensam programmerare , så är det ofta ingen mening med att använda externa data-definitoner: lägg in det som statiska arrayer/variabler i C++ koden, använd "Edit-and-continue", och kom fort framåt på projektet. Och det finns i princip aldrig nån anledning att ha externt definierad script-kod - skriv funktionaliteten direkt i C++ iställer - det är så man kommer framåt och får till projekt som gör något (t.ex. spelbara spel), och inte bara "frameworks" eller "motorer" eller annan tråkig teknologi som man ändå aldrig kommer att använda till nåt, eftersom det är för klumpigt, tråkigt och besvärligt att skapa de script som behövs för att fylla dem med innehåll...

[VilleK]

Tummen upp för Mattias inlägg. Ingenting är så lärorikt som att höra hur olika lösningar används i konkreta projekt och till vilken grad det varit framgångsrikt.

[TheSpaceMan]

Sedan ibland kommer man ju dock tillbaka till att man känner att resultatet inte är så prio egentligen det är processen att vara i det. Jag har aldrig sagt att xml är en bra utgångspunkt för ett scriptspråk, eller dåligt, känner dock faktiskt inte heller för att dra in lua och köra ett till språk i språket och alla binds och anrop fram och tillbaka.

Tror inte det är något jag kommer återanvända, tror dock inte heller dock att det är något jag vill hårdkoda då projektet då jag inte har en klar vision om hur upplägget ska vara totalt.

Jag kan lära mig mer lua, implementera det och använda det och antaligen känn att jag kunde fortsatt koda det i c++. Det här är mest ett nyfiket försök att göra något annorlunda jag inte gjort innan personligen.

speed är ingen issue för mig heller, och antaligen kommer jag hårdkoda en verison av systemet senare i vilket fall.

[Hildenborg]

Mattias:
Fantastiskt bra inlägg!
Håller fullständigt med.

Och på tal om xml som skriptspråk så ANT är just detta. Och jag vill minnas att jag för några år sedan läste en artikel skriven av en av de som var med och tog beslutet att göra ett scriptspråk för byggsystem baserat på xml, och han ansåg nu när man hade facit i hand att det var ett dåligt beslut.
Allting blev krångligare än vad det från början var menat att bli.
Själv så har jag tittat lite på ANT, och gett upp rätt fort. Känns inte som något man vill lära sig...

[tetsu]

Om du menar Apache Ant, så är det faktiskt något jag gillade. Har inte använt det på ett tag, men det var nog fler än jag som gillade det då även Microsoft kom med liknande byggsystem(MSBuild).

Har du föresten kollat något på XSLT? Beroende vad du skall göra med din XML-data kan XSLT vara något. Jag jobba på ett ställe engång där de använde XSLT rätt flitigt. Jag tyckte de la lite för mycket logik i deras XSLT-script, men det visade i alla fall att man kunde göra rätt så mycket med det.