Játékprogramozók (főleg)! Mai technológiával mennyi időbe telhet egy ilyen jellegű játék elkészítése? Bővebben lent.

Egy ilyen játék elkészítését már nem nevezhetjük egyszerűen "játékprogramozásnak", így ennek a kérdésnek a megválaszolása nem pusztán programozói kompetencia. Grafikus, játéktervező, zeneszerző és programozó csapatmunkájáról beszélünk. Ez nyilván nem 3-4 ember, inkább egy 8-10 fős csapat.

A készítési időt a technológia nem befolyásolja úgy, ahogy azt vélhetőleg feltételezed, oké a 3D objektumok renderelése pl gyorsabban fog menni mint 10 éve, de az idő jórészét a tervezési-alkotási folyamat teszi ki.

Nem szabad megfeledkezni az állandó tesztelésekről valamint a projekt menedzseléséről és koordinálásáról sem, ami plusz embereket jelent.

Nagyjából 3..4 évet saccolok, de ha még game engine sincs, akkor ez még plusz 1..2 év is lehet.

A csapat bővítésével fel lehet gyorsítani a fejlesztési időt, de van egy szint, amin túl már nem lehet (ill nem célszerű) kiosztani párhuzamosan részfeladatokat.

#4 lényegében mindent leírt, amit én tudtam volna. Egy dolgot még hozzátennék: Rockstar North-nak volt már tapasztalata hasonló játék fejlesztésében, és kiindulási alapja is, ahogy #2 is írta. Ezeknek szerepét pedig nem szabad lebecsülni...

Ha rendelkeznél egy hasonló csapattal, mint a Rockstar North, egy ilyen játékot tovább tartana megvalósítani, mivel lényegében többször kéne megtervezni a világot, és az egyes NPC karaktereket is fel kéne erre készíteni (pl máshogy kell reagálniuk egy kardos és egy géppisztolyos harcban).

Hány embernek? Neked egyedül?

Úgy 200-300 év.

Leírnám az én véleményemet erről, bocsi, kicsit hosszú lett.

A probléma már akkor sem a technológiával volt, mert a komplexitás növekedése manapság, ellensúlyozza az akkori "primitív" technológiát. Az igazi oka annak, hogy egy ekkora játékot sokáig fejlesztenek, az a rengeteg kommunikáció és megosztottság, ami a fejlesztés szakaszában zajlik. Nagy játékot nem fejlesztettem még, saját projektem viszont van, illetve több év nagyvállalati szoftverfejlesztői gyakorlatom is. Elmesélem, nagyjából hogyan is néz ki.

Egy nagy cég több részlegből áll, mint például grafikusok, HR, felsővezetés, fejlesztők, dizájnerek stb..A fejlesztői részleg is több külön csapatból áll. Egy fejlesztőcsapat fele, de inkább harmada áll tényleges programozó fejlesztőkből. A többiek mással foglalkoznak, ami elengedhetetlen ahhoz, hogy a programozók boldoguljanak (nem csak a programozás a fejlesztés).

Használjuk fel az említett játékot, a San Andreas-t: Lezlie Benzies gondol egyet, és azt mondja, hogy neki nem tetszett az, ahogy a fény becsapódott a betonba a Vice City-ben, így azt csinálják újra. Ehhez elemzik, hogyan épült fel a Vice City-ben használt raycasting komponens, az milyen interfészekkel kapcsolódott a komponensekhez amik körbevették, és refaktorálják az egészet. Nem azt csinálják, hogy átírnak bizonyos részeket, hanem kidobják a kukába amit a Vice City-ben használtak raycaster komponensnek, és írnak egy újat oly módon, hogy az akár a Vice City-be is beilleszthető legyen. Miért? Mert egyszerűbb így tesztelni, és könnyebb komponensalapon előállítani.

Na de ahhoz, hogy a raycastingot meg tudják csinálni, az nem annyiból áll, hogy a programozó megkapja a feladatot, hogy "tessék ittvan he". Először is minden generáció a realistább grafikára törekszik. Terepgyakorlatokat tartanak, megnézik a fény valós törését a betonon (lehet, hogy változott az elmúlt pár évben), majd lemodellezik matematikailag, használva az elérhető képleteket, azokat finomítva, validálják, hogy ez nem eredményezhet-e olyat, hogy a fény mondjuk tükör módjára x fokban teljes sugarával visszaverődik a betonról, majd ha ez kész, átadják valakinek, aki ütemezi ezeknek a kódolási folyamatát, megtervezi az elkészítést, megírja a teszteseteket hozzá (bár ezt már más is csinálhatja), végül átadja a programozóknak, hogy nesze, így a programozónak nem kell agyalnia a fotonok adott sűrűségű anyaggal való kontaktja esetén történteken, nekik csak egy magas absztrakciós modellt kell implementálni, végül átadnak egy - rossz példa, de - .dll fájlt, ami tartalmazza az új raycasting komponenst.

Miután ez elkészült, ezt vissza kell illeszteni a régi motorba, ennek a menetét valaki megint megtervezi, teszteseteket ír rá, leteszteli és ha sikeres, akkor készre jelenti a motort, ha nem, akkor vissza a fejlesztőkhöz az egész.

Ha már több level design is van, azt valakiknek le kell modellezni. A modellezés után a programozókkal egyeztetni kell, hogy mi interaktív, mi nem, mit hogy képzeltek el, milyen speciális szekciók vannak a modellben, hiszen egy ajtó kinyitása nem abból áll a játék szempontjából, hogy a játékos odamegy, és az ajtó modellel lép interakcióba, az ajtó keret, és maga az ajtó is két külön modell, amely ajtót a keret egyik oldalánál fogva kell kódból elforgatni, hogy kinyíljon. Ezt a programozó általában belső specifikációban kapja meg, amiből elsőre általában nem ért meg sok mindent, így a fölösleges körfutások jönnek, a levelezgetések arról, hogy a dizájner hogy képzelte el, és arról, amit a programozó megértett belőle, amíg aztán 3-4 levélváltás után rájönnek, hogy ha élőben megbeszélték volna, 10 perc alatt megértik kinek mi a baja.

GTA játék lévén, rengeteg hangot kell megszerkeszteni, felvenni, amihez a dialógusokat meg is kell írni, ami akkor jó, ha már van egy alap sztori hozzá, így rögtön egy mondatban 4 részleget vontunk be egy lépéshez. Egyeztetni kell az írókkal, hogy kit hogyan képzeltek el. A grafikusokkal, hogy lerajzolják sketchben legalább azt, hogy az írók kit hogyan képzeltek el. Ehhez kell hangokat keresni, a főszereplőkhöz ugye általában valami híresebb arcot. Azokat meg kell kérdezni, mennyiért vállalják el. A munkadíjukat egyeztetni kell a felsővezetéssel, hogy "belefér-e" a költségvetésbe. Megint csak egyeztetni a programozókkal, hogy melyik ingame párbeszéd mikor jelenjen meg. Az átvezetőket hagyjuk, azt a grafikusok animálják meg a házi engine szerkesztővel, ott ők bajlódnak a hangokkal, a szájra illesztéssel stb.. A programozó megint specifikációban kapja meg levélben, hogy mit mikor kell, aztán ebből megint nem ért dolgokat, és kezdődik újra a grafikusokkal már korábban eljátszott elbeszélés.

A hangok mellett zene is kell, amit licenszelni kell, ennek a jogdíja és a költségvetés milyen viszonyban vannak, rádióállomásokhoz DJ-ket és bemondókat szerezni, ezek dumáit megírni, ez igazából hozzávehető az előző részhez, de itt például jogi dolgokkal is számolni kell.

Rengeteg dolog van még, amit kihagytam, de ennyi szerintem elég lesz. A lényeg az, hogy a technológia akkor sem volt határ, mert ahogy korábban sem használtak, most sem fognak nagy fejlesztőcsapatok community engine-t használni (Unity, Unreal, CryEngine), hanem megírják a sajátjukat, ami akkor is, és most is elvette az időt. A korlátok mindig is hardveresek voltak, a 2003-ban használt C++ ugyanúgy tudta volna produkálni a 2016-os C++ szintjét, de ami most egy GTX960-at megizzaszt, az akkor a NASA szerverparkján sem futott volna. Az egyszerre betölthető (memóriában tárolható) elemek száma is drasztikusan megnőtt az évek alatt, így adódik például, hogy sokkal interaktívabb lett a GTA 3-hoz képest a GTA 5, mert megtehetik azt, hogy odaírnak 6GB memóriát követelménynek, ugyanis az manapság elérhető, ami anno 2001-ben öngyilkosság lett volna, mert senki sem tudott volna játszani vele. Egy ilyen hatalmas játékprojekt fő időigénye az apró részletekben van, és a korrekt szervezésben, mindenki csak azt csinálja, amit megkapott feladatnak. Természetesen amiket leírtam, azok párhuzamosan futnak általában, amíg a programozók programoznak, a többi már készíti elő nekik a következő lépésre az anyagot, a grafikusok pedig már dolgoznak a saját projektjeiken.

+1:

Érdekességképpen, így néz ki egy játék vizualitása in-production és post-production: [link]