játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5448
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2520

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Milyen is a játék-fejlesztés 2008.06.17 00:42


Mielőtt belevágnánk, szeretnék mondani pár szót magamról, hogy tudjuk annyira nem a levegőbe beszélek (habár szoktam :)).
2005. -től dolgoztam a StormRegion Kft. -nek, ami Magyarország egyik vezető játékfejlesztő stúdiója volt. A Codename Panzers Phase II befejezésekor érkeztem a céghez, majd a Rush For Berlin game codere lettem. Az RFB után jött a Codename Panzers Cold War projekt, ahol eleinte ugyancsak game coderként, majd Assistant Lead Programmerként tevékenykedtem. Lassan 3 évnyi játékfejlesztési tapasztalat áll mögöttem, ami barátok közt is édes kevés. Szinte semmi, hisz főleg RTS játékokkal foglalkoztam.

De azért vágjunk bele! :)

Hogy is kell játékot fejleszteni…? Ha bárki úgy gondolja, hogy annyi elég, hogy leül és gépeli a program kódot, akkor nagyot fog csalódni. Egy ideig megy a dolog, de eléggé hamar el lehet jutni azokhoz a részekhez, amiknél az ember megakad, egyszerűen nem tudja hova tovább és ez szokott elvezetni a kusza program kódhoz, amikor az ember már a saját kódját sem látja át.
Ezért minden fejlesztés, főleg a játék először tervezéssel kezdődik, de nem a program tervezésével, hanem maga a játék megtervezésével. Milyen stílus, milyen lehetőségek. Az alapok lefektetése, amit 1 ember nem nagyon tud elvégezni, kivéve, ha géniusz… :) Be kell látni, hogy napjaink játékfejlesztése nem olyan egyszerű! Sorra jönnek ki a jobbnál jobb játékok, amiket komoly tehetséggel megáldott, úgymond designerek találnak ki és komoly programozói, grafikusi gárda jelenít meg. Fontos a jó design, máskülönben a program nem lesz más, mint egy rakás bithalmaz, ami senkit nem érdekel, és azt hiszem egy fejlesztőnek ennél rosszabb nem is lehet. Én legalábbis azért fejlesztek, hogy az emberek szeressék! :)
Ha a tervezés alapjain túl vagyunk, jöhetnek is az első tétova lépések. Akár garázsprojekt, akár nem, mindenképpen megfelelő technológia után kell nézni, és mivel csapat munkáról beszélünk fontos, hogy legyen egy verzió követő rendszerünk is. Ennek alapos ismerete sem árt (SVN, CVS). Garázsprojekteknél általában free librarykat használunk, míg a stúdiók projektjeinél komoly fizetős engineket (UT engine, Crytek engine, Quake engine). Mi most szorítkozzunk a free libekre, ezekből is van jó pár, és igen sokat a komoly játékfejlesztésben is használnak. Ha már tudjuk, hogy kb. miről fog szólni a játékunk (soha sem lehet előre az egészet megtervezni, mert úgyis lesz olyan, amit másképpen kell csinálni), akkor elkezdhetjük kiválasztani a kellő dolgokat. Pár alapvető dolog mindenképpen kelleni fog (3D engine, SoundSystem), de nagyon sok dolgot nekünk magunknak kell megírni (streamek, avi kezelés, irányítások, toolok). Mindent jó alaposan gondoljunk át, próbáljunk elképzelni egy kész játékot, és azt, hogy mi minden kell ezekhez. Persze látnunk kell azt is, amit nem hoznak mindig nyilvánosságra: rengeteg tool, kiegészítő program, ami elengedhetetlen egy játék elkészítéséhez, habár nem is tudunk róla. Például map editor, minden játékhoz kell, mégsem adják oda mindegyikhez. Egy ilyen tool elkészítéséhez nem elég, ha már láttunk windowsos programot. Komoly C# vagy C++-CLR ismeretek kellenek (az MFC-t ne vegyük ide, azzal csak szívás van), emellett az engine-ünknek is támogatnia kell, hogy játékként és editor ablakként is fusson. A map editor mellett ott van az effect editor, video editor, animacio editor... mind-mind olyan tool, ami elengedhetetlen, legtöbbször nem helyettesíthető program. A különféle exporterekről nem is beszélve. Azok a fájlok, amiket az alap szerkesztők előállítanak (3D Studio Max, Sony Vegas, XSI ) nem megfelelőek, teli vannak olyan információkkal, amikre nincsen szükségünk, nem a mi engine-ünkhöz vannak optimalizálva, ezért kell egy program, ami ezt megteszi.
Ha összeszedtük ezen alapokat, a kellő libeket, akkor kezdődhet is a gondolkozás. Igen, még mindig csak ülünk a képernyő előtt és 1 betűt nem kódolunk. Jól át kell gondolni mi-mire épül, mit kb. hogyan akarunk megvalósítani, hogyan akarjuk az engine-t és az alapokat elkülöníteni a játék kódtól. Ezek nagyon fontos lépések, hisz a fejlesztés során jól el kell tudni őket különíteni, könnyen átláthatóvá kell tenni a projektet, hiszen egy-egy játék befejezésekor több ezer fájl, több ezer osztály is lehet a projecten belül. Ezen kívül át kell, hogy gondoljuk melyik területre melyik embert helyezzük, nagyon fontos, hogy a megfelelő embereket válasszuk ki, hisz hibázni nem nagyon lehet. Ha valaki nem ért az adott területhez, akkor nagyon lassan halad, garázsprojektek esetében akár abba is hagyhatja a fejlesztést, hisz szívni senki nem szeret. Miután mindezzel végeztünk, gondoljuk át jól, hogy mi körülbelül mennyi idő. Ehhez kell már komolyabb tapasztalat. Minden időt szorozzunk be legalább 2 –vel! Egy játék elkészítése (komolyabb), évekig tart, így azok, akik a gyors sikerben reménykednek, most abba is hagyhatják az egészet. Egy egyszerűbb játék, pl. egy RTS 2-3 évig készül, napi 8 (14 :)) órában, 10-15 programozóval. Most csak gondoljunk bele, hogy a szabadidőben végzett munkával, 2-3 esetleg 4 programozóval ez mennyi idő. Hosszú évek, mire egy olyan játék elkészülhet, amit nem mondanak gyenge demónak, hanem igazi létjogosultsága lehet a játék piacon. Persze, ha mindehhez hozzávesszük, hogy teljesen open source a projekt, bárki, bármikor foghatja magát és elviszi az egészet. (sajnálatos ezt még leírni is, de lássuk be - ne legyünk naivak -, hogy ez nagyon is könnyen elképzelhető, főleg, ha a projektünk jó és igényes). Szerintem senki nem akarja, hogy a sok-sok időráfordítással elkészült munkájával más villogjon.

Node kezdjünk bele a programozásba. Nagyon sokan úgy képzelik, hogy játékot fejleszteni csupa öröm és „bódogtág” :)… Sajnos nem az. Rengeteg olyan terület van, amit mindenképpen meg kell csinálni, de az ember semmiképpen sem akarja. Nagyon sok garázsprojekt itt vérzik el. Vannak olyan feladatok, amik nélkül a játék nem lesz játék, ezek elkészítése pedig rengeteg vesződség, rengeteg munka. Sok esetben rengeteg kutatómunka, a megfelelő algoritmusok kikeresése, leprogramozása, sok robotmunka (volt olyan eset, hogy 1000 sort kellett átírjak, 1 napig folyamatosan csináltam… 32-őt kellett volna csak 8-ra átírni…).
Már a kódolás megkezdésekor figyelembe kell vennünk bizonyos szabályokat. A kódjainknak átláthatónak kell lennie, debugoláskor könnyen debugolhatónak, külön kell választani a debug buildet és a végleges releaset, de nagyon figyelve arra, hogy ne csináljon mást a debug, mint a release (pl a debugban ne módosítsunk értékeket, amit releaseben nem tennénk meg).
Itt kiemelném az std könyvtár használatát, amit sajnos az Ogre 3D engine-ben használnak (rajtuk kívül sokan mások). Az std lib egy nagyon jó dolog szakdolgozatokra, vagy kis programocskákra, de egy komoly projectben, pl játék, már nem megfelelőek. Nem eléggé optimálisak, teljesen debugolhatatlanok, és több időt kell rájuk fordítani, mint írni egy átláthatóbb, optimálisabb saját core rendszert. Ennek a megírásához nem elegendő, ha valaki már írt egy „hello világ” kódot, sajnos. Komolyabb ismeretek kellenek, kell ismerni az eltérő platformok elvárásait, és bizonyos szempontból már tudni kell, hogy milyen lesz a játék végső formája. Nagyon kell ügyelni a memória felülírásra, a fel nem szabadított memóriára, hiszen a core rész lesz mindennek az alapja, az itt található osztályokat, függvényeket nagyon sokszor, sok mindenre fogjuk használni, ha ezen részek nem optimálisak, vagy memória pazarlóak, akkor az nagyban veszélyezteti a játékot is. Fontos, hogy a core rendszerbe a megfelelő osztályokat tegyük, az átláthatóság kedvéért minden osztályt külön fájlba. Ennél a résznél inkább a stabilitás és a gyorsaság a mérvadó, de nagyon fontos az átláthatóság is, habár, ha kell akkor inkább az átláthatóságból áldozzunk a gyorsaság, stabilitás kedvéért.
Azt lássuk be, hogy ez nem egyszerű feladat, és amíg készül semmi látható eredménye nincsen a dolognak. Mindössze a kóderek látják, hogy milyen sok szép fájl került fel az svn be :), viszont a grafikusok, designerek nem látnak ebből semmit. Ha garázs projekten dolgozunk, akkor nekik ne is szóljunk, amíg ezzel meg nem vagyunk. Ez dupla biztosíték, hisz, ha már itt elakadunk, akkor nincs értelme erőltetni a fejlesztést, ha túl jutottunk, akkor már mondhatjuk, hogy valami van a kezünkben.
Ha ezen túl vagyunk, eljutottunk odáig, hogy azt is tudjuk, hogy mit akarunk csinálni, akkor jöhet maga a játék! :) Ez is minimum 2 részre oszlik. Az egyik az engine kód, ami magát a grafikus motort hajtja, vezérli az animációkat, hangokat, effecteket, létrehozza a gui rendszert, kezeli az eventeket. Egy engine elkészítése óriási munka. Nem véletlen, hogy a komolyabb engineket komoly pénzért árulják. Ezért érdemes egy már kész, open source engine-t választani és azt használni. De ne higgyük, hogy ilyenkor kényelmesen hátra lehet dőlni és várni a galambot! :) Sajnos így is rengeteg munka van az engine személyre szabásával. Ki kell alakítani azokat az interfészeket, amik által könnyen elérhetünk bizonyos funkciókat, ugyanis ezek az engine-ek csak amolyan segéd eszközök, túlságosan is sokrétűek. Például nem kell, hogy 3-4 -féle fog típust kezeljen, vagy 20-féle kép típust, mert mi úgyis csak 1 fajtát fogunk használni (azaz érdemes 1 fajtát, hogy ne zavarodjon bele az ember, és a lehető legoptimálisabb fajta kell úgyis). Ezen dolgok elkészítéséhez viszont már komoly tudással rendelkező, jó matematikai érzékkel megáldott emberek kellenek. Őket nevezik Engine kódereknek.
A másik rész sokkal egyszerűbb bizonyos szempontból (azaz game codereknek egyszerűbb, engine kódereknek lehet nehezebb… :)), ez pedig a game code. :) Nem árt komolyan megtervezni, mert itt a legeslegfontosabb dolog az átláthatóság. Ez a rész az, ami folyton változik, állandóan belekerülnek dolgok, kikerülnek dolgok, és ha mindez nem átlátható, akkor egy idő után már nem lesz módosítható. Minden főbb rendszert jól el kell különíteni, de könnyeden elérhetővé kell tenni egymás számára, hogy ne legyen (úgymond :)) hack a dologból, mert azok nagyban csökkentik az átláthatóságot és a stabilitást.

Ezekhez persze bizonyos esetekben hozzá jöhetnek más területek is, pl MMORPG nél a szerver, ami általában Unix / Linux rendszeren fut, esetlegesen egy XBOX360 port, stb.

Nos, elsőre ennyi! :) Ha van rá igény írhatok másról is még, vagy egyes részeket kifejthetek. :)
Mielőtt bárki játék fejlesztésbe kezd, gondolja át jól, hogy milyen óriási munka egy játék elkészítése, ne várja azt, hogy 1-2 hónap alatt bárhová is jut, komoly tapasztalattal kell rendelkezni szinte az összes területen, és komoly tervezés kell hozzá. Ha még nem csináltunk játékot, akkor nagyon óvatosan közelítsünk a témához, mielőtt belefogunk. Készítsünk egymagunk kisebb játékokat, hogy lássuk milyen nehézségei vannak, ha nagyon nem megy, inkább keressünk egy teamet, akik már régebb óta foglalkoznak ezzel és szálljunk be oda fejleszteni, ne ugorjunk fejest azonnal, és próbáljunk 2 lábbal a földön járni.
Sajnos a mai világban egy garázsprojekt esélye, hogy egyáltalán elkészül, kb. 1%. Ennél többet nem szabad egyiknek sem adni, de úgy hiszem, akinek ez az álma, az jut is valamire, ha más nem egy fejlesztő studio felfigyel rá.

Mindenkinek sok sikert! Remélem sikerült valamit átadnom! Ha kérdés lenne, kérdezzetek! :)

Értékelés: 6.83

Új hozzászólás
Carlos          2009.06.06 14:11
Vagy az Apple, a Cisco, a Pixar, és még sorolhatnám.

De a hasonlat kissé sántít: az még a hippi-korszak volt, ugye. A világ megváltozott azóta, manapság két szakállas, mezitlábas srác nem sokra vinné komoly tőke nélkül - még akkor sem, ha amúgy zsenik.
Óvatosan kellene bánni a sztereotípiákkal: ami 40-50 éve működött, az ma már nem feltétlenül nyerő, még itt, vadkeleten sem. ;-)
Azuris          2009.06.03 15:27
...hiszen a Microsoft is csak egy garázsból indult...
Azuris          2009.06.03 15:19
Sziasztok!

Én a végén majdnem elsírtam magam...

De sajnos ez a szörnyű valóság. Az életben minden komolyabb dologhoz kell egy csapat. Egy ház felépítésénél ott a család. Disznóvágásnál a barátok, stb... Bocsánat ha ironikus voltam-

Én nem fejlesztettem még komolyabb 3D-s játékot. Főleg P.elektronikával és PC hardverrel foglalkozom. Eddigi tapasztalataim azt mutatják hogy egy "Garázs project" sikerességének esélyét az növeli a leginkább, hogy az elején te egyedül menyit készítesz el belőle. A bűvös határ valahol 40-50% között van. Tehát ha legalább 40%-ig elkészíted egyedül, akkor legalább 90% esélyed van arra hogy be is fogod fejezni azt, egy erre alkalmas csapattal. Ez az elv legalábbis nálam működött, mikor különféle értelmetlen elektronikai sz@rokat, pl 286-os mikrogépet építettem/fejeztük be.


Kitartást mindenkinek, ne adjátok fel soha az álmaitokat!
ShAdeVampirE          2008.06.28 04:58
"Viszont azért mint már írtam vannak buktatók (qsort pl).. szóval, mivel más írta a kódot, nem árt nagyon tisztában lenni vele, mert sok vesződségtől kímélhet meg."

Ez nagyon igaz, mint ahogy az az előző postomban is benne volt: nem mind1, h clear()-t v resize(0)-t hívunk meg, azaz tényleg érdemes ismerni az implementációt is.

Még 1 kis kiugrás (kezd átmenni STL topic-ba...): egy elvileg gyors stl implementáció: http://www.stlport.org/ (csak h alternatív is legyen, szintén GD.net rórumról).
twilek          2008.06.27 09:17
Hi

Ebben teljesen igazad van, sőt! Az előző postokból is leszűrve egyre valóbb az, hogy az stl el nagyon nagy gond nincs
Egy gp nél egésszen biztos, hogy jó megoldás, főleg, ha valaki épp ezzel nem akar szívni.
habár érdekes téma ilyeneket is írni
A sebességtől függetlenül az átláthatóság még mindig probléma szerintem ... (de mondom ez személyes vélemény, lehet valakinek meg teljesen átlátható).

Viszont azért mint már írtam vannak buktatók (qsort pl).. szóval, mivel más írta a kódot, nem árt nagyon tisztában lenni vele, mert sok vesződségtől kímélhet meg.
Szidi_Rezegh          2008.06.27 08:37
Alapvetően tetszett a cikk, sok igazság van benne. Én azt emelném ki belőle, ami GP vonatkozású., tehát a profi játékfejlesztés mellett a hobbiprojektek esetében is érdemes megszívlelni. Mindenekelőtt érdemes tervezni magát a játékot esetleg a kódot is, hogy átlátható legyen. Ha csapatban dolgozunk mások is átlássák, ha egyedül, lehetőségünknek legyen a későbbiekben is felhasználni a már egyszer megvalósított rutinokat(nem árt dokumentálni). Nagy igazság, hogy egy játék elkészítésénél(GP-nél is) sok olyan feladatot kell megoldani amihez nincs túl sok kedve az embernek (normális kezelőfelület kialakítása, balanszolás, tesztelés, hibák kutatása/javítása), unalmas, sok idő elmegy vele, de mégis meg kell csinálni, hogy épkézláb játékprogram kerüljön ki az emberek keze alól.

Amit viszont nem lenne jó átültetni és több GP-nél is hibának tartom, hogy a fejlesztők hajlamosak elveszni a részletekben (tisztelet a kivételnek). Az idő amit valaki a szabadidejéből egy gp-re tud áldozni korlátos és szerintem nem mindegy, hogy ezt mire fordítja. Nem akarom szegény-nyomorult STL-t védeni, de gp-k (akár egy minigame győztes vagy hgp) esetében teljesen jó, tehát felesleges pont ezzel tölteni az időt amíg pl.: nincs épkézláb játékmenet, kezelhetőség, esetleg valami pláne, ami játékot egyedivé/játszhatóvá teszi.
Adacs          2008.06.27 04:38
Design
Pont a GDF-en mondta az egyik cég (talán német vagy osztrák?) hogy nálluk a kiadás előtt egy fél évvel a deignereket átállították a következő projekt kidolgozására. Így a következő játékhoz komoly design volt a programozás 0. napján is. És bónuszban még nem szólogattak be az utolsó fázisban hogy zt cseréljük le, meg a 100 hektárból legyen inkább 1000. Persze nem kell nekik igazat adni mert nem éppen A kategóriát fejlesztettek és ráadásul valamit lovas játékot De azt mondta hogy jól megy a szekér és folyamatosan vesznek fel új embereket
twilek          2008.06.25 10:36
Ahh azt hittem ez egy lib nem néztem
Nem mondom, hogy nem lehet használni, vagy hogy nem fejleszt vele senki, azt hiszem ez már felmrült, hogy én is inkább lehet megszokásból használom a saját kódot, meg azért mer tegyes mérések alapján gyorsabb az a kód, ami speciálisan a feladatra készült, de ez egyáltalán nem jelenti azt, hogy ne lehetne használni bármilyen nagy játékfejlesztő cégnek
Drimm          2008.06.25 09:33
pl. http://nocturnal.insomniacgames.com/releases/Common/

Ez csak egy példa, de persze több fájlban is van:
Nocturnal_Common_1.0.0.zip\Common\Automation\Event.h

Csak rá akartam mutatni egy konkrét példával arra, hogy használják az STL-t nagy nevű komoly fejlesztőcégek is, így nem kellett azzal érvelnem szerintem mi a jó, hiszen ez nem az én kódom.
twilek          2008.06.25 09:03
Hi

A booston kívül az ott látott kodokban sehol nem láttam stl-t ... merre van? (ez nem kötöszködés, hanem érdeklődés, mielőtt fére lenne magyarázva!)

Mivel nem értettél egyett a cikkben? ( az is érdekelne )
Drimm          2008.06.25 08:31
Sok helyen nem értek egyet a cikkel, de most mindenbe nem mennék bele, inkább az STL-t védeném kicsit.

Nem kell azt az STL-t temetni, nézzetek bele az itt található kódokba, tele van vele:
http://nocturnal.insomniacgames.com/index.php/Main_Page

Ja, hogy ez melyik cég kódjaiból van?
http://insomniacgames.com/about.php

Néhány tízmillió db-ot eladtak a játékaikból (ps2, ps3), ha nekik jó volt, szerintem egy jó ideig nektek is jó lesz.

Persze, természetesen ésszel kell használni. Pl. nem használunk stringműveleteket sebesség kritikus részekben.

Ha meg fontos, hogy nagyon spóroljatok a memóriával, akkor ajánlom figyelmetekbe ezt a libraryt:
http://ustl.sourceforge.net/

(Wolfgang Engel neve talán ismerős, egy általa írt iPhone engine kódjai közt akadtam rá, hogy ott ezt a lib-et használja.)
könyvei:
http://www.amazon.com/s?ie=UTF8&search-type=ss&index=books&field-author=Wolfgang%20Engel&page=1
ShAdeVampirE          2008.06.24 09:02
Bár azért a teljesség igénye kedvéért: ebben az 5-8%-ban jelentős szerepe van annak, hogy itt a változók lefoglalásának az idejét is beleveszi a teszt, azaz h egy konstans tömböt v egy vector-t hozol létre.

Ja és azért vector és stl is gyorsítható, pl. ha tudsz olyan finomságokat, h clear sok implementációban törli is az elemeket a memóriából, míg resize(0) nem, csak jelzi, h már nem érdekli -> ez jóval gyorsabb lehet. És ez csak egy példa (pl. for ciklussal sem érdemse értéket adni a tömbnek ha kellően nagy, a helyett konstans tömb (gd.net szintén):
Kód:
// Bad:
for(int i = 0; i < numVertices; ++i)
m_vertices.push_back(v[i]);

// Good:
m_vertices.insert(m_vertices.end(), v, v+numVertices);
twilek          2008.06.24 07:53
ShadeVampirE ezzel el is dontotte akkor a kerdest
Koszonom en is az infot, ennyire azert nem voltam biztos benne.
Igazabol az 1% is szamitana, mar akkor megerne atirni... de 5-8% mar rengeteg
twilek          2008.06.24 07:52
A crytek engine, vagy UT engine egyaltalan nem hozhato fel peldanak
Ezeket a dolgokat eladasra szanjak, ezert el is vart a kello dokumentacio (hozzateszem az UT 3 engine dokumentalasa kb a 0 val egyenlo .. a pelda programok nem fordulnak le, tobb helyen irjak, hogy hat ez meg a regi engineben ilyen volt ...) szoval ez sem tokeletes eladasok alapjan az UT3 megis nyerobb mint a Crytek

Az uj kollegaknak bele kell tanulnia .. 1-2 het erre boven eleg, ha nem tudja megoldani, akkor az mar az O baja ... dokumentacio nelkul. Mondjuk a doksinal mindig is jobb, ha te probalsz megoldani valamit es ha nem megy akkor kerdezel.. ez egy elegge bevett szokas.

Az alap kovek persze le vannak fektetve a design doksiban, de az nagyon nem ter ki a reszletekre ... kb annyi, hogy: legyen egy rts jatekunk, amiben vannak tankok ))) egesszen a fejlesztes vegeig jonnek az uj otletek, a modositasok.
ShAdeVampirE          2008.06.24 06:55
OK, tévedtem, csak sikerült valakinek elírnia és a helyes:
Kód:
#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0


Ezzel tényleg sokat javul a helyzet, így már csak körülbelül 5-8%-kal volt gyorsabb átlagosan a sima, stl mentes kód.
ShAdeVampirE          2008.06.24 06:15
Bár a 2-es és 3-mas tesztet is érdemes megnézni, igazából nem is tudom miért nem azt a 2-t választottam, de kb. lényegtelen.

Amit viszont elfelejtettem: ez a teszt valószínűleg nem MSVC 2005-tel készült; én azzal is leteszteltem és nálam jóval nagyobb különbségek jöttek ki és nem az stl javára. Legtöbbször olyan 10-20%-kal volt gyorsabb az STL nélküli implementáció

+ amit alatta írnak, hogy MSVC2005-ben alapból mindig van bound check és ezt _STL_SECURE átállításával lehet kiiktatni -> ez nem teljesen igaz: Release-ben próbáltam a tesztet, de az alapján nekem úgy tűnt, hogy _STL_SECURE-t hiába állítgatom, az nem változtat semmin.

Mellesleg az std::vector [] operátorának kódja:
Kód:
reference operator[](size_type _Pos)
{ // subscript mutable sequence

#if _HAS_ITERATOR_DEBUGGING
if (size() <= _Pos)
{
_DEBUG_ERROR("vector subscript out of range");
_SCL_SECURE_OUT_OF_RANGE;
}
#endif /* _HAS_ITERATOR_DEBUGGING */
_SCL_SECURE_VALIDATE_RANGE(_Pos < size());

return (*(_Myfirst + _Pos));
}


-> mindenképp végez bound-check-et!
ShAdeVampirE          2008.06.24 05:50
Egy tesztből:
Kód:
// global array test

DWORD pixellist5[640*480];

void TestFunction5()
{
   
    tLockrect lockrect;
    lockrect.Pitch = 24;

    for(int i =0;i<640;i++) {
        for(int j=0;j<480;j++) {
            int index = i*lockrect.Pitch/4 + j;
            pixellist5[index] = dword[index % 8];
        }
    }
}

// global vector test

std::vector<DWORD> pixellist6(640 * 480);

void TestFunction6()
{

    tLockrect lockrect;
    lockrect.Pitch = 24;

    for(int i =0;i<640;i++) {
        for(int j=0;j<480;j++) {
            int index = i*lockrect.Pitch/4 + j;
            pixellist6[index] = dword[index % 8];
        }
    }
}


A többi nem annyira lényeges, a ez a 2 teszt a fontos. Ezeket többször is meghívták:
Kód:
time for test5 was 2887
time for test6 was 2904

time for test5 was 2892
time for test6 was 2870

time for test5 was 2899
time for test6 was 2902

time for test5 was 2896
time for test6 was 2898

time for test5 was 2881
time for test6 was 2869


Forrás: gamedev.net fórum

Érdemes átnézni, legalább ezt a tesztet amiből ezt kiszedegettem: egy static kulcsszó képes akár a 1/4-dére csökkenteni a futási időt. Persze ez egy spéci teszt, de azért az leszűrhető, hogy néha tényleg csak kulcsszavak v az dönt h hova rakjuk a változót (global v local, static v dynamic).
TPG          2008.06.23 15:19
Konkrétan játékkészítésben én is úgy tudom hogy nem használják az stl-t (bár az egyik Valve alkalmazott tett rá igen finom utalásokat hogy saját allocatoros stl konténereket is használnak már a Source-ban). Viszont a fizetős middleware készítésben igen, az egyik legnevesebb példa a Havok. A Bungie-nál anno szívtak is egy kört vele anno de utóbb kiderült hogy nem a Havokkal hanem velük volt a probléma. Manapság külföldi fejlesztőktől sokszor hallani már hogy az STL-t csak megszokásból nem használják a játékfejlesztésben, a mai korszerű implementációk általában baromi gyorsak már (mondjuk itt spec nem a MS-féle verzióról van szó), gyakorlatilag felesleges a sajátot megírni. Ez utóbbi ráadásul veszélyes is lehet, nem rég olvastam egy post-ot gamedev.net-en egy sráctól aki sebességben összehasonlította a Doom3-ban használt saját konténerek és az akkor friss megfelelő STL konténereket. Az STL nyert, pedig azokhoz a konténerekhez Carmack-nak is köze volt. Debuggolni is egész könnyen lehet már őket, ez saját tapasztalat, az MS-féle implementáció amit jelenleg még használok egész pontosan szól hogy hol fáj neki. Persze lehet jobbat, szebbet, gyorsabbat írni (mindig lehet, mindennél lehet) csak kérdés hogy megéri-e. Ezt mindenki döntse el maga. De persze ha a cégnél ez a követelmény akkor nincs mit tenni.

Kieg: az std::string általában tényleg lassú.
twilek          2008.06.23 14:09
Ugyanis a Designerek kitalalnak valamit. Azt a programmer kitalalja hogyan oldja meg, majd elkesziti, megmutatja, hogy ime, amikor a design eloall, jobb esetben nemi valtoztatassal, rosszabban egy teljesen mas dologgal ... akkor ujra csinalod, kiegeszited, stb .. a kod igy folyamatosan alakul ... olyan jatekfejlesztes nincsen, hogy elore ot a design doksi. A masik, ami ezt a dolgot neheziti, az, hogy itt nincsennek evek a feladatok elvegzesere, meg ujra irasara. Sokszor tobb napos feladatot alig par ora alatt kell megoldani, neha 2 napi folyamatos munka utan ... ilyenkor az ember se nem szepen, se nem optimalisan nem kodol, egyszeruen megcsinalja, hogy mukodjon valahogy es kesz. Ez persze nem jo megoldas, de nincs ido arra, hogy nezegesd mit lehet es hogyan, mert akkor nem lesz kesz.

Az STL-t minden esetben ki lehet dobni Azok az osztalyok amik kellenek egy 2-3 napos munkanal nem tartanak tovabb, igy nem olyan hatalmas az ido veszteseg raadasul sajat kod, sokkal, sokkal atlathatobb, es valamivel optimalisabb is. Emelett egy ilyen kod sokkal konnyebben megtanithato barkinek mint az, hogy mit kell megadni az std nek, hogy ugy forduljon, ugy mukodjon ahogy kell. Jatekfejleszto cegeknel nem is hasznaljak.
twilek          2008.06.23 14:09
Hat ha barki is tervezne barimt is, az valoban nagyon jo lenne , a jovo is errol szol, de nagyon kivancsian varom, hoyg mikor valosul meg ...
de nincsen ido sem a tervezesre, sem a dokumentalasra. Egy ilyen cegnel alap feltetel, hogy tudjal rendszert is tervezni, igy csak kiosztjak a feladatot, amit megtervezel, megcsinalsz .. kezdo suhancok nem igazan vannak... azaz pontosabban nincsennek. Ha valamiben elakadsz, kerdezel, rajossz, megoldod, de sebteben, ha nem megy, akkor konnyes bucsu kovetkezik.
Spanyol viaszt mindig es mindig fel kell talalni. Sose talalkoztam 2 szer ugyan azzal a problemaval es sosem hasznalunk masok altal kitalalt eszkozoket, hisz a legfontosabb a szerzoi jogok, amiket nem szabad megserteni (ez nem azert, mert mi vagyunk az erkolcsosseg pelda kepei, hanem mert csunyan perelhetove valnank). Ezert mindent, mondhatjuk ugy is, hogy fel kell talalni, persze akinek van egy kis esze, az elotte korbenez, peldak, mas megoldasok utan.

A jatekfejlesztesben egyaltalan nem mukodik a "Design - implement - optimize" modszer, pedig ez lenne a legszebb dolog a vilagon. Mar abban az esetben ha egyrol beszelunk Habar maskulonben is ...
twilek          2008.06.22 12:57
Hi

Azert egy toolt nem olyan veszes am osszedobni ugyanis nemi C# vagy inkabb C++-CLR kell hozza, a tobbi meg maga a game (sarkitva )))

Mi sajat fajl formatumot hasznaltunk, pont azert, mert abba benne van minden es a felesleges vackokat meg szepen nem tettuk bele ) ( de csunya mondat volt
Nem ismerem az osszes jatek fejleszto ceget de ahogy eddig lattam, mint sajat fajl formatumot hasznal ... sokkal konnyebb adatot tarolni, mert csak az van benne, ami a game nek kell
fpeti          2008.06.22 10:22
Jó kis cikk, globálisan beszél a témáról.
std - én sose használtam, ettől se jött meg a kedvem tőle
MFC- annó, amikor cpp kezdtem tanulni, sok mfc-s példát néztem, és azt hittem bennem van a hiba, hogy afféle fiaskónak tartottam az egészet, de mivel senkinek sem tetszik (mondjuk a codeproject oldalain 'istenítik' - de ők ugye nagyobbrészt indaiak), tényleg mondhatjuk, hogy el vala cseszve.
Szvsz ezzel a C++ -t nagyon aláásták a teljes IT szektorban, ezért (is) van akkora piaca a visual basic, C# és társainak (delphi), ahol rendesen meg van ez oldva.

Játék előtti tervezéshez:
Szvsz garázsprojekteknél esélytelen, hogy valaki lefekteti az alapokat, kitalál mindent előre:
mérget vennék rá, hogy a GP-k 95%-t olyanok írják, akik előtte nem írtak még olyat, és úgy nagyon nehéz előre kitalálni pl mennyi ideig tarthat egy rész (én inkább 5,10* szorzót ajánlanék )
Kevesen lehetnek, akik GP-ben már a haramadik FPS-üket írják. (úgy, hogy az előző kettő kész van)
(persze, ha valaki openszósz enginekódokat nézeget, javulhat a helyzet)

Tool-ok: szvsz több munka minden toolt megírni, mint magát a game-t. Itt egy garázsprojekt szvsz sok időt megtakaríthat, mert könnyen elmehet az összes idő egy hiperszuper segédprogi megírására, közben meg elmegy a kedv a projektől, vagy ami még valószínűbb, közben találkozik egy más témával, és hagyja az egészet a francba. GP-nél nem volna akkora probléma, ha a segédprogik bénábbak (nehézkesebbek), majd, ha jő a hírnév, és követeli a nép, akkor érdemes jobbat írni.

3D-s fileformátumok: profi cégek mindíg saját formátumot használnak? - ez megerősítné a negatív véleményemet az általános 3d-s formátumokról -mondjuk mindíg lehet valami gémspecifikus dolog, ami nincs benne. Csontos animációkat milyen formátumból importáltok? (- vagy jobb a saját exporter script írása?)
twilek          2008.06.20 13:15
Hi

Hat kimerhetek egy ilyet .. GlowCode szepen mutatja ogrenal de probalok valamit szamszeru adatot keresni.
Viszint, csak akkor leiras alapjan:
std regebbi verzioja volt, hyog bugos volt, ez ugye problema.
Masik, egy peldaval:
pl irsz egy Array osztajyt, aminek ugye az operator[]( int idx ); fuggvenyet kb igy irod meg:
Kód:
{
#ifdef _DEBUG
  if ( idx < 0 || idx >Size )
  {
      hiba kezeles
  }
#endif
   return Data[ idx ];
}


Ezzel azt ered el, hogy DEBUG ban lesz ellenorzes, mig RELEASE ben mar nem! Jelenleg ezt RTS ben mondom 100% ra ) ott ha debugban nem futott rossz indexel, akkor releaseben 99.99999% hogy nem fog, igy teljesen felesleges az if .. ez sokat (nagyon sokat, 1-2 fps-t) gyorsit!! ( ezutan jon a release test, szoval a hiba itt kizarhato )

Masik dolog, ez nem std-s de azert elegge core dolog, es jo tudni:
qsort, gondolom mindenki hasznalja ezerrel. Ezzel pont szivtunk, ugyanis a qsort maskepp mukodik win95/98, win2000, winNT, winXP, winVista ...
ha egy rendezett elemre meg 1 qsortot hivsz, akkor nem ugyan az lesz az eredmeny XP az ugyan olyan elemeket felcsereli, Vista azt hiszem nem ... es ez csak windows linux, ps3 .. hogy mukodhet ))

Amelett, ahogy irva volt, std nel a lenyeg, hogy minden platformon leforduljon .. ettol fuggetlenul van olyan std -s resz, ami windowson van, linuxon nincs .. ( type info egyes reszei )... a kod iszonyuan gany ... teljesen atlathatatlan .. egy letisztul szep kod, amirol te tduod mire kell az sokkal atlathatobb, es kevesebb benne az if is ))

std: ha nem debugot forditasz akkor is sokszor heapet, indexet ellenoriz, az emlitett pelda miatt feleslegesen!
Orphy          2008.06.20 06:47
Az std-vel kapcsolatos teljesítményproblémát már a második helyről hallom: anno, amikor látogatást tettünk a DR-nél, szintén volt erről szó.

Az egybehangzó vélemény ott is az volt: tévhit, ami a C++ könyvekben le vagyon írva. Az std a tankönyvi állításokkal szemben nincs agyonoptimalizálva, sokkal inkább azt tartották szem előtt, hogy minden platformon leforduljon, és emiatt elég csúnya, gányolt megoldások vannak benne. Javasolták, ha nem hisszük el, nézzünk bele a forrásába...

Persze, megint más kérdés, hogy ez mennyire érint egy GP-t, és mennyire érint egy AAA játékot...

Twilek, esetleg információ jelleggel tudsz nekünk adni egy durva összehasonlítást, hogy ez a teljesítmény-gond pl egy saját string-hez képest mennyire jelentős?
danó          2008.06.20 02:39
Egyetértek kiskamival minden nagyobb projektnek vannak olyan részei amiket nem szívesen de el kell végezni ha tovább akarunk haladni, a végén pedig úgyis az marad meg inkább, hogy elkészítettünk magunktól (vagy a csapatunkkal) egy játékot (vagy egy házat) amit büszkén felmutathatunk. Szóval ha így belegondolunk nem is siralmas a játékfejlesztés. Sőt egyes emberek pedig eleve azt élvezik ha akadályokat kell áthidalniuk...
kiskami          2008.06.20 01:11
Nem vitatkozunk, mások a preferenciáink.

Egyrészt nem tudom elképzelni az az esetet, amikor mondjuk egy std:string-et kellene debugolni, legfeljebb a tartalmát kell nézni, másrészt ha tényleg lassabb, akkor sem kellene kidobni miatta az egész std-t, ill. nem is érzékeltük eddig. Ha majd egy komoly funkcionalitást felvonultató kliens/szerver profiling *után* kiderül, hogy mondjuk az std::string komoly tényező, *akkor* ez megoldható lehet egy saját osztály implementálásával és replace-el. Első körben azonban, biztosan nem ezzel szeretném az időt tölteni.
twilek          2008.06.20 00:42
Hi

Az std vel kapcsolatban
Sajnos nem mitosz, nem eloitelet, egyszeruen ( sajnalom, lehet ez rosszul fog esni soakaknak ) hasznalhatatlan ...
Lassunak rettenetesen lassu. De nem mindig a futasi sebessegre gondolok. Mivel minden templateekbol epul fel belolle, ezert a forditasi sebesseg is jelentossen csokken miatta, ami egy ilyen projectnel igen is szamit! De ez csak az egyik dolog, sajnos futas kozben is igen lassu, sokkal lassabb mint egy sajat keszitesu osztaly. Itt nem azt kell nezni, hogy ohh hat 2 milisecce4l lassabb, azt kit erdekel ) )renderenkent van 100.000 string hivas mondjuk .. az azert mar nem mindegy ...
Masik dolog, es ez sajnos barmilyen allocatorral sem kivedheto .. a debugolas ...
Az std nek elegge sajatos a kodolasi syntaxisa, sokkal rondabb mint amit egy normalis ember hasznal (a rengeteg template miatt minden a headerben van, a valtozo nevek rettentoen kuszak, sokszor 1 sorban tobb utasitas van, stb). Ezzel szemben egy letisztult eletkepesebb ) kod konnyebben debugolhato ..

csak az std string nel maradva .. std::strig, amiben van std::basicstring .. ami asszem mar template ...
ezzel szemben egy sajat string osztalyban altalaban van egy char * amiben mar benne is van maga az adat ..

Ez a kotoszkodes az std vel nem azetr van mert kotoszkodni akarok vele hanem a tapasztalat, meresek, nezesekbol fakad. Hidd el, hogy akkora a kulonbseg, hogy egyszeruenm ki van jelentve, hogy "Nem hasznalhatsz std osztalyt" ...
kiskami          2008.06.20 00:28
Kettő dologban tér el a véleményem a cikkben leírtaktól. Az egyik a nyílt forráskód ellopása, a másik az std használata. Attól függetlenül, hogy a kód nyitott, még van neki egy licence - a mi esetünkben ez a gpl -, amit ha megsértenek, akkor jogi útra lehet terelni a dolgot. Ha valaki mondjuk a mi kódunkkal "robbantana" kis hazánkban, egyrészt elég hamar észrevennénk, másrészt a gpl simán lehetővé teszi a másolást módosítást, a kikötés annyi, hogy ugyanúgy gpl vagy azzal kompatibilis licence alatt kell lennie az "új" munkának is. De igazándiból minekünk az a fontosabb, hogy akárki meg tudja nézni, és hozzá tud járulni a munkához, ha van kedve, ideje, tudása, elképzelése.
Az std használatáról annyit, hogy az egy régi mítosz, hogy lassú. Az régen volt divat, hogy mindenki megírta a saját string-implementációját (semmi szükség rá). Egyrészt egyáltalán nem lassú, csak sokszor rossz eszközeit használják rossz feladatra, másrészt jól paraméterezhető saját allokátorokkal, egyéb algoritmusokkal - vagyis jól testreszabható. Nyílván nem kell ész nélkül használni mindenhol. Ha pl. egy std::string, map, vector jó az Ogrében engine-szintű dolgokra, akkor én nem fogok "alámenni" ennek a magasabb szintű játékfunkciókban - kérdéses és kétséges a sebességelőny haszna egy saját "optimailzált" megvalósítás bevetésekor.

Egyébként a cikk jó, és nyílván azok kifogásolják, vagy gondolják kicsit "sötét" hangulatúnak, aki még nem voltak nagyobb (profi) programozási projektben (nem kell feltétlenül játékfejlesztésre gondolni). Pedig a programozó élete ilyen. Nem csak móka és kacagás, sőt, leginkább nem.
Robsoft          2008.06.19 23:59
A dolgokat, amiket leírtál szerintem nagyrészben tudták eddig is alvasók, legalábbis azok biztosan, akik dolgoznak valamilyen fejlesztő cégnél.

Engem személyszerint a csapat összerakása, anyagi háttér érdekelne. Itt most nem az A-ról, hanem a casual/budget szintről lenne szó, ami itt mindekit érintene. Piacképes játékot baráti szeretetből nem lehet összerakni ezt azért leszögezhetjük. Ha a szomszéd "Pistike" rajzol nekem a paint-al egy Robsoft logót az meg ugye nem piacképes. A másik, hogy ha kész lesz a nagy mű legalább demó szinten akkor mit lehet azzal kezdeni? Kiadóknál kopogtatni, neten mutogatni és várni a csodát, vagy mégis hogyan?

A másik, hogy kihagytad platformokat. Linux ugye alapból nem játékos, elsődleges cél az xbox, utána windows. Ilyen szempontból az Ogre-val tökön lövöd magad, hacsak át nem írod a fél motort, de akkor már egyszerűbb sajátot írni, mivel ahogy leírtad az stl-t is úgy, ahogy van kigyomlálod belőle, meg még 100 féle átalakítás.
twilek          2008.06.19 12:51
MrPrise: sajnos az iras nagyon nem erossegem )) szerencsere van itt comment lehetoseg, igy magyarazkodhatok )) ezert most is meg a jovoben is elnezest azert irtam is ha van kerdes kerdezzetek ...
danó: thx
danó          2008.06.19 09:30
jó ez a cikk!! tetszik!! Gratula!
MrPrise          2008.06.19 09:25
Twilek,
Ok, így már világos, hogy mi volt a gond és erre valóban nem nagyon van automatikus (és jó) megoldás.
Viszont ha csak a cikkben írottakat olvassa az ember, abból az jön le hogy nem ismered a csere funkciót ;-) Ez pedig elég súlyos hiányosság lenne egy játékfejlesztőnél :-) Ezért nem tudtam mire vélni a dolgot
Igaz, láttam én már olyan beszerzőt, komoly multis cégnél aki egy megnyitott Excel táblában lévő két számot számológéppel (külső hw) adott össze, amikor a kollégája kérdezte, hogy mennyi az összegük ;-)
twilek          2008.06.18 16:00
hcs89: ok, a kov akkor arrol fog szolni
ha meg engednek ide irni
twilek          2008.06.18 15:58
Hi

Nem konstans ertek, de pl:
int8
int32
Mivel jatek fejlesztes, igy sajnos nem lehet megtenin, hoyg azt mondom, hogy a 8 ast csereld le 32 re ... meg sajnos igy sem, hogy regexp el az int8 at int32 re .. az ok roppant egyszeu, van 1000 hely ahol le kell cserelni, es van 2 ahol nem .. ezt az elejen nem tudod ( a vegen redul ki, hogy csak 2 helyen nem kellett ) es mivel ott a kiado uti a hatad, a fonokod uti a hatad, a testerek utik a hatad es a desingerek a fejedet )) ezert nagyon oda kell figyelni, hogy lehetoleg semmit ne ronts el! egy ilyen komplex kodban (tobb szaz fajl, tobb ezer sor ... ) barhol barmit valtoztatsz, az kihatassal lehet egy teljesen mas teruletre, ezert meg egy ilyen egyszerubb dolgot is jol at kell gondolni mielott ranyomod a savet ezt a search&replace nem vegzi el helyetted (amugy aVisual Studio az alap, mint editor, de szerintem mindenhol.. .vagy a nagyon nagy reszuknel a jf studioknak ))

Szoval emiatt kezzel, es ez sajnos nagyon nyogvenyelos
de persze van sok mas oldala is
A cikk foleg azert igy irodott, mert szerettem volna ugymond lebeszelni azokat akik 0 tudassal (programozoi, grafikai, stb) inditanak egy MMORPG -t )) hogy majd 2 het alatt elkeszul ugyis es ez megvaltja a vilagot ... (mint itt mar erre tobben is utaltak), Nekik es a nagyon lelkes embereknek szerettem volna megmutatni, hogy sajnos a jatekfejlesztes egy alom vilag, ahol neha elojonnek a remek ))
Persze lebeszelni senkit nem akarok, hisz attol fejlodik mindenki ha csinal valamit, de lattam mar eleg projectet en is bebukni (magam reszerol is).
MaximumViolence          2008.06.18 15:08
szép cikk,mondtál azért biztatót is
Kuz          2008.06.18 14:42
Szerintem itt csak arra gondolt, hogy egy bagatel hibát elkövetett, és nem vette észre, így baromi sokat kellett vesződnie, mire rájött. Talán...
MrPrise          2008.06.18 13:53
Ezen a soron akadt meg a szemem:
"sok robotmunka (volt olyan eset, hogy 1000 sort kellett átírjak, 1 napig folyamatosan csináltam… 32-őt kellett volna csak 8-ra átírni…"
Ezt nem értem. Ha csak 32-őt kellett 8-ra cserélni, akkor miért nem használtad a szerkesztő csere funkcióját, miért kézzel cserélgetted ki őket? Ha támogatja a regex-et a szerkesztő akkor pláne könnyű a dolog, bonyolult kifejezés esetén is. Ha pedig nem akkor olyat kell használni ami támogatja a regex-et is.
A gépek azért vannak, hogy helyettünk dolgozzanak. A számítógép pláne.
Ez a 32-t 8-ra csere pedig konstans érték bedrótózásának tűnik, ami eleve kerülendő, pont azért mert ha változtatni kell akkor minden helyen át kell írni ami időigényes, még akkor is ha nem kézzel csinálod, hanem cserével. Persze lehet, hogy ez egy olyan érték volt amiről úgy gondoltad, hogy sosem kell majd megváltoztatni (Murphy).
Értem én, hogy a játékfejlesztés árnyoldalát szeretted volna szemléltetni ezzel, de ez a példa szerintem nem volt túl szerencsés.
Dookle          2008.06.18 12:23
Én valahol egyetértek Twilekel.Én zenész vagyok zenéből élek.Szeretek rockot meg bluest játszani de ha komolyan meg akarsz a zenéből élni akkor bizony nagyon kemény munka és minden sz.rt el kell játszani hogy "megvehesd a mindennapi kenyeret".Úgyhogy valahol ez is olyan mint a játékfejlesztés
hcs89          2008.06.18 11:32
Hú twilek, igazad van. Meg is gondoltam magam, inkább megyek kapálni.
Na jó, ez csak vicc volt.
A cikk minden bizonnyal a valós helyzetet mutatja, de azért írhattál volna a játékfejlesztés napos oldaláról is. Remélem a következő cikkedben ezt bepótolod .
twilek          2008.06.18 10:49
hi

Itt abszolute a komoly jatekfejlesztesrol van szo, tehat nem arrol, amikor otthon osszeteszel egy par honapos, hetes jatekot.
Nem en vagyok tolle megfaradva, csak szerettem volna tudatositani, hogy a jatek fejlesztes (ha nem garazsproject) akkor az bezony nem csak moka es kacagas, hanem ugyan olyna kemeny munka mint a tobbi.
A garazs projectekben el lehet hagyni a nehez reszeket (nem baj ha kicsit lassabb, kicsit csunyabb, kicsit egyszerubb ..) mig a komoly jatekoknal egyszeruen nem lehet.
A masik dolog, hoyg mig otthon hobbybol fejleszted azt, amit te szeretsz, beleadva a te kreativitasodat, stb, addig egy fejlesztocegnel ilyenrol szo sincs. Egy koder nem szol bele abba, hogy mi legyen, nem mondhatja meg a legalapvetobb dolgokat sem, igy a kreativitas az nulla, emelett nem biztos, hoyg pont azt fejleszted, amihez neked kedved van

En imadom a jatekfejlesztest, nagyon szeretnek ezzel fogllakozni, de pl egy tankos rts-t nem csinalnek
kicsy          2008.06.18 07:33
Azért nemkevés 1-2 hónap alatt elkészült játékot láthattunk itt az oldalon is, elég csak a versenyekhez bekukkantani.. Inkább azt kell tudatosítani, hogy az AAA címek egy teljesen más kategória, teljesen más megközelítéssel mint a hobbifejlesztés, vagy független fejlesztés, akár piacra.
ragoon          2008.06.18 07:16
A cikk maga nem rossz, a hangulata már nem annyira. Nekem az egészből az jön le, hogy milyen szar játékot fejleszteni és mindenki aki ezt akarja csinálni, inkább menjen el kőmüvesnek, vagy akassza fel magát, ha nem akar mindenféle problémát a nyakába venni és vért izzadni. Én speciel azt élvezem az egészben, amikor problémákat kell megoldani és dolgoztatom az agyamat. (Még ha hibakeresésről van is szó)
Viszont az is lehet, hogy csak te unod ennyire a játékfejlesztést és a vele járó gondokat. Persze lehet, ha ez lenne a szakmám, halálra unnám magam és bármi mást csinálnék szívesebben. Mindegy... Minenesetre gratula a cikkhez és a bátorsághoz, hogy feltetted.