Scriptnyelvek a gyakorlatban …

Rettentően elmés címem mellett valójában azt szeretném ma leírni, hogy hogyan is kell beépíteni a Pythont illetve a Lua-t saját C++ projectünkbe. Ha eddig nem is lett volna egyértelmű, most már biztos, hogy ez megint egy technikai írás lesz, amit remélem sikerül legalább annyira érdekesre, vagy viccesre megírnom, hogy azért ne aludjon el mindenki a monitor mögött.

LUA

Kezdjük először a Lua val, mivel ez a script áll hozzám közelebb és sokkal jobban is ismerem mint a Pythont, így talán a későbbi botlásokat könnyebben elnézik.

A Lua jelenleg az 5.1 es verziónál tart, C ben fejlesztik és egy eléggé egyedi (már a scriptnyelvek terén) nézőpontot támogat, méghozzá a stack kezelést. Gyanítom ebben rejlik hihetetlen sebességének kulcsa.

A sebességnek viszont mindig ára van, jelen esetben a kicsit sem egyszerű C interface, amivel sajnos meg kell birkóznunk.

#include <stdio.h> 
#include <stdlib.h> 
#ifdef __cplusplus
   extern "C" {
#endif // __cplusplus 

 #include <lua.h> 

#ifdef __cplusplus
    };
#endif // __cplusplus 

int main( int argc, char** argv )
{

    // Lua VM letrehozasa   
    lua_State* State = lua_open();

    // Lua alap libek betoltese 
    lua_openlibs( State );

    // myfile.lua fajl futtatase 
    lua_dofile( "myfile.lua" );

    // MyFunc fuggveny elovetele
    lua_getfield( State, LUA_GLOBALSINDEX, "MyFunc" ); 

    // elso parameter 
    lua_pushinteger( State, 10 );

    // a MyFunc fuggveny felhivasa 1 parameterrel, 0 result al 
    lua_call( State, 1, 0 ); 

    // Lua State lezarasa 
    lua_close( State ); 

    return 0;
}

Mint a kódon láthatjuk egy egyszerű függvényhívás is már egy összetettebb probléma, hát még az objektum orientált függvények, tömb, table változók.

Szerencsére vannak megoldások arra, hogy a Lua is elfogadható és könnyen használható legyen. Mivel a projectekben fontos az, hogy ne hetek, hónapok menjenek el egy egy feladattal, hanem minél rövidebb idő alatt álljon elő olyan eredmény, ami kielégítő működést ad, ezért nem mindegy, hogy mennyire nehézkes a választott scriptnyelv importálása az alkalmazásunkba.

A Lua általam legkedveltebb C++ interface-e a LuaPlus. (Dokumentáció: http://wwhiz.com/LuaPlus/LuaPlus.html)

A LuaPlus al sokkal könnyedebbé válik a Lua használata, úgy, hogy nem vesztünk jelentős sebességet.

#include <stdio.h> 
#include <stdlib.h> 
#include "LuaPlus.h" 

using namespace LuaPlus;

int main( int arcg, char** argv )
{
    // Lua VM letrehozasa es alap libek betoltese 
    LuaState* State = LuaState::Create( true );

    // myfile.lua fajl futtatasa 
     State->DoFile( "myfile.lua" );

    // MyFunc fuggveny elovetele 
    LuaFunction<> MyFuncObject = State->GetGlobal( "MyFunc" );

    // a MyFunc fuggveny felhivasa 1 parameterrel, 0 result al 
    MyFuncObject( 10 );

    // Lua State lezarasa 
    LuaState::Destroy( State );

    return 0;
}

Remélem a példával jól látható, hogy a LuaPlus egy sokkal egyszerűbb, érthetőbb interface, mint az alap C Api. Rengeteg olyan lehetőséget biztosít, amivel komoly Lua bindet építhetünk össze úgy, hogy nem megy el rengeteg felesleges idő a fejlesztésre.

Ami még nagyon hasznos a LuaPlus ban, az az, hogy Nativ és Managed kódhoz is van DLL je, így amit C++ alkalmazásunkban használunk, majdnem ugyan úgy használhatjuk C# toolunk ban is! Ez megint csak csökkenti a fejlesztési időt.

Persze ez is olyan, mint sok más interface, az ember szeret belőle sajátot írni, ami jól is hangzik elsőre, de amint próbálunk a Lua C Api mélyére ásni, rá kell jöjjünk, hogy nem olyan egyszerű feladat.

 

Python

A Python jelentősen más fajta mint a Lua. Személyes véleményem szerint itt sokkal inkább a használhatóság, beépíthetőség volt a fő szempont, mintsem a gyorsaság. Ez egyben előnye, de hátránya is a scriptnek. Előny, a már említett fejlesztési idő miatt és hátrány, a sebesség vesztés miatt. A  Python körülbelül 2 szer lassabb és 1.5 ször több memóriát eszik meg mint a Lua, habár vannak esetek, amikor Ő teljesít jobban. Jelenleg ugye a Pythonból úgymond 2 verzió létezik a 2.7 és a 3.2. Az itt megadott mérési eredmények a 3 as Pythonra vonatkoznak: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=lua (az oldal nehézkesen működik, úgyhogy néha sokat kell próbálkozni)

De akkor lássuk hogy is építsük be a Pythont a kódunkba:

#include <Python.h> 

 int main( int argc, char** argv )
{
    // Python VM letrehozasa 
    Py_Initialize();

    // hozzaadas a path hoz az aktualis konyvtarat
    // erdemes azt, ahol a python fajljaink vannak 
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");

    PyObject* ModName = PyString_FromString( "my_file" );

    // a sajat fajlunk betoltese mint modul 
    PyObject* Module = PyImport_Import( ModName );
    if ( Module == NULL )
    {
        // ha nem sikerult volna, akkor error es kilepes 
        PyErr_Print();
        return 1;
    }

    PyObject* Dict = PyModule_GetDict( Module );
    // a fuggvenyunk lekerese 
    PyObject* Func = PyDict_GetItemString( Dict, "MyFunction" );

    // ellenorzes, hogy felhivhato-e 
     if ( PyCallable_Check( Func ) )
    {
        // parameter eloallitasa 
        PyObject* Args = Py_BuildValue( "(i)", 14 );
        // a fuggvenyunk felhivasa 
        PyObject_CallObject( Func, Args );
    }
    else {
        // hiba eseten hiba kiirasa es kilepes 
        PyErr_Print();
        return 1;
    }

    Py_XDECREF( Module );
    Py_DECREF( ModName );

    // VM torlese 
    Py_Finalize();
    return 0;
}

Hát elsőre úgy tűnhet, hogy jóval hosszabb kód állt elő, de ennek egy része a fájlunk és annak függvényeinek betöltése, plusz itt van hiba kezelés is, ami jóval egyszerűbb, mint a Lua ban.

A kódból nekem az jött le, hogy sokkal “felhasználó” barátabb, könnyebb a kezelése, pointerekkel dolgozik, így talán kevesebb objektum létrehozás van, mint a LuaPlus ban.

Konklúzió

Mindazok mellett, hogy milyen komoly szavakat ismerek, azt kell mondjam, hogy mindkét script nyelv nagyon érdekes, a használatuk izgalmas és rengeteg sok lehetőség rejlik bennük. Igazából nem is nagyon tudnék dönteni, hogy most melyik tetszik jobban.

Mindkét nyelvhez található IDE és Debugger is szép számmal:

LUA

  • IntellijIDEA– egy multi platform editor, eléggé sok feature el, LUA supportal, ahol saját(!) libeket lehet hozzá adni (van hozzá WoW és Rift Library). Ez nagyon hasznos tud lenni, mert így a saját projectunk függvényeit könnyedén be tudjuk illeszteni, ami segíti a fejlesztést
  • LuaEdit– teljesen ingyenes és eléggé igényes editor és debugger a Luahoz, solution fájlokat kezel
  • Scite– eléggé komoly, multi platform editor minden féle nyelvhez
  • Addon Studio– érdemes megnézni, mit is lehet csinálni egy IDE vel és egy jó script engine el. Persze ez csak egy editor, de itt látható, hogy a WoW Addon / GUI rendszere mennyire flexibilis
  • LuaStudio– egy eléggé komoly és letisztult Lua IDE és debugger
  • Decoda – sajnos fizetős, de természetesen a legjobb IDE és debugger. Előző írásomban már áradoztam róla. Mindent tud, amit kell, főleg a remote debug a kielégítő benne!

Python

  • GDB– most lehet páran megrökönyödnek, hogy hogy lehetséges, hogy a gdb-t valaha is szóba hozom, de jelenlegi munkám során találkozom vele és nem árt, ha a debugger rendszerekből nincs tíz féle. Persze egy designer vagy tester nem biztos, hogy valaha megbirkózna vele, de ettől még egy lehetőség
  • WinPdb– egy multi platformos Python debugger, persze Python ban. Ingyenes, és egyszerűen mindent tud, amit egy debuggernek tudnia kell, mindamellett, hogy még igényes is! Természetesen alapból remote debugging, úgyhogy nagyvalószínűséggel a szerveren futó Python scripteket is gond nélkül debuggolja
  • PyScripter– open source IDE és debugger, meglepően jó syntax highlight al és code completition el!
  • WingWare – fizetős program nem is próbáltam ki, a WinPDB és PyScripter után azt hiszem teljesen felesleges

 

Mindent összevetve mindkét nyelvhez vannak iDE-k és Debuggerek is, mindkettőhöz jól használhatóak a programok, viszont a Pythonnak 1 nagy előnye van: GDB, hisz nem árt, ha az ember egyből tudja debuggolni, ha akár a saját alkalmazásában hal el a script.

Nekem személy szerint az újdonság erejével tetszik a Python nagyon és abban a szerencsés helyzetben vagyok, hogy szórakozhatok mindkettővel, de hogy melyiket használnám egy projectben … az még számomra is kérdéses, ehhez azért sokkal több konkrétum kell és egy jól megfontolt döntés!

 

Addig is remélem van akinek felkeltettem az érdeklődését az alábbi 2 irományommal és kedvet csináltam némi scriptelgetéshez! Jó szórakozást mindenkinek!

Python, Lua azaz scriptnyelvek

Végre egy technikai téma, mondhatnánk, remélem értelmes lesz mindaz amit itt majd le szeretnék írni.

A mai játékok szép számmal tartalmaznak script nyelveket. Leginkább a Lua vagy a Python nyelv lehet ismerős. Egyre ritkábbak a saját script próbálkozások (mint például az Unreal Script).

Jelen írásomban a Luaról és a Pythonról fogok írni, megpróbálom összeszedni, miért is jó dolog a script, melyik mennyire jó, hol használják és mire.

Sokkal több játékban vannak scriptek, mint hinnénk, hisz a mai modern nyelvek már eléggé jól beépíthetőek, elrejthetőek, viszont vannak olyan esetek is, amikor a script a játék szerves része, a fejlesztők bátorítják a játékosokat, hogy minél több úgynevezett addont írjanak, ezzel is bővítve a játék tudását.

De akkor lássuk is, hogy mi mindenre lehet jó egy scriptnyelv egy program fejlesztésekor, főleg játék fejlesztésekor. Ha valaki ki tudja egészíteni, azt szívesen veszem.

    • Prototipizálás –  egy nagyon jó megoldás, ha a designerek a játék motorját használva egy scriptnyelvel próbálgatják a lehetőségeket. Minél komolyabb Script Engine van a játékunkban, annál több problémát tudnak megoldani, annál jobb utat találnak arra, hogy a játék sikeres legyen. Mivel egy engine-t nem csak egy játékhoz fejlesztünk (többnyire), ha nem is az első, de a második játéknál már egészen biztos behozza a ráfordított időt.
    • Design kódok – egy játék fejlesztése során sok olyan kód készül, amik a designerek kénye kedve szerint változik. Leginkább a skillek, AI vagy épp a GUI ilyen. Ezek legtöbbször olyan feladatok, amik tipikusan egy scriptnyelvnek valók. A játék engine ad bizonyos lehetőségeket a skill, AI vagy GUI rendszernek, ha ezeket a lehetőségeket kivezetjük egy scriptnek, akkor a designerek, vagy GUI fejlesztők átírhatják, alakíthatják ezeket a működéseket. Ez is egyfajta prototipizálás, de kevesebb fejlesztés, viszont általában csak egy projectet szolgál ki.
    • Triggerezés – a trigger rendszer egyik napjainkban elterjedt módja, hogy script nyelveket használnak. Ez komoly szabadságot ad a designereknek arra, hogy a pályákat egyedire építsék. Először egy RTS játékban találkoztam ezzel a megoldással (Codename Panzers: Cold War), ahol nagyszerűen működött. Persze ahol a sebesség mindennél fontosabb, ott erősen meggondolandó, hogy szükséges-e ez a megoldás.
    • GUI rendszer – egyre több helyről hallom, hogy egy játék, vagy program teljes GUI rendszere, logikája, scriptnyelvre épül. Talán a legismertebb példa maga a World of Warcraft, ahol az addonokkal tetszőleges ablakokat, widget elemeket hozhatunk létre és vezérelhetjük Őket, sőt, ha azt akarjuk a Blizzard által biztosított alap GUI interface-t 100%-ig átalakíthatjuk a saját kedvünkre. Ez a megoldás óriási flexibitást ad a GUI tervezésekor, fejlesztésekor, arról nem is beszélve, hogy a játék élettartalmát is képes meghosszabbítani, hisz a játékosok vagy fejleszthetik, vagy a mások által fejlesztett módosításokkal szinte egy új játékot játszhatnak.
      Blizzard FrameXML: WoWWiki –n találhatunk némi leírást arról, hogy mit is alkotott meg a Blizzard. A FrameXML hez hasonlóan ezt a megoldást már több MMORPG nél láttam. Jó megoldás, persze nem kevés fejlesztést igényel, de cserébe egy olyan GUI Rendszert kapunk, amivel bármit meg lehet valósítani és ha ésszel készítjük el, akkor jó sok projectet kiszolgálhat.  (ActionBarFrame)
    • Addonok – na igen, ez egy nagyon általános megfogalmazás, de sajnos nem találtam jobbat. Az addon rendszer nagyon hasznos lehet egy játékban, akár évekkel is elnyújthatja a játék élet ciklusát, jelentős terheket vehet le a fejlesztők válláról, illetve jelentősen csökkentheti a fejlesztési időt. Másik járulék az olyan addon oldalak, ahonnan a játékunkhoz tartozó addonokat letölthetik a játékosok. a Curse oldalán 4.500 WoW addon található, az egyszerű “Hello világtól”, egésszen a Grid nevű addonig, ami eléggé sok mindent tud (és nem mellesleg 4.5 millió (!) letöltése van, ami már egy teljes játéknak is jó lenne, nem hogy egy addonnak).
    • Content – vagy akár Quest rendszer is lehetne. A Pirates of the Carribean nevű játékban volt megoldva az egész játék menet scriptelve. Itt egy C syntax script nyelv volt, amit indításkor fordított le a játék. Rengeteg kiegészítő készült a játékhoz, amivel jelentősen megváltoztatták a játék menetet!

A megvalósítások után nézzük meg, hogy milyen scriptnyelvek vannak, azaz inkább azt, hogy én miket ismerek, amik szóba is jöhetnek.

Arra, hogy mi mindenre képesek ezek a nyelvek nem nagyon akarok kitérni, hisz mindegyik képes C függvények felhívására, ami mindenre képessé teszi Őket. Habár itt felmerül egy bónusz kérdés, mégpedig a C#. Persze nem megoldhatatlan feladat, ha már tudnak native C kódot hívni, hogy C# ot is elérjék, illetve a C# elérje a scriptet, de azért a legjobb az, ha ez a rész már meg van valósítva és mindezt valakik mások valósították meg. (Igen ezen a területen kicsit ellentmondásos vagyok Önmagammal, hisz mindig azt mondom, hogy mindent nekünk kell megvalósítani, akkor lesz kellően optimális, de egy komoly script nyelv elkészítése, a hozzá tartozó összes toolal … nem kicsi feladat.)

Vágjunk hát bele.

 

Számomra legjobban ismert scriptnyelv, a Lua.

A Luanak rengeteg előnye van és alig akad olyan hátránya, amit komolyan fel lehetne neki vetni.

  • Sebesség – rettentően gyors, gyorsabb mint minden más script nyelv, amivel eddig találkoztam. Az alap rendszer nagyon letisztult, nem zsúfolják tele minden féle extra felesleges feature el, ezt meghagyják a betölthető moduloknak
  • Memória használat – ugyancsak verhetetlen, pont azért, amiért gyors is. Az alap rendszer nem sok mindent csinál és amennyire lehet agyon van optimalizálva
  • Binary format – nem is tudom mennyire lehet felhozni ezt előnynek, hisz ma már alapvető elvárás ezeknél a scripteknél
  • User friendly – a Lua nagyon egyszerű, jól átlátható, a számomra általános nyelvekre hasonlít (C, JavaScript, PHP, Java) emiatt könnyen tanulható, de mégsem típusos, nincs benne pointer, vagy bonyolult alacsony szintű adatkezelés, emiatt nem csak programozóknak, hanem designereknek, grafikusoknak, tesztereknek is könnyen emészthető
  • Toolok – a Lua hoz nagyon komoly editorok és debuggerek találhatóak a neten. Egyik személyes kedvencem a Decoda, ami egy eléggé komoly IDE / Dedugger. A Lua VM hez kapcsolódik, így nem kell nekik külön kód support. (Lua Tools)
  • SDK – ez kicsit kétélű a Lua val kapcsolatban. Maga a Lua source szinte teljesen átláthatatlan, viszont készül sok féle C/C++ implementáció (és C#, Java, sőt, még Python is), amik sokkal jobban használhatóak. Személyes kedvenc ismét a LuaPlus. Sajnos binary kiadásban 2010 es a legfrissebb, amit nem is nagyon értek, mert a weboldal logjait nézegetve alig pár napos az utolsó commit. Reméljük az érkező 5.2 es Lua nál frissítik a binárisokat is. (főleg mert a source hoz Jam al kell legenerálni a legeneráló fájlokat, nem is értem hogy jut eszébe ilyesmi bárkinek is …)
  • Multi platform– igen igen! A Lua multi platform. Főleg, hogy a Lua5.1 source-a annyira ansi, hogy szinte bármire le lehet fordítani, de jó sok előre fordított bináris is van. (LuaPlus is fordul Linux alá, némi módosítással). Linux/Windows/Xbox/PS/Kb minden okos telefon
  • Modulok – azt írtam, hogy az alap rendszerbe nem akartak sok mindent zsúfolni, viszont a modularitása komoly figyelmet kapott. Rengeteg modul készült a Luahoz, amivel már szinte bármit meg tudunk csinálni (OpenGL,D3, hálózat, Windows Forms, GTK+, adatbázisok és még sorolhatnám). Saját magunk is nagyon egyszerűen fejleszthetünk hozzá saját modul-t ami így könnyebben portolható a projectek között.

Egyszóval a Lua rendkívül sokoldalú és jól használható script nyelv, rengeteg olyan tulajdonsággal, ami egy játékfejlesztés, vagy bármilyen más fejlesztés során fontos lehet. Az alap C Lua5.1 es kód (most ez a legújabb, de már készül az 5.2, ami most beta), nehezen érthető, nehezen átlátható, nem a legkönnyedebb, de vannak hozzá olyan C++ kiegészítők, wrapperek, amik könnyűvé teszik a használatát, de nem lassítják jelentősen.

Játékok amik biztos, hogy Lua-t használnak:

  • Codename Panzers: Cold War
  • World of Warcraft
  • Warhammer Online
  • Alods Online
  • Rift
  • Sim City 4
  • CryEngine
  • Supreme Commander
  • Heroes of Might and Magic V
  • S.T.A.L.K.E.R.
  • Homeworld 2
  • Maffia II

és még sokan mások:

http://lua-users.org/wiki/LuaUses
http://en.wikipedia.org/wiki/Lua_%28programming_language%29

Nem kevés alkalmazás is a Lua-t választotta, és ami még számomra is meglepő volt, hogy az Apache nak is van Lua module ja és a MySql nek is!

 

Egy másik lehetőség a Python.

A Python egy nagyon komoly script nyelv, amit leginkább Linux alatt láttam rendszer szintű scriptek írására. Rengeteget tud, viszont számomra érthetetlen módon mintha próbálna minél jobban különbözni minden más programozási nyelvtől. Ettől függetlenül sok játékban, alkalmazásban használják, nem kevés előnye miatt.

  • Fejlesztés – a Python open source, alapvetően Linuxos technológia, ettől fogva komoly fejlesztés van mögötte. Jelenleg a 3.2.1 es verzió a legújabb ami éppen egy nagy átmenet és a rendszerek még a 2.7 es verzióval jönnek. (pl a Linuxban is 2.7 es van még, illetve a kikerülő alkalmazások is inkább ezt javasolják)
  • Modulok – hát nem kevés kiegészítő található a Pythonhoz sem. Mivel a C összekötése nagyon egyszerű, mindenki mindent megírt alá, amit nagyon könnyen lehet implementálni. A Linux is nagyon sokat dobott ezen a dolgon, mivel megadta neki azt a keretet ami a Luatól nagyon hiányzik.
  • SDK – még nem nagyon néztem szét, hogy milyen C/C++ interface ek vannak a Python hoz, de az alap, amit a Python-dev csomaggal adnak (vagy ami a Python Windowsos source ban van ugye), az annyira borzalmasan egyszerű, hogy az egész dokumentációja 1 oldalt tesz ki. Emelett az IronPython egy eléggé komolyn .NET es implementációnak tűnik, ami ugyancsak komoly fejlesztési figyelmet kap.
  • Típusok – ez nem lenne alapvetően előny, de ahogy a Python oldotta meg, úgy mégiscsak az. Alapvetően a Python nem típusos nyelv, azaz nem kell megadni hogy valami string vagy int, de ettől függetlenül lehetőség van a típusok használatára, amihez a Python eléggé sok eszközt ad
  • Objektum orientáltság – a Python eléggé komolyan képes objektum orientált lenni, még öröklődés és többszörös öröklődés is van benne: Az OOP nem egy erőltetett valami típusra ráhúzott “hack” mint a Lua ban, hanem valódi, jól megvalósított eszköz, exceptionökkel, öröklődéssel, private változókkal, konstruktorral
  • Multi platform – a Python is rengeteg platformon elérhető. Linux/Windows/Xbox/PS (IronPythonról szólnak Xbox os cikkek). Linux az biztosan működő képes, mivel erősen Linux párti a Python. Maga a Python interpretert láttam már futni Windowson, de még nem néztem meg, hogy mennyire nehézkes saját Python libet csinálni Windows környezetben. A többi platformról még kevesebbet tudok

Hát igen, mindenképpen azt kell mondjam, bármennyire is Lua párti vagyok, hogy a Python egy nagyon nagyon csábító alternatíva. Viszont ameddig a sebesség döntő tényező (már a program futási sebessége), addig a Python komoly hátrányban van, mivel lassabb mint a Lua.

Pár általam ismert játék, ami Pythont használ:

  • EVE Online
  • Battlefield 2 és 2142
  • Civ IV
  • Battlefield Heroes

Mondhatnám, hogy és még sokan mások, de nem nagyon találtam említésre méltó neveket, akik Pythont használnának. Viszont a Python is rengeteg Game Engine kiegészítést tartalmaz! A PyGame egy külön game engine, ami Pythont használ!

 

Némi extra információért az alábbi linkeket tudom még javasolni:

http://lua-users.org/wiki/LuaVersusPython

http://web.archive.org/web/20040916084425/http://www.bagley.org/~doug/shootout/craps.shtml

http://lua-users.org/wiki/LuaComparison

http://en.wikipedia.org/wiki/Comparison_of_programming_languages

http://www.mvps.org/scripting/languages/

Ubuntu, Kubuntu, Xubuntu … azaz Linux

Igen … eljött az idő és telepítettem egy Linuxot. Persze nem Debiant, hanem egy szép Kubuntu-t!

"Ubuntu: Az alap ubuntu kiadás, ami Gnome kezelő felületet tartalmaz

Kubuntu: Az ubuntu kiadás, csak KDE kezelő felülettelUbuntu

Xubuntu: XFCE kezelő felületű ubuntu kiadás"

Hát vegyesek az érzéseim azaz igazság. Először is a telepítés nagyon gyors és kényelmes volt. Csak le kellett töltsek egy 1.5 MB os exe-t a Windowsra, egy kis telepítés, ahol kiválaszthattam, hogy hova szeretném logo-kdetelepíteni és már mondta is hogy boolthatok! Na mondom ez már igen, akkor nyomás. Szépen be is épült a windows boot ba, azaz választhattam az Ubuntu Linuxot. Hajrá! Hát a KDE változott azóta amióta utoljára láttam, de csak kinézetben. Egyszerűen nem értem, hogy miért nem mennek rá arra, hogy kijavítgassák a bugokat, ahelyett, hogy szinte értelmetlen featureöket építenek bele. Azt meg kell hagyni, hogy nagyon szép lett, és rengeteg olyan grafikai elem van benne, ami a windowsban is benne lehetne (pl ami nagyon tetszett, hogy mozgatáskor az ablakok deformálódtak, áttetszővé váltak, stb)

No de miközben ezen sorokat írogattam, észrevettem, hogy van Gnome hoz Windows 7 Theme, Gnomeúgyhogy úgy döntöttem feltelepítem inkább azt, hátha valamivel jobb lesz. Meg kell hagyni, hogy az Ubuntu installere messze túlszárnyalja a windowsét technológiailag. Habár grafikailag is nagyon sokat fejlődött, azért még bőven van hova neki. Nem értem azt sem hogy miért kell hogy én lássan egy 2 soros ablakban hogy éppen milyen linuxos commandokat hajt végre a telepítéshez … legyen egy másik terminálon, aki nagyon azt akarja nézni, nézze azt, de ne az installerben.

Aztán jött a gnome … hát le van maradva a KDE től az biztos. Először is ugyan azokon a problémákon végig kellett mennem mint a KDE nél a dupla monitorral, habár itt már mondhatni szakértő voltam Mosolygó arc 

Hát ez valamivel gyengébb a KDE nél. A Windows 7 theme nem annyira sikerült, főleg mivel az új Gnome felülbírálgatta mindenben, eltűnt a taskbar, stb … szóval annyira nem érte meg.

Az az érzésem már nagyon nagyon rég óta, hogy a Linuxos grafikus felületek azért ennyire bugosak és szétesősek, mert nagyon általánosak akarnak lenni. Mindent lehet bennük, bárhogy nézhetnek ki, és emiatt csak azok az alapok működnek megbízhatóan, amit a fejlesztők csinálnak, viszont ezek általában eléggé rondák. Míg a Windows ban minden kötött nincs theme zés, nem lehet mindent össze vissza állítgatni, addig a Linux ban teljes szabadság van, akár GTK környzetben QT –s alkalmazást is futtathatunk és emiatt az ablakok szétesnek, a betűk kilógnak …

Szóval levonva a logikus következtetést … a Linux olyan nehéz mint egy kacsa Mosolygó arc

Eléggé sok jó dolog van a Linuxban, technológiailag fejlettebb a Windows nál, Server felhasználásra pedig egyszerűen butaság bármi mást használni linuxon kívül. Viszont desktop gépre szinte teljesen alkalmatlan. Ha már Gnome-ot vagy KDE-t használunk akkor instabilabb mint a Windows, ha az alap telepítéstől már csak egy kicsit akarunk eltérni, akkor ahhoz komoly ismeretekre van szükségünk (Windows alatt az NVidia driver telepítője egy szép grafikus alkalmazás, aminél elegendő a Next gombot nyomogatni, Linux alatt le kell állítani az X servert, ami még nekem sem ment mert a KDE nem hagyta, majd olyan kérdéseket tesz fel, amit szerintem egyszerű halandó sose fog megválaszolni) nvidia_linux

Úgyhogy mindent egybe vetve én azt hiszem maradok Windows 7 fun, amíg ki nem jön a következő verzió Mosolygó arc de azért a tisztesség kedvéért adok még 1 esélyt a KDE nek (ja igen, mindent lehet állítgatni Gnome alatt, csak éppen a bejelentkező képernyőt nem, ami a narancssárga színével egyszerűen az őrületbe kerget … az interneten millió leírás van hogy az Administration –> Logon Screen Settintgs ben ezt könnyedég át lehet állítani … nos az Ubuntu ezen verziójában ez a panel teljesen máshogy néz ki, és nem lehet beállítani a kinézetet).

NADIRIM is up and running! :)

Igen igen igen! Végre itt van a NADIRIM! Amit remélem minden erre tévedő már jól ismer! Megkezdte működését a BÉTA, ami open, úgyhogy lehet jönni és játszani!

Nadirim

Igen ez az az MMORPG (juj de ezt még leírni is jó!) amin eddig dolgoztam (persze nem egy magam, de ez az én blogom Mosolygó arc)

Szóval ezt fejlesztettük először a Digital Reality majd a Twisted Tribe szárnyai alatt.

Nadirim_1

Hogy mi is ez pontosan? Remélem nem szegek meg semmilyen titoktartási szerződést Mosolygó arc de azt hiszem pár érdekességet (ami szerintem az, de lehet más dög unalmasnak fogja tartani), megoszthatok mindazokkal akik eme remekbe szabott blogot olvasgatják!

Először is a leglátványosabb elemről mesélnék kicsit, a grafikáról! Ki hitte volna, de a grafikusaink mind volt Stromregion-ös 2D grafikusok, és azt kell mondjam (habár nekik már mondtam), hogy egyszerűen elképesztő amit összehoztak. A grafika nagyon szép, a tárgyak, épületek, helyszínek szépen össze állnak, az itemek, karakterek mind mind úgy van megrajzolva, hogy huh .. le a kalappal! Hogy kicsit a DevBlogunkat is  hirdessem, pár linket megosztanék azokkal akik még nem látták:

Pár 2D –s karakter és Ilderim. Hát nem semmi munka na, bőven kárpótol engem a 3D elvesztéséért!

A grafika utáni második látványos elem, maga a kliens, ami teljesen Flash alapú (10.2 compatible), úgyhogy tényleg nem kell hozzá más, csak egy böngésző, amiben képes futni (ezt meg ne hallják a kliensesek, de egyszerűen hihetetlen mit műveltek Ők is!). Én Flashben ilyet még nem láttam. Valjuk be férfiasan a Frontierville ehhez képest sokkal ocsmányabb, a feature listája kb a tizede a Nadiriménak és hát sokkal sokkal jobban szaggat és eszi meg a gépet, mint a Nadirim (ja és ott nincs sok ezer másik user)

Jaj és hát akkor rá is térek a legérdekesebbre, a legjobbra, a legnagyszerűbbre! A szerverre Mosolygó arc bezaNadirim ám, kell oda craft ahol ilyesmit kell meghajtani. Ugye ez nem az első MMORPG project amiben vagyok, de az első céges és komoly. Nem is gondoltam volna, hogy ilyen kemény meló egy ilyen szervert összetenni. Persze voltak komoly aggályaim a stabilitás és sebesség témakörökben, de szerencsére a kiváló (de valóban az) szerver fejlesztő Teamnek, ezek a kétségek teljesen elmúltak! Egyszerűen élvezet a szervert csinálgatni látni, ahogy élednek fel benne a dolgok, habár napi 8 órában egy fekete ablakban nézzük hogy rohannak a szürke betűk Mosolygó arc

Hajjaj, nem ejtettem szót a leglényegesebbről, amit sokan el szoktak felejteni. Ez a Design. Van jó pár designer-ünk, akik … hát a belüket lehet nem, de azért keményen dolgoznak azon, hogy a játék élvezhető legyen. Persze a rengeteg ötletet le is kell kódolni, úgyhogy aki most csak legyint kicsit Nadirim_kezdogondoljon bele, hogy a ma nagy nevek hol kezdték annak idején (amikor persze sokkal több lehetőségük is volt). Szóval ha most lennének is fenntartások (meglepő módon és magam is sokkal rosszabbra számítottam), akkor ezeket gyorsan hessegessük el, mert nagyon nagyon jó dolgokat találtak, találnak ki, csak győzzük Őket megcsinálni! Spoilerezni nem akarok, nem is szabad, de az tuti, hogy én fogok játszani a Nadirimmel, ami nagy szó, mivel az a játék amit általában az ember fejleszt azt a végére már utálja is Mosolygó arc.

Na de kicsit visszatérve a grafikára az nem tudom mindenkinek lejött-e hogy a kezdő hely egy repülő Inama templom, ahonnan láthatjuk az alant elterülő tájat! Én elmondhatom, hogy ott voltam, ott álltam az alkotó mögött amikor mindez készült és hát egy életre szóló élmény volt! Hihetetlenül jól néz ki, elképesztő, hogy valaki ennyire tudja, hogy mit csinál, amikor megrajzol egy ekkora valamit! Na a végén aranyba öntik a nevem a grafikusok Mosolygó arc 

További munkáik: http://nadirim.com/media érdemes rápillantani

 

Azt hiszem kibeszéltem magam, legközelebb lehet kicsit technikaibb témákat fogok felhozni, vagy sem Mosolygó arc

Addig is jó játékot mindenkinek: http://nadirim.com/