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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [25] [27]
Pretender - Törzstag | 2498 hsz       Online status #193308   2013.04.10 13:58 GMT+1 óra  
Ja, szóval továbbra is scene-függő a leginkább. Illetve attól függ, hogy hány fajta shadingre van szükség, illetve mennyi tükröződő felület van, stb.
De ha például ilyen diablo2 nézetes valamit akar az ember, ott belefér a deferred, mert egyszerre úgyis kevés dolgot renderelsz, cserébe berakhatsz egy valag fényt (minden egyes lövedékhez fényforrás, stb-stb.)
Ha viszont valami nyílt terepes TPS-t akar az ember, ott nem feltétlen szerencsés a deferred. Bár annak is megvan az előnye, a geometriát még mindig 1x kell csak kirenderelni; cserébe ott vannak ugye az ismert hátrányai...

Azért nem olyan egyszerű az szerintem... Egy csomó mindennek kell a depth buffer ugyan úgy, tehát ha "pre-z" passt csinál az ember, aztán még egyszer renderel, netán egyben a kettőt (MRT), akkor meg már majdnem ott van, mint deferreddel, csak a normal hiányzik (ami mondjuk simán tud 4 byte-nál több is lenni / pixel )

Nem beszélve a postprocess effektekről, amik szintén felhasználhatják a deferred adta targeteket (normalokat esetenként, netán a light buffert)

   
Geri - Törzstag | 2185 hsz       Online status #193294   2013.04.09 19:41 GMT+1 óra  
a mai gpuknak meg se kottyan pár fényforrás, csak a 8-adiktól már fele annyi az fps

   
versio - Tag | 659 hsz       Online status #193293   2013.04.09 18:26 GMT+1 óra  
a mai gpu-knak meg se kottyan par fenyforras, ezert teljesen felesleges deferred rendert irni,a kulonbozo posteffectek azok amik igenylik azt, pl le lehet renderelni az objectek elso es hatso felet is, es utana screenspecaben raytracing algoritmussal krealni arnyekot, elethu tukrozodest stb
   
ddbwo - Tag | 1625 hsz       Online status #193292   2013.04.09 16:23 GMT+1 óra  
Nálam a deffered nem jelent plusz fényt. Elméletileg sose igényelt egy térrészre olyan sok fény, hogy ne lehessen megoldani. Uniformként is, vagy textúrába is át lehet küldeni a fény adatokat. Csak azt is fel kell osztani. Csináltam így már 16+ lehetséges fényt is. csak elég értelmetlen.

Inkább azt érdemes figyelni, hogy sok polygon takarhatja-e egymást, és minden tele van-e szórva csillogással.
Pl. Ha Crysis szintű terepek és TotalWar mennyiségű karakterek takargatják egymást szűrés nélkül, a tényleges kirajzolt fényszám igencsak megnőhet egy kevésbé szerencsés szögből. Attól függetlenül, hogy a végső képen melyik fragment marad meg. (a legközelebbi)

Belső tereken ha van valami szűrés, akkor a takarásban lévő dolgok nem kerülnek rajzolásra. És a fények sem kerülnek még gondolatban se a shaderbe. Viszont azt meg ki kell dolgozni.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
versio - Tag | 659 hsz       Online status #193286   2013.04.09 13:31 GMT+1 óra  
szeretem a deferred megoldast, de 2 dolog is problemas, az egyik az hogy a mobilok kozul egyik sem tamogatja, beleertve meg az intel chipjeit is , persze elvileg megy, csak lassu mint a tetu
a masik dolog pedig hogy 6-8 rendertarget kellene , 4 az loszar
   
Pretender - Törzstag | 2498 hsz       Online status #193282   2013.04.09 10:08 GMT+1 óra  
Igazából azon gondolkoztam amikor lefeküdtem aludni (mert mikor máskor ), hogy inkább jelenetfüggő, hogy mikor melyiket érdemes. Például ha a játék alapvetően nyitott terepen játszódik, akkor nem feltétlen éri meg azért a pár plusz fényért. Viszont ha sok dinamikus fény kell egy belső térre... Cserébe ugye a materialokat nehezebb kezelni.

Deferreddel kapcsolatban azon gondolkoztam, hogy material id helyett a stencil buffert használom fel. Mondjuk minden egyes shading type 1/255-el több, mint az előző, és úgy rajzolom bele a gbufferbe. Shading lépésben pedig a stencilt úgy állítom be, hogy az adott értéken lévő pixeleket rajzolja csak. Nem tudom egyáltalán lehet-e így, ekkor viszont bármilyen shading ugyan úgy megoldható (az ilyen sbusurface scatteringtől kezdve mindenféle). Természetesen átlátszóság, tükröződés így is necces...

   
versio - Tag | 659 hsz       Online status #193281   2013.04.09 05:54 GMT+1 óra  
Pretender: a mobil cuccok nem tudnak deferredet, ez nagy problema, de ugy igazabol megse az, mert ha forwardot hasznalunk , deferreddel kombinalva , akkor mindenhol fut az enginunk
en ugy csinalom hogy forwardal renderelek , tobb rendertargetbe, es specialis effectek utolag vannak hozzaadva , mint pl screenspace ambientocclusion, DOF, screenspace shadow, screenspace reflection, screenspace subsurfacescattering stb...

aztan ahol nem fut le technologiai vagy sebessegbeli problemak miatt, a deferred reszt letiltom , es marad a forward
   
Pretender - Törzstag | 2498 hsz       Online status #193260   2013.04.08 19:30 GMT+1 óra  
Nézegettem a Valve publikációit. A lightmappel elég szép dolgokat lehet csinálni, meg elég jó dolgokat mutogattak, de azt próbáltam mérlegelni, hogy ha dinamikus dolgokat akarok, akkor az ugye nem járható út.
Vajon érdemes inkább tényleg deferred shadinget / lightningot csinálni, amivel teljesen dinamikus jeleneteket kaphatok? Cserébe lehet, hogy kevesebb trükköt lehet alkalmazni, és költségesebb is.

   
syam - Törzstag | 1491 hsz       Online status #190056   2013.01.06 19:16 GMT+1 óra  
Igen, a térrészeket tudom szerkeszteni és sokszorosítani. A térrészek tetszőleges konvex testek. Külső terekhez is használható ott még automatizálható is.
Az pedig még egy plusz adalék, hogy statikus láthatóságot is könnyű generálni ehhez.

A szerkesztőjéhez sok matek kell ill. sok tervezés a szerkesztéshez.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #190054   2013.01.06 18:58 GMT+1 óra  
Az még talán nem is nagy baj, főleg egy nagyobb nyitott terepnél, ahol van, ahol sűrűn vannak az objektumok, van, hogy ritkábban. Magukat a térrészeket tudod akkor szerkeszteni? Csak AABB-ben, vagy esetleg tetszőleges sokszögben érdemes gondolkozni? + ez jó lehet szektor alapú vágásra belső térnél. Csak általánosítani erre nem lehet...

   
syam - Törzstag | 1491 hsz       Online status #190053   2013.01.06 18:50 GMT+1 óra  
Belső tér helyett zsúfolt teret mondanék (pl. szabálytalan utcákkal teli város vagy kanyon).

Az egyik ilyen a bsp, de annak a generálása elég macera. Nem feltétlen kell vele geometriát vágni, simán berakod az adott vágósík mindkét oldalára.

Én olyan felosztást használok - reptile szerint olyasmi, mint a Descent használt - hogy szerkesztőben létrehozod a térrészeket és azokat összekötöm gráffá.

http://jatekfejlesztes.hu/kep.php?id=556535d21
http://jatekfejlesztes.hu/kep.php?id=4c1dce964

Ennek hátránya, hogy szerkesztő kell hozzá - automatán generálni háromszöghalmazból elég nehéz.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #190052   2013.01.06 18:25 GMT+1 óra  
Ilyen például..? BSP? Azzal még nem nagyon foglalkoztam, de valami olyasmi maradt meg, hogy néha a geometriát is ketté kell vágni. A BSP mondjuk inkább belső terekhez van, nem?

   
syam - Törzstag | 1491 hsz       Online status #190051   2013.01.06 17:57 GMT+1 óra  
Nagyon nem tudod egyszerre kezelni a kettőt a renderelés miatt.

Ha mindent felülről látsz akkor minimális lesz az overdraw, ha szabad a kamera akkor pedig nagyon nagy lehet. Az utóbbihoz mindenképp egy olyan térfelosztót érdemes választani, ahol szinte ingyen van a távolsági rendezés.

Mondjuk egy ilyennel lehet felülnézeti renderelést is csinálni.
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #190049   2013.01.06 17:32 GMT+1 óra  
Ha térfelosztásról van szó, és abban gondolkozok, hogy alapvetően 2 "fajta" játékot szeretnék működtetni a zendzsinemmel (diablo 2 - felülről nézős, illetve valami tps), akkor melyik térfelosztó rendszert érdemes választani?
- uniform grid: minden cella egységes méretű, nincs szülő-gyerek kapcsolat. Egy objektum helyét viszonylag gyorsan meg lehet határozni, pár alap művelet az egész (az egységes méret miatt)
- quadtree: mindenki által ismert szülő-gyerek kapcsolatos, egyre kisebb méretű nodeok. A szűrés gyorsabban megtörténhet, egy elem helyének a megkeresése valamivel tovább tart, mint az uniform grid esetén (talán nem számottevő.
Ismerem még az octree-t, de az kb. csak annyiban különbözik a quadtreetől, hogy a függőleges irányban is "terjed", tehát nem 4 részre osztja... vagy valami ilyesmi - erre talán nekem nincs szükségem.

A generálásról meg annyit, hogy az első esetben minden pályán a [floatmin, floatmax] tartományban "legenerálnám" a gridet, azaz runtime nem változna a térfelosztó, míg a másik esetben (quadtree) érdemes módosítani, ha módosul a pálya.

   
syam - Törzstag | 1491 hsz       Online status #186125   2012.08.16 16:33 GMT+1 óra  
Köszi a tanácsokat, végigpróbálgatom őket^^
alias aalberik
   
HadaHector - Tag | 71 hsz       Online status #186118   2012.08.16 13:24 GMT+1 óra  
http://www.diablowiki.net/Randomization#Map_Generation_and_Size
a diablo 3 mapgenerálásáról egy leírás, najó nem túl jó

Viszont az én elképzelésem szerint generálsz szobákat, és azokat kötöd össze. Ha hurkokat szeretnél, azt pedig úgy mond manuálisan programozd bele. Amúgy az ne legyen kifogás hogy nincsenek termeid, csinálj, a csővezeték egy idő után marha unalmas.

Szívem szerint én több fázisban generálnék, először a főágakat, aztán a mellékeket. Sőt igazából kiugranék a 2 dimenzióból, hogy igazán izgalmas legyen. Tegyél díszítőblockokat is mint diablóban is van.

   
ddbwo - Tag | 1625 hsz       Online status #186093   2012.08.15 22:26 GMT+1 óra  
Én random generálnék simán... Nincs "algoritmus" név a zsebemben.

pl.:
0-9 = kanyar jobbra
10-19 = kanyar balra
20-29 = kereszt
30-39 = vége
40 felett = egyenes

Az arányok változhatnak is. pl.:
- 4 egyenes után kötelező valaminek lenni. a fentiekből.
- vagy max 3 kereszteződés lehet, utána nincs esélye
-. Ha kanyar volt, muszáj végig balra fordulni, míg nem ütközik.
- max mélységnél van csak az ág vége, amit minden elemre számol
- bizonyos elem csak bizonyos távra lehet más valamiktől

Előre is lehet vizsgálódni kicsit, hogy van-e elég tér bizonyos alakzat sorsolásra. Ha nincs, visszatörli az ellenőrző pontig, vagy új véletlen helyet sorsolni és a max kívánt mélységig végig próbálni más irányba. Vagy szimplán vég kerül oda és nem számít fő útnak...
A mentett elágazásokat meg visszakeresni, folytatni, mint A*-nál.

Nálam stócóni kell egy raklap feltételt.
Vagy lehet "implement akármi generator" címeket guglizni.
Én inkább magamnak lerajzolom a feltétel fákat a lehető legegyszerűbben.
---

A sorsolt elem irányát mindig úgy tekinteném, mint ha a generátor haladna a folyosón, és attól balra, jobbra, előre.

Ezt a hozzászólást ddbwo módosította (2012.08.15 22:43 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
M4 - Tag | 187 hsz       Online status #186072   2012.08.15 14:46 GMT+1 óra  
Rakj le téglalapokat véletlenszerűen, majd törölj éleket véletlenszerűen. A megmaradó élekből lesz a csővezeték. Azt is meghatározhatod, hol legyenek a lezáró részek, hol elágazások.

   
DMG - Szerkesztő | 3172 hsz       Online status #186064   2012.08.15 13:05 GMT+1 óra  
Nade oda kell figyelni, mert különben a szemfüles játékosok belekötnek az űrhajó kiterjedésébe, és a landolás, manőverezés nehézségeire.
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #186062   2012.08.15 12:55 GMT+1 óra  
A modulok amikből építkezem ezek: http://yscik.com/jf/kep.php?id=f8a1e0680
(egyenes, sarok, elágazás - ezeken kívül van még 2 lezáró elem is).

A végeredmény az leginkább csővezetékre fog hasonlítani.

Szóval a kérdés inkább az, hogy csővezetéket mivel érdemes generálni úgy, hogy legyen be sarok, elágazás ill. hurok is.
Aztán ezt vagy űrbázisnak vagy űrhajónak vagy vmi teljesen másnak lehet elkeresztelni
alias aalberik
   
LugaidVandroiy - Törzstag | 504 hsz       Online status #186061   2012.08.15 11:56 GMT+1 óra  
Vagy pre-definied vagy teljesen alap szobákat létre tudsz hozni, és összekapcsolni őket folyosóval. Esetleg kialakíthatsz zónákat a generátorban, és az alapján szisztematikusan, de mégis random tudod őket ledobálni.

   
M4 - Tag | 187 hsz       Online status #186060   2012.08.15 11:11 GMT+1 óra  
H. R. Giger?
Amúgy mire gondolsz, kinézetre, textúrára vagy az alagutakra szobákra?

   
syam - Törzstag | 1491 hsz       Online status #186058   2012.08.15 10:52 GMT+1 óra  
Procedurális űrhajóbelső generátorra van vkinek tippje?
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #185749   2012.08.07 21:11 GMT+1 óra  
Egy fontos részt kifelejtettem, talán mert annyira szem előtt van, hogy már egyértelmű, pedig az egész hangulat kialakításáért felelősek ezek.

- feladat infók, küldetés napló
- hint-ek, utasítások
- felirat
- talált információs anyagok (cetlik, plakátok, Doom féle PDA-k, zár kombinációs infók)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
ddbwo - Tag | 1625 hsz       Online status #185716   2012.08.06 21:00 GMT+1 óra  
Na most jutott eszembe.
- lézerek mint területi aktivátor. (pl szenzórához)
- kamera, tv
- teleport
- energiamező ( lassít, rugó, gyorsít, antigrav, felhajtó erő )
- energia pajzs
- AI node-hoz target. (npc odalő valahova a jelenett miatt, pl helikopter kilövi a gátat)
- instant kill / sérthetetlenség (jelenetekben egy lövésre ölnek, vagy nem halnak meg golyózáporban sem)

Na ennyi. most már elég sok szempont előkerült, a többi meg bővíthető amikor kell...

Ezt a hozzászólást ddbwo módosította (2012.08.06 21:06 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
ddbwo - Tag | 1625 hsz       Online status #185715   2012.08.06 20:46 GMT+1 óra  
Nem gond, meg közbe le is futtatom fejben a témát, hátha közbe beugrik valami.

Még a kialakítással kapcsolatban jól jön, ha az egységek kaphatnak is csoportot, hogy ki mit használjon. Illetve az AI node-oknál is megvan adva hogy bárki hsználhatja, kifejezetten csak egy karakter, vagy csoport (Pl cinematic dolgok), Illetve milyen helyzetben. Harc, nyugalmi, stb.
A node-hoz kerülést meg már bárhogy lehet intézni. navmesh, waypoint, stb.

Az egység típusok úgyis csak akkor használják, ha le van írva a típusnak. Ezt C szinten kell lerendezni minden lehetséges játékelemre.

Még ilyeneket kifelejtettem, hogy model váltás, tulajdonság váltás (pl fizikánál rigid body-vá változik valami, vagy éppen statikussá), textúra váltás, animáció start, animáció stop, stb.
Meg mindennek jó, ha külön kell megadni modelt és nem az alapoknál kapja azt a modelt.
---
Robbanás téma:

A robbanás sem vészes, lehet egyszerűt is csinálni, bár több féle van abban is.
- gránát szerű detonáció (kis füst lökés, valami szikra, annyi)
- rakéta szerű (szétáradó részecske, vagy frame-es részecskék)
- nagy robbanás (kavargó lassabb, nagyobb részecske rendszer sok füsttel)
A szín már akár lila is lehet. Plusz lehet egy gyorsan felvillanó rövid életű fény is. Vagy csak energia robbanás.
Én játékokban nézegetem hogy náluk hogy néz ki. De a kinézet már egy könnyen módosítható rész. Energia gránát, vagy bármi ami a világba illik.

Meg ha már van olyan is, akkor lehet fekete flekket dobni a falakra.

Robbanás hatóköre. Sima bounding volume, esetleg plusz vonalas ütközés vizsgálat a terepre a középpontok közt, hogy volt-e takarás falakkal, terekkel. A sérülés erejét lehet linear vagy quadratic attenuation-nel számolni a hatókörön belül.
Ha fizikai detonáció is kell, akkor az energia iránya a robbanás középpontjától megy a tárgy felé a robbanás pillanatában. Ezt is ugyanazzal az attenuation-nel meg lehet oldani. Az energia max ereje meg tetszés szerint belőve.
Vizualizálni is lehet editorban egy gömbbel. Vagy kettővel mondjuk 50% erőtől vagy bármi.
A konstans sebzés nem túl életszerű, de a játék világa akár igényelheti is...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
syam - Törzstag | 1491 hsz       Online status #185689   2012.08.06 14:10 GMT+1 óra  
ddbwo:

Thx még egyszer. Ahogy nézem ezek közül sokat már meg tudok csinálni, egyedül a robbanás programozási mikéntje ismeretlen még előttem, de az szerintem csak az enginem köv. verziójába kerül bele.
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #185668   2012.08.05 22:38 GMT+1 óra  
Amit írtam gyorsan lent, abból az AI node volt a lényeges script szempontból. Még pár kiegészítő hozzá:
- fedezék / lőállás / töltő / visszavonulás / roham / fokozott járőr pont / speciális pont (pl aniim) / munka / légi csatorna / helikopter kedvenc figyelő helye / riasztó / kikötő / leszálló / beszálló / kiszálló / híd / ugró pont / guggolás / mászás / ablakon átugrás (FEAR) / ajtó betörés / vágás / robbantás.
Ezek járművekhez is lehetnek rögzítve, vagy bármi máshoz követve a mozgást.

Aztán be lehet szőni a fényeket, hangokat, zenéket ugyanígy.

Tehát tényleg igénytől függ, na meg attól, hogy mihez van animáció, ezért nem lehet teljes a lista.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
ddbwo - Tag | 1625 hsz       Online status #185657   2012.08.05 17:31 GMT+1 óra  
Egy ilyen source SDK félét fel tudok vázolni, de pl mapper szemmel az ajtónál is más megközelítés lenne.

Ajtó:
- forgó / szétnyíló / animált
- zárt / nyitott
Kioldás:
- gomb / kulcs / scene script
Nyitás:
- player, humanoid NPC, fotocellás, gombbal
Záródás: idő, -1 nyitva marad

A gomb lehet: kar, tolós, láthatatlan (pl animált érintős panel)

Aktivátorok:
- terület / gomb / tárgy / használat / dolog a zónában / a playernek van / érintés / elpusztulás / NPC / időzítő / erőhatás / súly terhelés / sebzés / robbanás / adat változás meghatározott NPC vagy tárgy meghatározott tulajdonságában

Időzítő
- véletlen / fix
- periodikus / egyszeri (hányszor? -1 örökké)

Scene script
- speciális animációk / gesztikuláció

AI node (földi, vízi, légi, jármű, humanoid, környezeti)
- fegyver / jármű / fontos helyszín / riasztó / mászóka / kötél / spawn pont / főellenség
Ezek elég fontos dolgok lehetnek, pl, sokkal okosabbnak tűnik az ellenség, és alig kerül valamibe kidolgozni. Példának itt ez az egyszerű illusztráció:

Az AI csakl ott lenne, de megadtunk egy node-ot, amihez odafut. Ha valaki lenne a géppuskánál, a node kikapcsolna. De mivel szabad, felmászik a falmászó node-on és elfoglalja a géppuskát a fegyver használó node miatt. Esetleg aki a fenti ajtóból jön, a falmászó node-ot lefoglalja és ott ugrik lefelé egy szép animációval.


tárgy használat (player)
- létra / kötél / csúszda / jármű / fegyver / szenzóra / csapda

Egyéb speciális:
- gyúlékony
- fokozottan tűz és robbanás veszélyes
- törékeny
- törésnél hulladék spawn

Entity pawner
- utánpótlás
- társak
- ellenség
- részecske rendszer
- jármű
- állat / szörny / bogár / halacska

Egyéb fizikához
- kötélen lóg
- tengelyre akasztott, billeg
- összekapcsolt
- mérleg szerűen ellensúlyzott
- pályán rögzített

++ Persze mindenhol ott a stb.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
syam - Törzstag | 1491 hsz       Online status #185655   2012.08.05 15:18 GMT+1 óra  
ddbwo:
Köszi, ilyenekre voltam kiváncsi.

Szerintetek milyen "játékelemeket" szoktak még scriptelni ajtókon, lifteken kívül ill. azoknak milyen típusai lehetnek?
Pl. ajtóból lehet automatán nyíló, kulccsal nyitható, vezérlővel nyitható stb.
alias aalberik
   
ddbwo - Tag | 1625 hsz       Online status #185652   2012.08.05 14:40 GMT+1 óra  
Persze attól függ, hogy milyen szemszögből nézzűk a scriptet. A "3D akciójáték" miatt én mapper szemmel vizsgáltam.
Ebben az esetben minden eltérő esemény scriptet jelent. A változatos körítés nem árt.

Pl.: A HL2-ben amikor Dog elkapja az APC-t és harcol vele, az szemmel láthatóan scriptelt jelenet. De pl ugyancsak a HL2-ben a metropolice-ok leereszkedése is az a canals-ban a falakról. Mert csak akkor csinálják, ha meg van írva a forgatókönyvben.

Vagy a Crysis-ben amikor a katonák egyesével leugrálnak a szállító kocsiról. Szinte elkülönülnek minden eseménytől, mert végre kell hajtaniuk a scriptet. A játékosok ezt nevezik scriptnek.

De még ha programozó is valaki, akkor is jól jön, ha egyszerű paneleken öt perc alatt összekattint egy teljes jelenet scriptet. A kódok copy-paste-je nem túl barátságos.

Script .. Twice the fun!
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
versio - Tag | 659 hsz       Online status #185648   2012.08.05 14:16 GMT+1 óra  
nem mindegyik jatekba kell script, miert hasznalnak scriptet? hat azert mert minden valtoztatas miatt nem lehet leforditani a kodot , a masik ok pedig , hogy altalaban a jatek designerek nem is tudnak programozni
pl ha egy ember csinalja a gemet akkor siman le lehet programozni c++ -ban is , persze itt nem doom3 szintu bonyolultsagot kell elkepzelni, de eleg lehet egy sima text file is
viszont ha durvulni kell akkor ott a c# , lazan a legjob script nyelv , es a leggyorsabb is
   
ddbwo - Tag | 1625 hsz       Online status #185643   2012.08.05 13:35 GMT+1 óra  
1. Alapvetően két nagy ág szokott lenni, ezen belül meg a fantázián múlik hogy hogyan alakul.

- El kell érni valamit / valahova
Gomb kapcsolgatás, ugrálás, folyosókon keringés, kulcs gyűjtés, robbantás, lopakodás, stb.
- Ki kell várni / túlélni
Ellenség özön, tankok, járművek, gépágyú, légvédelem, a lényeg hogy ideig vagy a szörnyek elfogyásáig egy helyben kell maradni.

2. Hát mindent, ami esemény.
- Egy alap dolog az "NPC maker". A szörnyek potyognak a mapra lyukakból, hozzáférhetetlen helyekről ereszkednek, teleportálnak, stb.
- gomb lenyomás, zónába érés, sima időzítő, kapcsolók, aktivátorok, helikopter útja, stb.

pl. lha belelősz egy szelepbe, felrobban egy cső, átalakul a cső modellje, bekapcsol a "gőzgyártó" részecske rendszer. -> Van a szenzor a térben. Akár maga a szelep. -> Aktiváláa sérülésre. Ez három dolgot aktivál ha megsérül. Robbanás, modell váltás, gőz bekapcs.

Vagy a player megérint egy síkot / zónát, leereszkedik egy helikopter, lift, megszólít az npc, stb.
---
tehát kellenek szenzorok, amik elágazva több dolgot módosíthatnak. Persze a szenzor bármit nézhet, pl megmurdált-e egy karakter. A Half-Life 2-ben ezek nagyon jól megvannak csinálva, mert bármi bármit aktiválhat és szinte minden esemény lehet aktivátor. Ja ráadásul nincs szám korlátozás sem.

Erős mapper szemlélet kell hozzá csak. Amikor megjelenik egy probléma, új mozdulat / eseménysor, akkor kell megcsinálni hozzá a scripteket.

Ezt a hozzászólást ddbwo módosította (2012.08.05 14:10 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Geri - Törzstag | 2185 hsz       Online status #185642   2012.08.05 13:31 GMT+1 óra  
mindent szkripttel kell csinálni, leszámítva olyan alapdolgokat mint a szereplők sétáltatása és alapmozgatása

   
syam - Törzstag | 1491 hsz       Online status #185641   2012.08.05 12:06 GMT+1 óra  
1 - 3D akciójátékokban milyen típusú feladatok szoktak lenni?
2 - Miket szoktak scripttel megvalósítani?

Esetleg van erről vmilyen cikk a neten?
alias aalberik
   
Pretender - Törzstag | 2498 hsz       Online status #185028   2012.07.24 08:24 GMT+1 óra  
No, azt történt, hogy: van egy interfészem, amit egy dll-ben implementálok. Mivel nem töltöm be a dll osztályait, stb., ezért van egy CreateXY() globális függvényem benne, ami létrehozza az adott objektumot. Valami ilyesmi
Kód:
// === proj ===

class interface
{
    interface() { }
    virtual ~interface() { }
};

// === dll ===

class derived : public interface
{
    derived() : interface() { }
    ~derived() { }
};

void CreateDerived(interface** obj)
{
    *obj = new derived();
}

Ezt a függvényt a "proj" libraryben GetProcAddressel elkérem, majd létrehozok egy példányt a dlles derived osztályból. Ez a megoldás egy könyvben van, ahol azt írják, hogy kell egy ReleaseXY() is, mert:
Idézet
As you will see in a moment, the object that implements the interface is created inside the DLL. Therefore, I let the DLL do the release job of this object as well because the objects's memory has been allocated on the DLL's heap.

Kipróbáltam a ReleaseXY() nélkül, simán delete obj, a vtable miatt természetesen ez is működött, de nem tudom, hogy az idézett résznek később lesz-e jelentősége. Szóval tényleg számít-e, hogy a dllben implementált fgv, amit GetProcAddressel kértem el hozta létre az objektumot.

   
ddbwo - Tag | 1625 hsz       Online status #184531   2012.07.14 14:54 GMT+1 óra  
Idézet
dvorgaz :
blob shadow



Nosztalgikus.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
dvorgaz - Törzstag | 575 hsz       Online status #184526   2012.07.14 09:45 GMT+1 óra  
blob shadow
   
ddbwo - Tag | 1625 hsz       Online status #184518   2012.07.13 23:15 GMT+1 óra  
Milyen árnyék képzés technikák vannak?

Ami hirtelen eszembe jut:
- planar (mátrix lapítós)
- volumetric (z-fail)
- render buffer

Van még amit kifelejtettem?
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pretender - Törzstag | 2498 hsz       Online status #184512   2012.07.13 15:24 GMT+1 óra  
A c++ topicban elkezdtem egy eszmefuttatást, hogy szépen szét akarom választani a dolgokat libekbe / dllekbe, és végül is ApplicationWin, stb. osztályok lennének.
Az első kérdésem az lenne, hogy meddig a szintig lehet általánosítani? Konkrétan az Application osztályra gondolok. A Windows rendszert ismerem, ott ugye egy HWND van. Linuxot, Macet, Androidot, stb. nem ismerem, ott is esetleg a handlerek leírhatóak egy unsigned int típussal? Ugyan ez lenne ugye a renderelőnek a "bemenete" (ablak handlerje) is, ezért lenne fontos pl.

Esetleg van-e valami jó kis tutorial, ami összeszedi a Win, Linux, Mac, Android, stb. ablak létrehozását. Így látnám, hogy lehet-e pl. általánosan az összes platformon létrehozott ablak handlerje egy unsigned int.

Őőőő, izé... kicsit furán tettem fel a kérdést

   
Pretender - Törzstag | 2498 hsz       Online status #184017   2012.06.29 08:15 GMT+1 óra  
Van fixed timestepem, azaz az Update() mindig fix 60x fog lefutni, ez így elég állandó. Vannak a megjelenítés előtti teendők (culling, etc.). Azt nézegettem, hogy ha a tényleges FPS < 60, azaz lassabban tudja csak kirajzolni, akkor ugye az Update() fut le többször, ellenkező esetben pedig a Draw(). Tehát akkor hova érdemes az ilyesmi számításokat rakni? Az update fixnek tűnik, viszont, ha lassabb a kirajzolás 60 FPSnél, akkor ott "érné meg jobban". Ha viszont több, akkor ugye többször kiszámoljuk fölöslegesen ugyan azt.
Érdemes a kirajzolást is maximalizálni mondjuk 60 FPSre, és akkor mondjuk oda rakni ezeket a számításokat?

   
syam - Törzstag | 1491 hsz       Online status #182279   2012.06.04 00:55 GMT+1 óra  
Idézet
fpeti :
A huszárvágás:
Deferred rendering + transparency



Fuuu, ezt ki kell próbálni...
Bár már volt ehhez hasonló megoldás régebben
alias aalberik
   
fpeti - Törzstag | 1280 hsz       Online status #182278   2012.06.04 00:45 GMT+1 óra  
Geri - Törzstag | 2185 hsz       Online status #182167   2012.06.02 17:03 GMT+1 óra  
nab: nálam be van töltve az egész, csak a precízió változik. aztán ahogy haladsz, időnként újragenerálja részletenként (ez még nem működik autómatikusan). igen, röccen tőle néhányat. először külön threadon akartam generálni egy új fába, csak ez igencsak megdobná a memóriaigényt.

   
fpeti - Törzstag | 1280 hsz       Online status #181980   2012.05.30 20:52 GMT+1 óra  
Idézet
nab :
Geri ha van videód az engine -röl szívesen megnézném. Az látszik hogy a szűk keresztmetszet a processzor. Senkinek sem sikerült megoldani hogy olyan gyorsan generálódjon le a pálya hogy a töltés ne látszódjon. Ezért én olyan pálya generáláson gondolkoztam aminél csak az töltődik le ami látszik pl a föld alatti barlangok nem. Gondolkozom azon érdemes lenne cuda -t segítségül hívni a generálásban persze akkor ati kártyával lassabban működne. Szerintem komoly jövő áll a voxeles játékok előtt főleg azért is mert nem kell iszonyatos mennyiségű grafikai elemet hozzáadni a játékhoz hogy élvezhető legyen.



Nemrég jelent meg az XBox-on az MC, ott rögzített a terepméret vmi 4K blokk azt hiszem, amin sokáig el lehet szórakozni. Nekem az is jó lenne, ha várni kéne 5 percet, generálna egy nagy területet és utána gond nélkül lehetne pár órát kalandozni. Annyi elég egyszerre. Utána csinálna még területet, ha kell. Sok játéknak a teljes játékideje pár óra, ahhoz képest nem lenne rossz.
Egyébként szerintem is nagy jövő előtt áll, külön genre-k családját hozza létre ez a fajta pályafelépítés, a kockák egyre kisebbek leszek, a végén már látni se lehet majd őket.
Egyébként az MC nagyon brute-forceosan rajzol, se lod, se semmi, lehetne trükközni, sok tartalék van még benne.
Idézet
Parallax :
Azt majd az ipar, meg az okosok kitalálják mi lesz a hatékony, addig is valamiből élni kell, szóval poly.


Ne tévesszem meg a voxelek emlegetése, nem sok köze van hozzá, csak a pálya felépítése hasonlít abban, hogy kockákból áll, de a rajzolás 3szögekkel megy itt is.
Franc se gondolta volna, hogy a pörgős kockás helloworld-öt továbbfejlesztve ilyet lehet..
   
Parallax - Tag | 574 hsz       Online status #181961   2012.05.30 17:50 GMT+1 óra  
Azt majd az ipar, meg az okosok kitalálják mi lesz a hatékony, addig is valamiből élni kell, szóval poly.

   
nab - Tag | 30 hsz       Online status #181956   2012.05.30 14:03 GMT+1 óra  
Geri ha van videód az engine -röl szívesen megnézném. Az látszik hogy a szűk keresztmetszet a processzor. Senkinek sem sikerült megoldani hogy olyan gyorsan generálódjon le a pálya hogy a töltés ne látszódjon. Ezért én olyan pálya generáláson gondolkoztam aminél csak az töltődik le ami látszik pl a föld alatti barlangok nem. Gondolkozom azon érdemes lenne cuda -t segítségül hívni a generálásban persze akkor ati kártyával lassabban működne. Szerintem komoly jövő áll a voxeles játékok előtt főleg azért is mert nem kell iszonyatos mennyiségű grafikai elemet hozzáadni a játékhoz hogy élvezhető legyen.

Ezt a hozzászólást nab módosította (2012.05.30 14:16 GMT+1 óra, ---)

   
Geri - Törzstag | 2185 hsz       Online status #181932   2012.05.30 01:57 GMT+1 óra  
nekem működik a voxeles grafikus enginem gyakorlatban is, azt kell hogy mondjam, hogy kicsit még korai ez a technológia, kell még neki MINIMUM 3-4 év, hogy az első értelmesebb voxel alapú játékok elkezdjenek szállingózni. És itt most voxel alatt a renderelési technológiát értem, és nem azt, hogy féltéglákból áll a játék.

   
nab - Tag | 30 hsz       Online status #181925   2012.05.29 22:08 GMT+1 óra  
Ez a unityis jópofa

   
fpeti - Törzstag | 1280 hsz       Online status #181918   2012.05.29 20:30 GMT+1 óra  
Idézet
nab :
Minecraft -oz hasonló játékot, milyen engine -el lenne érdemes csinálni? Tele van az internet millió 1 enginel, de nézegetem amint "voxeleket" szeretnék megvalósítani rengeteg probléma adódik, pl udk -ra elég nehéz ráerőszakolni hogy egyszerű cubeokat generáljon, voltak már próbálkozások ogre ben, de ott sem sikerült eddig senkinek használható kódot írnia. Voxel engine meg jelenleg még nem létezik. Próbálkozott már valaki hasonlóval?


Vannak azért voxeles cuccok, esetleg: Polyvox

Egyébként az MC elég speciális genre, bár mostanában mmo félék is kijöttek kockákból összerakott világokkal (láttam valahol, név nem jut eszembe). Én arra tippelnék, hogy saját megvalósítás a legtöbb. Ogre-ben is van ilyen tényleg. Ott visszakonvertálja a kockákat mesh-re.
A nagy részét úgyis neked kell megírni szerintem, a kirajzolást már akármelyik engine végezheti, csak tudjon sok kockát/háromszöget rajzolni.
Egyébként rákerestem a 'Minecraft like engine'-el,és úgy néz ki meg lehet oldani Unity-vel is:
vid
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] > 5 < [6] [7] [8] [9] [10] [15] [20] [25] [27]