köszi, megnézem

Az eltének van egy lua oktató oldala.
Nincs kizárva, h oktatják is

Sziasztok!

Hol lehet idehaza LUA scriptet tanulni?

Pretender: Ehhez már fordítóprogramot kell fejleszteni. Egyszerű esetben nem olyan nehéz, de elég mély a téma. Lexer, parser, interpreter. A suliban majd fogsz róla tanulni és egy egyszerűbb elemzéssel meg is valósítani egy kis nyelvecskét talán az ANTLR közbeiktatásával, ami már a lexer és parser-t meg is oldja helyetted.

Syam: Én olyasmire gondolok, hogy írom a rendszert, persze alapos tervezés után és menet közben integrálgatom a scriptet, tesztelek. Valamennyire időtálló, sőt 1-1 alrendszer nem is nagyon változna később. Csak mivel mindent magamnak írok, nem biztos, hogy megéri és összességében nem biztos, hogy gyorsabb a fejlesztés, ha a teljes játéklogikát scriptelem, mintha C++ ban írnám, de minden kis fingnyi változtatás után fordítás lenne.

Itt ahogy olvastam mindenki oda van a scriptől, meg vissza, akkor is ha saját motort fejleszt.
Szerk.: Jövőre indítok ilyen projectet, ha mást nem majd én számolok be, hogy mennyire éri meg.

Én erről nem is tudok sokat... anno úgy oldottam meg a "scriptelést", hogy szövegesen beolvastam a parancsot, meg a paramétereket, és külön-külön lehetett minden egyes parancshoz rendelni egy konvertálós és végrehajtó függvényt.
Pl. volt az a parancsom, hogy

Abból beolvastam, hogy command = player_spawn, parameters[] = "0", "0", "0", "5"
Volt egy dictionary-m is, ami megadta, hogy mit kell hívni az adott parancs esetén. Meghívtam azt a két függvényt


Node kizárt, hogy ezt így szokták (így pl. minden egyes parancshoz írni kell két függvényt, változókat eltárolni, stb.), szóval hogy érdemes ilyet írni?

Szerintem ez attól függ, h az engine egy vagy több játékra lesz tervezve.
Utóbbi esetben az engine-t gyaklag csak modolja az ember amihez pedig minél nagyobb szabadság kell, amit a script tud (csak) nyújtani az engine átírása nélkül.

Viszont utólag megírni a script bind interface-t az egy halál...

Idézet

---

Parallax :

Idézet

---

barack1 :
Kész engine-t nem is nehéz scriptelgetni, a finom feladat az, amikor magadnak írsz mindent.

---

Annak azért már nem sok köze van a scripteléshez.

---

Akkor talán itt jobb helye van ennek a problémának. Engem érdekelne másoknak mi a tapasztalata. Megéri e a script integrálással való munkát (binding, felület írás) az a gyakorlatilag egyetlen előny, hogy gyorsabb játék logikát írni, vagy engine-t tesztelni? Ez arra az esetre vonatkozik, ha kis csapat van pár fő, vagy csak 1-2 programozó.

Idézet

---

dvorgaz :
LuaBind-nál a függvények importálásához/script futtatásához kell ugy egy ilyen:

Kód:

  // Create a new lua state
  lua_State *myLuaState = lua_open();

  // Connect LuaBind to this lua state
  luabind::open(myLuaState);

  // do stuff...

  lua_close(myLuaState);

Ezt minden alkalommal el kell játszani mikor scriptet futtatok, vagy mondjuk a program elején létrehozom ezt a luastate-et meg exportálok c++ függvényeket, aztán majd kilépéskor meghívom a lua_close()-t?

---

Én utóbbit csinálom, de szerintem létezhet olyan eset mikor az elõbbi is hasznos lehet.

LuaBind-nál a függvények importálásához/script futtatásához kell ugy egy ilyen:



Ezt minden alkalommal el kell játszani mikor scriptet futtatok, vagy mondjuk a program elején létrehozom ezt a luastate-et meg exportálok c++ függvényeket, aztán majd kilépéskor meghívom a lua_close()-t?

Az ilyesmi policy függõ, abban az esetben amit írtál emlékeim szerint a copy az alap policy. A policy-krõl itt olvashatsz.

Hello, bekötöttem egy MyResourceManager nevû (ResourceManager típusú) objektumot Luába LuaBind-dal:



Ilyenkor tényleg cím szerint adja át a scriptnek (tehát nem jönt létre belõle másolat), vagy bemásolja valahova a scriptbe is? Pl. mennyire hatékony, ha nagy mennyiségû adatot szeretnék így átnyomni a scriptnek?
Azt próbálgattam, hogy bekötés után változtatgattam az objektum egy tagváltozóját C++ból és scriptbõl is, és mindíg "szinkronban" voltak a scriptbeli és kódbeli változók, de nem egyértelmû, hogy ez amiatt van-e, hogy pointerrel lett átadva, vagy azért mert külön szinkronizálja õket.

Ez is szin ... de ugye Red Green Blue Alpha ... nahh de az utolso az alpha? vagy az elso? (kozepre enm szoktak tenni ))
ezert jo ha leirod, mert ezt egybol nem fogod tudni ... amelett van ahol nem RGB-t kernek, hanem BGR-t ... szoval )))

Idézet

---

twilek :
haaat

akkor ez vajon mit jelenthet? lamp0001={1, 1, 1, 0}
? ))

---

Ez így nem ér, a színnél könnyebb 3 számot beazonosítani! (way túúúúl sarkos a példád)

Pedig en tenyleg javaslom ... de valo igaz, hogy draga. 100$ = 18.000 huf (kb )) ez a dolog bosegesen meger ennyit .. tenyleg nagyon nagyon hasznos ...
ami nagyon jo benne:
alt+shift+g -> feljon egy ablak, ami a projectben talalhato osszes filet tartalmaza, ahogy gepelsz ugy szuri a listat, enterre a fjalhoz ugrik
alt+m -> lenyilik egy ablak, a fajlban levo fuggvenyekkel, gepelsz, szur, enter oda ugrik
alt+g -> valtas header es cpp kozott / ujabb verzioban mar inl -t is kezel

a faj llistahoz hasonloan van fuggveny lista is egesz soulution ben ... refeneciak, hivas listak, minden .. renegeteg nagyon hasznos funkcioja van, amibol mar az elso 3 miatt erdemes )))

szoval nagyon nagyon nagyszeru kis tool .. a code complite rol nem is beszelve ...
beirsz neki .. pl:
for ENTER
for( ITT A KURZOR )
{

}

switchre, exception re .. de te bovitheted alistat ... elkepeszto ..
Nahh de ez nem a reklam helye, bocsi, tobbet nem irok

Idézet

---

fpeti :
Nekem a VS intellisense bõven elég.. de az mondjuk nem ennyire szép színes

---

Nézd csak végig a feature listát. Én konkrétan lementem hídba mikor megláttam a cuccot egy videón mûködésközben. Elõtte a VC#-ra irigykedtem mert baromi gyorsan és kényelmesen lehetett a fejlesztõkörnyezet miatt dolgozni benne, de az a VA-hoz képest vicc. Ezért nem merem a trialt kipróbálni.

haaat

akkor ez vajon mit jelenthet? lamp0001={1, 1, 1, 0}
? ))

A visual assist sokkal tobb mint az intelisens
nem csak kodot szinez, de fajl megnyitasban is sokat segit .. header / cpp / inl valtasban, fuggvenyhez ugrasban .. a fejlesztest kb 10% al gyorsitja ..

De valo igaz, abszolute fuggoseget okoz!!!! ahol nincs VS ott konkretan mar alig tudok dolgozni ... (((

Nekem a VS intellisense bõven elég.. de az mondjuk nem ennyire szép színes

Idézet

---

fpeti :
ps:
a "Hasznalj Visual Assistot a C/C++ kodokhoz" azt jelentené, hogy ne notepad-ben írjjam be a VC8-nak a kódot? - húú, ettõl nem kell félni, olyan elvetemült azért még nem vagyok

Üdv.

---

Sztem a Visual Assist alatt ez volt értve. Már évek óta nézegetem de még nem volt rá felesleges 100 dollárom, a trialt meg nem merem letölteni mert könnyen megeshet hogy függõséget okoz és akkor le kellene warezolnom amit meg nem szeretnék.

Deeee neeeem,
a programozó nem gépel fölöslegesen, fõleg, ha nem muszáj -szerintem.
Tehát nem azt írtam, hogy nem akarok, vagy nem szeretek, csak "fölöslegesen gépelni" nem szeretek, az egyik alapigazság: a jó programozó lusta - itt megint nem arról van szó, hogy nem csinál semmit, hanem, hogy fölöslegesen nem dolgozik, de nem kell ezt magyaráznom.
Egyébként meg egy színmegadásnál mit is jelenthetne 3 szám, mint rgb? (néha jelenthetne gbr-t is, de ehhez elég izének kell lenni. )
Teljesen egyetértek a szabatos-kódolással, én pl sokat kommentelek a kódban.
Ha belegondolok, hogy pályánként x1000 lámpánál kell begépelni, extra sorokat, elég rossz lesz, azon kívül a fileméret is növeXik.

Nem tudjátok ám (méég), micsoda 'super' kis rendszerem van a' egészre, de leírom, le én:
- van egy pályaszerkesztõcském, nem tud sokat, objektumokat lehet vele pakolgatni, meg lehet írni bármelyiknek scriptet, amit egy kis ablakba lehet beírni, na ott alapból kiesik minden syntax-help, mert az egy sima textbox.
Na itt nem kéne túlgépelni magunkat, valami ilyesmiként kell beírni a Kriptet:

minden objektumhoz külön scriptrész kapcsolódik, ezek nem egy lua fileban vannak, hanem a pályaleíró binárisban, a többi objektadattal együtt.

Amikor eljõ' az engine ideje, akkor fogja a pálya-filet, megkeresi az összes scriptet, és feldolgozza úgy, hogy a @-k helyére behelyettesíti a 'name' paraméretét, és ezt kiírja a tábladefininícióval egy temp .lua fileba (tegnap megtudtam, hogy nem muszáj fileba, a luaL_loadbuffer()-rel is lehet karaktertömbbõl! - majd)

Ezt szépen átadja a luanak, ami compilálja, az objektumok meg a neveik alapján lekérik a lua-tól az adataikat - esetünkben ez egy point-light fényforrás - és tádám, lõ a világosság
- ebbõl körvonalazódhat a lua-rendszerem, most csinálom éppen a másik felét, nem a legprofibb megoldás fényenként begépelni - de 2100 elõtt akarék már egy futtatható exe-t a kisközönség elé présente.. szóval értitek, nem élünk örökké, sietünk, még ha nem is látszik

Szvsz bármilyen birkatürelmû szkriptert kiborítana, ha @.color = {1,1,0} helyett mindíg
lamp001.red = 1
lamp001.green = 1
lamp001.blue = 0
sorokat kéne beírnia... sokkal tovább tart, de amúgy minden igaz, amit leírtál.

ps:
a "Hasznalj Visual Assistot a C/C++ kodokhoz" azt jelentené, hogy ne notepad-ben írjjam be a VC8-nak a kódot? - húú, ettõl nem kell félni, olyan elvetemült azért még nem vagyok

Üdv.

Hi

Hat csak jotanacs:
1. ott a luaplusz, ahoz irhatsz sajat wrappert, megkonnyiti az eleted, de a stack kezelese is sokkal egyszerubb ...
2. egy programozo nem gepel feleslegesen .. az elso pelda amit irtal: lamp001.color={1,1,0} egyszeruen nem jo ... a 2. a megoldas, ugyanis 1 honap, 1 ev utan azt sem fogod tudni mi azaz 1,1,0 ...
Torekedj MINDIG arra, hogy a kod atlathato legyen, meg sokkal kesobbi visszaolvasaskor is, ne csak neked, de masnak is. Ezert a jobbik megoldas a :
lamp001.red = 1
lamp001.green = 1
lamp001.blue = 0
igy ranezesre fogod tudni, hogy micsoda .. foleg ha a lamp001 nev helyet inakbb egy normalis nevet adsz neki ...

Hasznalj Visual Assistot a C/C++ kodokhoz (meg amihez meg kell ) a lua hoz valami kiegeszitos editort... es akkor kevesebbet gepelsz, viszont atlathatobb lesz a kod ... (amugyis egy programozo ne mondjon sose olyat, hogy nem szeret gepelni .. epp csa kez a munkaja ))

Szerintem ne bonyolítsd az életed, sokkal olvashatóbb is a mûködõ megoldásod.

LUA gyakorlati bibim van:
kicsi tábla, benne egy fényforrás pár adata, a 'color' adatainak beolvasásával nem boldogulok, csak, ha van a color tábla elemeinek is neve.
Ilyen a tábla:


color beolvasó kód:

ezután kellene kiolvasni a color elemeit, mint egy tömböt, de a
lua_rawgeti(L,-1,1); mindíg nil-t rak a stack-top-ra (a 2 tábla benne van a stackben, ellenõriztem: table,table,nil a stack, miután a rawgeti-t meghívtam.)

ps:
lamp001.color={r=1,g=1,b=0}
ha így írnám menne "r","g","b" elemeket lekérve, de így túl sokat kellene gépelni fölöslegesen

A szkriptnyelvekrõl annyit, hogy már a Quake játéklogika részét is quakec-nek nevezett c-re hajazó szkriptnyelvben írták, az UT-nek java formájú, a Wow kliensének a guija paraméterezhetõ, szkriptelhetõ luában, a Crysys logikáját is luában írták, nemrég valaki az EVE Online kliens oldali elõfordított python kódjára eresztett egy decompilert (pedig a python egy nagyságrenddel lassabb, mint pl. a lua), és aki megnézi, meglátja, hogy ott is gyakorlatilag a teljes kliens oldali játéklogika python-ban van.

Ezek után gondolom nem meglepõ, hogy az én véleményem az, hogy ahova nem kell a sebesség vagy magasabb szintû logika kell, oda szkript. Gyorsabb, egyszerûbb a fejlesztés, és újrafordítás nélkül lehet cserélni a "kódot" a játékban (a C++ fordítás baromi lassú) - akár menet közben is (szerver!). A lua szerintem is zseniális, amilyen pici, olyan sokoldalú tud lenni; akár OO is megvalósítható vele (többféleképpen is).

Pont én is most lua-zok, én pl csak az eseményekre adott választ adom meg lua-ban, de minden akció cpp-kódban lesz, de, hogy mi, azt a lua dönti el. - nekem a legtöbb bajom mostanában a lua-cpp közötti adatkonzisztencia volt, pl nem akanék egy kapcsoló minden kirajzolásánál lua-t hívni, hogy be vagy ki van-e kapcsolva, mit rajzoljon ki. Persze így mind lua-ban, mint cpp-ben meg kell lennie a kapcsolók állásának plö, erre vigyázni kell. De így csak a spec események váltanak ki lua-futást, az meg viszonylag kevés idõ.
- ezzel persze a motor alakíthatósága csökken (nem tehet akármit a szkript, csak váltogathat).

Apropó grafika gpu-t használ: dx9 esetén framenként 2-300 draw 1 gigaherz-nyit vesz le a cpu-ból (50 fps esetén), sajnos a d3d eszi a cpu-t is rendesen..

Ps. kezd megtetszeni a LUA, elõtte voltam oly hunczut, hogy írtam saját Kriptnyelvet, hát elég sittes lett , a lua meg olyan, hogy szinte bármit beírhatunk neki, mindent jól le tud fordítani, respect a kitalálója elõtt, állati összetett nyelv 'ahhoz képest', sokkal közelebb állhat a syntax egy nem programozó beállítottságú emberhez, mint mondjuk a C.
Még egy érv mellette, talán a közös nevezõ is lehetne: felgyorsítja a fejlesztést (remélem), az idõ meg tudjuk mi az iparban. (pénz gy.k.)

Az utolso mondat: PONTOSAN )) akinek ami tetszik az a szep megoldas ugyis.
A script nyelvek nyujtotta elony vitathatalan. Ha a kodod kivulrol erkezo scriptnyelvek altal vezerelt, akkor az nagyon jo. De azert van am sok minden egy jatekban ami nem a gpu-t zabalja
AI, Game code, Widget system ( widgetbol attam olyat ami megevett egy eros gepet ))
nehez a dontes mit erdemes, en szemelyes velemenyem, hogy nem allnek at full script vezerlesre

Idézet

---

twilek :
Hi

Ide is beledumalok
Szoval. A script nyelvekkel vigyaznek a magam reszerol. Az UT engine is a sajat script jevel dolgozik, viszont, ott is bebizonyosodott, es szerintem mindenhol mashol is igy van, hogy a script nyelvek sokkal lassabbak mint a C++ kod. Ez fix.

---

Ez tény. Bár a LuaJIT-es Lua már nincs nagyon messze a C# + Mono kombótól sebességben. Az UnrealScript meg még ennél is jóval lassabb. Akkor vajon miért erõlteti Sweeney annyira? Azért mert processzoridõ az van bõven, a script meg futhat a rendereléssel párhuzamosan is. A CPU-t úgysem használja semmi más max a fizikai motor de lassan már az is a GPU-ra kerül (lásd a Havok Intel által lelõtt kísérletei vagy a PhysX portolása Cuda-ra). A többi mint hangrendszer és társai meg elhanyagolható mennyiséget esznek. És azok is mehetnek külön szálban. Beépített scriptelési lehetõség kell, sokkal kényelmesebb a DLL forgatásnál. A Source is ilyen DLL alapú és nem véletlen hogy egy halom modder azzal kezdte hogy Lua támogatást épített bele. Pl.: Garry's Mod. De ott van még Lua téren a Far Cry/Crysis duó vagy szélsõséges példának a Psychonauts ami másfélszer annyi Lua kódot tartalmaz mint C++ t. Ahogy észreveszem manapság már nem megy a sebességhajhászás, 60FPS felett úgyis mindegy (sok motor alapból ennyire van limitálva, hiába engedné a hardware akkor sem megy többet), azt az idõt meg el lehet pazarolni arra hogy szép, igényes de lassabb rendszert rakjanak össze. De az egész felfogás és hozzáállás kérdése, mindenkinek más a szimpatikus, mindenki tegyen úgy ahogy neki tetszik.

Hi

Ide is beledumalok
Szoval. A script nyelvekkel vigyaznek a magam reszerol. Az UT engine is a sajat script jevel dolgozik, viszont, ott is bebizonyosodott, es szerintem mindenhol mashol is igy van, hogy a script nyelvek sokkal lassabbak mint a C++ kod. Ez fix.
Ezert a kritikus pontokon nem teheted meg, hogy script nyelvet hasznalsz, legalabbis olyan scriptet nem, amit nem forditasz le binarissa, esetleg konvertalod forditaskor C++ ra majd binaris ... mert tul lassu. emelett az interpletalt nyelveknek az ahatul utoje, hogy futas kozben dobnak hibat. Ha van egy komoly jatekot, akkor nem lehet olyan hibaja, hogy csak jatek kozben jon elo, mert elirtal valamit a scriptben, esetleg nem jo fajta erteket kapsz meg ...
a script nyelveket inkabb csak kiegeszitonek erdemes hasznalni. Komplett ai-t nem erdemes irni benne, mert ahoz is tul lassu. Jelenleg mar minden morzsta inkabb a 3D megjelenitesre kell aldozni.
amelett egy C++ kod ugyan olyan olvashato, sott, inkabb olvashatobb, mint egy lua kod (habar ez gusztus dolga )), az, hogy dll ben van annyiban konnyiti a dolgot, hogy akar ujra inditas nelkul is lecserelheto, akarcsak egy script fajl. Viszont nagysagrendekkel gyorsabb egy scriptnel.
Szoval en csak javaslom, de a scriptet probaljatok minnel jobban a hatterbe szoritani, mert (egy mai jateknal mar fontos) ugyis rengeteg mindent fog csinalni es az eleg eroforras zabalo .. az osszes tobbi pici cpu idot pedig a 3D megjelenitesre es a game code ra aldozzatok, attol lesz tobb egy jatek

(Hozzátenni nem tudok, de dúrva, hogy benne hagytad a flexes emailcímeket.)

mind1, megoldottam

Jó volt.

Huhh, ez tényleg hasznos volt

Köszönöm a kimerítõ választ

Általában a koncepció minden csapatnál egyedi, hogy két szélsõséget említsek: a CryTek a FarCry és a Crysis esetében is a komplett játékmenetet és a multi-t Lua-ban írta viszont a Valve Source motorja klasszikus értelemben nem scriptelhetõ, õk mindent C++ ban írnak és DLL-ekben gyûjtenek mert szerintük ez a leggyorsabb (ami igaz is de annyival nem gyorsabb hogy a rugalmasságot fel kelljen áldozni miatta). Én speciel a CryTek filozófiáját érzem közelebb magamhoz. Te magában a motorban legyártod a keretet de ez a keret önmagában nem csinál semmit, a scriptek fogják élettel feltölteni. Nálam jelenleg a kódban öt pont van ahova scripteket lehet beszúrni végrehajtás szempontjából (Init,Reset,Delete,Invalidate,FrameMove), ha a kód valamelyik ponthoz ér akkor szól a scriptrendszernek ami pedig üzen a betöltött fõscriptnek. Innen scriptszinten olyan mintha az ember simán progik írna, van egy fõ függvény ahol a C++ átadja az irányítást, ez a függvény megkapja hogy éppen melyik ponton adta át a C++ az irányítást (olyan mintha simán üzenetet kapna egy C++ progi). Ez a fõfüggvény egyszer van összesen meghívva, akkor mikor legelõször nyúl a C++ hozzá. Ennek meg van az oka, a fõfüggvényben van egy végtelen ciklus (mint a Win-es C++ progikban csak azokban kevésbé végtelen az a függvény), és ez a ciklus van minden egyes futás végén megszakítva. Így a vezérlõscript gyakorlatilag úgy mûködik mint egy egyszerû önálló program. Hogy érthetõbb legyen (C++ példával, a Lua most nem ugrik be):

A megszakítás helyén a kód végrehajtása megáll, majd onnan folytatódik. A megszakításon keresztül lehet értékeket beküldeni a scriptbe.

Lényegre térve: a példádat teljesen le lehet kódolni mondjuk Lua-ban, a játékos is egy Lua osztály, a szörny is és a tárgy is. Innentõl kezdve a kölcsönhatásaik is a scriptben lesznek leírva. A sebzõdés, a plusz erõ és maga az ütés is az elõbb említett scriptbéli osztályok részei. Ezek nem a motor részei hanem mind a játékmeneté. Viszont ezen játékmenetbeli változásokat valahogy jelezni is kell, itt jön képbe az hogy a motor függvényeit lehet hívogatni Lua-ból. Mondjuk a szörnynek véreznie kell mikor megütöd, ehhez utasítod a részecskerendszert hogy adott pontban adott textúrával adott animált részecskéket jelenítsen meg. Az egyik zseniális dolog amit a LuaBind tud hogy megfelelõen felkészített C++ osztályokból tudsz olyan Lua osztályokat származtatni amiknek példányait visszaadva a C++ kódnak a Lua kód fog tagfüggvény hívása esetén végrehajtódni. De azt is lehet csinálni amit te írtál, csak olyankor a játékmenetbeli elemeknek a C++ kódban is létezni kell, és nálam a scriptrendszer lényege hogy a játékíráshoz egy átkozott sort sem kell a motoron módosítani (és ez miatt nem is kell újrafordítani ami 20 percnyi idõ).

Az AI-nál ugyanez a helyzet, lehet úgy is csinálni ahogy te írod de spec. az nem passzolna az én filozófiámhoz. Az AI-nak csak az általános rész kell hogy motorszinten legyen, ez az általános rész pedig kimerül az útkeresésben, az AI többi része stílusonként és játékonként változik így az is inkább a játékmenet részének tekinthetõ. Ráadásul az AI nagyrészt a játékmenetbeli történésekre reagál amik szintén a scriptben vannak. Lényegében az AI akkor kerül csak kapcsolatba a motorral mikor lekérdezi hogy az adott célhoz melyik a legrövidebb út és mikor az adott NPC modelljét a játékmenet történéseihez igazítja (beállítja hogy melyik animáció játszódjon le stb.).

Én így csinálom/fogom csinálni, a Lua elég gyors ahhoz hogy nagy mennyiségû kódot lehessen belõle végrehajtani.

Hello

Mostanában szemezgettem a Lua-val/LuaBind-al, olvasgattam a tutorialokat és tök jó, hogy így scriptbõl lehet C++ függvényeket meg kódból scripteket meghívni, csak az nem jött át igazán rajta, hogy a gyakorlatban hogy is használják a scripteket a játék állapotának/mûködésének befolyásolására.
Például van egy varázsgyûrûm, ami ad +5 erõt, meg mindíg ha egy szörny megüt, akkor a szörny is sebzõdik x hp-t. Ilyenkor nekem kell biztosítanom a script számára megfelelõ c++ függvényeket, amik ezeket a változókat (pl erõ) manipulálják, vagy a script is meg tudja valahogy közvetlenül változtatni? A szörnyet sebzõ hatásnál meg pl. valamilyen eventlistenert kéne csinálni (mondjuk ha megüt, akkor dob egy OnHit eventet, ami meghívja a script OnHit függvényét)?
A másik meg az AI gyakorlati megvalósítása lenne. Gondolom ez valahogy úgy megy, hogy minden ellenfélhez rendelve van egy script, amit minden frame-ben meghívnak és eredményül megadja mit is kéne csinálniuk. De ehez át is kéne adni a scriptnek az egész játék állapotát (npc-k helyzete, állapota, navigációhoz waypointok stb). Ezt így hogyan?

LuaInterface cikk a GameDev.net-en:
http://www.gamedev.net/reference/articles/article2275.asp

BlogSpot-os tutorok:
http://einfall.blogspot.com/2006/05/scripting-with-lua-in-c.html

Rögtön elsõ kérdésként:

A .NET-es LuaInterface-hez tud valaki valami jó doksit?
Esetleg az AngelScript-hez egy .NET-es interface-t?

Hello,

körbenéztem, és azt láttam, hogy még nincsen külön topic ilyen célra.

Ez a topic, a különbözõ script nyelvek gyûjtõhelye lenne:
- AngelScript
- Lua
- Python
stb...