Stickman Warfare Mod Tutorialok

Egy egyszeru kis oldal leirasokkal, hogy hogyan is modoljuk meg Stickman Warfaret. A tutorialok nem mennek teljes reszletessegbe, hiszen ezt mas mar megtette helyettem. Az ilyen dolgok megtalalhatok a Forrasanyagok pontban. Az itteni iromanyok inkabb hogy-kezdjem-el-es-mit-csinaljak tipusu dolgok lesznek.

A legtobb embert talan ez erdekel, igy ezzel is kezdem. Uj epuletet kesziteni, meglevot kivenni vagy modositani. Az elso lepes termeszetesen kitalalni, hogy mit is akarunk megvalositani. Erdemes papiron rajzolgatni egy kicsit a 3D munka megkezdese elott, ez nagyon sokat tud segiteni. Ha meg van az elkepzelesunk, a Wings3D nevu programot fogjuk hasznalni. A hasznalatrol szamos leiras es video van, meg magyar nyelven is, igy erre nem terek ki.

Ami a modolas szempontjabol fontos az az, hogy a modell ne legyen torz, es ne legyen rosszul texturazva. Ha lapokat vagy eleket latunk, amik semmihez sem kapcsolodnak, lapokat amiknek nincs fekete vonallal hatarolt eluk, vagy modelleket, amiken atlatunk, valami rossz. Erdemes azt is figyelni, osszesen hany lap es hany csucs hatarolja a modellunket. Ahogy szinte minden jatekban, egy modell Stickmanben is haromszogekre osztodik fel. Ha tul sok felesleges csucsunk van, azoktol is szabaduljunk meg. Ez azt jelenti, hogy ha mondjuk egy elen van 4 csucs, amibol ketto a sarka, es a ketto kozteshez semmi sem csatlakozik, toroljuk azokat. Ugyanakkor ne legyen tul sok felesleges lapunk akkor sem, ha nem helytelenul vannak ott. Peldaul ne smootholjuk le a modellt csak azert, hogy jobban nezzen ki.

A texturazas az egyik legnehezebb resz, es oda is kell figyelni, ha azt akarjuk, be tudjuk tenni a modellt a jatekba. Eloszor is, vagy minden felulet legyen letexturazva, vagy egy sem. A programban talalhato paletta szinezese nem megfelelo erre, es hibat is okozhat. A texturakat vehetjuk a jatekbol, a data/textures mappabol, vagy hasznalhatunk sajatot is, de akkor muszaj berakunk okek az elobb emlitett mappaba. A jatek hibauzenetet is dob ha nem talal valami filet. Arra is figyeljuk oda, hogy a jatek nem kezel attetszo vagy modositott feny-elnyeles tulajdonsagu texturakat - erre van sajat rendszere. Ha egy materialt modositunk, hibat okoz. Az is modositasnak szamit ha csak megnezzuk a tulajdonsagait Wingsben.

Ha a modell teljesen kesz, exportaljuk ki .3ds allomanyba, majd ezt a filet konvertaljuk at a jatekhoz szukseges allomanyokba a StickConvert hasznalataval. A kapott fileok maga a modell es a hozza tartozo arnyekterkep. Ezeket rakjuk be a data/objects mappaba. Igy mar majdnem keszen is vagyunk, vagyis a jatek be tudna tolteni a modellt, csak meg kell mondani neki. Ez a data/stuff.json fileban tortenik. Megkeressuk a "buildings": sort. Innen lefele vannak a jatekba betoltesre kerulo modellek. Ahogy latjuk sok csuko-nyito kapcsos zarojel van, koztuk adatokkal. A stuff.json tartalmanak elmagyarazasarol van mar leiras, igy erre sem terek itt ki. Egy meglevo modell mintajara adjuk hozza a sajat alkotasunkat is. Az azonosito neve legyen ugyanaz, mint az .sm0 file neve, amit az objects mappaba tettunk.

Ezek utan ha mindent jol csinaltunk, elso futtataskor a jatek legeneralja a modellhez tartozo szilardsagot, ez automatikusan az objects mappaba kerul .kd1 kiterjesztessel. Ha a modell scalex vagy scaley erteket, esetleg talajhoz valo igazodasat modositjuk, ezt es csakis ezt a filet torolni kell. Hiszen ha az .sm0 vagy lm filet torolnenk, nem lehetne betolteni a modellt. Sot, a modell stuff.jsonbeli tulajdonsagait kedvunkre modosihatjuk.

Mas jatekon beluli epuletek tulajdonsagait is itt, a stuff.sjonban modosithajuk, vagy ha teljesen toroljuk az adott epulethez tartozo bejegyzest, a modell sem kerul betoltesre. Ha csak a filejait toroljuk, az hibauzenetet fog eredmenyezni, hiszen a stuff.json tartalmat a jatek keresi, de a fileokat nem talalja hozza.

A modolashoz hihetetlenul sokszor kell a stuff.json tartalmat atirogassuk. A jatek mukodesehez szinte minden itt van leirva es rendszerbe szedve. Itt adhatunk hozza vagy vehetunk el dolgokat, itt modosithatjuk a mar bent levo dolgok tulajdonsagait is. Azonban a file tartalma nagyon fontos, hogy helyesen legyen leirva, kulonben a jatek el sem tud indulni. Ehhez hozzatartozik a szamtalan kapcsoszarojel, kettospont, idezojel es vesszo, meg mindenfele mas szempont. A "stuff.json ertelmezese" tutorialsorozat alatt ezeket a szintaktikai szabalyokat akarom elmagyarazni.

Kezdjuk a talajmodositokkal, mert az elegge egyszeru, de egyben hasznos is. Ezeknek az a lenyege, hogy anelkul kilapitjak/emelik/sullyesztik a foldet, hogy egy modell lenne ott. Ehhez nem is kell nekik mas tulajdonsag, mint hogy hol vannak es mekkorak (illetve a nevuk es egy extra). A stuff.jsonban "terrain_modifiers" cimszo alatt vannak, vagyis a jatekba a "terrain_modifiers" valtozotomb elemeikent toltodnek be. Latjuk, hogy itt szogletes, nem pedig kapcsos zarojel nyilik. Ez azert van, mert ez nem egy cimszavakkal indexelt tomb, hanem egy halmaz. Peldaul epuleteknel majd latunk peldat indexekre. Itt az egyes talajmodositok csak egy kapcsoszarojelparon vannak. A jatekban elfoglalt poziciojuk az x, y es z koordinata ertekek, a nagysaguk pedig a radius. Az offset azt jelenti, hogy mennyire legyen meredek az atmenet a terepmodosito kozeppontja es korive kozt. A name pedig ertelemszeruen a pont neve, az egyedi azonositoja. Ezeknek az ertekeknek egyuttese adja meg egy talajmodosito jatekbeli osszes tulajdonsagat. Nem kell a jatek mas filejaihoz nyulni vagy barmit is modellezni. Ezek az ertekek az egyes talajmodositok valtozoi. Peldaul a meret a radius valtozo. Ezeknek a valtozoknak itt, es mashol is vannak tipusaik. Peldaul itt a nev tulajdonsagon kivul mindegyik szam tipusu valtozo, a nev pedig szoveg tipusu. Ezen kivul van meg peldaul a logikai ertek tipusu valtozo, aminek erteke lehez true vagy false, vagyis igaz vagy hamis.

Ahogy az epulet lerakos leirasban irtam, egy jatekba kerulo modell nem kerul betoltesre, amig nincs a stuff.jsonban. Ezek a bejegyzesek mar valamivel osszettebbek mint a talajmodositok. Nevezzuk is neven oket: objektumok. Mar a talajmodositok kis zarojeles tulajdonsagegysegei is objektumok voltak, sot, maguk a "terrain_modifiers" vagy "buildings" is. Ahogy egy objektumnak lehetnek egyszeru valtozoi mint egy szam vagy szoveg, ugy lehetnek objektum tipusu osszetett valtozoi is. Peldaul a "terrain_modifiers" elemei az egyes talajmodosito objektumok. Hasonloan a "buildings" elemei az egyes epuletek objektumai. Azonban irtam azt is, hogy mig a talajmodositok egy halmaz, a "buildings" egy indexelt tomb. Az indexek az egyes epuletek nevei, de ugyanugy objektumok, mint a talajmodositok. Csak eppen mas valtozoik vannak. Latjuk, hogy itt is van x, y es z koordinata, meg egy halom masik szam tipusu valtozo. Ami nekunk uj, az az, hogy itt a pozicio koordinatak egy masik, "position" objektum elemei. Ez az objektum egy halmaz, es latjuk is, hogy szogletes zarojellel kezdodik. Pont ugy, mint a "terrain_modifiers". Hasonlo nehany epulet eseteben a "special" valtozo, ami egy masik halmaz objektum. Ebben szoveg tipusu elemek vannak. Vegyuk eszre, hogy itt nincs ertekadas. Eddig ha egy valtozot neztunk, peldaul a pozicio koordinatait, mindig "valtozo kettospont ertek" ahogy kinezett. De "special" alatt csak szovegek vannak felsorolva. Akkor ezek mihez is vannak tarsitva? Magahoz a "special"-hoz. Ahogy a "position" elemei objektumok, es azok sincsenek egyesevel indexelve. Szoval a "position" objektum elemei mas objektumok. Ezek az ugynevezett beagyazott, egymasba agyazott objektumok, tombok, halmazok. Fontos, hogy egy beagyazott dolog nyitozarojelehez meg a beagyazas szintjen kell tartozzon egy csukozarojel. Ha megnyitom egy modell "position" objektumat, nem csukhatom be a modell csukozarojele utan.

A scriptrendszer a modolas egy sarkkove. Az embernek szinte itt van a legtobb szabadsaga, hogy meroben uj dolgokat keszitsen, a jatek viselkedesen modositson, es meg nem kell hozza sok programozasi tudas. A "scripts" es "triggers" objektum ket indexelt tomb, alapbol mindketto ures. Indexelt objektumokkal tolthetjuk fel oket. A "scripts" objektum indexei az egyes scriptek azonositoi, ezeknek az objektumoknak az elemei a script sorai. Ugyan eddig mindig fontos volt, hogy milyen valtozok vannak egy objektumban, mint peldaul poziciok koordinatai, itt csak az ertekek szamitanak majd, a valtozok nem. A scriptrendszerrol mar Hector irt egy leirast, ennel jobbat en sem tudnek, igy nem errol fogok most irni.

Egy scriptet tobbfelekepp is meg lehet hivni. Ha egy scriptet meghivunk, az lefut, azaz kiertekelodik. Egy egyedi script, a "startup" azonositoju script minden esetben lefut a jatek inditasakor. Itt lehet valtozokat felvenni peldaul. Lehet a bind paranccsal gombnyomasra is scriptet rogziteni, illetve lehet triggerekhez scripteket tarsitani. A "triggers" objektum eredetileg ures, mi tolthetjuk fel indexelt objektumokkal. Ezek az indexek legyenek egyediek. A tulajdonsagaik ertelemszeruek, hasonloak mint egy talajmodosito. Ami ujdonsag, azok az "ontouch" es "onuse" valtozok. Ide azoknak a scripteknek a neveit irjuk, amiket futtatni akarunk ha belepunk a trigger radiuszaba, illetve ha F-et nyomunk a radiuszon belul. Ha jol emlekszem van "onleave" is, ha elhagyjuk a radiuszt, de sosem probaltam ki.

A script es trigger rendszerrel szuper dolgokat lehet csinalni. Peldaul mint a husveti tojaskereses. De tegyuk fel, hogy szeretnenk csinalni egy modot, amiben autoversenyezhetunk masokkal. Csinaltunk egy modellt egy jo kis palyaval, de akarjuk, hogy legyenek checkpointok a palyan, amiken muszaj athaladni, hogy a celbaerkezeskor kapjunk egy uzenetet, biztositva, hogy senki sem csalja le a palyat. Ehhez a "startup" es nehany egyedi triggeres scriptet kell irnjunk.

Eloszor csak tegyuk be a "startup" scriptet. Vagyis a stuff.json beli "scripts" objektumnak adjunk egy masik indexelt objektum valtozot, aminek az indexe startup. Igy "scripts":{} helyett "scripts":{"startup":{}} lesz. Erdemes ezeket uj sorokba irni, hogy atlathatobb legyen. Ezutan kell majd egy szam tipusu valtozot felvenni, hogy a jatekos hanyadik checkpointnal tart. Az elso checkpoint ertelemszeruen a start, az utolso a cel lesz. Egy valtozot felvenni egy sor, a "startup" objektum egy eleme. Igy nez ki: 0:"var %valtozoneve". A 0 itt barmilyen szam lehet, en megszokasbol ha uj valtozot veszek fel, azt nullas sornak irom. valtozoneve helyett legyen mondjuk check. Ezutani uj sorban adjunk neki erteket. 1:"%check = 0". Fontos mindent szokozokkel elvalasztani, es a %-t is kitenni. A soreleji 1 nalam azt jelenti, hogy valtozonak adok kezdoerteket. Ismet, ez lehet barmi ami tetszik. Ezutan kovetkezik a "startup" zaro kapcsos zarojele.

De kell egy script is, ami ugye noveli a %check erteket ha atmegyunk egy checkpointon. Adjunk egy uj elemet a "scripts" objektumnak, vagyis a "startup" csuko kapcsoszarojele utan irjunk egy vesszot, majd egy uj indexelt objektumot. Igy: "scripts":{"startup":{...},"checknovel":{}}. Persze ... helyett a "startup" tartalma az elozo nehany sor amit irtunk. "checknovel" tartalma egyszeru, csak novelni kell a valtozot. Igy: 4:"%check = %check + 1". A szokozok es jelek itt is nagyon fontosak. A negyes a sor elejen nalam az "egyeb utasitas" jele, vagyis ha valami egyertelmuen vegrehajtodik.

Most azt kell elerni, hogy ez a script fusson le amikor kell. Ehhez hozzunk letre uj triggereket, es tegyuk le olyan x,y,z koordinatakra, ahol a jatekon beluli checkpointokat akarjuk. A triggereknel az "ontouch" valtozo erteke legyen "checknovel", hiszen ilyenkor akarjuk futtatni. Az utolso checkpointhoz, vagyis a celhoz azonban egy uj script kell, ami, ha az ember minden checkpointon atment, gratulal, ha nem, akkor pedig informalja a versenyzot.

Ehhez vegyunk fel egy uj scriptet "scripts"-be, vagyis egy uj indexelt objektumot. A neve (indexe) legyen "celcheck". A tartalma pedig egy logikai kapu, egy if-else lesz. Ha peldaul 10 checkpointon tudtunk athaladni, akkor igy: 2:"if %check > 9". Ezzel azt nezzuk meg, hogy legalabb 10 checkpointon athaladtunk. Ha ez igaz, akkor a 3:"endif" sorig levo utasitasok fognak lefutni. Ez a logikau elagazas igaz aga. Ha mi egy hamis agat is be akarunk szurni, akkor meg a 3:"endif" sor elott kell egy 2:"else" sor oda, ahol az igaz ag veget er. Utana a 3:"endif" sorig fog tartani a hamis ag, vagyis ha nem mentunk at legalabb 10 checkpointon. Az igaz agba es a hamis agba is egy-egy szovegkiirast forunk irni. Az igaz agba keruljon 4:"fastinfo Gratulalok!" a hamisba pedig 4:"fastinfo Kihagytal $_ valamit!". A $_ a szokoz jelolesere szolgal. Ha nem tennem oda, a szoveg ami a jatekban megjelenik "Kihagytalvalamit!" lenne.

Ezzel meg is vagyunk. Persze igy ha valaki ugy dont, egy checkpointon tobbszor athalad, azzal mindig novelni fogja a szamlalot, es igy is csalhat. Erre megoldas minden checkpointra egyedi scriptet triggerelni, ahol megnezi, hogy ha valamelyik checkpointon vagyunk, csak akkor novelje %check erteket, ha az sorszam-1. Vagyis minden triggerbe kellene egy if egyedi ertekekkel. Sajnos ez egy hatulutoje a scriptelesnek, hogy vannak dolgok, amiket csak nagyon korulmenyesen lehet megoldani.