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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2194
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] > 8 < [9] [10] [15] [16]
danielkekk - Tag | 1 hsz       Online status #167267   2011.10.21 12:52 GMT+1 óra  
Sziasztok!

Az lenne a kérdésem, hogy tudtok valami általános algoritmust a címben említett probléma megoldására vagy egy oldalt ahol le van írva? A konkrét feladat a következő: A parton van X darab kannibál és Y darab misszionárius és át kell juttatni őket a túlpartra. Ezenkívül meg lehet adni a misszionáriusok erősségét. Ha például azt adom meg, hogy 1es erősségű akkor ha 4 kannibál és 3 misszionárius van a parton még életben maradnak. C-ben kellene megoldanom a feladatot.

Köszönöm a segítséget előre is.

   
borsi - Tag | 180 hsz       Online status #166236   2011.10.05 09:42 GMT+1 óra  
Amúgy szerintem a helyett, hogy egyes formátumokhoz írnál konvertert, érdemesebb valami ehhez hasonlót használni. Így elég egy adatszerkezetet ismerned, és több mint 20 formátumot tudsz használni

   
syam - Törzstag | 1491 hsz       Online status #166232   2011.10.05 09:15 GMT+1 óra  
Ha jól emlékszem ez a téma már (legalább) egyszer felmerült .obj loader kapcsán :3
alias aalberik
   
Matzi - Szerkesztő | 2525 hsz       Online status #166230   2011.10.05 09:10 GMT+1 óra  
Nem tökéletes, de ez biztos benne van.
Link.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #166226   2011.10.05 08:46 GMT+1 óra  
Nekem is X importer amúgy
Valóban egy egyszeri dolog, csak fura, hogy amit a dxviewer 2mp alatt megnyit, azt nekem 10-15mp-ig "konvertálja" (mert a végén kimentem binárisba, és azt töltöm be)

@Matzi: lehet átküldted anno, nem tudom azóta van-e frissebb változat, mert mintha nekem még az lett volna meg, amibe teszt jelleggel beraktad ezt a fajta "rendezést"

   
Matzi - Szerkesztő | 2525 hsz       Online status #166225   2011.10.05 08:37 GMT+1 óra  
Nekem speciel pont van egy X importerem, ami pont ugyanezt csinálja, és ha érdekel oda is tudom adni, ha még nem tettem meg.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
dvorgaz - Törzstag | 576 hsz       Online status #166224   2011.10.05 08:33 GMT+1 óra  
Ez valami modell exporter? Ha igen, én ezt úgy oldottam meg, hogy a modellezőben egy háromszög 3 csúcsához le vannak tárolva a pozíció/normál/texcoord indexek és egyszerűen kiexportáltam háromszögenként 3 vertexet pos/norm/tex-szel együtt. Ezután végigmentem a vertex listán és kiszórtam amiből több volt, ezzel együtt újraindexeltem a csúcsokat.
Egyébként szerintem ennek tökmindegy, hogy mennyi keresgélés van benne, mert úgyis egy preprocessz jellegű dolog.
   
Pretender - Törzstag | 2498 hsz       Online status #166210   2011.10.05 05:32 GMT+1 óra  
@ddbwo: újra indexelni mindenképpen kell. Mondom, képzeld csak el egy kocka egyetlen csúcsát. Vicces lenne, ha csak egy normal tartozna hozzá. = több vertex lesz = módosulnak az indexek

@Asylum: nem értem mire gondolsz... már hogy duplikáljam? Nem tudom, hogy miből kell kettő, vagy három, vagy több, és hogy annak milyen új indexe lesz...

   
Asylum - Törzstag | 5471 hsz       Online status #166204   2011.10.04 22:49 GMT+1 óra  
Ezt igy felejtsd el, duplikáld a pozíciókat / amit kell 24-re.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #166203   2011.10.04 22:41 GMT+1 óra  
Ne legyen újra indexelés, csak hagyja ki ami nincs, vagy párhuzamosan az újra indexelés mellett kerüljenek be 0 indexek a false-hoz.
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 #166017   2011.10.03 12:50 GMT+1 óra  
Na hát talán ide való a kérdés:
Szóval van egy rakat pozícióm, normálom, texcoordom, a pozíciókra és a normálokra vonatkozó indexem. Tekintsünk egy kockát
8 pozíció, de kapásból 24 normal és texcoord. Ami természetesen indexelve van, az alap viszont a pozícióra és a normalra külön vonatkozik. Valahogy ebből nekem értelmesen össze kellene raknom egy saját vertexstruktúra elemeit.

Jelenleg működő állapotban van, de ez így nem az igazi, elég sok a keresgélés. Berakom a kódot, hátha megérti valaki rajtam kívül
Kód:
/*m_PositionIndices = a pozíciók indexelése
m_NormalIndices = a normálok indexelése
m_Vertices = a vertexstruktúrámból egy vector
m_VertexIndices = ez pedig a végső index lista, hiszen változni fognak az indexek (pl. az előbbi kocka esetén nem 8*3 lesz, hanem több, mert hiába 8 csúcsa van, de a csúcsoknál különbözőek a normalok*/

for (int i = 0; i != m_PositionIndices.size(); i++)
{
    int positionIndex = m_PositionIndices[i];
    int normalIndex = m_NormalIndices[i];

    //create vertex
    VertexNTB vertex = VertexNTB(m_Positions[positionIndex], m_Texcoords[positionIndex], m_Normals[normalIndex], Vector3::Zero, Vector3::Zero);

    //vertex exist?
    bool exist = false;
    for (int k = 0; k != m_Vertices.size(); k++)
    {
        //vertex exist
        if (m_Vertices[k] == vertex)
        {
            exist = true;
            m_VertexIndices.push_back(k);
            break;
        }
    }

    //if vertex exist
    if (exist)
    {
        //move to next index
        continue;
    }

    //create vertex and add new index
    m_Vertices.push_back(vertex);
    m_VertexIndices.push_back(m_Vertices.size()-1);
}


szerk.:
Ugyan ez igaz a vertexeknek "felskinnelésére". Az X miután definiálta a mesheket, megadja csontonként, hogy az melyik id-jű vertexet milyen súllyal befolyásol. Csak mivel nekem változtak az indexek, így az X-ben lévő indexek nekem nem jók.
Kód:
int numSkins = m_Skins.size();
for (int s = 0; s != numSkins; s++)
{
    XSkin* skin = m_Skins[s];

    //search the frame to the skin
    int bone = GetBoneId(skin->m_Name);

    //set parameters
    int numVertexIndices = skin->m_VertexIndices.size();
    for (int i = 0; i != numVertexIndices; i++)
    {
        int pid = skin->m_VertexIndices[i];

        for (int v = 0; v != m_Meshes[m]->m_VerticesBone.size(); v++)
        {
            if (m_Meshes[m]->m_VerticesBone[v].Position == m_Meshes[m]->m_Positions[pid])
                m_Meshes[m]->SetVertexBoneValues(v, bone, skin->m_VertexWeights[i]);
        }
    }
}

Ezt a hozzászólást Pretender módosította (2011.10.03 13:08 GMT+1 óra, ---)

   
Asylum - Törzstag | 5471 hsz       Online status #165881   2011.10.02 12:43 GMT+1 óra  
Ha pl. plasmagunra gondolsz, akkor rendes ütközésvizsgálat kell (ami alatt sweep test-et értek).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
ddbwo - Tag | 1654 hsz       Online status #165877   2011.10.02 12:21 GMT+1 óra  
Ja visszatérve a nyíl példára, a kezdő és végpont megadja az irány vektor, a végpont vagy kezdőpont pedig lehet a lövedék modelljének középpontja.

Ha nincs ütközés mondjuk fallal, akkor a modell megjelenik, különben történik aminek kell, megmaradó nyilaknál meg a falon számolt végponton jelenik meg egy új objektum, a régit lehet törölni még a rajzolás előtt. Hogy semmiképpen ne jelenjen meg olyan helyen, ahol nem is lehetne. Pl fal mögött. De ha a kezdőponton jelenik meg mindig, annak jónak kell lenni,.

De magát a lövedék fizikáját vonalként vagy szakaszként a legspórolósabb kezelni. persze a tengelyen végig lehet küldeni karikákat, hogy hengernek számítson. meg ha indokolt, lehet korong, gömb, hasáb, stb. A lehető legegyszerűbb kell ami leírja a lövedék viselkedését.

Ezt a hozzászólást ddbwo módosította (2011.10.02 12:28 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
   
Matzi - Szerkesztő | 2525 hsz       Online status #165870   2011.10.02 10:58 GMT+1 óra  
Speciel az FPS-ek többségében a sima gépfegyver lövedékek egyetlen vonal ütközést vizsgálnak a lövés pillanatában, és utána kb random a lőpálya valamelyik szakaszát felvillantják. Van egy játék, amiben ez nagyon durván megfigyelhető, a többiben nem feltűnő.

A lassabb lövedékeknél, pl gránát, rakéta, stb... ott valószínűleg rendesen kell ütköztetni és mozgatni.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
ddbwo - Tag | 1654 hsz       Online status #165863   2011.10.02 10:22 GMT+1 óra  
A lövedék sebességéből meg lehet kapni, hogy mekkora távot tesz meg egy "logic step" alatt. A kezdőpont és a végpont közt egy vonal keletkezik, amire vonalas ütközésvizsgálatot lehet csinálni.
Amennyire kell, annyira pontos lesz a vizsgálat és tévedhetetlen, csak minden step-nél az előző végpontból kell a következőt kiszámolni. Így be lehet iktatni a ballisztikus pályát is, gellert, meg ami kell.

Ha a vonal ütközést mutat, a kezdőpontból kis karikákat lehet "kilőni" a végpont felé, hogy kiderüljön az ütközés pontos helye, valamint hogy a fal miatt meddig érvényes a golyó. Csak hogy el legyen kerülve a falon átlövés meg ilyenek.

A megjelenítés lehet sárga csík, ami a vonal tört részére vagy egészére kerülhet. Vagy bármi más. De pl a cod-okban meg sok fps-ben így van megoldva és elég életszerű szokott lenni.
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
   
zeller - Törzstag | 486 hsz       Online status #165862   2011.10.02 09:25 GMT+1 óra  
Projectile-ok.
Tfh van olyan fegyver, vagy barmi, aminek a lovedeke nem fenysebesseggel halad, hanem lathatoan animalni kell, szoval ugyanolyan mozgasallapottal rendelkezo merev testkent kell kezelni, mint barmely masik jatekbeli objektumot, csak eppen rovidebb eletu.
Ezt hogyan szokas optimalizalni? Meg egyaltalan kezelni
Elvileg akar rajzolhatnank is csak egy valamit minden frame-ben egy kicsit eltolva es elore kiszamoljuk az idopontot amikor talalkozik, a hatasat pedig kesleletve fejti ki egy dummy valami.
Vagy erdemesebb merev testet es utkozeseket kezelni? Akar egy nyilvesszonel is?

   
zeller - Törzstag | 486 hsz       Online status #165133   2011.09.24 13:58 GMT+1 óra  
Gondoltam, hogy triggert teszek ra, de tulzasnak tartottam, minek ilyen eroforrast hasznalni egy mashogy is megoldhato problemara.
De aztan lehet, hogy atirom ugy, majd meglatjuk.

   
borsi - Tag | 180 hsz       Online status #165125   2011.09.24 12:24 GMT+1 óra  
Unitytől függetlenül az ilyen line of sight problémákat általában triggerré alakított colliderekkel szokás megoldani. Az más kérdés, hogy a fizikai motor milyen adatszerkezetet és algoritmust használ az ütközés vizsgálathoz. És nem hinném hogy kevésbé lenne optimális a megoldás, mintha saját algoritmust használnál.

   
Pretender - Törzstag | 2498 hsz       Online status #165124   2011.09.24 12:23 GMT+1 óra  
Valóban, valószínűleg a háttérben ez is ilyesmit alkalmaz, mint amit írtak / írtunk lentebb.

Amúgy szerintem a közös jf-projekthez kell neki, szóval szerintem Unity-s cuccra gondolt. De lehet, hogy tévedek

   
Matzi - Szerkesztő | 2525 hsz       Online status #165122   2011.09.24 12:16 GMT+1 óra  
borsi:
Ez egy unity specifikus cucc, ami valószínűleg szintén térfelosztással operál a háttérben. Tehát használni egyszerűbb ugyan, de a működése nem az. Illetve ugye a kérdésben nem szerepelt, hogy unity specifikus megoldás kellene.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
borsi - Tag | 180 hsz       Online status #165121   2011.09.24 12:12 GMT+1 óra  
Ezeknél van jóval egyszerűbb megoldás is: trigger. Minden toronyhoz csatolsz megfelelő méretű triggert (empty child sphere collider-el), csak azokat kell ellenőrizni OnTriggerStay()-ben, amik éppen benne vannak.
Konkrét példák itt: http://technology.blurst.com/unity-physics-trigger-collider-examples/

   
Pretender - Törzstag | 2498 hsz       Online status #165115   2011.09.24 10:31 GMT+1 óra  
Előfordulhat olyan eset, hogy 8 trillio kilométerre van egy ellenfél? Amúgy meg lehet ilyen voxelgridet (olyasmi, mint a quadtree, csak ez egyenlő "dobozokból" áll, és statikus) csinálni pl., és akkor csak a (optimális esetben) szomszédos gridben lévő ellenfelekre kell letesztelni. De szerintem két vektor távolságának kiszámolása nem egy olyan nagyon-nagy feladat, hogy ne bírja...
Kód:
v1 = (x1,y1,z1)
v2 = (x2, y2, z2)
d = sqrt((x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2)

de gondolom ezt tudod te is...

szerk.:
ájh, látom, elkéstem

   
syam - Törzstag | 1491 hsz       Online status #165114   2011.09.24 10:30 GMT+1 óra  
A toronyból frustum cull ami közben távolság alapján sorba is rendez.
Aztán utána választhat a leggyengébb, legközelebbi stb. között.
alias aalberik
   
Matzi - Szerkesztő | 2525 hsz       Online status #165113   2011.09.24 10:29 GMT+1 óra  
Térfelosztás. 4fa, 8fa, uniform grid, BSP, stb... A konkrét választás a pálya adottságaitól függ. Én egy TD-nél, ami ugye egy korlátolt fix pályán játszódik a talajszinten, vagy az uniform gridet használnám, vagy ha valamiért nagyon muszáj, akkor esetleg 4fát. Először kiszámolod, hogy a tornyod melyik mezőket látja a térfelosztásban (optimálisan ez elég kevés lesz), és azon belül nézi meg az egységeket. Az egységeket meg minden elmozdulás után hozzárendeled a mezőhöz, amiben állnak.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
zeller - Törzstag | 486 hsz       Online status #165112   2011.09.24 10:16 GMT+1 óra  
Tower defense.
A toronynak celpontot kell talalnia.
Az alapjan donti el, hogy valaki celpont-e, hogy a ket helyvektor kulonbsegenek abszoluterteke kisebb mint a hatotavja.
Amig nem talalt ilyet, pasztazza az ellenfeleket a palyan.
A kerdes:
hogyan lehetne felokositani az algoritmust, hogy a teljesen szoba nem joheto, pl 8 trillio kilometerre levo ellenfeleket ne akarja feleslegesen megnezni?
Esetleg mas megkozelitessel kellene csinalni az algot?

   
zeller - Törzstag | 486 hsz       Online status #163009   2011.09.08 09:23 GMT+1 óra  
Entity systemek megint:
Az ok, hogy az entityk komponensei csak markerek, hogy mit kell veluk csinalni.
Az elvi nyeresegunk, mivel az entityk is helyet foglalnak a memoriakban, az n-1 virtualis fuggveny tabla.
Az entityknek kell legyen sajat allapota, kulonben ddbwo scripthez jutnank, ahol
cicapoziciok[100000] es hasonlo tombok lennenek. Ezt senki sem akarhatja...

Tfh minden viselkedeshez kulon komponenst vagy elemi komponensek egy halmazat rendeljuk, ezaltal
a kiscica = kis + cica(es cica = negylabu+allat+...) a nagycica meg = nagy +cica

Es most jon a drawback! Valahogyan neked definialnod kell, hogy a nagy meg a kis dolgok hogyan viselkednek. Ezt pedig fuggvenyekkel irod le. Azaz amit nyertel, azt majdnem elvesztetted, nem?

Persze kirajzolasnal elvileg nem, hiszen n vertexet ugyaugy rajzolsz mint 2n-t. Jateklogikanal viszont a veszteseg sokkal nagyobb lesz, mint amit nyernel. Minden viselkedesre meg kell irnod a fuggvenyt, amit aztan tipusazonositas segitsegevel kell meghivnod az objektumra. Ez amiatt, hogy az entityknek es a komponenseknek nincsenek fuggvenyeik, valahogy igy fog kinezni:
Kód:
if e is okos:
   okosanKovet(e, player)
if e is buta
   butanKovet(e, player)

Megfelelo mennyisegu tipusnal nehezen karbantarthato es terjengos kodot eredmenyez.

Elfogadom, hogy megjelenitesnel, hangoknal a funkcionalis dekompozicio polimorfikus objektumokon (buzzword: entity system) hatekonyabb mint az objektum orientalt. Ezt Szirmay is megmondta mar szggrafon.
De minden mas esetben nem. Szerintem.

   
borsi - Tag | 180 hsz       Online status #162424   2011.09.03 12:19 GMT+1 óra  
Ezt a kérdést úgy oldja meg, hogy a komponensek nem részei az entitynek, külön-külön megfelelő adatszerkezetekben vannak tárolva. A kapcsolat az összetartozó komponensek között annyi, hogy mindnek ugyan az az "entity id"-ja. Esetleg optimalizálásként az entityk tárolhatnak pontereket a komponenseikre. És így egy systemnek csak a megfelelő komponenseken kell végig menni, nem az entityken.

Például a hang systemnek kell a megfelelő pozíció és hangeffekt komponens, a render systemnek kell a pozíció és a renderelni kívánt adat (shader, vbo, ebo, stb), a fizika systemnek kellhet a sebesség, pozíció, bounding box, stb. Ha még azt megoldjuk, hogy egy komponenst csak egy system írhasson, akkor könnyen párhuzamosítható is.

De amúgy csak azt próbálom összefoglalni, amit a lent linkelt két cikkből megértettem, mert még soha nem csináltam ilyesmit.

Ezt a hozzászólást borsi módosította (2011.09.03 12:28 GMT+1 óra, ---)

   
zeller - Törzstag | 486 hsz       Online status #162391   2011.09.03 09:11 GMT+1 óra  
Ez szerintem elegge spanyolviasz.
Funkcionalis dekopozicio, polimorfikus 'objektumokon'. Csak ehhez nem kell entity systemnek nevezni...

A kulcs tenyleg ott van, hogy nem kell minden kodot objektumorientaltan megirni, de ezt Stroustrup is megmondta, ezert nem pure oo a c++.

pszeudokod szinten ez valami ilyesmi lehet:
Kód:
macska is allat
entity1 is macska
//etc

system allatsiomogato

fun simogat():
   foreach entity:
       if entity is allat:
            doSimogat(entity);


A kulcskerdes, hogy hogyan optimalizalod a kodot arra, hogy ne kelljenmindig a tipust identifikalni.
Mondjuk index szerkezettel, mapekben.

   
fpeti - Törzstag | 1295 hsz       Online status #162376   2011.09.02 23:16 GMT+1 óra  
Idézet
syam :
vannak az alap építőelemek (mesh, shape, light stb) amiket node-okhoz lehet rendelni a node-okból csontvázat, a csontvázat pedig szereplőhöz.


Lehet kezdem lassan fogni.. de nálam marad az öröklődés egyelőre
   
syam - Törzstag | 1491 hsz       Online status #162371   2011.09.02 22:55 GMT+1 óra  
Ezt nehéz röviden leírni: vannak az alap építőelemek (mesh, shape, light stb) amiket node-okhoz lehet rendelni a node-okból csontvázat, a csontvázat pedig szereplőhöz.

Ezeket az elemeket lehet / kell tárolni a térfelosztásban, fizikában, játék logikában, script rendszerben stb.

Attól függően mi mivel rendelkezik és miben tárolom írom meg hozzá a függvényt. Így pl vminek szüksége van aabb-re, vminek nem.

Oda kell rá figyelni az elején, de utána automatán megy a szereplődarabolás, robbantás, öltöztetés, ha modell a tüzet fog stb.

Ha pedig bármi kétség merül fel, csak meg kell nézni a táblázatot ^^
alias aalberik
   
fpeti - Törzstag | 1295 hsz       Online status #162367   2011.09.02 22:32 GMT+1 óra  
Idézet
syam :
Jéé, én ilyet csináltam - nekem is van egy ilyen rácsom, h mi milyen részekből áll


Ebben nincsenek a dolgok 'egységesítve'? Mondjuk le akarok kérni egy pozíciót, aabb-t, akkor azt hogy lehet megcsinálni? Minden objektumtípusra külön meg kell írni, vagy hogy?
Minden objektumtípus külön listában van?
- nem értem ezt - (10 sor kód elég lett volna a duma helyett - sokan savallják is a kommentekben)
   
ddbwo - Tag | 1654 hsz       Online status #162366   2011.09.02 22:29 GMT+1 óra  
Az alap gondolatmenet a következő. Ha pl valami alap mozgó dolog van, adott egy sima tömb:

float data[512][9], van 512 lény egység, aminek van 9 float mozgás adata.

Az ismert sorrend a következő lehet modelleknél példának okáért:

{pos_x, pos_y, pos_z, vec_x, vec_y, vec_z, speed, rot_x, rot_y, rot_z}

A kezelő metódus a következőt teszi mozgásnál pl:

void move()
{
for (int num = 0;num<512;num++)
{
data[ num ] [ 1 ] += data[ num ] [ 4 ] * data[ num ] [ 7 ];
data[ num ] [ 2 ] += data[ num ] [ 5 ] * data[ num ] [ 7 ];
data[ num ] [ 3 ] += data[ num ] [ 6 ] * data[ num ] [ 7 ];
}
}

kirajzolásnál a pozíció az első három adat, a forgás az uccsó három, a blur a hetedik.

Ugyanezen logika alapján lehet keverni minden mást. Minden egységnek megvan minden adat, de csak azokat alkalmazza a rendszer, amik az adott tárgyra tartoznak, a többi nulla. Pl egy fának nincs vektora és sebessége.

Persze ez most nagyon egyszerű példa, mert nem raktam current_pos-t, meg next_pos-t és nincs fizikai algoritmus sem. De tisztán látszik hogy nem oop, mégis megvannak a tárgyak a maguk módján. Ezek konkrétan sprite-ok...

@syam:
Na ugye, nem nagy cuccok, ki lehet őket taláni.
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 #162365   2011.09.02 22:12 GMT+1 óra  
Jéé, én ilyet csináltam - nekem is van egy ilyen rácsom, h mi milyen részekből áll
alias aalberik
   
borsi - Tag | 180 hsz       Online status #162364   2011.09.02 22:07 GMT+1 óra  
Ez a link rövidebben összefoglalja, de pont ezért elég felületes is. Jelenleg még én is csak emésztem és próbálom papíron meg fejben összerakni, hogy ebből hogyan lesz egy működő egész. Az egyik alapvetés, hogy ne használjunk benne oop kódot, hoz némi kihívást.

   
ddbwo - Tag | 1654 hsz       Online status #162363   2011.09.02 21:26 GMT+1 óra  
Idézet
borsi :
A komponens alapú játékfejlesztéssel van már valakinek tapasztalata? Konkrétan az ilyen durván data-driven megoldásra gondolok, ahol egy entity csak egy id ami összekapcsolja az összetartozó komponenseket.



Ha jól veszem ki, akkor arról szól a rendszer, hogy mindennek megvan a lényeges funkciója, jellemzője, tulajdonsága, ami alapján működésbe lép, vagy ami alapján használják.
Szerintem hasonlóval kísérleteztem Blenderben. De ez eléggé feltétel rendszerekre épül, mivel a tulajdonságokat a megfelelő logikai halmaz alapján lehet beazonosítani.
Ez sem annyira különleges, mint ahogy beállítják.

Ráadásul minden egységnek kell metódus, de azt írja hogy nem, pedig akkor mi alapján választaná meg az egység a lehetőségek közül a vélt jó reakciót?
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 | 1654 hsz       Online status #162362   2011.09.02 21:07 GMT+1 óra  
@Parallax:

Értem én, hogy sok embernek, főleg fiatalabb korosztálynak (pl 18 év alatt) idő kitapasztalni a dolgokat, vagy fel kell venni a kód szemléletet, mert még új. De nekem már nagyon rég óta nem kell hosszan gondolkodnom semmin, elég látnom egy helyzetet és megvan minden megoldás.

Most minden gúnyolódási szándék nélkül, nekem ez az egyszer jönnek a szívások ilyen "jön a zsákos ember és elvisz" félének tűnik. Még sosem láttam olyat, amit igazán nehéz megoldani. Persze megint lehetne jönni egy csinálj Szudoku megoldó algoritmust tanáccsal.

Egy játék szintjén semmi váratlan feladat nem érhet... A következő mondatom önteltnek tűnhet, de az a legnagyobb hátrányom, hogy tisztában vagyok a képességeimmel.
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
   
borsi - Tag | 180 hsz       Online status #162360   2011.09.02 21:00 GMT+1 óra  
A komponens alapú játékfejlesztéssel van már valakinek tapasztalata? Konkrétan az ilyen durván data-driven megoldásra gondolok, ahol egy entity csak egy id ami összekapcsolja az összetartozó komponenseket.

   
Parallax - Tag | 603 hsz       Online status #162359   2011.09.02 20:40 GMT+1 óra  
zeller: Természetesen én se céges projectről beszélek, hanem sajátról. A cégesben sajnos sok dilettáns is beleszarik, nem lehet normálisan betartani semmit. Az ördögtől valónak titulálnak sokszor teljesen alap dolgokat is, főleg, ha több cég is összedolgozik és különböző szintű emberek, az mekkora káosz. Saját project kódjára öröm ránézni, esetleg újrahasznosítani, az más eset. Aztán, hogy ez mennyire jó arról csak annyit, hogy legtöbb helyen húzzák-vonják adott felépített rndszerüket. Onnan nem tudnak kimozdulni, legfőképp tervezés hiánya, l'art pour l'art fejlesztés, pontosabban gányolás miatt. Látszólag gyorsan haladnak ideiglenesen, de csak egy helyben járnak.

ddbwo: Majd rájössz, ez hosszú évek és szívások folyamata lesz, nem csak úgy sitty-sutty. A programozás egy gondolkodásmód, aminek érési folyamata van. Érdemes nézni mindenféle fejlesztési, programozási módszert és használni, megérteni. Elsőre hülyeségnek, erőltetett dolgoknak tűnő módszerekre rájössz, hogy ez hosszútávon tök jó. Sebességben akkora különbség nincs egy magasszintű nyelven belül, hogy ne érné meg. Ha sebeségezni kell, akkor asm, de kinől a szakállad mire abban megírod és át is látod. A script jó ötlet, extrém gyors fejlesztés, csak legyen hozzá jó debug lehetőség, különben visszaüt.

   
ddbwo - Tag | 1654 hsz       Online status #162358   2011.09.02 20:15 GMT+1 óra  
OOP-ben sem hiszem hogy minden automatice jön létre, két sort azért csak be kell szúrni valahova... De összefoglalhatom egy metódusba az egészet és akkor csak ennyi látszana:

enemy_logic();

Attól még vannak benne if -ek, meg struktúrák, meg minden, csak nem látszik. A legelső barbár if-es módot sosem használtam, minek kérdezni hogy van-e kolbász, ha egyszer tudom hogy van?

Persze izlések és pofonok. Nekem ez a minimális programozási modell bejön, mert teljes a kontrollom minden felett. És mi lehetne gyorsabb, mint egy egyszerű struct tömb végigpörgetése, ahol ráadásul minden egy helyen van, így a memória a legminimálisabban sem tördelt?

Én magamnak átlátom azt is, ha csak egy float enemy[10][512][12] van, és egy metódus fut végig az egészen. Ezt is használtam mostanában.

Amiben biztos vagyok, hogy ennél nincs gyorsabb és egyszerűbb megoldás. Persze a class-osat is ismerem, meg is tudom csinálni, de ez gyorsabban is gépelhető egyedül. Nekem megfelel a gépi utasítás szint is, már a metódus megnevezéséből is tudom, hogy mire jó.
Biztos nem ez a legszebb kinézetre, de a legminimálisabb. És bármit meg tudok csinálni vele.

Ha látnátok, h milyen rövid egy-egy cucc. Na de nem reklám, mindenki használja csak azt amit, mert biztos van oka, hogy miért azt használja.

---
Viszont komolyan tervezem mostanában a python integrációját, amiben majd szépen .py fájlokban fogok scriptelgetni, a python már a kisujjamban van, vagy két hétig nyúztam aztat.
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
   
zeller - Törzstag | 486 hsz       Online status #162356   2011.09.02 19:50 GMT+1 óra  
Sokszor sajnos nem a hardcore modularitas, design for reuse and extend a nyero, legalabbis a valo eletben, de szerintem ez azert van mert sok a kokler. Ha mindenki pro lenne es nem kv-val toltene a munkaideje felet, akkor nem igy lenne.
De ez tan mar off ide...

   
Parallax - Tag | 603 hsz       Online status #162355   2011.09.02 19:41 GMT+1 óra  
Pont a végeredmény érdekében alakultak ki nem véletlenül bizonyos dolgok. Lehet tolni is egy kocsit, meg bele is lehet ülni és menni 100-al.

   
zeller - Törzstag | 486 hsz       Online status #162354   2011.09.02 19:39 GMT+1 óra  
Annyit hozzatennek, hogy cpp-ben a struct == class aminek minden tagja publikus. C-ben valoban nem lehetnek tagfuggvenyei.

De mindenki ugy kodol ahogy akar.
Amugy is a vegeredmeny szamit, meg hogy mennyit hoz a konyhara. A hajukat hullato maintenance programmerek csereszabatosak

   
Parallax - Tag | 603 hsz       Online status #162351   2011.09.02 19:07 GMT+1 óra  
Kalóz mester: A struct-nak nincsenek tagfüggvényei. A struct csak adatokat tárol és globális fgv-ek végeznek az egyes struct-okon adat manimpulációkat. Ez így most ilyen felemás valami. OOP is, meg nem is. Ehhez nem kell iskola ez egy paradigma, amihez a nyelv ki van alakítva. Lehet szembe úszni is az árral, de ahogy írták nem kifizetődő egy esetleges újrahasznosítható, neadj isten javítható kóddal szemben. És ez csak az alap, programtervezési mintákat is átláthatóbb OOP-vel megoldani. Az egész értelme, hogy te mind ember nem gépi utasításokat nézel, hanem egy beszédes kódot, amiről ránézésre átlátod, hogy mit takar a jelentése, amiből egy halom másik kódot is egyből megértesz nem csak azt a 10 sort.

   
zeller - Törzstag | 486 hsz       Online status #162348   2011.09.02 18:51 GMT+1 óra  
En mindossze annyit mondtam meg a kezdetek kezdeten, hogy az if elkerulheto, ha indokolt, pl polimorfizmussal...
Ez sokszor melegen ajanlott. pl. 12 elagazasos ifek eseten, amit jelenleg sajnos sokat latok...

Es jo struktura mellett a kod sokkal rovidebb es olvashatobb, konnyebben kiterjeszthetobb lesz. strukturfuggony nelkul ddbwo kodja minden uj entityvel +2sor lesz, az entitin felul.

Masik oldalrol, ha nem indokolt, akkor ne csinaljuk.

   
gopher - Törzstag | 496 hsz       Online status #162344   2011.09.02 17:29 GMT+1 óra  
Meg még ezer dolog. Hosszú futamidejű és nagy projekt esetén ezek az apróságok nagyon-nagyon sokat számítanak.
   
ddbwo - Tag | 1654 hsz       Online status #162343   2011.09.02 17:28 GMT+1 óra  
Na amikor a struktúrák listája struktúrákba jönnek, az a struktúrfüggöny, úgy már nem kéne.
De típusonként ennyi amit kézileg kéne beállítani pluszba anélkül 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
   
gopher - Törzstag | 496 hsz       Online status #162342   2011.09.02 17:25 GMT+1 óra  
Na ez az. Ha ezt OOP-vel csinálod, ehhez a részhez már nem kell hozzányúlnod.
   
ddbwo - Tag | 1654 hsz       Online status #162341   2011.09.02 17:25 GMT+1 óra  
xD Ugyanoda sorba jöhetnek. De nekik más csekker és más doitbaby kell, mert repülnek, ezért máshogy reagálnak a környezetre. xD

fly_enemy

for (int num = 0;num < max_num;num++)
{
zombie[ num ].csekker();
zombie[ num ].DoItBaby();
bat[ num ].csekker();
bat[ num ].DoItBaby();
}
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
   
gopher - Törzstag | 496 hsz       Online status #162340   2011.09.02 17:21 GMT+1 óra  
Hol vannak a denevérek? (Entity_Bat)
   
ddbwo - Tag | 1654 hsz       Online status #162339   2011.09.02 17:15 GMT+1 óra  
gányul hirtelen elnagyoltan:

struct enemy
{
float pos[3]
(stb, stb)

void csekker() { ... }
void DoItBaby() { ... }
}

enemy zombie[512];
max_num = 512;

for (int num = 0;num < max_num;num++)
{
zombie[ num ].csekker();
zombie[ num ].DoItBaby();
}
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
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] > 8 < [9] [10] [15] [16]