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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2198
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Orphy - Törzstag | 1893 hsz       Online status #55149   2007.05.17 10:42 GMT+1 óra  
Idézet
ShAdeVampirE :
Az elsőt, és ez az amit engine-nek hívok, de nem általános, mindenre jó engine-nek Az általános nézettel nekem tényleg az a bajom, h egy csomó olyan dolgot oldanánk meg benne amit lehet h sosem kéne (persze ez csak akkor igaz, ha kódolunk is, ha csak UML akkor ez annyira nem jelentős), tegyük fel Portals-t, és soha az életben nem használsz portals-t mert találsz helyette jobbat. Az ilyen dolgok, h mi kell és mi nem pont egy játék megtervezésekor derül ki.



Pont erre hoztam az FPS-RTS, engine bővítős témát
Az FPS-ben volt mondjuk BSP, az RTS-hez meg mondjuk QuadTree kellett, akkor fogták magukat, és kibővítették az engine-t a QuadTree-vel.

Ekkor a példabeli engine-ben még mindig csak BSP és QuadTree van, a többi technikát nem kódolták le, mert nem volt rá szükség
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #55141   2007.05.17 09:21 GMT+1 óra  
"- Szvsz használhatóbb, ha a technikákról úgy írunk, hogy pl ezt RTS-ben érdemes használni, lehet FPS-ben, és TPS-ben is, de ott már van hatékonyabb: ez és ez. RTS-ben viszont ez a legoptimálisabb / legegyszerűbb / leggyorsabb technika."

Ez pontosan az, amiről én beszéltem, bizonyos típusú szempontból nézni a technikákat

"- Az aktuális játék megközelítés itt azért nem jó, mert ahány projekt, annyi követelmény, és annyi "aktuális" játék. Amit itt leírunk, hogy egy példajátékban az lesz a totálüberszuper megoldás, egy másik játéknál nem feltétlenül igaz. Vagy: itt bemutatjuk a dolgokat pl a Pong-on. Szuper, mindenki érti, mindenki örül, mindenki keresztbe-kasul vág mindent. Aztán amikor akar írni egy MMORPG-t, akkor..."

Ok, de ezt tudtuk is előre, csak az én koncepcióm az volt, h játékokat vesézünk ki bizonyos időnként, és ha 1el végzünk, akkor lehetőleg teljesen más stílusú játék következzen, így nem mindenre kell egyszerre koncentrálni (mint egy engine-nél ami mindenre jó), hanem 1-1 részre, de mindíg más részre, más szempontból.

"Ok, hogy játékot fejlesztünk, de...
Ha megkérdezem, hogy befektetsz +10% munkát, egy bővíthető alapért, amire ráhúzhatod a játékodat,
Vagy inkább minden játékot kezdesz 0-ról, melyiket választod?"

Az elsőt, és ez az amit engine-nek hívok, de nem általános, mindenre jó engine-nek Az általános nézettel nekem tényleg az a bajom, h egy csomó olyan dolgot oldanánk meg benne amit lehet h sosem kéne (persze ez csak akkor igaz, ha kódolunk is, ha csak UML akkor ez annyira nem jelentős), tegyük fel Portals-t, és soha az életben nem használsz portals-t mert találsz helyette jobbat. Az ilyen dolgok, h mi kell és mi nem pont egy játék megtervezésekor derül ki.

Egy kompromisszumos megoldás, ami most eszembe jutott hírtelen: elkezdjük mind2-t, és mikor egy játék specifikus esetnél vmi jó 5let felvetődik megnézzük hogy lehetne összeegyeztetni a független engine-nel De ez a téma itt még nem áll le
   
Orphy - Törzstag | 1893 hsz       Online status #55138   2007.05.17 09:07 GMT+1 óra  
A nagyok közül a legtöbben inkább úgy működnek, hogy ha kitalálják, hogy írnak mondjuk egy FPS-t...

Akkor készítenek / szereznek hozzá egy engine-t...!
A meglevő engine-nel (esetleg annak továbbfejlesztett változatával) elkészítik a játékot, és...
A további ilyen technikákat használó játékukhoz megvan mindenük!

Aztán ha kitalálják, hogy akarnak egy RTS-t, akkor...
Vagy írnak / szereznek ahhoz is egy új engine-t, vagy kibővítik a régi FPS-est azokkal a dolgokkal, amik egy RTS-hez kellenek.

Továbbra is azt mondom, próbáljunk ne egy X játék szempontjából bemutatom a dolgokat típusú tudásbázist létrehozni...
Miért? Több okból is.


- Szvsz használhatóbb, ha a technikákról úgy írunk, hogy pl ezt RTS-ben érdemes használni, lehet FPS-ben, és TPS-ben is, de ott már van hatékonyabb: ez és ez. RTS-ben viszont ez a legoptimálisabb / legegyszerűbb / leggyorsabb technika.

- Az aktuális játék megközelítés itt azért nem jó, mert ahány projekt, annyi követelmény, és annyi "aktuális" játék. Amit itt leírunk, hogy egy példajátékban az lesz a totálüberszuper megoldás, egy másik játéknál nem feltétlenül igaz. Vagy: itt bemutatjuk a dolgokat pl a Pong-on. Szuper, mindenki érti, mindenki örül, mindenki keresztbe-kasul vág mindent. Aztán amikor akar írni egy MMORPG-t, akkor...

- Nekem az a tapasztalatom, hogy programozásból 3 féle feladat van:
a.) Projekt specifikus, nem általánosítható
b.) Rutinfeladat, naponta kb 50x írod meg majdnem ugyanazt az osztályt
c.) Visszatérő probléma: egy korábbi projektben már meg lett oldva...

a-val igazából sokat nem lehet kezdeni...
b-vel ha ügyes vagy, lehet
c-vel meg pláne: ezek a tipikusan olyan dolgok, amiket szépen össze lehet gyűjteni egy osztálykönyvtárba, később jelentős fejlesztési időt megspórolva ezzel...

Persze ezt sokan nem veszik észre, vagy idő hiányában a "gyorsabb" megoldás mellett döntenek - ilyenkor van az, hogy az ember összes projektjét a 0-ról kezdni, vagy a régiekből copy-paste-tel... Végeredmény: lassan fejlődő, trágya kód (sajnos tapasztalat).

Ok, hogy játékot fejlesztünk, de...
Ha megkérdezem, hogy befektetsz +10% munkát, egy bővíthető alapért, amire ráhúzhatod a játékodat,
Vagy inkább minden játékot kezdesz 0-ról, melyiket választod?

Nyilván az elsőt
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #55129   2007.05.17 08:28 GMT+1 óra  
"Viszont sokan pl azt sem tudják, melyiket, az meg, hogy akkor kellene írni egy BSP-t, nah, ott jönnek a gondok, merthát nem 1xü már maga a működési elve sem..."

Pont erről szólna az advanced téma Tutort a legtöbb esetben lehet találni, itt én főleg az egyes technikák kivesézésére fektetném a hangsúlyt (melyik mikor jó, mikor érdemes használni, hogy lehet optimalizálni...) Próbálok optimista lenni, de mellette azért realista is, és főleg ezért nem támogatom egy engine összedobását. Másrészről pedig azért, mert szvsz felesleges, aki kész engine-t akar használni annak OGRE, aki meg magának akar írni egy játékhoz, az úgyis speciális dolgokat fog használni, és a témára jellemző dolgokat optimalizálni.

Én mindenképp erre a második megközelítésre helyezném a hangsúlyt, mert még1x, ez játékfejlesztés, ahol nem általános megoldásokban kell gondolkodni (szvsz), hanem azon, h az aktuális játék hogy lesz a legjobb / leggyorsabb / legstabilabb, esetleg ha távlatokban is gondolkodunk, akkor a köv. hasonló stílusú játékhoz is legyen vmi alap, de sztem elég kevesen írnak úgy engine-t, hogy az minden játékukhoz jó legyen. Vagy ha mégis, akkor sosem készítenek hozzá játékot
   
Orphy - Törzstag | 1893 hsz       Online status #55090   2007.05.17 02:56 GMT+1 óra  
Idézet
ferchild :
SceneGraph-ban valamiért biztos vagyok, hogy lehet általánosítani, és az viszont tuti hasznos lenne...

lehet, de nem feltétlenül éri meg....nem feltétlen ua a szerkezete egy FPSnek és egy RTSnek színtérgráfban sem....sajnos
bár lehet párhuzamot vonni és majdnemhogy általánosítani
de az nem a színtérgráf lesz hanem annak egy részhalamza....és aara jön a gémspecifikus cucc

de igen....vannak részek amik függetlenek a gémtől...vfs, input (én ide sorolom), kamera osztály (amivel sokaknak baja van), stb...
most mennem kell még leszek oszt beszélünk róla



A SceneGraphoknál nem is arra gondoltam, hogy megírjuk A szintérgráfot, hanem arra, hogy pl egy QuadTree-t, Octree-t, BSP-t, Portalt, Roaming-ot, alap Java3D-t, stb

Ilyen szinten viszont lehet általánosítani!

Tudom, hogy más játékstílushoz más és mást éri meg ezekből használni...
Viszont sokan pl azt sem tudják, melyiket, az meg, hogy akkor kellene írni egy BSP-t, nah, ott jönnek a gondok, merthát nem 1xü már maga a működési elve sem...
   
syam - Törzstag | 1491 hsz       Online status #55079   2007.05.17 02:17 GMT+1 óra  
na ja frameworknak pl ott a humus
írjunk pszeudokodbant enginet?
vagy szedjük össze azon "elemeket", amikből ki lehet hozni 1 játékot?
alias aalberik
   
ferchild - Törzstag | 815 hsz       Online status #55078   2007.05.17 02:11 GMT+1 óra  
már én sem tudom követni

bár szerintem ne! framework legyen....az egy kicsit nagy falat tanulni mármint ha a tanulás / tanítás a cél
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
syam - Törzstag | 1491 hsz       Online status #55076   2007.05.17 01:58 GMT+1 óra  
hmm,
most akkor cikk sorozat, framework v engine készülne?
alias aalberik
   
sirmok - Tag | 101 hsz       Online status #55073   2007.05.17 00:54 GMT+1 óra  
ahoj!

szivesen és komolyan megépiteném a készülő enginetekhez a modelleket.
csak a paramétereket kérem, hogy mikor milyen tesztelési fázisnak felejen meg a tri count, texture px.....etc etc.....már a komolyabb, időrabló objectekre gondolok, amikor már kimerül a low poly fogalma, ami alatt én személy szerint a homo homo sapiens 6000 tri-t értem....

egyébként:hajrá! minden sikert!

   
Kuz - Törzstag | 4455 hsz       Online status #55072   2007.05.17 00:45 GMT+1 óra  
Ha már Orphy úgyis felvetette az engine készítést, érdekelne a véleményetek, hogy mi lenne, ha egyből egy "Game Maker"-szerű frameworköt dobnánk össze, így maga a játék elkészítése - itt a játék alatt azt értem, hogy csak meg kell adni, hogy mit, mikor, hova töltsön be, milyen effectet használjon, etc - csak már meglévő utasítások hívásából állna (na jó nem teljesen, de kb erre gondolok : "setHDR(true);" )? Persze nyílván nem ma kezdenénk el, mert ehhez pont azokat a dolgokat kéne végigbeszélni, amikről eddig szó volt, de sztem ez később jó gyakorlás lehet. Vagy ez nagyon elvetemült ötlet és inkább fogjam be ?
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
ferchild - Törzstag | 815 hsz       Online status #55065   2007.05.16 23:11 GMT+1 óra  
SceneGraph-ban valamiért biztos vagyok, hogy lehet általánosítani, és az viszont tuti hasznos lenne...

lehet, de nem feltétlenül éri meg....nem feltétlen ua a szerkezete egy FPSnek és egy RTSnek színtérgráfban sem....sajnos
bár lehet párhuzamot vonni és majdnemhogy általánosítani
de az nem a színtérgráf lesz hanem annak egy részhalamza....és aara jön a gémspecifikus cucc

de igen....vannak részek amik függetlenek a gémtől...vfs, input (én ide sorolom), kamera osztály (amivel sokaknak baja van), stb...
most mennem kell még leszek oszt beszélünk róla
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #55062   2007.05.16 21:46 GMT+1 óra  
Persze, sok dolog van amit lehetne függetleníteni, de azért olyan is akad, amit ennél összetettebb...
"Ugyanígy a mozgatás, forgatás, nyújtás is, mert nem nyúl a grafikus eszközhöz, csak a mátrixot módosítja..."
A méret változtatása mindenképp CPU oldali, viszont az eltolás már nem: ezt OGL is GPU oldalon végzi, így nem mindent olyan egyszerű csoportosítani, ha optimális sebességre is törekszünk. Ha csak az API függetlenség a cél, akkor könnyebb a helyzet

kuzanth: én sem 1 hétre gondoltam, sőt, ahogy azt már írtam lejjebb nem is konkrét fix időre gondoltam, csak egy körülbelülire, ami el is húzódhat ha még vannak aktív, értelmes hozzászólások.
   
Orphy - Törzstag | 1893 hsz       Online status #55060   2007.05.16 15:56 GMT+1 óra  
Shade: A mit függetlenítenék kérdésre:

- Azokat a dolgokat, amiket egyes api-k nem tudnak (pl Vector, Matrix, BoundingBox, BoundingSphere...)
- SceneGraph-ok...
- Továbbá minden olyan dolog, amit egy saját wrapper osztályban használsz, és nem közvetlenül a render-hez tartozik, hanem inkább a wrapper osztály xy funkciójának logikájához: pl Sprite automatikus animálása 30 fps sebességgel -> aktuálisan megjelenítendő textúrarész meghatározása függetleníthető. Ugyanígy a mozgatás, forgatás, nyújtás is, mert nem nyúl a grafikus eszközhöz, csak a mátrixot módosítja... Ami api specifikus, az az init, a render, meg az api események, pl deviceLost, ahol van.

Igazából lehet, hogy egyszerűbb úgy feltenni a kérdést, hogy mit nem függetlenítenék...
Minden olyan kódot, ami a graf, input, hang stb hardverhez nyúlkál...

Sprite-nál maradva: lenne egy alaposztály az összes háttérfuncionalitással, és a származtatott osztálynak annyi lenne a feladata összesen, hogy a választott api segítségével kirajzolja az alaposztály által megadott téglalapot a megadott transzformációkkal... -> DX-OGL esetében a Math osztály után kb ez annyi különbséget jelent, hogy a Render()-t különy osztályba írod meg. XNA-val már némileg változott a helyzet.

Továbbra is ötlet, jöhet pro-kontra.
SceneGraph-ban valamiért biztos vagyok, hogy lehet általánosítani, és az viszont tuti hasznos lenne...
   
Kuz - Törzstag | 4455 hsz       Online status #55057   2007.05.16 15:24 GMT+1 óra  
Én erre a mit csináljunk, mit ne csináljunk dologra azt mondanám, hogy ha valaki meg AKAR csinálni valamit, az csinálja, és ne vegye el a kedvét mások véleménye. Segítség és ellentábor mindig is lesz...

Közös Engine? Benne vagyok, már ha hasznomat tudjátok venni...De itt szükséges a tervezés (vki asszem említette már). Anélkül halott dolog (sztem).

Vesézzünk ki egy egyszerűbb játékot? Jó ötlet, csak ehhez ismerni is kéne azt Akkor már inkább vesézzük ki valamelyikőnk játékát (pl Shade-é már eléggé előrehaladott állapotban van, szóval jó lenne erre a célra).

Lektorok? Hát ennek szívből örülnék, de nem tudom itt konkrétan kire gondoltatok? Itt az oldalon van valaki, aki akkora géniusz, h ezt fel tudja vállalni? Ha igen, feltételezem úgyis a csapat tagja lesz, egyébként meg tartom annyira okosnak a társaságot ahhoz, hogy ezt meg tudjuk/tudjátok oldani magunk/magatok is!

Minden héten új téma? Kizárt, h a dolgok többségét 1 hét alatt kivesézzük. A legtöbben közülünk dolgoznak is, így nem érnek rá a nap 24 órájában!

Egyelőre ennyi, majd írok még, ha érdekel vkit a véleményem...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #55053   2007.05.16 14:42 GMT+1 óra  


Megy ez a topic is rendesen, de a jfhu most úgy általánosságban is. Gondolom itt a nyár meg minden Tehát most megint visszaolvastam (volt mit).

Első kérdésem akkor az API függetlenséggel: mi az amit függetlenítenél? Rengeteg olyan dolog van, amit meg lehet csinálni függetlenre, de ahogy azt már írtam, mondjuk egy RTS-nél semmi értelme / teljesen máshogy Optimális megoldani, vagy csak az idők folyamán elavul és mondjuk api függetlenre megírni 2x annyi idő (v több) mint speciálisan. Nekem nem tetszik az API független ötlet, én inkább ferchild "fogjunk egy játékot és azt vesézzük ki / tervezzük meg" féle szemléletét osztom, de persze hibázhatok, gondolhatom rosszul; jó lenne ha mások is kifejtenék a véleményüket

Eleinte sztem nem sok értelme lenne engine tervezésnek, mert ha jól gondolom ez az aloldal nem 1 nap alatt forrna ki / alakulna ki; a témáknak, a közönségnek is érniük kell és meg kell szoknunk, valamint bővülhet is az olvasók köre (akár szakmai részről is, ki tudja )

Az h matek osztályt írj... Erről már sokszor volt vita, elég off lenne ( és lett is már párszor) h akkor most hol is legyen a határ, mert ugye akár gépszintig vissza mehetünk v OS szintig, szoftveres renderer-t is írtak már jópáran, de sztem itt nem ez lenne a cél. A játékfejlesztésnél fokozottan érvényes az, h határidők vannak és gyorsan kell dolgozni. De az én véleményem csak 1 vélemény a sokból, szívesen hallgatnám a többieket is ebben a témában (is)
   
Orphy - Törzstag | 1893 hsz       Online status #55041   2007.05.16 12:32 GMT+1 óra  
Én ismerek pár embert itt, a Portálon, akik engine-je elég kiforrott állapotban van ahhoz, hogy észrevegyék az óóóóóóóóriási bakikat
   
ferchild - Törzstag | 815 hsz       Online status #55033   2007.05.16 11:53 GMT+1 óra  
egy kétely van csak egyébként bennem:
kellene egy lektor......vagy több
akik igenis a gémdevben vannak és ha valami óóóóóóóóriási bakit lövünk akkor szól....de egyébbként is jó volna ha lenne
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55032   2007.05.16 11:51 GMT+1 óra  
Mindenesetre továbbra is tartom, hogy szerintem jó ötlet lenne egy engine-tervezés.

Azért, mert
- egy engine tényleg szép, és komoly feladat.
- Nem csak feldobott témák lennének, amiről sokan azt sem tudnák, mi az, hanem az engine X részéhez kapcsolódóan lehetne tárgyalni a dolgokat. Kb akkora lenne a különbség, mint amikor tanítják a suliban a mátrixokat, és tanulod, mert muszáj - vagy amikor érdeklődéssel keresed, kutatod, mert szükséged van rá az új 3d játékodhoz. Utóbbi esetben azért jóval érdekesebb a dolog...
- Szerintem nem én vagyok itt az egyedüli, akinek van sejtése arról, hogyan is kell megalkotni egy engine-t, de kellő tapasztalat híján nélkülözi az öreg rókák apróbb trükkjeit, nem ismeri ilyen téren a bevett szokásokat, a mit hogyan érdemes kérdéseket... Azt hiszem, ilyen szempontból is hasznos lenne. Pl Kuzanth kérdései: térpartícionálás, mit érdemes szálasítani, és mit nem... Ezek is mind ide vágnak!

- Akik pedig éppen újként betévednek, és szeretik rendszerben látni a dolgokat - azoknak ez jól összeszedve maga lenne a paradicsom...
   
ferchild - Törzstag | 815 hsz       Online status #55031   2007.05.16 11:46 GMT+1 óra  
lehet........este van
meg mostanság vannak kognitív diszfunkcióim..... ez is egy közüllük
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55029   2007.05.16 11:44 GMT+1 óra  
Idézet
ferchild :
nyilatkozathábú rulez!



Ki beszél itt hábúról?

Te azt vetetted írtad, szerinted itt több értelme van a tervezésnek, mint kód írásának.
Én azt írtam, tervezhetnénk egy engine-t.

Aztán hozzábiggyesztettem, hogy mostanában az jár a fejemben, milyen király lenne, egy olyan engine-t írni, amiben amit csak lehet (és még értelmes) 3d api-tól függetlenné, és hordozhatóvá teszünk.

Aztán utána elvesztünk a részletekben: 3d api, implementálás...
   
ferchild - Törzstag | 815 hsz       Online status #55027   2007.05.16 11:35 GMT+1 óra  
Idézet
ferchild :
én nem mondtam azt, hogy ne legyen kód, csak szerintem az mellékes.....legalábbis nekem, de ha a többségnek kell én nem zárkózom el előle....
csak egy doksiból szerintem többet lehetne tanulni, mint a kódból....de ez személyes vélemény.
lehet nem így van......

szerintem egyébbként, hogy építő jelleggel is hozzászóljak:
nem forráskódokat kellene feltölteni, meg írni. Elmondom miért:
1) aki érdemben hozzá tud szólni, annak ez már nem nagy kunszt, mert lekódolni nem nagy kunszt semmit, ha már tudod mit akarsz.
2) akinek meg az, az nem szóljon hozzá, mert még nem tart ott
Éppen ebből kifolyólag nem értek egyet pl azzal, hogy feltöltöd a Pong forrását. Persze lehet azt is, de nem fontos. Sokkalta fontosabb lenne egy projektdokumentáció, ahol UML diagramokkla a szerkezetét, felépítését mutatod be. Mit hova, hogy terveztél, öröklési hierarchiuák, vezérlés, az egész tervezése. Szoftvertervezés! nem kódolás, mert ha megvan egy ilyen vázad, akkor tul. képpen az előbb említett (1) pont lép életbe. És akkor már a nyelv sem számít. Mert majd megoldja C++-ban,, vagy Perl-ben....az már legyen az ő baja. Forráskódra itt a JF C#,C++,Delphi,.... topikjai.

Éppen,, hogy az egésznek elméletekről, tervezésről kellene szólnia. És algoritmusok még max pszeudo-kóddal. Szvsz.



nyilatkozathábú rulez!
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55026   2007.05.16 11:32 GMT+1 óra  
Én platform és 3d api független engine-tervezést vetettem fel, implementációt csak eshetőségként említettem

hsz:
http://ilab.hu/jf/forums.php?m=posts&p=54979#54979
   
ferchild - Törzstag | 815 hsz       Online status #55025   2007.05.16 11:23 GMT+1 óra  
én sem xna-ra gondoltam anno...olvass vissza én leginkább csak szoftvertervezést gondoltam
UML-lel, meg doksival...az implementáció meg mindenki magánügye
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55024   2007.05.16 11:12 GMT+1 óra  
Shade 3d api-s megjegyzésére reagáltam:

"Az pedig még egy plusz dolog, h olyan engine-t írni ami független minden 3D API-tól nagyon nehéz és ráadásul általában nem is éri meg, mert az API-k közti különbséget nem használja ki (pl. ami DX-ben alapból van (akár Mesh loader, akár Math osztályok)) azt OGL-ben nem használhatjuk; meg kell írni még ha nem is lenne szükséges, mert OGL alatt nincs."

Az okfejtésemhez még annyit tennék hozzá, hogy ha a minimál api-hoz az ember mindent kidolgoz, akkor az engine vázát elvileg tudja bármihez használni, csak az adott api-nak megfelelően meg kell írni a dolgokhoz a rendert...

Vannak általánosítható dolgok, mint sceneGraph, vagy a részecskerendszerben a rendszert működtető folyamatok, animációs frame számolása, stb-stb-stb... Ezek mind nem függnek a 3d api-tól!

Shade-nek igaza van abban, hogy ez azzal jár, hogy pl ha vesszük az OGL-t, (amihez nincsen matek könyvtár), hogy néhány dolgot implementálni kell, amit egy másik api esetében nem.

Ezzel szemben én azon gondolkoztam el, hogy ez az esetleges többletmunka (amiben nem vagyok biztos hogy annyira jelentős) azt jelentené, hogy az engine több api-t is támogathatna, fájdalommentesen...

És ha pl az MS bejelenti, hogy mostantól nem támogatja az XNA-t, hanem helyette valami új cucc lesz, és az XNA-sok kapják be (mint anno az MDX-el tette), akkor sem kell kukázni az engine-t...

Csak 1 kósza ötlet, ami már napok óta motoszkál a fejemben...

Vélemény?
   
ferchild - Törzstag | 815 hsz       Online status #55020   2007.05.16 10:52 GMT+1 óra  
ezért nem értettem az okfejtésed, de biztos én értettem félre
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55018   2007.05.16 10:49 GMT+1 óra  
Igaz,

viszont ez a topic alapból egy "advanced" szerveződésről szól, ott pedig ritka eset hogy valakit nem érdekel, mit vágott be a kódjába
   
ferchild - Törzstag | 815 hsz       Online status #55016   2007.05.16 10:42 GMT+1 óra  
én csak a saját példámat tudom megemlíteni:
dx-eztem/ezek és ott igaz "minden" megvolt, de mégis meg kellett tanulni, mert már a legegyszerűbb problémát sem tudod megoldani annélkül, hogy ne értenéd mi van mögötte...pont a minap jött elő egy ilyen probléma az egyik GP kapcsán. Segítenem kellett és tudtam is szerencsére
úgyhogy nem jobb a OGL mert nincs semmi és nem jobb a DX sem mert ott van

Szerintem ez beállítottság kérdése. Ha valakit érdekel utánanéz, akit meg nem annak lehet implementálva egy mátrix művelet, lehet magának kell levadásznia a netről és kopipészt, de akkor sem érdekli.
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
Orphy - Törzstag | 1893 hsz       Online status #55006   2007.05.16 09:12 GMT+1 óra  
Idézet
ShAdeVampirE :
Ja és Orphy-nak még azt: mi alapból nyelvfüggetlenül akartuk csinálni; csak UML diagrammok, esetleg DOK Doxygen-nel, semmi nyelvspecifikus dolog Az pedig még egy plusz dolog, h olyan engine-t írni ami független minden 3D API-tól nagyon nehéz és ráadásul általában nem is éri meg, mert az API-k közti különbséget nem használja ki (pl. ami DX-ben alapból van (akár Mesh loader, akár Math osztályok)) azt OGL-ben nem használhatjuk; meg kell írni még ha nem is lenne szükséges, mert OGL alatt nincs.



Jaja, ez igaz
Viszont ez egyben jó és rossz hír is...

Ugyanis azzal, hogy OGL alatt pl az ember nem kapja kézhez a mátrixot, a vektort, stb rá van kényszerítve arra, hogy utánanézzen, és legalább lesz 1 kis fogalma arról, amivel dolgozik. Lesz fogalma arról, hogy az egész hogyan áll össze, és ha valami nem úgy működik, ahogyan kellene, akkor tudja, hova nyúljon...
A Math könyvtár szvsz talán azért nem a legjobb példa, mert pl DX-ben, és XNA-ban kapsz Vector-okat, Matrix-okat, de elég alap szinten: elég arra, hogy megoldd vele a transzformációkat, ok...
De mi a helyzet pl ia görbékkel (Egyenes, szakasz, kör, Bezier, NUBS, NURBS) Az már ott sincs...
Vagy 2 Vector által közbezárt szög?

A modell betöltőhöz annyit tennék hozzá, hogy az MS általában a saját, .x kiterjesztésű file-jához mellékel valamit, amihez még mdx alatt is kellett wrappert írni, ha az ember használni akarta...
Az X file nem rossz. Kezdésnek. Aztán valahogy mindig mindenki valami mást akar használni, pl MD3, MD5, vagy saját... Ahhoz meg így is-úgy is meg kell írni a betöltőt.

Egyébként eddig úgy vettem észre, hogy azért ilyen hiányzó osztályból nincsen annyira sok, hogy meg kelljen rettenni tőle További jó hír, hogy mivel ugye OpenGL-hez ezekből elég sokat lehet találni neten, amit csak be kell illeszteni...

Megaztán...
Ha túlságosan leegyszerűsítjük a dolgokat, az sem jó...
Nem azt mondom, hogy 0 és 1 formájában kell programozni, de ha egy fejlesztőeszköz elrejti előled pl a modell-betöltést, akkor nem fogod tudni, hogyan működik. Ha elrejti az alapokat, akkor lehet, hogy összedobsz egy játékot - de használható tudás nélkül.

Ahhoz, hogy ez az egész érjen valamit, gondolnunk kell azokra a rendszerekre, amikhez nem jár alapból annyi kényelmi szolgáltatás, mint a DX-hez.

Szvsz.
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54990   2007.05.16 08:11 GMT+1 óra  
Ja és Orphy-nak még azt: mi alapból nyelvfüggetlenül akartuk csinálni; csak UML diagrammok, esetleg DOK Doxygen-nel, semmi nyelvspecifikus dolog Az pedig még egy plusz dolog, h olyan engine-t írni ami független minden 3D API-tól nagyon nehéz és ráadásul általában nem is éri meg, mert az API-k közti különbséget nem használja ki (pl. ami DX-ben alapból van (akár Mesh loader, akár Math osztályok)) azt OGL-ben nem használhatjuk; meg kell írni még ha nem is lenne szükséges, mert OGL alatt nincs.
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54989   2007.05.16 08:02 GMT+1 óra  
Azthiszem ilyen engine tervezéshez hasonló 5let eddig is volt már, csak ott konkrét játékokra gondoltunk; de ez azt is jelenti egyben, h a játék stílusának megfelelő engine-t tolunk alá. 1 db. engine fejlesztése... nem azt mondom, h hülyeség, de nem célszerű / optimális. Nagyon sok stílus és játék specifikus dolog van (pl. már a tér particionálás is), amiből persze lehet implementálni mindet, de nem hiszem, h erre innen bárkinek lenne kedve / ideje (pl. megírni bsp, octree, portals, clipmaps technikákat, valamint octree-re is több megoldás van, pl. meg lehet oldani occlusion quieries alapúra, és az elég sok dologban különbözik egy CPU oldali technikától).

Így én inkább maradnék annál, hogy mindíg egy-egy témát / játékot veszünk elő, és annak felépítését vesézzük ki; ez azért sokkal aktívabb közösséget is eredményezhet: ha éveken keresztül beszélünk 1 engine-ről, akkor kevésbé érdekes egy idő után, mintha új, friss témákat veszünk el, és persze azért elég sokan vannak itt a JFHU-n, akik eddig még csak 1 stílusban gondolkoztak (teszem azt syam engine-je (uhh, nevét most elfelejtettem, réginek Petra volt azthiszem a neve ) kifejezetten FPS-ekhez idomul, tehát ő pl. ilyen nézőpontból tudna Legtöbbet segíteni).

Modell formátumokra eddig még nem gondoltam, de ha lenne elég ember hozzá, az is jöhetne Ja és én is naggyal értek egyet abban, h cikkeket fordítani nem éri meg: az ilyen cikkeknek tipikusan hasonló a nyelvezetük, kis gyakorlással még minimális angol mellett is megérthetőek (max 200-300 szó), a speciális neveket, pl. technikák nevét meg egyébként sem érdemes magyarra fordítani, mert magyarul is octree-nek hívjuk meg bsp-nek, meg vfs-nek
   
nagyy - Törzstag | 248 hsz       Online status #54984   2007.05.16 07:37 GMT+1 óra  
Ez a cikk fordítósdi régebben nekem is eszembe jutott, de végül elvetettem magamban az ötletet. Szerintem aki programozással szeretne foglalkozni, annak legalább olyan szinten kellene tudnia angolul, hogy ilyen doksikat meg tudjon érteni. Persze ha van rá igény, az is hasznos lehet, de szerintem inkább valami újat kellene alkotni.
Egyébként az engine tervezéses javaslatot én is ötletetnek tartom.
   
Cow - Tag | 52 hsz       Online status #54983   2007.05.16 07:03 GMT+1 óra  
Nos ez egy igen jó felvetés. Ha esetleg ez nem valósulna meg (ne adja az Isten), lenne egy helyettesítő ötletem.
Mi lenne, ha közös erővel elkezdenénk a Gamasutra programozóknak szóló cikkeit lefordítani magyar nyelvre? '97-től.
Eredetit, újat és ötleteset - bárhol és bármikor... avagy nem vetem meg az ágyat, mert megvetem.
http://cow.isgreat.org
   
Orphy - Törzstag | 1893 hsz       Online status #54979   2007.05.16 06:54 GMT+1 óra  
Hello,

ebben a buliban én is benne lennék, úgy gondolom, a közösség is nagy hasznát vehetné...
A lent említett dolgok mellett engem (és remélem, nem csak engem) nagyon érdekelne az engine-tervezés (úgy gondolom, a játékfejlesztésnek ez egy elég komplex és érdekes része ahhoz, hogy megérje vele foglalkozni: ráadásul több buktató is van benne, komoly optimalizálást, stb igényel...)

- El lehetne kezdeni az alapoktól (mi a játékengine, miért jó, stb...)
- Milyen főbb részekből áll

Ezek után lehetne szó arról, az egyes részek hogyan kapcsolódnak egymáshoz, és hogyan alkotnak mégis egy egységes egészet...
Be lehetne mutatni, mit érdemes az egyes rendszerekbe implementálni(pl Math részleg: Vector, Matrix, Görbék...)

Mindezek után lehetne csinálni közösen egy minimális motort, és egy minimál játékot rá, amin aztán mindenki tudná a gyakorlatban is tanulmányozni a leírtakat.

Aztán tovább lehetne lépni az advanced témákra:
- modell formátumok
- térparticionálás (indoor, outdoor algoritmusok)
- shader támogatás
- ray tracing
- többszálú működés
- stb...

Mindezt lehetne akár platform és grafikus api függetlenül is nézni: pl általános particleSystem-et írni, aminek üres lenne a Render() függvénye. - > Attól függene, hogy dx, ogl, sdl stb, hogy a programmer az alapból örököltetett osztályban melyik api-val valósítja meg a kirajzolást...
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54715   2007.05.14 08:22 GMT+1 óra  
Akkor lassan összefoglalhatnánk, hogy mit is kéne csinálni, hogy kezdjük el, utána átbeszélhetnénk még1x és bele is vághatnánk. Tehát ha valakinek még van ötlete, az jelezze!
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54629   2007.05.13 22:05 GMT+1 óra  
Alakul, alakul 1ébként én 1x már elkezdtem saját magamnak egy olyan blog-ot, ahol azt írtam le, hogy mivel szívtam sokat, aztán persze azt is, hogy hogy oldottam meg. De a fejlesztési napló mindenképpen érdekes. Még pl. az lenne egy különleges dolog, ha a ferchild által megemlített játékot egyszerre többen is megpróbálnánk megtervezni, majd ezek után megnéznénk, hogy miben különböznek az elképzelések, ki mit hol hibázott / csinált jó dolgot.
   
syam - Törzstag | 1491 hsz       Online status #54617   2007.05.13 12:58 GMT+1 óra  
ráadásul gyorsabban elkészül egy napló, mint 1 cikk mivel nem stilizál az ember nem nagyon kell formázni és pl egy nap vagy egy fejlesztési szakasz végén lazán össze lehet egy ilyet hozni
alias aalberik
   
TPG - Tag | 3402 hsz       Online status #54615   2007.05.13 12:54 GMT+1 óra  
Idézet
syam :
....
szerintem:
-pl minden témához kellene 1-2 "szakember", aki legalább "tudja miről van szó" és akiktől kérdezni lehetne, de ne lehessen sokadszorra uazt a kérdést felvetni; ezt pl a "szakember" ki tudná szűrni a kérdésből és esetleg átirányítani a megfelelő témához; ennek hiányát lehet látni az egyik portál tudástárjában, ahol egymást érik a "majdnem uolyan kérdések"
-a cikkek általában sok időt fognak le esetleg egy többé-kevésbé "jól felépített "fejlesztési napló többet érhet mivel általában több témát is érint, mint egy cikk ill. személyes tapasztalatokat is bele lehet venni; a kérdés csak az, h milyen a jól felépített fejlesztési napló
-a forráskódokat lehetne doxygennel dokumentálni valamint portolni több nyelvre, mint a nehen
....


Ez a fejlesztési naplós dolog nem is rossz ötlet, az ember általában egy cikkbe csak a működőképes jó ötleteket írja le viszont egy ilyen naplóba bekerül a téma kutatása során előkerülő összes mellékvágány és szopás is így az olvasó nem csak azt tanulja meg hogy hogy kell azt az adott dolgot megvalósítani hanem azt is hogy hogy nem szabad nekiállni és miért.
Reality is almost always wrong. - House

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54602   2007.05.13 11:16 GMT+1 óra  
Ahh, értem a koncepciót Akkor ezt is felírtuk a listára
   
ferchild - Törzstag | 815 hsz       Online status #54600   2007.05.13 11:06 GMT+1 óra  
nincs, de szerintem mi jobbat hozunk össze...
mellesleg sokkal többet lehetne így tanulni, hogy csak látod mit szeretnél....de Neked kell megtervezned.
próba szerencse
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54579   2007.05.13 06:36 GMT+1 óra  
Scorched planet-et én is ismerem és szeretem is, felírhatjuk a listára (lassan azért még egész hosszú listánk lesz, h miről lehetne beszélni Kérdés, h ehhez van forráskód is meg dok-is?
   
ferchild - Törzstag | 815 hsz       Online status #54578   2007.05.13 05:51 GMT+1 óra  
az általános offtopikban vanm egy "GP ötletem" kivesézésre
Feci Barath (by Kuz)
XD
http://már nem elérhető...új lesz
   
syam - Törzstag | 1491 hsz       Online status #54575   2007.05.13 05:39 GMT+1 óra  
alakul alakul,

a kérdés, h milyen formában történjen mindez egy témán belül;
csináljunk egy roadmapot, h mi mikor kerülne sorra
vagy csak 1 kezdőtéma és ahogy alakul?
vagy a 2 kombinációja, mint1 szeminárium jelleggel

a GP tervezés az igy jó lenne szerintem, ha nincs konkrét gp, akkor általános tervezési feladatok lennének porondon
alias aalberik
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54572   2007.05.13 05:11 GMT+1 óra  
syam: 5 alcsoport
Szvsz akkor is minimális számú topciot kéne tartani, hogy egyszerre csak kevés témára kelljen odafigyelni -> jobban ki lehet dolgozni. Persze ilyenkor lehet az is, h 1. héten térpart. megjelenítésben, aztán mikor ezzel végeztünk a köv héten tér part. a fizikában. Másik megoldás, hogy együtt tárgyaljuk a témát, és akkor nem 1 hétig van "napirenden", hanem mondjuk 1 hónapig. Bár ez is olyan, h nem kell ragaszkodni ahhoz, h 1 hét v 1 hónap, amíg aktív a téma addig megtartjuk, utána archiváljuk.

GP tervezés:
Ezt lehetne úgy is, hogy ha van GP amit ki lehet vesézni, akkor az a téma, ha nincs, akkor egy általánosabb témát veszünk elő (akár azt, hogy milyen szempontokat kell figyelembe venni egy RTS elkészítésekor, mielőtt belevágnál, ahogy ezt már említetted).

naggy: ennek mindenképp az lenne a lényege, hogy azok szóljanak hozzá, akik hozzá tudnak tenni valamit. 1ébként az sztem nem gond, ha vki butaságot mond, csak a témába vágjon, mert így ki lehet javítani és a kezdőknek amolyan megjegyzésként ki lehet emelni, h ez téves/ rossz. A lényege a dolognak az lenne, hogy komolyabb, összetettebb témákról beszéljünk, aminek svzsz az 1ik kulcsa, hogy kevés téma legyen egyszerre nyitva. Erre jó ellenpélda a jfhu mostani állapota: rengeteg téma, nehéz kiszűrni ami tényleg fontos és minden kedveltebb témában naponta több, különböző kérdés/ észrevétel érkezik -> nem beszéljük át az egyes témákat komolyabban, valamint a témák szintjén is lehetne emelni.

Itt újra hangsúlyozom, h sztem ilyen is kell, tehát a jelenlegi JFHU-ra is szükség van, vicc topic-kal, off topic-kal, stb. csak e mellett kéne egy ilyen is. A kezdők úgysem fognak egyből az aloldalra lépni; ha a jfhu főoldalról lehet átlépni az aloldalra, akkor úgyis itt teszik fel a kérdéseiket. Ha meg mégsem, akkor moderálás, de sztem ebben a rendszerben ez jelentősen csökkentené a nem megfelelő hozzászólások számát.
   
syam - Törzstag | 1491 hsz       Online status #54568   2007.05.13 04:34 GMT+1 óra  
"- általánosan a játékokban használt technológiákról (ezt akár al csoportokra is lehet osztani, 3D grafikai rész, másik csoportba pedig a többi téma, pl. a sokat emlegetett térparticionálás)"

még ez is tul általános; mindenképp kell az a kb. 5 alcsoport hiszen a térparticionálás máshogy müködhet/müködik a grafikában, mint a fizikában és ami az egyikben előnyös a másik esetében kevésbé az

"- játék megtervezése, annak kivesézése. Itt pl. az lenne szvsz a legjobb, ha időről időre egy GP-t vennénk górcső alá és azt veséznénk ki, hogy annak melyik részét hogy kéne megvalósítani, és mi az ami nagyon 5letes, máshol is jól használható."

na igen, a kérdés az, h mennyi idő alatt készül el egy gp, amit ki lehet vesézni...
alias aalberik
   
nagyy - Törzstag | 248 hsz       Online status #54566   2007.05.13 04:06 GMT+1 óra  
Szerintem is jó ötlet lenne egy ilyen feature beépítése az oldalba, márcsak azért is, mert ezzel az oldalt látogató emberek tábora is kiszélesedne, és így akár még szintent is léphetne a jf.hu. (ne értsétek félre, kedvelem az oldalt.)
A megvalósításnál én is azt az ötletet tartom jónak, hogy lennének fórumok, ahol mindenki kifejti a véleményét, és végül az eredményt egy cikk, vagy wiki formájában lehetne összefoglalni. A fórum részleg meg szerintem az idővel ki tudna alakulni, ha látnák a hozzá nem értők, hogy ott komolyabb dolgokról folyik a diskurálás, akkor csak nem szólnának közbe oda nem illő dolgokat. Persze ehhez az kell, hogy a színvonal végig megmaradjon, és tényleg ne térjen el az eredeti témától.
A buktatója szerintem az a dolognak, hogy ugyebár egy ilyen fórumnak a lényege az lenne, hogy mindenki elmondja hogy szerinte melyik megoldás a jobb, melyik a kevésbé jó, és hasonlók. A lényeg, hogy nem a kérdéseké a főszerep, mert arra való a többi topic. Így mindenkinek utána kellene nézni a dolognak, mielőtt hozzászólna az aktuális témához, amit így önmagában jó ötletnek tartok, csak nem tudom, hogy meglenne -e a kellő számú ember, akik érdemben el tudnának beszélgetni egy adott témáról (lehet, hogy tévedek ). Például olyanra gondolok, hogy tfh az aktuális téma az lenne, hogy ki milyen módszereket használ árnyék megjelenítéséhez. Ennek utánanézek, hogy mik vannak, melyik milyen stb... A probléma az, hogy ha épp akkor ismerkedek meg egy számomra teljesen új dologgal, akkor nem biztos, hogy lesz is róla véleményem, hogy melyik a jobb, melyiknek milyen előnyei, hátrányai vannak, és hülyeséget meg nem akar az ember írni, nehogy másokat félrevezessen... Persze biztos lennének mindíg hozzáértők, akik profik az aktuális témában, csak kérdés hogy milyen számban.
De összességében nézve szerintem meg kellene próbálni valami ilyesmit, mert maga az alapötlet nagyon jó.
   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54558   2007.05.13 01:05 GMT+1 óra  
Idézet
TheProGamer :
El kellene dönteni hogy mit szeretnénk mert azért egy wiki meg egy rövid pórázon tartott fórum téma teljesen más műfaj. Én spec azt mondom hogy mindkettő kell de sztem a két dolog nem fogja metszeni egymást. A wiki arra jó és azért kell mert ott be tudjuk mutatni azt amit tudunk, egy fórum téma viszontennek az ellenkezője, ott meg tudjuk kérdezni azt amit nem tudunk.



OK, de akkor te ezt hogy képzeled el? Én ebben a postomban írtam le, hogy én hogy gondolom, te ezt mennyiben látod máshogy? #54476 2007.05.12 10:20 GMT

Idézet
syam:
egyik felosztási alap lehetne pl a műfaj, mivel egészen más tészta megírni egy rts-t, egy fps-t vagy egy rpg-t; ez leginkább elméleti és logikai feladat ill. tervezés( ezt nagyon sokszor kihagyják a fejlesztésből és egy idő után fejleszthetetlenné válik a project)



Én eredetileg úgy gondoltam, hogy témákra lenne osztva az alportál / fórum, amik teljesen külön mennének: külön szavazás a következő témáról és még az is lehet, hogy nem mind1iket egyszerre kéne elmenteni és fogni a következő témát, hanem attól függően, hogy melyikkel mennyi ideig foglalkozunk.

A felosztásra eddig 2 csoportot találtunk:
- általánosan a játékokban használt technológiákról (ezt akár al csoportokra is lehet osztani, 3D grafikai rész, másik csoportba pedig a többi téma, pl. a sokat emlegetett térparticionálás)
- játék megtervezése, annak kivesézése. Itt pl. az lenne szvsz a legjobb, ha időről időre egy GP-t vennénk górcső alá és azt veséznénk ki, hogy annak melyik részét hogy kéne megvalósítani, és mi az ami nagyon 5letes, máshol is jól használható.

Idézet
syam:
harmadik nézőpont lehetne a játék fejlesztésének menete, hogy hogyan indul és kikkel ill. mivel, milyen segédeszközök ill. technologiák kellenek/szükségesek


Ez szvsz nem olyan jelentős, volt már rá utalás, hogy kéne egy általános adatbázi (faq), ezt elég lenne oda felrakni (pl. egy wiki rendszerben valaki ennek megírhatná az alapjait, milyen programokat érdemes használni és ezt utána lehetne bővíteni), de ez a téma csak 1xi téma lenne, külön csoportot/ topicot szerintem nem érdemes hozzá létrehozni. Magukat a technológiákat / technikákat egy külön csoportban tárgyalnánk, így aki elkezd fejleszteni egy játékot és gondolkozik azon, hogy milyen térparticionálás lenne a legmegfelelőbb az átkutatná az archivált adatbázis ezen részét.

Az én elgondolásom szerint nem szabadna 2-3 aktív témánál többet fenntartani, viszont ebben a 2-3 témában minél több embernek hozzá kéne szólnia. De persze még semmi sem végleges, várom a véleményeteket, hogy jó e az elképzelt felosztás, kell e változtatni a rendszeren, vagy ti teljesen máshogy képzelitek
   
syam - Törzstag | 1491 hsz       Online status #54553   2007.05.12 19:04 GMT+1 óra  
először is köszönöm, h megkérdeztetek

sok éve foglalkozok petrával ( a játékfejlesztés helyett inkább engine fejlesztést mondok) és nagyon sok buktatón vagyok túl( bár azok is csak átalakulnak...)
mivel a játék/engine-fejlesztés manapság már egész nagy falat és sokrétű mindenképp célszerű felosztani a témát keveredést elkerülendő;

egyik felosztási alap lehetne pl a műfaj, mivel egészen más tészta megírni egy rts-t, egy fps-t vagy egy rpg-t; ez leginkább elméleti és logikai feladat ill. tervezés( ezt nagyon sokszor kihagyják a fejlesztésből és egy idő után fejleszthetetlenné válik a project)

egy másik nézőpont a játékok "általános" felépítése ha lehet ilyet mondani ma még; ide jöhetne a grafika, fizika, ai, hang valamint maga a játék engine; ezekre vmilyen szinten minden játékban szükség van, de természetesen a lehetőségek nagyon szerteágazók ( és talán a programozókat ez a része fogja meg leginkább ill. ezen belül is a grafika/megjelenítés része)

harmadik nézőpont lehetne a játék fejlesztésének menete, hogy hogyan indul és kikkel ill. mivel, milyen segédeszközök ill. technologiák kellenek/szükségesek

hogy hogyan is lehetne vmi hasonló szerkezettel bíró "portált" ill. "fórumot" összehozni arról hosszan lehetne gondolkodni nem is beszélve a karbantarthatóságról...

szerintem:
-pl minden témához kellene 1-2 "szakember", aki legalább "tudja miről van szó" és akiktől kérdezni lehetne, de ne lehessen sokadszorra uazt a kérdést felvetni; ezt pl a "szakember" ki tudná szűrni a kérdésből és esetleg átirányítani a megfelelő témához; ennek hiányát lehet látni az egyik portál tudástárjában, ahol egymást érik a "majdnem uolyan kérdések"
-a cikkek általában sok időt fognak le esetleg egy többé-kevésbé "jól felépített "fejlesztési napló többet érhet mivel általában több témát is érint, mint egy cikk ill. személyes tapasztalatokat is bele lehet venni; a kérdés csak az, h milyen a jól felépített fejlesztési napló
-a forráskódokat lehetne doxygennel dokumentálni valamint portolni több nyelvre, mint a nehen

kapásból ennyi jut az eszembe, lássuk mit mondanak többiek
alias aalberik
   
TPG - Tag | 3402 hsz       Online status #54551   2007.05.12 17:40 GMT+1 óra  
El kellene dönteni hogy mit szeretnénk mert azért egy wiki meg egy rövid pórázon tartott fórum téma teljesen más műfaj. Én spec azt mondom hogy mindkettő kell de sztem a két dolog nem fogja metszeni egymást. A wiki arra jó és azért kell mert ott be tudjuk mutatni azt amit tudunk, egy fórum téma viszontennek az ellenkezője, ott meg tudjuk kérdezni azt amit nem tudunk.
Reality is almost always wrong. - House

   
ShAdeVampirE - Törzstag | 1313 hsz       Online status #54537   2007.05.12 15:30 GMT+1 óra  
Én még azért megvárnám TPG, syam, maniac véleményét is mielőtt belevágunk, hátha van még vmi észrevételük (de persze más véleményét is szívesen várjuk )
   
kicsy - Szerkesztő | 4304 hsz       Online status #54532   2007.05.12 14:10 GMT+1 óra  
Már lentebb írtam, nem lehet felhasználónként szabályozni a jogosultságokat. Írási és olvasási lehetőségeket lehet állítani fórum-részleg szinten, felhasználói szintek szerint. De tekintve, hogy eddig se szólt hozzá a témához senki akinek nem kellett volna, meg nem kérdezett be senki hogy mijjaza gémméker, továbbra is azt javasolnám hogy a túlszervezkedés helyett vágjunk bele! Ha működik, lesz anyag, akkor lehet felállítani wikit meg különféle tudástárakat. Ha sokan offolnak/szétzúzzák a témát, akkor lehet gondolkozni elzártabb diskuráláson.
A moderátorok hozzáértését tekintve meg lehetnél optimistább, Kuzanth
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com