2009. december 18., péntek

A natív és menedzselt kód versenye

A .NET rendszer bevezetésének idején ádáz vita folyt arról, hogy vajon a menedzselt vagy a natív kód az, amelyik gyorsabban fut. Voltak, akik az egyikre, míg mások a másikra esküdtek. Sőt, számos mérési eredmény is közszemlére került. Főleg a C/C++ fejlesztők voltak azok, akik jókat nevettek azokon az állításokon, hogy egy menedzselt kód gyorsabb, mint a születésénél fogva natív kód. Ez a vita mára eldőlni látszik, mégpedig a menedzselt, JIT fordító által generált kódok javára. Ez igaz a Java és .NET kódra egyaránt .
Amikor egy C/C++ fordítóprogram előállít egy natív, futtatható fájlt (pl.: Windows alatt egy EXE-t), akkor különböző feltételezésekkel kell élnie, hogy a generálandó kódot majd milyen működési környezetre optimalizálja. Igyekszik az architektúra szerinti legkisebb közös többszörösnek megfelelő futtatható kódot előállítani. Azt azonban nem tudhatja, hacsak a programozó előre meg nem mondja neki, hogy ahol az a kód majd ténylegesen futni fog, hány processzor van, milyen a processzor és/vagy az adott hardver környezete, architektúrája, utasításkészlete, jellemző tulajdonságai, stb. Elképzelhető, hogy a programozó gépének tulajdonságai (ahol a futtatható kód előáll) gyökeresen eltérnek attól, ahol végül is a program majd futni fog.
Egy menedzselt kódnál a programozó, pontosabban fordítóprogram egy gép és architektúra független, köztes kódot állít elő még akkor is, ha a programozó fordítási időben ezt valamelyest befolyásolhatja. Később ezt a már említett .NET vagy Java szerinti gépfüggetlen kódot az adott számítógépen, ahol a futatás történik a JIT fordító fogja röptében végrehajtható, natív, gépi kódra fordítani. A lényeg az, hogy miközben a JIT fordító sorra veszi a köztes kód utasításait, azt is megnézi, hogy az a gép, ahol éppen működik, milyen architektúrával, utasításkészlettel rendelkezik, és ennek megfelelően képes az általa generált gépi kódot fordítás – vagy „jittelés” – közben optimalizálni. Másképp fogalmazva az adott végrehajtási környezetnek leginkább megfelelő futtatható kódot állít elő, ami gyorsabb lehet, mint egy adott környezetben (pl.: C/C++ fordítóval) már előre legenerált, futtatható kód. Ezen kívül a JIT fordító a natív kód generálása előtt képes kiszűrni és eltávolítani az olyan felesleges kódokat is, mint pl.: if(numberOfCpu > 1){...} vagyis a processzorok számának vizsgálatát akkor, ha az adott gépen csak egy processzor van. Ha pedig a gépbe mégis beletesznek egy újabb processzort, akkor a követező futtatásnál a „jitter” ezt már észleli, és a gépi kód előállításakor ennek megfelelően cselekszik.
Persze egy menedzselt kódnak nem csak előnyei, hanem hátrányai is vannak. Az egyik az, hogy a futtatható program első indulása meglehetősen lassú, hiszen a JIT fordítónak a köztes kódból le kell generálnia natív, futtatható, gépi kódot. Természetesen ez a művelet csak egyetlen egyszer hajtódik végre, hiszen amíg a program a maga natív, gépi kódú állapotában a memóriában van, addig azt többször már nem kell natív kóddá alakítania. A másik hátrány, hogy a program futása alatt a JIT által előállított natív kódot tárolni kell a memóriában, emiatt a fizikai memória helyfoglalása lényegesen nagyobb lehet, mint amit egy eleve natív, futtatható program esetén tapasztalunk. Fontos észben tartani, hogy a .NET rendszert „végtelen” nagy memóriára tervezték. Ez az elképzelés a mai átlagos RAM méret mellet (4GB) már nem is olyan naiv.

2009. december 15., kedd

A játékipar nagyjai: Sid Meier

A többség számára bizonyára ismerősen cseng Sid Meier neve, nem véletlenül. Az 1954. február 24-én született kanadai programozó már több mint huszonöt éve van a szakmában, sokan a "számítógépes játékok atyjának" hívják, de nevével akkor is találkozhattunk, ha nem igazán ismerjük munkásságát, ugyanis több tucat játékot adott ki saját név alatt. Karrirerjét 1982-ben a MicroProse megalapításával kezdte — ebben Bill Stealey, az Egyesült Államok Légierejének visszavonult ezredese volt a segítségére — majd következett az az időszaka, melyet ma már csak úgy emlegetünk: "az elsők". A cég megalapítása után három évvel ugyanis kiadták az első igazi repülőgépszimulátort, az F15 Strike Eagle-t, valamint a Silent Service nevű tengeralattjáró szimulátort. Előbbi programból több mint egymillió példányt sikerült eladniuk, ami bizony ma sem rossz eredmény, huszonöt éve pedig egyenesen kiváló volt. A rókabőr fogalmát persze már akkoriban is ismerték a programozók, az F15 Strike Eagle-ből ennek megfelelően még két rész jelent meg (a harmadik 1993-ban), de Sid ezután sem ült sokáig a babérjain, amit legjobban az 1987-ben megjelent Pirates! bizonyított.

Pirates! Gold

A Pirates! volt az első játék, melynek címében ott szerepelt Sid neve, a program teljes címe ugyanis Sid Meier's Pirates! volt. Erre a marketingcselre azért volt szükség, mert bár Sid korai programjainak rengeteg rajongója volt, a MicroProse a Pirates! megjelenésééig szinte kizárólag repülőgép és egyéb harci szimulátorokat dobott piacra, kellett valami, ami átcsábítja a hangsebességhez szokott gamereket az új stílusú játékra. A Pirates! ugyanis annyira új volt, amennyire csak lehetett. Egy kalózt testesítettünk meg benne, aki a 16. és 18. század között próbálta megszerezni a betevő falatra valót — hogy hogyan, azt a játékos döntötte el. Városokat, hajókat és más kalózokat is meg lehetett támadni, de a békésebbek kereskedhettek, valamint kutathattak kincsek és elveszett rokonok után is. Az 1988-ban az év akciójátéka díjat is besöprő program nem csak nyitott játékmenete miatt volt különleges, hanem azért is, mert a pályák minden egyes játéknál mások voltak (a program dinamikusan generálta őket), valamint a programnak nem volt konkrét vége, addig kalózkodhattunk, amíg csak akartunk — igaz, az idő múlásával minden egyre nehezebbé vált a játékban. A program eredetileg Commodore 64-re jelent meg, de pár év alatt szinte minden létező platformra portolták (Apple II (1987), PC (1987), Apple IIGS (1988), Macintosh (1988), Amstrad CPC (1988), Atari ST (1989), Amiga (1990), NES (1991)), melyeken ráadásul kezdetleges másolásvédelemmel is elláttak — a legtöbb platformnál szükség volt pár információra a kézikönyvből ahhoz, hogy el tudjuk indítani a programot. A népszerű szoftvert kétszer is felújították: az 1993-ban piacra dobott Pirates! Gold Windows 3.1-re és Sega Genesisre érkezett, 2004-ben pedig megjelent a teljesen felújított változat, melyet valószínűleg a Karib Tenger Kalózai című filmeposz is nagyban inspirált.
A Pirates! után még jó pár harci szimulátort dobott piacra (F-19 Stealth Fighter, M1 Tank Platoon), de Sid ekkoriban már a stratégiai játékok felé kacsintgatott. A nagy sikerű Railroad Tycoon 1990-ben került piacra, melyet 1991-ben követett az a Civilization, melyet sokan minden idők legjobb játékának tartanak.
Azt már kevesen tudják, hogy Sid Meier legendás játéka tulajdonképpen nem is annyira Sid Meieré. A programozó ugyanis sok ötletet és technológiai fát "vett kölcsön" az azonos nevű táblás játékból, mely Hartland Trefoil 1980-ban publikált Angliában. Nem is ő volt az első nagy programozó, aki el akarta készíteni a játékot, de ő volt az első, aki véghez is vitte, amit akart. Először az Electronic Artsnál dolgozó Danielle Bunten Berry fejében fordult meg, hogy el kéne készíteni a Civilization játékot. Kétszer is nekifogott, de sem 1983-ban, sem 1985-ben nem fejezte be, úgyhogy végül hagyta inkább az egészet. Másodszor a Utopia (az első szimulációs játék) dizájnere, Don Daglow próbálkozott meg a játék elkészítésével 1987-ben, de mikor felajánlottak neki egy vezető állást a Broderbundnál, dobta a projektet.

Civilization

Sid viszont nem dobta, ezzel pedig valószínűleg unokái anyagi jólétét is megalapozta, hiszen a Civilization hatalmas siker lett. A program időszámításunk előtt 4000-ben kezdődött, célunk egy olyan civilizáció létrehozása volt, mely kiállja az idő próbáját. Meier innentől nem is nagyon próbálkozott más típusú játékok készítésével, a Civilization utódjait és klónjait viszont futószalagon szállította. 1994-ben jelent meg az alapjátékra nagyon hasonlító Colonization, mely azonban közel sem lett olyan népszerű, mint testvére. Ennek oka az volt, hogy a játék megnyeréséhez célszerű (de nem kötelező) volt kiirtani az őslakos törzseket, a rabszolgává tétel lehetősége ellenben hiányzott, holott a valós történelemben létezett — emiatt sokan már filozófiai szinten is kritizálták a programot. Elkeseredettségében Sid 1995-ben piacra dobta a többjátékos funkcióval felvértezett CivNetet, mely gyakorlatilag ugyanaz volt, mint a négy évvel korábban megjelent alapjáték. Ezt követte a Civilization II (1996), két harci szimulációs játék (a Gettysburg! és az Antietam! 1997-ben és 1998-ban), majd jött az újabb nagy siker, az Alpha Centauri. A program nagyon hasonlított a Civilizationre, csak épp ott kezdődött, ahol az véget ért: a távoli jövőben, ahol az emberiség elpusztította a Földet, de találtak egy ahhoz tulajdonságaiban nagyon hasonló planétát, ahol újra elkezdték a csatározást. A siker meggyőzte Meiert arról, hogy a jövője ezekben a játékokban van, az elmúlt tíz évben tehát csak úgy jöttek a hasonló alkotások, melyek elődeikhez hasonló sikereket arattak.

Alpha Centauri

Az utóbb felsorolt programokat Sid már az 1996-ban általa megalapított Firaxis Games berkein belül fejlesztette. Érdekes, hogy az úriember több játékában is elrejtette saját nevét, az Alpha Centauriban például van egy rejtett párt (a Firaxis), melynek Sid Meier a vezetője, de említhetnénk a Civilization III legnehezebb fokozatának nevét (Sid) vagy a Civilization IV-ben a barbárok vezetőjét, aki — döbbenetes, de — szintén Sid Meier névre hallgat.

Civilization 4.

Sid Meier volt a második ember, aki felkerült az Interaktív Művészetek és Tudományok dicsőségfalára (Academy of Interactive Arts and Sciences' Hall of Fame), közvetlenül Shigeru Miyamoto, a Nintendo legendás programozója után. 2008-ban életműdíjat kapott a Game Developer's Conference-en.
Bocha

2009. december 11., péntek

A rommá vert Juventus

Hiába vezetett David Trezeguet góljával 1-0-ra a Juventus a Bayern München ellen a Bajnokok Ligája A-csoportjának ki-ki meccsén, a találkozót végül 4–1-re a meggyőzőbben futballozó bajorok nyerték meg, és így a „zebrák” búcsúztak a legrangosabb európai kupasorozattól. Ciro Ferrara, a Juventus edzője a találkozó után nem keresett kifogásokat, elismerte, a német csapat megérdemelte a továbbjutást.

Elbukta a nagy vizsgát a Juventus

„Nagyon sajnálom a klubot, a csapatot és a szurkolókat egyaránt. Fájdalmas kiesni a Bajnokok Ligájából. Nem szereztünk pontot az utolsó két meccsünkön, egyszerűen nem tudtuk kezelni a kiélezett helyzetet, nem voltunk képesek felnőni a feladathoz” – mondta csalódottan az olasz televíziónak a vezetőedző a mérkőzés után.
A szakember nem keresett kifogásokat, elismerte, hogy a müncheniek jobb teljesítményt nyújtottak, és győzelmükkel megérdemelték a továbbjutást. „Minden tekintetben felülmúlt minket a Bayern, igen keveset tettünk le az asztalra. Nagyon nehéz megfogalmazni, mi volt a bukás oka. Ez olyan sorozat, amelyben mindig motiváltnak kell lenned” – fogalmazott kritikusan a Juve mestere.
Természetesen Jean-Claude Blanc, a „zebrák” elnöke sem kerülhette ki az olasz sajtósok kérdéseit. „Túl sok energiánkat emésztette fel az Inter elleni mérkőzés, fizikailag ma nem tudtuk állni a versenyt. A Bayern nagyszerű csapat, és ezen a mérkőzésen kijött a különbség a két együttes között” – mondta rövid értékelésében a presidente, aki arra hívta fel a szurkolók figyelmét, hogy a nehézségekben is ki kell tartani a szeretett csapat mellett.
„Célunk, hogy tovább erősödjünk, és folytassuk a megkezdett munkát úgy, ahogy eddig. Hogy Ferrara marad-e? Természetesen. Megerősítem a pozícióját” – mondta Jean-Claude Blanc.
Louis van Gaal, a vendégek holland vezetőedzője érthető módon sokkal felszabadultabban nyilatkozott a lefújás után. „A Bayern volt a jobb csapat a pályán. Rendkívüli első félidőt játszottunk, amelyben nem volt szerencsénk, mégis tudtunk válaszolni a Juventus találatára, és ez megfordította a mérkőzést. Talán könnyebb volt felkészülnünk az összecsapásra, mert nekünk csak egy eredmény volt elfogadható, de ma este bizonyítottuk, hogy milyen tartásunk van” – dicsérte csapatát a szakember.

2009. december 5., szombat

id Software engine licencek: múlt, jelen, jövő?

Az id Software kétségkívül azon játékfejlesztők közé tartozik, akiket aligha kell bemutatni. Hiszen valószínűleg még a totálisan casual játékosok is hallottak a Doom vagy a Quake sorozatokról, amelyekben felhörgött a láncfűrész, és aprított a balta egyre beljebb haladva. A belsőségek meg kifelé. A fenti okokból kifolyólag az Ideas from the Deep múltját, pontosabban annak 90-es évekbeli csúcsait csupán érintőlegesen kívánjuk boncolgatni cikkünkben, és sokkal inkább a cég jelenére és jövőjére fókuszálnánk.

Wolfenstein 3D

Az id korai történetét elvileg mindenkinek kívülről kell tudnia, még hajnal négykor felkeltve is: Commander Keen, Wolfenstein 3D, Doom, Quake. A cég a játék nevével ellentétben semmi esetre sem háromdimenziós Wolfenstein 3D-vel megteremtette az FPS-ek műfaját, a Doom sorozattal pedig John Carmack, John Romero és kicsiny csapatuk végérvényesen bebetonozta az id nevét a játékfejlesztők nagykönyvébe. Míg az Apogee Software-rel (a Duke Nukem Forevert nagyjából az Özönvíz óta fejlesztő 3D Realms elődje) közösen kiadott Wolfensteinnek hála Carmack megvehette élete első (de korántsem utolsó) Ferrariját, az id által önállóan terjesztett Doom sikere után pedig valóságos flottát építhetett méregdrága sportkocsikból. A történet ezen részét szinte mindenki ismeri, azt a tényt azonban már sokkal kevesebben, hogy a Doom motorjának alapjait Carmack a szintén ekkoriban induló Raven Software Shadowcaster című játéka számára készítette el, a Wolfenstein motorjának felturbózásával. Ettől a ponttól számíthatjuk az id későbbiekben óriási volumenűre felfutott engine-licenceléseit, ami igazán a Doom motorral teljesedett ki, amelyet már tucatnyi játék használt.

Doom

A grafikus motorok licencelésének napjainkban is reneszánszát élő koncepciójának lényege az, hogy az adott cég (jelen esetben az id) elkészít egy grafikus motort, ellátja azt a megfelelő segédprogramokkal és dokumentációval, és az egészet különféle csomagokban kínálja megvételre. A rendszer nagy előnye, hogy a vásárlónak így nem kell alapjaiból megírnia egy grafikus motort, hanem csak módosítania kell a már meglévőt, amellyel nem csupán időt, energiát, hanem jobb esetben pénzt is spórolhat úgy, hogy garantáltan magas szintű grafikát fog kapni. A Doom szériától kezdve az id számára a grafikus engine-ek licencelése különböző cégek számára ha nem is váltotta ki a játékok eladásaiból származó pénzeket, mindenképpen egyre nagyobb szeletet jelentett a cég bevételeiben. Azonban az igazi forradalmat ezen a téren is a Quake első része indította el, amelynek motorját 1996-os megjelenését követően tömegesen vették bérbe: az engine-licencek terén az id voltaképpen egészen a Quake II megjelenéséig abszolút egyeduralkodónak számított.
A Quake azonban egy másik téren is új fejezetet nyitott a cég történelmében, hiszen elkészülte után hagyta ott a céget John Romero. A programozó-designer, majd pedig a designer Sandy Petersen kilépése, és American McGee szintén 1997-es kirúgása bár hivatalosan persze nem rázta meg a céget, nagyon is éreztette hatását a Quake II egyjátékos részében. Az 1997 decemberében megjelent Quake II folytatta elődei hagyományait abból a szempontból, hogy újfent álleejtős grafikát produkált, innovatív elemekkel bővítette a többjátékos opciót, és millió fölötti eladásait is le lehetett kopogni. A kopp-kopp azonban az egyjátékos részt tekintve csak úgy-ahogy valósulhatott meg, lévén a Quake I gótikus dizájnjához, pályatervezéséhez képest a Quake II sci-fi világa meglehetősen vérszegénynek hatott. Nem volt rossz, de az elődök zsenialitása semmi esetre sem jelent meg benne. Az engine-licencek terén azonban megint nagyot domborított az id, hiszen a Quake II motorját az elkövetkezendő három évben többtucatnyi játékhoz használták fel. Mondhatni a licenszek puszta számát tekintve az id a Quake II-vel ért fel a csúcsra, azonban az egyeduralkodása is pontosan a Quake II megjelenésével szinkronban ért véget.

Quake I.

1997 végén ugyanis már mindenki várta egy Epic Megagames nevű stúdió Unreal című FPS-ét, amely nem kisebb célt tűzött ki maga elé, minthogy porba döngölje az id aktuális motorját. A Tim Sweeney vezette csapat korábban főként a Jazz Jackrabbit szériával szerzett relatív ismertséget, a nagy dobás Unrealt pedig majd’ négy évig fejlesztették. Bár kezdetben maximum heveny röhögőgörcsöket generált annak puszta felvetése is, hogy az Epic egy olyan motort fog készíteni, ami vetekszik az aktuális id motorral, a cinikusok ez esetben alaposan mellélőttek. Mondhatni sikerült kilőniük a hajtókat a szarvasok közül. A játék ugyanis 1998 májusában jelent meg, és ekkorra már aligha volt játékos, akinek nevethetnékje támadt az Epic munkájától, lévén az Unreal motor bizony a földbe döngölte a Quake II engine-jét, legyen szó a modellek részletességéről, a fényeffektekről, avagy éppen a hatalmas külső terek használatáról. Az Unreal megjelenése után számos cég bontotta fel a már megkötött szerződéseket az iddel, hogy a forradalmian új Unreal motorra térjenek át.
Bár az id az 1999 decemberében megjelent Quake III motorjával visszavágott, sőt, nagymértékben felülmúlta a pár hónappal korábban debütáló Unreal Tournament alatt dohogó, továbbfejlesztett Unreal motort, a cég bizonyos hiányosságai ekkor már kezdtek kiütközni. Ezek közül az első mindenkinek szembetűnő volt: míg a Quake II egyjátékos része csupán ellaposodott, úgy a Quake III Arena nemes egyszerűséggel nem is tartalmazott egyjátékos részt, pusztán botok elleni harcot. Vérszegény, mondhatnánk. Azonban bár voltak egyesek, akik cinikusan "techdemónak" nevezték a Quake III-at, az egyjátékos rész totális hiányát egy multira fókuszáló játéknak könnyedén elnézte az ember. Ami viszont keveseknek tűnt fel, az a megnyúlt fejlesztési idő volt: miközben a Quake I, és a Quake II megjelenése között mindössze másfél év telt el, a Quake II és a Quake III esetében ez már két évre nyúlt. Ekkor még senki nem gondolta volna, hogy ennek bármiféle jelentőse is lesz a jövőre nézve; pedig lett, több szempontból is.

Quake III.

Az id számára a Quake III megjelenése újfent azzal a felettébb örömteli procedúrával járt, hogy nem győzték lesni a bankszámlák gyarapodását, mind a végül kétmillió körüli eladások, mind pedig a minden korábbit felülmúló engine-licencek miatt. Azonban amint megkezdődtek, és egyre előrehaladottabbá váltak a Doom III fejlesztésének munkálatai, úgy lett napnál is világosabb, hogy az id hőskorszakból megmaradt csapatlétszáma egyszerűen nem képes megfelelő gyorsasággal játékot fejleszteni. Míg a 90-es évek első és második felében elégségesnek bizonyultak a pártucat fős fejlesztőcsapatok, úgy az új évezredben a mind komplexebbé váló játékok egyre nagyobb és nagyobb stúdiókat követeltek. Ehhez képest az id a 2000-es évek elején is mindössze pár tucat emberrel dolgozott, ami azt eredményezte, hogy a várva-várt, szokás szerint forradalmi grafikát ígérő Doom III megjelenési dátuma olyan nagy népi trükköket vetett be, minthogy elkezdett csúszni, csúszni és csúszni... A játékot 2000 közepén jelentették be, és az eredeti tervek szerint 2002 decemberére meg kellett volna jelennie, amit a Doom III határozottan nem tett meg. Megtette azonban helyette az Unreal Tournament 2003, amely 2002 októberében debütált, és bemutatta, mire is képes az Unreal 2.0-ás motor. Ezáltal az id hirtelenjében akkorát csattant a padlón, mint egy jóllakott csótány, hiszen a cég nem volt képes megfelelő választ adni az Epic új enginjére, csupán az immáron három éves Quake III motort tudták megvásárlásra kínálni. Ez pedig vajmi kevésnek bizonyult az új Unreal engine-nel szemben, habár még egészen 2003 végéig jelentek meg Quake III motoros játékok, ezek korábbi szerződések hozományai voltak, nem új vásárlásoké. A Doom III motor azonban, amely elvileg (és a gyakorlatban is) porba alázta volna az Unreal 2.0-t, csak nem akart debütálni, hiszen maga a játék hiányzott alóla. Carmack az engine-t, a Tech 4-et már 2002-re nagyjából végleges állapotba hozta, azonban a már említett, egészen minimális csapat érthető módon nem volt képes a fény terjedési sebességével haladni a tényleges játékelemek elkészítésével. Éppen ezért a Doom III megjelenése folyamatosan csúszott: 2002 végéből 2003 nyara, tele, majd 2004 tavasza lett, amiből végül is 2004 augusztus elején jelent meg a játék. Mindeközben az Unreal 2.0-ás motort tömegével licencelték a cégek, és az Epic belefogott az Unreal Engine 3.0 fejlesztésébe is, ami nem sok jót ígért az id számára. Ezt Tim Seweeney már igazi next-gen engine-nek szánta – ami persze ebben a formában puszta parasztvakítás volt csupán, azonban az Epic lépéselőnye vitathatatlanná vált.
Játékként a Doom III fogadtatása meglehetősen vegyes volt: amint azt magam is leírtam a bő négy évvel ezelőtti ismertetőben, jónak jó játék volt, de semmi esetre sem kiemelkedő, fantasztikus meg pláne nem. A mára már lassan négymillió közelébe kúszó eladások ugyan mindebből semmit nem tükröztek, azonban a szinte tantrikusan emlegetett engine-licencek annál is inkább. A Doom III ugyanis pontosan félidőben jelent meg: az Unreal 2.0 motor ekkor már közel kétéves volt, míg az Unreal Engine 3.0 megjelenésig pedig még két év volt hátra. Mindez azzal járt, hogy az elmúlt két évben rengeteg cég kötelezte el magát az Epic motorja mellett, másrészt szintén sok cég kivárt: bár az Unreal 3.0-ás csoda megjelenési dátumát még nem lehetett tudni, azt azonban már igen, hogy nagyobbat fog szólni, mint az id féle Tech 4. Ennek, és a csillagok minden bizonnyal roppant szerencsétlen együttállásának, továbbá a világgazdasági válság nem létező előszelének köszönhetően a Doom III motor sikere meg sem közelítette, közelíti az id korábbi grafikus motorjaiét. Külsős cégek alig-alig licenszelték azt, sokkal inkább az id "családi körébe" tartozó fejlesztőcsapatok használták, így a Carmack által rendkívül megkedvelt outsourcing jegyében fogant a Quake 4, a Enemy Territory Quake Wars, és a hamarosan megérkező új Wolfenstein is a Doom III motorját használják. Ez azonban, kiegészítve például az idhez szintén közel álló 3D Realms által fejlesztett Prey-jel, illetve még egy-két játékkal, vajmi kevés a korábbi több tucatnyi játékhoz képest. Mindebben persze szerepe van annak is, hogy az id mindig is olyan grafikus motorokat készített, amelyek elsősorban belső terek megjelenítésére voltak optimalizálva, ellentétben a külső terekben is jeleskedő Unreal engine-ekkel. Ez pedig egy alapjaiban elavult koncepció, amit maga Carmack is beismert azzal, hogy bejelentette: új játékuk, a Rage alatt dohogó Tech 5 már hatalmas külső tereket is képes lesz kezelni.

Doom III.

A Rage-et az id 2007 nyarán jelentette be. Ez a játék a Quake óta az első új id franchise lesz. A videók és a képek az idtől megszokott álleejtős mutatványt generálták a nézősereg körében, azonban kérdéses, hogy a játék ténylegesen mikor is fog megjelenni: a csúszások máris megkezdődtek, hiszen az eredeti tervekkel ellentétben a Rage idén már biztos nem kerül a boltokba. Ismerős történet... Technikai szempontból rengeteg innovációt zsúfoltak az új motorba, amely esetében a helyzet némiképpen a Doom III-ra emlékeztet: Carmack szerint az engine voltaképpen már kész van, játék azonban még sehol, és kérdéses, hogy az id mennyiben tudja tartani a meglehetősen lazán vett megjelenési dátumot. "When it’s done." Bíztató.
A csapat létszáma, dacára annak, hogy immáron elérte az id korábbi méreteihez képest szinte gigantomán ötven főt, még mindig rendkívül kicsinek mondható a nagy fejlesztőstúdiók több száz alkalmazottjához képest. Márpedig az idnek alighanem nagy szüksége lenne a Rage megjelenésével vélhetően újból előrekapó engine-licencelésekre, hiszen e tekintetben a Doom III e téren felmutatott rendkívül gyenge eredményeire financiálisan aligha lehet alapozni. Márpedig pontosan a pénzügyi függetlenség az, amelyet az id már megalakulásától kezdve féltékenyen őriz, hiszen ez tette lehetővé a csapat számára, hogy bár játékaikat a Quake-től kezdve az egyik – sőt, ma már a Blizzardal karöltve a – legnagyobb kiadó, az Activision adta ki, a cég megmaradt magánkézben. Némileg furcsa jel, miszerint a Rage már az EA gondozásában fog megjelenni, még akkor is, ha az óriással csupán ezen egyetlen játék kiadásának erejéig kötött szerződést az id.

Rage

S hogy mit hoz a jövő? Fogós kérdés. Összehasonlítva a 90-es és a 2000-es éveket, szembetűnő, hogy az FPS műfaj megalkotója milyen nagy mértékben szorult hátra, miközben a megjelent játékaik száma (a kiegészítőket nem számítva) hétről kettőre esett vissza – már persze abban az esetben, ha a Rage még ebben az évtizedben megjelenik, amire azonban nem nagyon van reális esély. Pedig a nagy visszatérés lehetősége itt van az id előtt: a rivális Epic hivatalosan még csupán alig kezdett bele az Unreal 4.0 motor fejlesztésébe, amelyet elviekben nem szándékoznak hamarabb megjelentetni, mint ahogy a következő konzolgeneráció kijön. Amennyiben a Rage valóban megjelenik idén, úgy az id kitöltheti az Unreal 3.0 és 4.0 motorok közti űrt. Amennyiben viszont további sorozatos csúszásokra kerül sor, úgy már egy ki tudja milyen képességekkel felvértezett Unreal 4.0-ás motorral szemben kell helytállnia a Rage-nek úgy, hogy közben az egyre erősebb CryTek is belekezdett a CryEngine 3 fejlesztésébe. Ezen rivális motorok megjelenése pedig a licencek számának aligha fog jót tenni. Következésképpen magának az idnek sem.

Gerry

2009. december 2., szerda

Hatmillió .NET fejlesztő készíthet linuxos alkalmazásokat

A Novell bejelentette az első kereskedelmi forgalomban is elérhető megoldást, amely segíti a Linux, UNIX és Mac OS X rendszereken futó .NET alkalmazások fejlesztését Visual Studio környezetben. A Microsoft Visual Studio integrált fejlesztőkörnyezetéhez készült új bővítménymodul, a Mono Tools for Visual Studio abban segíti a .NET fejlesztőket, hogy a már megszokott Visual Studio használatával tervezzenek, kódoljanak és tartsanak fenn többplatformos alkalmazásokat. A Mono Tools használatával jelentősen csökkenthető a fejlesztési költség és idő, így a fejlesztők és a független szoftvergyártók gyorsan és egyszerűen bővíthetik piaci és telepítési lehetőségeiket.
"A Microsoft Visual Studio egy integrált környezet, amely a tervezéstől a telepítésig tartó fejlesztési folyamatot egyszerűsíti le" - mondta Cyrill Glockner a Microsoft Corporation üzleti fejlesztéssel, platformokkal és eszközökkel foglalkozó részlegének igazgatója. "A Microsoft Visual Studio Industry Partner Programmal (VSIP) olyan eszközök fejlesztését támogatjuk, amelyek zökkenőmentesen integrálhatók a Microsoft Visual Studio alkalmazással, és segítik ügyfeleink sikeres működését. A Mono Tools for Visual Studio több mint hat millió, .NET rendszert használó mérnök számára teszi lehetővé, hogy a Microsoft eszközeik és saját tudásuk kihasználásával újabb értéket teremtsenek" - tette hozzá Glockner.

A Mono Tools for Visual Studio lehetővé teszi a Microsoft Visual Studio használatában járatos C# és .NET fejlesztőknek, hogy az általuk használt integrált fejlesztő környezetet megtartsák, és hasznosítsák meglévő gyakorlatukat és .NET kód-, tár- és eszközrendszerüket a Linux, UNIX és Mac OS X rendszeren futó alkalmazások fejlesztésére és az alkalmazások átvitelére. A Mono Tools megjelenése előtt a .NET alkalmazások átviteléhez új programozási eszközök elsajátítására és az alkalmazások újraírására vagy átalakítására volt szükség. A Visual Studio használatát ismerő fejlesztők a Mono Tools segítségével közvetlenül a Visual Studio környezeten belül használhatják ki már meglévő ismereteiket és szakértelmüket a többplatformos alkalmazások telépítésére és a kapcsolódó problémák azonosítására. Egyedülálló, többplatformos fejlesztés a Visual Studio rendszerben.
A Mono Tools a Microsoft Visual Studio bővítménymodulja. Ez az eszköz a Novell által szponzorált nyílt forráskódú Mono projektet fejlesztő és támogató mérnökök közreműködésével jött létre. A Mono Tools for Visual Studio legfontosabb jellemzői:
  • .NET alkalmazások fejlesztése és átvitele Linux, UNIX és Mac OS X rendszerekre: a Mono Tools for Visual Studio használatával a független szoftverszállítók, vállalati fejlesztők és fejlesztési szolgáltatásokat nyújtó vállalkozások jelentős mértékben csökkenthetik a többplatformos alkalmazások fejlesztési költségeit, és időt takaríthatnak meg meglévő .NET alkalmazásaik nem Windows platformra történő átvitelekor.
  • Kulcsrakész virtuális és szoftverkészülékek létrehozása .NET alkalmazásokkal az integrált készülékek fejlesztésére alkalmas funkcióval. A Mono Tools for Visual Studio azonnali integrációt biztosít a SUSE Studio Online alkalmazással, ami pedig lehetővé teszi a SUSE Linux Enterprise Server vagy openSUSE készülékek gyors fejlesztését és tesztelését.
  • Integrált átviteli elemzőeszköz: sok .NET fejlesztő nem tudja, hol kezdjen neki az alkalmazások átviteléhez egy nem Windows-alapú platformra, ez a probléma azonban gyorsan megoldható a Mono Tools-szal.
  • Alkalmazások futtatási és hibakeresési lehetősége a Mono-ban, a Visual Studio rendszeren belül: a Mono és a .NET, valamint a Linux és a Windows közötti inkompatibilitások elkülönítéséhez. Ezzel a funkcionalitással könnyebben megkereshetők azok a problémák, amelyek befolyásolhatják a többplatformos fejlesztést.
  • Automatizált csomagolás a SUSE Linux Enterprise Server és openSUSE rendszerek esetén, amely előkészíti az alkalmazásokat a Linux rendszerre történő azonnali telepítésre.
"A Mono Tools for Visual Studio összekapcsolja a világ egyik vezető fejlesztői platformját, a Visual Studiot és a világ egyik vezető platformját, a Linuxot" - mondta Miguel de Icaza, a Mono projekt alapítója és a Novell fejlesztői platformokért felelős részlegének alelnöke. "Ügyfeleink részéről már régen felmerült az igény, hogy .NET alkalmazásaik Linux, UNIX és Mac rendszerekre történő átvitele könnyebb, egyszerűbb és zökkenőmentesebb legyen. Eszközeink Visual Studio rendszerbe történő integrálásával lehetővé tesszük a Windows és a .NET rendszereket jól ismerő fejlesztők számára alkalmazásaik gyors megjelentetését a Linux-piacon. A független szoftverszállítók pedig szoftvereiket azonnal futtatható készülékként jelentethetik meg" - tette hozzá Icaza.

A Mono Tools for Visual Studio már elérhető. Háromféle termékkiadás kapható: a Professional Edition (magánszemélyeknek) 99 dollárért, az Enterprise Edition (legfeljebb egy fejlesztő egy szervezeten belül) 249 dollárért és az Ultimate Edition 2499 dollárért, amely korlátozott kereskedelmi engedélyt biztosít a Mono terjesztésére Windows, Linux valamint Mac OS X rendszereken, és öt fejlesztői licencet tartalmaz. Minden termékverzió mellé egy éves termékfrissítési előfizetés jár.

Sting