játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5444
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:    2188
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] [16]
7slash - Tag | 8 hsz       Online status #208766   2015.12.08 12:03 GMT+1 óra  
draneor.. felrebeszelek.. latszik cata volt az utso contentem
a tobbi tapasztalat klantarstol jon, aki naponta 4 orat ol bele es mindig meseli az "izgalmas" reszeket....

mindegy offtema ^^

igy vagy ugy, de valamit csinalnak a hatterben, mert ha 9000 ember egy itemet ide oda rakosgat a taskajaban, nem fagynak ki a szerverek.. szoval valami van.

Azt mar csak ok tudjak, hogyan..
mellesleg 24+ magos, 64gb os szervergeprol lehet a legjobban feszbukra posztolni, mert a chrome annyi ramot zabalhat, amennyit csak akar

   
Asylum - Törzstag | 5444 hsz       Online status #208765   2015.12.08 11:00 GMT+1 óra  
Outlanden??? Draenor-ra gondolsz nem? (az még nem Outland, leülhetsz, 1-es).
Szervertől függ egyébként, én az Ajzol-on vagyok és bár szokott lagolni, de nem túl gyakran (nagyobb probléma a gyakori dc...)

Megjelenéskor konkrétan be se lehet jutni a játékba (várólista..), egyébként néhány ezer játékosnál már rottyangat.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
7slash - Tag | 8 hsz       Online status #208763   2015.12.08 10:02 GMT+1 óra  
Nyilvan nem 100% de vannak erosen erre utalo jelek (es volt mar nem egyszer), de ha mmot uzemeltetnek/programoznek en is csinalnek valamifele terheles elosztast, mert ha 9000 ember egyszerre, egy szervernek kuldi folyamatosan az adatot es melle meg var is vissza nem keves adatot, biza konnyen lehet laggoltatni a szervert, mikozben vegzi a kis "dolgait" is. (szervergeptol fuggetlenul)

Kezenfekvo, hogy zone szerverekre veszem szet, igy a kulonbozo szigetek, kontentekhez nagyobb eroforras rendelheto, mint egy olyan teruletre ahol a kutya se jar.

Ebben igy nem vagyok biztos es persze elkepzelheto, hogy igazad van, ahogy az is, hogy nem fizikai szerverekre osztjak szet, hanem virtualizaljak, ki tudja..

Ket biztos dolgot megmondok es ezt mint jatekos tapasztalom/tapasztaltam, ami engedi feltetelezni ezt.

1. jelenleg Outlanden 2-4szer nagyobb a ping, a lag, napszaktol,emberszamtol fuggoen, mert az most az "ujdonsag" es a legtobb player ott tartozkodik.
Ekozben mas teruleten pl. Kalimdorban "nulla" kesessel jatszol, de mindenkepp latvanyos jobb a pinged, mint Outlanden.

2. minden uj kontent berakasanal X ideig kb. lehetetlen atjutni az uj teruletre, konkretan a legutolso kieg megjenese utan, megrottyantak a. szerverek es az uj teruletre valo atjutasi probalkozasokat, discnnectel jutalmazta a blizz..

Ekozben vigan jatszottal barmilyen mas teruleten, mert azok mentek

Tenyleg nem allitom, hogy ez igaz, de akadnak erre utalo jelek boven es nekem ugy remlik meg nem erositett forrasokbol, hogy a wow alapveto szerver kiepitese all db,realm,world, zone szerverekbol. (nagyjabol..) Ami belegondolva logikus es esszeru tervezoi megoldas ennyi ember kezelesere.

Ezt a hozzászólást 7slash módosította (2015.12.08 10:15 GMT+1 óra, 684 nap)

   
Asylum - Törzstag | 5444 hsz       Online status #208762   2015.12.08 09:32 GMT+1 óra  
A wowban nincs területenként szétválasztva a szerver...sőt, szerintem egy szerveren több realm is fut (most konkrétan realm). Ne ilyen hétköznapi gépekre gondolj, amin a fészbúk postjaidat írod, hanem 24+ magos 64+ GB memóriás gépekre, ahol a teljes adatbázis a RAM-ban van állandóan. De még azt is el tudom képzelni, hogy az egész virtualizálva van (mint pl. PVM) és több szervergép össze van kötve egybe és úgy hostolnak.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
7slash - Tag | 8 hsz       Online status #208761   2015.12.08 08:12 GMT+1 óra  
Bar az eredeti blizzard kodot nem ismerem, mangos/trinitycore emun dolgoztam egy kis ideig, ott alapvetoen a unit class(ha jol emlekszem), ami mindennek (mob/pet stb.) az apja/anyja mar ugy volt megirva, hogy ezt az egesz phasinget kezelte, vagyis a unitmanager, meg a tobbi dolog.

Mivel az eredeti kodot masoltak, probaltak gondolom hasonlo eredetin is.
Lenyeg, hogy az elmeleti resze ugyan az.

Ez igy ebben a formaban (bar unityt nem ismerem) nem hiszem, hogy megvalosithato se unrelben, se unityben, hiszen nem igy lett megtervezve az object kezelese, mert hiaba van network visibility az csak true/false lehet tobbnyire, mig blizznel ez konkretan egy szam, az ugyanolyan szamu (phaseid) playerek latjak egymast es a mobokat, a tobbiek nem es nyilvan a mobok/bossok pedig csak a veluk egy phaseids playerekre aggrozhatnak stb.

Unityt nem ismerem, mint irtam. Modszeresen tavol tartom magamat attol az enginetol , de..

UE4 ben vannak game sessionok, ami arra jo, hogy egy szerver mondjuk tobb ugyanolyan meccset inditson, kulonbozo jatekosokkal.
Azt most igy fejbol nem vagom, hogy pl. lehete mapot cserelni adott sessionnel, vagy minden instahoz kene futtatni egy szervert, fogalmam sincs hogy hova mentenem le a sessiont a kesobbi ujracsatlakozashoz es a tobbi, de ha ilyen instance dolgot kene megoldanom, tuti ezt neznem at eloszor, mert ez all a legkozelebb a problema megoldasahoz es nem kene atirni hozza a fel enginet

Amph

   
Instalok - Tag | 540 hsz       Online status #208760   2015.12.08 07:20 GMT+1 óra  
Csak azért is jutott eszembe az egész, mert akár Unity, akár UE4 szinten megnézi az ember, arra nem nagyon van lehetőség, hogy 1 szerveren belül a játékosok ne tudjanak interakcióba lépni mással. Nyilván a network visibility-t ki lehet kapcsolni, de attól még a szerver oldalon ott vannak az objektumok, így láthatatlan dolgokkal ütközne például a játékos.

A Unity tud olyat, hogy Layerekbe rendezed, de az sem jó megoldás igazán, nem erre találták ki. Ezért jutott eszembe az, hogy 1-1 instance egy új "game instance" a szerver oldalon is. A kapcsolat a "master serverrel" nem veszik el, hanem szól a kliensnek, hogy "tessék, ide is csatlakozz, ez szolgáltatja neked az adott instát".

   
7slash - Tag | 8 hsz       Online status #208759   2015.12.08 05:42 GMT+1 óra  
nagyjabol Asylum leirta ^^

Eredetileg konkretan phasing van.

A belepo group/jatekos kap egy instanceID-t, ami alapjan phasebe vannak rakva a jatekosok es a tolto kepernyo alatt spawnolja le az insta alap scriptje a mobokat/bossokat, ugyanezzel a phasingel.

Az adott terulet(outland/northrend stb.) szervere hostolja az instaban levo jatekosokot, akik gyakorlat ugyanott vannak, de se egymast es se az instaIDhez kotott mobokat/bossokat nem latjak es nincsenek hatassal egymas instajara.

Ahogy Asylum irta ez a cross realm ota annyiban valtozott, hogy van egy a realmokat osszekoto szerver ahol ugyanez zajlik adott esetben. (pl. group finder)

funfact: regen a hosidokben elofordultak olyan bugok, hogy 6. emberkent berakott egy 5 fos grouphoz ^^

Amph

   
Asylum - Törzstag | 5444 hsz       Online status #208756   2015.12.05 11:33 GMT+1 óra  
Én úgy vettem észre, hogy amióta a wow-ban vannak cross-realm dungeon-ök, azóta mindig egy dedikált szerveren fut az adott instance (de ezt nehéz ránézésre megmondani). De ezt nem szerver szinten kell szétválasztani, mert az open world-ön belül is vannak ún. "phase"-ek, amikor nem látom az adott playert mert még nem tart ott a sztoriban mint én. Szvsz a jó megoldás erre is az, hogy ne is létezzen ilyen fogalom, hogy "szerver". Majd az implementáció legalsó rétege eldönti, hogy ki hostol. A felső rétegekben úgy legyen leprogramozva, mintha egyetlen egy szerver létezne csak.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #208755   2015.12.05 09:18 GMT+1 óra  
Mi az általános technika olyan multiplayer játékoknál, ahol van open-world terület is, ahol minden játékos látja egymást, meg van instance-based terület is, ahol csak a közös instance-ben lévők látják egymást? Minden egyes instance egy új szervert jelent, amely a kívánt pályát tölti be, a kliensek pedig arra (is?) csatlakoznak rá?

   
glezmen - Törzstag | 381 hsz       Online status #208497   2015.10.19 06:55 GMT+1 óra  
Idézet
ricsi9328 :
A játék állását, hogy éppen hol tart a játékos a játékban, miben célszerű elmenteni, ezt úgy általában is kérdezem, de leginkább Android operációs rendszernél vagyok rá kíváncsi, ha van különbség a többihez képest. Én most szimplán egy saját kiterjesztésű fájlba mentem bele az adatokat. De ez nem tudom mennyire helyén való.



A kiterjesztesnek pont nincs semmi jelentosege. A lenyeg hogy mi a file formatuma/tartalma. Nyilvan erdemes ugy kitalalni hogy ne legyen tul konnyu dolga annak aki bele akar turkalni (igy csinalva tobb penzt/palyat/stb maganak).
Egy masik 'szint' amikor felhobe mentesz, pl. Google Play Services-en keresztul, ennek tobb elonye is van. Ezt a sajat boromon is ereztem most hogy telefont csereltem, tobb jatek (pl. Fallout Shelter, Hill Climb Racing) siman koltoztetheto volt az uj telefonra mindenfele backup program nelkul.
   
ricsi9328 - Tag | 24 hsz       Online status #208482   2015.10.18 10:36 GMT+1 óra  
Sziasztok!

A játék állását, hogy éppen hol tart a játékos a játékban, miben célszerű elmenteni, ezt úgy általában is kérdezem, de leginkább Android operációs rendszernél vagyok rá kíváncsi, ha van különbség a többihez képest. Én most szimplán egy saját kiterjesztésű fájlba mentem bele az adatokat. De ez nem tudom mennyire helyén való.

   
Instalok - Tag | 540 hsz       Online status #208390   2015.09.29 17:33 GMT+1 óra  
Ha jól értem, végső soron ez hasonló, mint ami lentebb már megszületett, azzal a különbséggel, hogy callback függvényekkel dolgozik, amik egy rendszer alá kerülnek. Azaz nem maga a skill végzi el az ő dolgát, meg nem is maga a módosító, hanem azok szinte csak adatokat tárolnak (pl. hogy hány újabb lövedék keletkezzen).

Nyilván az építőelemek ki lesznek találva, a játék nem írhatja meg magát helyettem azonban maguk a képességek a játékos által lesznek összeállítva, és így nehéz mindenre gondolni, hogy "mi történik, ha ezt meg ezt is összerakja".

Terv szerint egyébként az lesz, hogy egy nagyon alacsony szintről indul az egész. Úgy kell elképzelni az építkezést, mint a Spore-ban a kis lényünk összerakását.
Alapvetően 2 féle akció lehet, amelyek jól elkülöníthetőek: attack és cast. Az attack továbbá lehet melee és ranged. A cast lehet projectile és aoe. De már ezeket is maga a játékos választja ki. Azaz rétegenként pakolja tovább, például hogy mi történjen találat esetén, vagy már castoláskor. Megpróbálok majd kitalálni jó néhányat, és az alapján összeszerkeszteni, viszont pont ezért volt lényeg a modularitás, hogy, ha később eszembe jut még valami, az könnyen belerakható legyen.

Egyébként ezt az egészet Unity alatt készítem, és már azon is elgondolkoztam, hogy konkrétan új objektumokat létrehozzak-e minden egyes skillnek, vagy egy-egy játékoshoz tartozik 1 db system object, és csak "képzeletbeli" objektumaink vannak.

No hát szóval majd lesz valahogy, próbálkozok, köszönöm a segítséget.

szerk.:
Agyaltam sokat közben a képességeken, és lehet, hogy nem fog menni az ennyire alapoktól induló legózás, mert így például a summon képességek hova kerülnének? Azaz valamilyen szinten lekorlátozódna a játék. Lehet, hogy több alapot fogok adni, és maradok a módosítóknál, ahogy már lentebb (többször is) volt róla szó.

Ezt a hozzászólást Instalok módosította (2015.09.29 18:36 GMT+1 óra, 754 nap)

   
M4 - Tag | 187 hsz       Online status #208387   2015.09.29 13:17 GMT+1 óra  
Instalok:
Sokat gondolkoztam azon, hogyan lehetne bonyolult rendszereket programozni. Hogy majd
készítsek egy programnyelvet ami ezekre az absztrakciókra épül. De mivel nem látok
benne sok pénzt ezért nem kap tőlem túl nagy prioritást. Úgyhogy nem lesz kész
egyhamar .

blindmessiah777 szerencsére jól elmagyarázott pár dolgot belőle (kompozíció), ez az
egyik szükséges elem a megvalósításhoz.

(Megj.: Prototype-based_programming: ezen is gondolkoztam, de én arra jutottam, hogy
jobb különválasztani a kódot (class) az objektumtól. De lehet, hogy ez szubjektív,
amit előbb tanult az ember (class vs prototype) az az egyszerűbb.)

Egy nagyobb programnál nem az objektumok belső viselkedését szeretnénk megmondani,
hanem az objektumok közötti interaktivitást kéne definiálni. Mert az interaktivitás
adja meg a program működését. Tehát az objektumok felett álló, azokat vezérlő
rendszereket programozzuk. Egy (fizikával rendelkező) játékban alapból tudunk legalább
három rendszert. Grafikai, fizikai és logikai. A fizikai objektumoknak megadhatjuk az
AABB-jét tömegét stb., és a fizikai rendszer majd lépteti az objektumokat.
(Erre persze mondhatják az objektum orientált programozás szakértők, hogy a rendszer
is egy átlagos objektum. De ha ezen filozófia alapján készítünk egy programnyelvet,
nem a Java jönne ki. Pl: static-ra nem lenne szükség, az csak egy lokális változó
lenne a rendszerben.)

"Ki és hogyan irányítja, hogy mi történjen?"
Nem a skill vagy a karakter, hanem a skill rendszer.

A bonyolultságot a problémádnak az is adja, hogy nem korlátoztad mire képesek a
képességek és a módosítók. Tehát elvileg akármit csinálhatnak. Így nehéz leprogramozni
bármit is, de leírom mit találtam ki.

Eseményvezérelt lesz. Az események időponthoz és akcióhoz (egérgombnyomás) is
köthetőek. Az esemény következtében meghívódik egy függvény a képesség rendszerben, a
fontos paraméterekkel: aki indította, képesség, módosítók.

Vegyünk egy példát. Nyíllövés képesség, duplázó módosítással. Az alapfolyamat,
létrehozzuk a nyilat, majd letesszük a térképre.
Kód:
actionShootArrow(){
  putOnMap(createProjectile(...));
}

Ahhoz, hogy megduplázhassuk, a createProjectile után meg kell hívni a módosítót.
Kód:
actionShootArrow(){
  putOnMap(doublerModifier(createProjectile(...)));
}

És persze a putOnMap egy listát is fel kell tudjon dolgozzon.
Átalakítjuk, hogy a doublerModifier csak szükség esetén hívódjon.
Kód:
actionShootArrow(skill, modifiers,...){
  Projectile[] m = createProjectile(...);
  //Event type: TypeX (call createProjectile modifiers before putOnMap)
  for(modifiers)
    if(modifier is TypeX)
      m = modifier.changeProjectile(m);
  putOnMap(m);
}
...
changeProjectile(projectile[]){
  return doublerModifier(projectile);
}

(A for ciklust biztos ki lehet optimalizálni, ha sok a modifier.)

Fork skill:
Kód:
//a fizikai rendszer hívja meg
eventProjectileHit(){
  processDamage(...);
  //Event: TypeY
  for(modifiers)
    if(modifier is TypeY)
      m = modifier.processEventTypeY();
}
...
Forkmodifier.processEventTypeY(...){
  actionShootArrow(...);
}

Tehát minden eseménynek létrehozol egy típust, és amelyik módosító reagálhat rá annak
meghívod valamelyik függvényét. (Akár lehet ugyanaz is, ha megadod az eseménytípust
paraméterben.) Ha több módosító is reagálhat, te tudod, hogy kell-e rendezni. Attól
függ mik a módosítók.

Végül: azért kell a kompozíció, hogy az objektum darabkákat egyberakd. Egy karakter
áll majd egy grafikai, egy fizikai és egy logikai részből is. Meg még amiből akarod.

   
Instalok - Tag | 540 hsz       Online status #208385   2015.09.29 08:57 GMT+1 óra  
Megnéztem a kódot is, tényleg jó ötlet! Lehet, hogy majd egy absztrakciós szintet lépek, és az alap komponens például a Projectile lesz, mert alapvetően (bárhogy kombináljuk őket), csak néhány fajta skill-osztály lesz:
- melee hit (target vagy area - aoe)
- projectile (attack vagy spell, de a lényeg, hogy projectile)
- aoe (szintén lehet attack pl. nyíleső, vagy spell, pl. d2-ből ismert blizzard)
Viszont a továbbiakban szépen bővíthető a komponensekkel. Amiket ráadásul a játékos pakolhat majd össze magának (ha minden jól megy).

Amin viszont elgondolkoztam az például a melee attack. Általában a top-down-view játékokban (mint pl. a PoE vagy D2) melee attack esetén először a megfelelő range-be mászik a játékos, majd azután üti. Projectile esetén ez ugye nem gond, csak fogjuk magunkat, és lövünk az adott irányba egy lövedéket, ami aztán intézi a saját dolgait, repül, becsapódik, stb. De melee esetén először magát a karaktert kell mozgatni, és csak utána végrehajtani az adott akciót. Ezt lehet, hogy érdemes a skilltől elválasztani? Például mindegyik alapból tárolna egy range-et, amin, ha kívül van a játékos, akkor először megközelíti a célt, és csak azután csinálja az adott skillt? Projectile esetén a range lehetne ~inf.

Illetve bele fognak kerülni még olyan kiegészítések, mint a source player eltárolása, hogy a különböző módosítóit le tudjam kérni Damage esetén, stb., de ez már teljesen független magától a rendszertől.

Ha menet közben valamin még fennakadok, akkor majd írok még.

szerk.:
Általánosítva a problémát: a játékosra visszaható képességeken akadtam fent egy picit. Ilyen például a fent említett "előbb menjek közel", vagy például jump/dash képesség, amely a karaktert kell, hogy mozgassa, stb.

Ezt a hozzászólást Instalok módosította (2015.09.29 10:27 GMT+1 óra, 754 nap)

   
Instalok - Tag | 540 hsz       Online status #208383   2015.09.29 07:43 GMT+1 óra  
Valóban, a Unity GameObject igazán eszembe juthatott volna, hiszen azzal (jó esetben) hasonlóan dolgozik az ember. Az első leírás is érthető volt, tetszett, hogy példákat hoztál fel (úgy szerintem mindig könnyebb valamit megérteni ), a kódot pedig meg fogom nézni! Ezer köszönet!

   
blindmessiah777 - Tag | 14 hsz       Online status #208381   2015.09.28 21:59 GMT+1 óra  
Mivel visszaolvasva a hozzászólásom, egy kicsit: hú hát ez nehezen emészthető + nesze semmi fogd meg jól érzetem támadt, összedobtam egy ilyen pszeudo-kód félét, ami egy nagyon alap rendszer a lentebb említett elveket véve alapul:
3507-entitycomponent.txt
Remélem így érthetőbb lesz mire akartam kilyukadni .
   
blindmessiah777 - Tag | 14 hsz       Online status #208377   2015.09.28 20:27 GMT+1 óra  
Szerintem erről a témáról (flexibilis design, hiába szűkítjük le a "skill rendszer" témakörre, lényeg ugyan az) évezredekig lehetne agyalni és mesélni (+ mindenki biztos megfűszerezi egy kicsit a saját prefernciáival ), szóval inkább "rövid" leszek, bedobok két tippet/elvet amit érdemes tanulmányozni elsőként, illetve mesélek róluk pár szót.

https://en.wikipedia.org/wiki/Entity_component_system
Az ECS egy olyan féle-fajta elv ami a kompozíciót tekinti előnyösebbnek a leszármazásnál és a lehető legnagyobb flexibilitásra törekszik. A Unity GameObject rendszere sacc-per-kb erre épít. Érthetőbben: a leszármazás nagyon limitált flexibilitás terén, ugyan is a leszármazási hierarchia "limitálja" az adat és funkciók kombinálhatóságát. Ha van egy mély leszármazási láncod, egyre kevésbé tudnak "örökölni" adatot és funkciókat a mélyebben lévő típusok. Még érthetőbben: nehéz valamit származtatással "repülő + ütköztethető + sebző + találaton-effektus-kiváltó + passzív-képességet-adó + ..."-valamivá tenni. Persze lehet többszörös öröklődéssel de isten ments mert abból aztán brutál kezelhetettlen katyvasz lesz !!! Helyette legyen sok egyforma kombinálható kicsi építőelem: "kompónens" és "kompozíció". A kompónens egy adat vagy funkció morzsa, a kompozíció pedig komponens-ek halmaza. Ebből már nagyon is könnyű kevés kóddal megépíteni az imént említett csudaskill-t .

https://en.wikipedia.org/wiki/Prototype-based_programming
Egyes magasabb szintű nyelvek (pl javascript) már az objektum rendszer szintjén valami hasonló dolgot fogalmaznak meg. Ez természetesen itt is runtime penalty-val jár (runtime performance zabálás), viszont ennél flexibilisebbet akarni sem tudsz . Lényegében, egy objektum nem több mint adattagaok és funkciók halmaza és ezen tagok halmaza futásidőben állhat össze, illetve a származás / kiegészítgetés is valójában ezen alapul, tehát ami olyan mint valami másik az csak a másolata és x-y új adattaggal és funkcióval való kiegészítése (runtime).

Ez tudom, hogy borzalmasan absztrakt, de ha flexibilitás a cél, akkor ezek az "adat-oriántált" minták és programozási paradigmák követendőek. Ha ezekkel elindulsz és elkészítessz egy repülni tudást adó darabkát, aztán egy sebezni képessé tevő darabkát, majd egy sebzést duplázó darabkát etc... akkor kombinálhatod ezeket a végtelenségig minimális kóddal (sőt egy jó serializer/sorosító rendszerrel kód nélkül is!!!) és pillanatok alatt szárnyalhat a képzelet: egy lövedék ami találat esetén olyan passzív képességgel lát el az első sebesülésedig aminek köszönhetően minden ütésed bárkin életerőt lop az eredetileg eltalált lénytől, ilyesmi kompónensekből összerakva: lövedék + találton-effektus-kiváltás + életlopás-célponttá-tétel-effektus + sebesülésen-effektus + életlopás-célpont-vesztés-effektus.

Hajrá !
   
Instalok - Tag | 540 hsz       Online status #208366   2015.09.28 10:03 GMT+1 óra  
Tudom, volt már hasonlóról szó régebben, de ez most egy picit más. Gondolkoztam egy moduláris skillrendszer leprogramozásán, és szeretnék segítséget kérni a tervezéssel kapcsolatban. Aki játszott pár a Path of Exile játékkal, annak ismerős lehet a rendszer. Persze nem teljesen olyan lenne, de ahhoz tudnám a leginkább hasonlítani.

Adott egy játékos, neki van egy karaktere. A karakterhez tartoznak itemek, illetve (passzív) tulajdonságok, mint például "megnövelt tűz sebzés". Ezek a tulajdonságok a tárgyakból is jöhetnek, bizonyos szabályok szerint összegződnek. Emellett vannak a játékosnak skillek is, amelyek "lego-szerűen" összerakhatóak. Azaz például van egy alap támadás, ami mondjuk egy íjjal lő egyet. Ehhez hozzákapcsolható például egy olyan passzív skill, hogy többet lőjön egyszerre. Vagy mondjuk egy olyan, ami becsapódáskor területi sebzést csinál, stb. Konkrétan a skill-rendszerhez várnék ötleteket, programozás szinten.

Például nem vagyok biztos benne, hogy bizonyos dolgokat melyik osztálynak kellene intéznie. Azaz például egy skillnek alapvetően 3 fázisa van:
- létrehozás
- frissítés (azaz például repül a lövedék)
- befejezés (például a lövedék becsapódott valahova)
Azonban például egy sebzést okozó skill saját maga mondja meg, hogy ő mekkora sebzést akar okozni arra, akit eltalált? Illetve az ennél nagyobb problémám az az, hogy hogyan lehet megoldani ezt a lego-szerű építkezést. Azaz ha csak van egy egyszerű Projectile osztályom, ami annyit tud, hogy létrejön egy lövedék, az repül egy irányba, ha eltalál valakit, akkor sebzést okoz, akkor ez így úgy tűnik, hogy rendben van, tudunk lőni, és megsebezni valakit. Azonban mi van, ha mellérakom a fent említett "többet lövök" passzív skillt? Ki és hogyan irányítja, hogy mi történjen? Vagy bonyolultabb példa ennél, a PoE-os Fork skill, ami annyit csinál, hogy találatkor a sebzésen kívül létrehoz újabb lövedékeket. Vagy például a sebzést módosító passzívok (pl. +10 tűz sebzés). Szóval valamilyen moduláris, flexibilis rendszer kellene, nem szeretném az összes kombinációt leprogramozni.

Emellett felmerült bennem, hogy egy adott skill honnan tudja, hogy mekkora sebzést kell okoznia (ha sebzést okoz egyáltalán)? Ugye vannak a karakternek a fent említett tulajdonságai, amelyek több forrásból is származhatnak. Erre egyébként az jutott eszembe, hogy minden egyes skillhez (valószínűleg egyébként is szükséges lenne) hozzárendelném azt, hogy kitől származik. Az adott karakter pedig képes megmondani, hogy összességében egy adott tulajdonságból (például tűz sebzés) milyen értékei vannak. Így a skill a neki megfelelő részeket le tudja kérni, és úgy dolgozni tovább.

Tudom, kicsit hosszú, de van esetleg valakinek valamilyen jó kis ötlete erre?

   
itamas - Tag | 78 hsz       Online status #207889   2015.07.03 12:34 GMT+1 óra  
Igen, a file-ba írás az nyilvánvaló, csak az nem mindegy, hogy mit és hogyan. Csináltam már én is azt, hogy pl. egy egyszerűbb lövöldözős játéknál minden pályához volt egy szintkód (általában valami nehezen megjegyezhető írásjelkatyvasz), amit a játék elején begépelhetett a játékos, ha már tudta azt, mert előzőleg elérte azt a szintet és kiírta neki a játék a kódot.
A másik, pl. pályaszerkesztőnél alkalmazott megoldásom, hogy egy-egy ciklus végigmegy az objektumokon, és a nevüket meg az X és Y koordinátáikat kimenti egy szöveges fájlba.
De a tulajdonképpeni játékmentést még soha nem alkalmaztam, nem tudtam, hogy hogyan kell ezt frappánsan megoldani. A játékoknál a mentés pillanatok alatt megtörténik és a mentett állást tartalmazó állomány sem lehet túl nagy, úgyhogy elképzelni sem tudom, hogy működhet pl. az általad is említett Minecraft-é, ahol az egyes kockákat is le kell(?) menteni.
   
Pixi - Tag | 206 hsz       Online status #207883   2015.07.02 20:03 GMT+1 óra  
Szerintem mindenféleképp file-ba kell írni, hisz hogyan máshogyan tárolódna bármilyen adat? Annyi tán a leglényegesebb különbség, hogy egy forgalomba került játéknál nyilván nem egy valami.txt-be mentik ki az adatot könnyen olvasható formában, hogy azt te simán tudd manipulálni. Persze később mindent lehet, ha az ember rákeres a neten, hogyan tud egy adott játék mentéséhez hozzáférni, vagy átírni azt. Azt nyilván tudod, hogy két féle mentésről beszélünk. Vannak az amolyan statikusabb állapotok, amikor csak 1-2 adatot tárolsz, hogy melyik szintnél tartasz, és nincs lehetőség szabad mentésre játék közben. Gondolok itt kisebb játékra, amiben van 10 pálya, és csak annyit tárolhatsz, hogy éppen melyiknél hagytad abba, és a Continue folyamán csak egy darab adatot pl. számot kell kiolvasni. Esetleg még mellé eltárolódik a High Score meg egyéb pl. élet, extra fegyverek, bármi. A másik eset az, amikor pálya közben csinálsz mentést szabadon, ekkor viszont több adat kerül kiírásra. A játék típusától függ az egész, hogy miket kell tárolni. Ha a pályát felépítő elemek szabadon manipulálhatóak (lásd Terraria vagy Minecraft), akkor szinte minden egyes elemét tárolni kell, és nem csak a játékos állapotát és a mozgó objektumokat, vagy éppen azt, hogy mit szedtél már fel, és mit hagytál el. Én ugyan nem C/C++ -ban, hanem C#-ban programoztam eddig, és a következő megoldás a kedvencem:

Kód:
public static void Betoltes(string txtfile)
{
    string[] sorok=txtfile.Split(new char[]{'\r','\n'},StringSplitOptions.RemoveEmptyEntries);
    foreach (string sor in sorok)
    {
            string[] szavak=sor.Split(new char[]{' '},StringSplitOptions.RemoveEmptyEntries);
            elemek.Add(new Elem(szavak[0], new Vector2(Int.Parse(szavak[1]),int.Parse(szavak[2])), .....);
    }     
}


Röviden ez annyit tesz, hogy beolvassa egy file tartalmát, amikben több sor van egymás alatt. Itt minden egyes sor 1 adott elemet ír le szóközzel elválasztva a különböző paramétereket, ahol fontos a paraméterek sorrendje, tehát pl. a legelső mindig az objektum típusa, a 2. és 3. mindig az X és Y, stb. A legjobb persze ha kerüljük a stringet mint kiírandó paraméter formátumot, mert ami belefér számokba, az úgy sokkal kevesebb helyet is foglal eltároláskor. Persze ha konkrét szöveget tárolunk, vagy beszélgetést, akkor értelem szerűen magát a szöveget íratjuk file-ba.

Mondjuk érdekelne a te eddigi megoldásod.

   
itamas - Tag | 78 hsz       Online status #207880   2015.07.02 13:10 GMT+1 óra  
Sziasztok; remélem jó helyre írom ezt a kérdésemet, de ha már feltették ugyanezt itt valahol, akkor elnézést, és útbaigazítást kérek azon hozzászólások felé...
Tehát az lenne a nagy kérdés, hogy hogyan csinálják a játékokban a játékállás kimentését?
Game Makerben van erre ugyebár egy kényelmes utasítás, és kész is (a zene kivételével). Plusz még ha írtam valami pályaszerkesztős játékot, akkor annyi volt a saját pályák elmentése, hogy az objektumairól minden szükséges dolgot (koordináták, stb.) kiírtam egy fájlba és onnan vissza lehetett tölteni.
Viszont
1. más programnyelvekben (pl. C++) nincs ilyen lehetőség alapesetben, hiszen nem játékírásra vannak kiélezve, hanem általános célúak;
2. van egy olyan sejtésem, hogy a valódi mentési mechanizmus azért összetettebb picikét az én fájlbaírós megoldásomnál.
A fejlettebb (mondjuk a kereskedelmi forgalomban kapható) játékoknál olyan érzése van az embernek, mintha egy pillanatfelvétel készülne az adott állapotról; lehet ezt valami könnyű, gyors és egyszerű módon megcsinálni?
Elnézést, ha netán ez olyan kérdés, hogy egy fórum nem igazán alkalmas az elmagyarázására, de azért remélem, jutok némi információhoz, támpontokhoz.
   
Pixi - Tag | 206 hsz       Online status #207754   2015.06.05 21:10 GMT+1 óra  
Parallax:
Sima osztályokra gondolj, csak a funkciójuk más szerepet tölt be. Betehetném az összes objektum típust egy közös osztályba, de a statikusokat külön szeretném kezelni. Ez annyit takar az én esetemben, hogy minden paramétert kézzel kell manuálisan állítani, ellenben a Dinamikus osztályban lenne egy felsorolás mondjuk egy byte változóval, ami aztán lehetne mondjuk egy eső generátor, vagy éppen random villámlás vagy csak fények, de akár szikrázó effektus, vagy tűz, füst...vagy olyan ami sima textúra, de folyamatosan forog körbe egy adott tempóval...Természetesen minden felsorolás alatt külön logika van előre megírva, de ez szerintem nem gond. Egyszerű ez így felvázolva, nem kell túlbonyolítani.

Az adattárolást pedig úgy gondoltam legegyszerűbben megvalósítani, mint a hálózati játékoknál az üzenetküldősdi protokoll. Bár is én így képzelem el, annyi, hogy itt adatküldés/fogadás helyett csak ellenőrzi egy ciklus, hogy az adott Event objektum FPS/time változója tartalmazza-e az aktuális FPS számot, ami éppen a globális idővel egyenlő, az után ellenőrizné csak a többit, hogy pl. statikus vagy dinamikus objektumról van-e szó ami lehetne egy bool, a következő változó ami szintén lehetne byte egy üzenet típust írna le, ami lehetne kb ilyen: 0:add, 1:remove, 2:X, 3:Y, 4:Width, 5:Height, stb...végül pedig egy változó, ami egy szám értéket tárol, ezt ha legegyszerűbben akarom megoldani, akkor egy float változót használhatok. Kb. ennyi.

Ui: Ja meg lenne egy ID változója is az objektumoknak, valamint ugyanilyen változója az Event osztálynak is, amivel a megcélzott objektumra tudunk hivatkozni.

Ezt a hozzászólást Pixi módosította (2015.06.05 21:34 GMT+1 óra, 870 nap)

   
Parallax - Tag | 579 hsz       Online status #207690   2015.05.24 13:01 GMT+1 óra  
Pixi, jól van, csak próbálom követni a gondolatmenetedet.
Szóval van egy konténer osztályod ez az Elements, ami elvileg egy static osztály, vagy Singleton és benne sok tömb, amikben az elemek adatait tárolod. Ezt már alapvetően megfordítanám úgy, hogy lenne egy Elem osztály a tömbök helyett csak 1-1 változó lenne, még véletlenül sem public ez nem Pascal. 1-1 Element benne lenne egy List<Element> ben annyi, amennyi szükséges éppen. Az, hogy miért kell 3 perces animációhoz mindenből 10800 nekem nem világos. Normális esetben egy animáció ismétlődő elemekből áll, ami összesen mondjuk egy 8*8 as atlasz és 64 képkocka, amiben van 8 féle mozgása a figurának. Tehát összesen az összes elemnek lenne 64 képkockája egy helyen egy atlas-ban mondjuk. A pozíció, sebesség, forgatás számolt érték, amit valamilyen algoritmussal számol a program dinamikusan, nem előre letárolt framenkénti információ kéne hogy legyen elemenként külön-külön.

   
Pixi - Tag | 206 hsz       Online status #207662   2015.05.16 13:14 GMT+1 óra  
misi: Hasonlón gondolkoztam én is, hogy lenne egy osztály, ami csak eseményeket tárolna (ha jól értettem a felvázolt megoldást). A "Type felsoroló" jutott eszembe nekem is a stringes megoldáson kívül. Bár absztrakt osztályokkal még nem foglalkoztam, nem is biztos, hogy szükségem lesz rá, majd kiderül élesben.

Parallax: Nem nagyon kell kódot mutassak, hisz eléggé egyértelmű a probléma forrása, de ez érezhető volt már kipróbálás előtt. Valahogy így képzeltem el az egészet 0. lépésben:

Kód:
    class Elements
    {
        public int textureIndex;
        public Vector2 point;
        public Rectangle sourceRect;
        public float rotate;
        public Color color;

        public int[] t; // textúra index
        public int[] px, py; // pozíció X, Y
        public int[] sw, sh; // szélesség, magasság
        public float[] r; // elforgatás
        public Color[] c; // szín (RGBA)
    }


3 perces animáció esetén egy példány létrehozásánál itt minden tömb változó 10800-at kapna. Eléggé egyértelmű hogy ez egy nagyon egyszerű és egyben legrosszabb megoldás.

   
Asylum - Törzstag | 5444 hsz       Online status #207658   2015.05.16 12:39 GMT+1 óra  
- animációt teljesen fölösleges 60 fps-en renderelni (30 is bőven elég)
- egyszerre sosem kell az egész bent legyen a memóriában, mert 1) úgysem dolgozol vele 2) még X perc mire oda jut a lejátszás
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
misi - Törzstag | 971 hsz       Online status #207649   2015.05.16 10:10 GMT+1 óra  
Nem teljesen értem a problémád, de ezek alapján én csinálnék egy Event osztályt, aminek a következő mezői lennének
objectID - hozzá tartozó mező
Time - idősíkon vett pozíciója
EventType - esemény típúsa ( mozgás, képváltás, szinezés... Ami kell )
EventValue - eseményhez tartozó érték

Ha az eseményekhez más típusú értéket szeretnél tárolni, akkor. Csinálsz egy absztrakt osztályt, és abból származtatsz pl SpriteEvent ColorEvent... osztályokat.
Aztán persze az Event-eket egy listába tárolod. Ha rendes objektumaid vannak, akkor praktikus ha ők hozzák létre az eseményt. Pl almafa.setSpriteIndex(1) esetén a setSpriteIndex-ben.

Szerintem stringet kerüld ha nem szükséges, csinálj inkább egy Type felsorolót amiben tárolod az esemény típusokat.
   
Parallax - Tag | 579 hsz       Online status #207644   2015.05.15 22:42 GMT+1 óra  
Ha OutOfMemoryException-t kapsz, akkor valamit nagyon redundánsan tárolsz, vagyis fontos az is, hogy miből mennyi van. Lehet 1-2 kódrészlet pontosabban leírná, hogy mit csinálsz.

   
Pixi - Tag | 206 hsz       Online status #207643   2015.05.15 21:31 GMT+1 óra  
Parallax: Nem 60 sprite az, csak egy int, ami egy sprite indexként szolgál, a sprite(oka)t betölteném még a program indulásakor egy Listába, melyek nevei 0-tól menne felfelé (ha több is van, márpedig több lenne mint 1). Itt fontos és legsűrűbben jelentkező adat egy objektum textúra index száma, valamint a térbeli helyzete (X, Y). Az tény, hogy X, Y adat jelentkezik legtöbbször, de ott van a szélesség, magasság is meg egyéb, akár Color(RGBA). Itt most nem az a kérdés miből mennyi van, hanem hogy milyen módszerrel tároljam az adatokat.

   
Parallax - Tag | 579 hsz       Online status #207642   2015.05.15 20:56 GMT+1 óra  
Pixi: Miért kell másodpercenként 60 sprite-ot tárolni egy animációhoz? Szerintem elég egyet és annak csak egy darabját megjeleníteni adott képkockában és tárolni csak a poziciót kell objektumonkánt, hogy melyik éppen melyik fázist rajzolja ki, az egészhez pedig egy darab képet kell csak betölteni egyszer.

   
Pixi - Tag | 206 hsz       Online status #207641   2015.05.15 19:58 GMT+1 óra  
Tunyu: Ezt kifejtenéd bővebben? Esetleg valami kódrészletet tudnál erről mutatni te hogyan képzelted el?

Idézet
Így nem jönne létre adat minden egyes képkockához...


A tömbös megoldásnál pont az történik, hogy ha van nekem egy int X változóm, és létezik mellette egy int[] _X is, és pl. 1mp az animáció, akkor:

_X = new int[60];

Egy példány legenerálásakor ez helyet foglal a memóriában. Mivel élesben teszteltem már ezt a módszert nem egy darab példánnyal és változókkal, és nem 60FPS-el, így kb. 100+ elemnél már kaptam az "OutOfMemoryException" hibaüzenetet.

Ezt a hozzászólást Pixi módosította (2015.05.15 20:08 GMT+1 óra, 891 nap)

   
Tunyu - Tag | 448 hsz       Online status #207640   2015.05.15 16:14 GMT+1 óra  
Én nem tartom az elsőt rossz ötletnek,bár nagyon nem értek hozzá.Csak annyi a dolog lényege hogy elsőnek letárolni az objektum minden adatát. Ezután csak akkor kell újabb adatot tárolni ha az eredeti adatokhoz képest változás történt, és csak a változást tárolni a frame-el megjelölve.Így nem jönne létre adat minden egyes képkockához és ha létre is jön, jelentősen kisebb méretben.

   
Pixi - Tag | 206 hsz       Online status #207637   2015.05.15 13:58 GMT+1 óra  
Ti hogyan oldanátok meg a következőt? Nagy mennyiségű adattárolás egy 2D-s animációs idővonalon, ahol a statikus objektumokon van a hangsúly, melyek állapota akár képkockáról-képkockára változhat, úgy, hogy 1mp = 60FPS. Mindez C#-ban íródna.

Az eddigi ötleteim: Az alap időt egy globális int írná le.

Az első elképzelésem (ami egyértelműen rossz) az volt, hogy ha van egy osztály, melyben vannak tagváltozók (textúra index szám, X, Y, szélesség, magasság, stb...), akkor mindezek mellé még tartozna egy ugyanilyen típusú tömb változó is, ami értelem szerűen akkora méretet kapna, amekkora maga a maximális idő (pl. ha 1mp az animáció, akkor a tömbök mérete 60 lenne). Így nagyon egyszerű értéket átadni, vagy módosítani az adott képkockának megfelelően minden példány esetén. Éppen csak annyi a hibája, hogy rettenet sok memóriát eszik. Ez nem jó, mivel file-ban is el kell tárolni utólag az állapotot.

A másik elképzelésem olyasmi, hogy az elemek egy külön osztály saját tagváltozókkal, de nem lenne tömb változójuk. Az adatok képkockánkénti tárolását egy teljesen külön osztály végezné, amik különálló példányok. Ezeknek lenne egy index változójuk, mellyel ellenőrizni tudná mindig önmagát, hogy az adott képkockának megfelelő értéket viseli-e, mint az éppen aktuális globális int, a 2. pl. az, hogy az elemek osztályban hanyadik elemről van szó, a következő lehetne akár egy darab string is, mely leírná szavakkal (egy szóközzel elválasztva) hogy mit kell csinálni az adott objektummal, vagy mennyi tagváltozóján kell manipulációt végezni, de akár megkerülhető lenne a string, és külön változó tárolna minden egyes értéket, és ha nincs módosult állapot egy következő képkockában, akkor egyszerűen nem foglalkozik azzal az értékkel. Nagyjából így képzelem el, gondolom utóbbi megoldás valamennyivel jobb mint az első. Viszont úgy érzem ettől valaki tud sokkal hatékonyabb megoldást is. Mindkét osztály példányait egy globális listában tárolnám, így egyszerűen hozzá tudnék férni mindkettőhöz. Tehát röviden az egyik osztály maga az objektum mely kirajzolásra is kerülne a képernyőn, a másik pusztán adattároló objektum, mely megfelelő utasításokat adna át a meglévő objektumoknak. Ez a gyakorlatban úgy nézne ki, ha van 1 darab karakterem, és 1mp-ben 5x változik a textúrája, akkor az adattároló osztályban 5 különálló példány létezne, mely a megfelelő időben (FPS-ben) a megfelelő adatot adná át a kirajzolandó objektumnak. Ebben az esetben mindig csak egy számot, hogy hanyadik sprite-ot adja át az objektumnak kirajzolásra. Ugyanígy történne a többi tagváltozóval is, mint pozíció, szélesség...

Ha esetleg valaki foglalkozott már hasonlóval, és tud jobb megoldást, azt megköszönném.

   
Instalok - Tag | 540 hsz       Online status #207621   2015.05.12 18:47 GMT+1 óra  
Ja, természetesen vannak más alrendszerek is, azaz nem mindent hardcode-olni akartam az ability-be.

Az meg, hogy a képesség döntse el, hogy létrejöhet-e azért jutott eszembe, hogy flexibilisebb legyen a rendszer. Kiindulva például a LoL-ból, van amelyik ability mana costos, van amelyik health cost, energy cost, no cost, stb. Egyéb játékokban ott vannak a chain skillek, azaz ezt-azt csak egy bizonyos másik ability után lehet használni, és így tovább. Illetve ebben az esetben könnyen jöhetnek ability-specifikus faktorok is.

Persze lehet azt is csinálni, hogy veszem a feltételek halmazát, és mindegyiket letárolom az adott ability-ben (azaz mana/energy/health costok, skill dependency, stb.). A hátránya ennek viszont az, hogy ha egy abilitynek speciális feltételre van szüksége, akkor azt mindegyik másiknál is tárolnom kell.

Emellett vannak globális "képesség-blokkolások", pl. stun, silence. Ezek természetesen globálisan vizsgáltak lennének.

Valószínűleg a kettő ötvözete marad, azaz a minden képességre érvényes dolgokat előbb megvizsgálom, majd, ha minden stimmel, akkor az opcionális speciális feltételeket is megnézem.

   
M4 - Tag | 187 hsz       Online status #207618   2015.05.12 12:45 GMT+1 óra  
Elodin-nal értek egyet, a képesség használata csak létrehozza a tűzlabdát, utána működne magától (fizikai rendszer). Hacsak nem szeretnéd tudni, hogy a tűzlabdát milyen képesség hozta létre. De azt is tárolhatod a tűzlabdában.

A képesség-rendszer a képességek közös tulajdonságaiért felelne. Pl.:
Kód:
SkillSystem{
  Skill{
    String name;
    Image icon;
    int minLevel;
   
    onActivate();
  }

  Skill FireballSkill{
    name = "fireball";

    onActivate(Player p){
      map.add(new Fireball(x,y,angle,speed,...));
    }
  }

//vagy

  Skill[] skills = {
    new Skill("fireball",icon,1,function {...}),
    ...
  }

}

//learn fireball
player.skills.add(FireballSkill);

Ez csak vázlat, hogy az adott nyelven hogyan implementálod az a te dolgod. Például java-ban jó erre az Enum is.

   
Elodin - Tag | 173 hsz       Online status #207616   2015.05.12 11:28 GMT+1 óra  
Fura ötletnek tűnik számomra, hogy az ability döntse el, hogy létrejöhet e.
Én kapásból úgy csinálnám, hogy a tűzlabda csak a saját viselkedését vezérelné a születéstől.

Ha ennek hatására túl bonyolult lenne a karakter osztály, akkor inkább kiegészíteném egy köztes komponenssel, (MyCharacterSkillManagerComponent vagy mittudomén ) ami kezeli ezt, és az összes többi skill-t.

   
Asylum - Törzstag | 5444 hsz       Online status #207615   2015.05.12 11:08 GMT+1 óra  
Ha már rendszerben gondolkozol, akkor az ütközésdetektálást egy külön modul (a fizika) végzi. Én is épp most tervezem újra a demóim játék felületet (dev videó, csak itt, csak nektek ).

Nincs nekem külön ilyen, hogy "ability", nálam GameObject-ek vannak. A plazma is ilyen gameobject (leszármazva), de a saját dolgait mind ő kezeli (pl. a robbanás effektjét is). Memberként van egy qRigidBody-ja, a fizika visszaszól ha ez ütközött valamivel. Ilyenkor csak azt kell tudni, hogy mivel ütközött (body alapján vissza lehet keresni a gameobjectek között). Pl. ha egy szörnnyel, akkor monster->Hit(PLASMA_DAMAGE);

Nekem a nehézség az volt, hogy a rajzolást sem a gameobject végzi, hanem az engine (de ez ugyanakkor kényelmes is), ezért a robbanáshoz pl. egy külön callback kellett az engineből, hogy a paramétereket tudjam állítani.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #207614   2015.05.12 09:49 GMT+1 óra  
Képesség-rendszeren gondolkozok mostanában, a következőnél van-e valami jobb "tervminta" az egészre?
Minden egyes ability saját maga funkciójával rendelkezik. Példának nézzünk egy tűzgolyót (mert miért is ne fireball lenne az első ). Amikor egy ilyen varázslat létrejön, onnantól kezdve a saját dolgait intézi, azaz mozog, illetve vizsgálja a becsapódást. Ha becsapódott, akkor meghívja az adott objektum sebződés függvényét egy adott mennyiséggel (ami nyilván függ a varázslat szintjétől, stb.). Illetve maga az ability vizsgálja azt is, hogy az adott körülmények között létrejöhet-e (a játékosnak van-e elég xy pontja, mozog-e, stb.), és így tovább.

   
M4 - Tag | 187 hsz       Online status #207561   2015.04.30 10:38 GMT+1 óra  
"Úgy álltam neki, hogy egy részfeladat egy csoport kiszolgálása, tehát a lehetséges ételek közül kiválasztani, hogy melyikből mennyit kapnak. Ha sikerült, jön a következő csoport és így tovább. A probléma ott van, ha egy csoportot nem lehet kiszolgálni. Ekkor jönne a visszalépés, itt viszont nem tudom, hogy mi alapján kéne máshogy kiválasztanom hogy mit kapjanak. "

Először oszd ki a csoportnak az ételeket minimális költséggel. Aztán ha módosítani kell, legyen egy keresési elágazás a lehetséges módosításokkal (A étel helyett kapjon valaki B ételt). Először válasszuk a legolcsóbb módosítást. Majd a következőt stb. (Így lehet többször előjöhet ugyanaz a kombináció, szűrni kéne)

   
gberes - Tag | 37 hsz       Online status #207555   2015.04.28 21:28 GMT+1 óra  
Sziasztok!

Van egy feladat, elakadtam benne, segítséget szeretnék kérni hozzá:

Adott egy étteremben kapható ételek listája, mindegyikből 50 darab készülhet maximum, az áruk is ismert. Adott n db csoport, amiknek tudjuk a létszámát, és hogy milyen betegségek (pl. cukorbetegség, lisztérzékenység, ...) fordulnak elő benne. Ha egy betegség miatt az egyik étel nem fogyasztható, akkor olyat az egész csoport nem kaphat (pl. ha van a csoportban cukorbeteg, akkor az a csoport nem kaphat tortát). A cél, hogy minden ember kapjon valamit. Egy csoportot többféle étellel is ki lehet szolgálni (pl. egy 40 fős csoportot 10 tortával, 10 sült hallal és 20 fánkkal). Ki van kötve, hogy visszalépéses kereséssel (backtracking) kell megadni, hogy melyik csoport miket fog kapni, úgy, hogy az összköltség a végén a lehető legkisebb legyen.

Úgy álltam neki, hogy egy részfeladat egy csoport kiszolgálása, tehát a lehetséges ételek közül kiválasztani, hogy melyikből mennyit kapnak. Ha sikerült, jön a következő csoport és így tovább. A probléma ott van, ha egy csoportot nem lehet kiszolgálni. Ekkor jönne a visszalépés, itt viszont nem tudom, hogy mi alapján kéne máshogy kiválasztanom hogy mit kapjanak.

Gondoltam arra is, hogy nem csoportokat és ételkészleteket kezelek, hanem mindkettőt egyesével. Tehát egy 20 fős csoportból lenne 20 ember, és minden kajából 50 egyesével. Ekkor már szerintem működhet a dolog, de úgy gondolom ennél van egyszerűbb megoldás is.

Valakinek van esetleg ötlete? Nem megoldást szeretnék, csak hogy merre érdemes elindulni. Előre is köszi!

   
M4 - Tag | 187 hsz       Online status #206235   2015.01.13 12:01 GMT+1 óra  
Idézet
Instalok :
Anno láttam egy ilyen zombi-apokalipszis-túlélő rövidfilmet, ahol online lehetett éppen kattintani, és kiválasztani, hogy éppen mit csinálsz. Ha valamit nem jól csináltál, akkor megettek a zombik.


Ilyen játékmechanizmust hentai játékban láttam . Igen, ezzel csökkentheted a komplexitást, hogy ha szinte minden szálban meghal a főhős.

Nem tudom az segít-e, de ha két csomópont között hosszú a történet, akkor több fájlba is írhatod, és akkor egy fájl lineáris. És az elágazásokat külön adod meg.

De azon kívül, hogy leírod a történetszálakat, mit szeretnél? Kielemezné egy program, hogy nincs-e benne hiba? Például meghal valaki, de később megjelenik. Vagy nem úgy viselkedik egy NPC ahogy kéne.

   
Instalok - Tag | 540 hsz       Online status #206211   2015.01.12 17:13 GMT+1 óra  
Egy adott dologgal kapcsolatban dönthet, nem tudja, hogy mi fog abból kisülni. Azaz nem tudja, hogy milyen történetszál között választ, de egy gyors példa:
"Ott fekszik előtted Józsi, aki felé egy vérszomjas macska lohol. Megmented? - Igen/Nem" - itt választ a játékos valamit, és a történet további része ennek megfelelően fog alakulni. Vagy valami ilyesmi.

Anno láttam egy ilyen zombi-apokalipszis-túlélő rövidfilmet, ahol online lehetett éppen kattintani, és kiválasztani, hogy éppen mit csinálsz. Ha valamit nem jól csináltál, akkor megettek a zombik.

   
M4 - Tag | 187 hsz       Online status #206204   2015.01.12 13:12 GMT+1 óra  
(az xml-t nem szeretem, de az is jó)
És milyen játékra gondoltál? Mert azt írod, eseményeket kötsz össze (gráffá?). Tehát minden történetszálat definiálni akarsz?
Mert különben le lehetne egyszerűsíteni, ha csak előfeltételeket írsz a történésekhez. Pl Lucy csak akkor mond valamit, ha hajsütővas van nálad. Vagy ha megoldottál valamit kinyílik az A ajtó. És akkor nem kell gráfot karban tartani.

Most jövök rá, azt írtad dönthet a játékos. Vagyis meg van mondva a játékosnak mikor választ több történetszál közül?
Lehet, hogy félreértelmeztelek.

   
Instalok - Tag | 540 hsz       Online status #206198   2015.01.12 11:24 GMT+1 óra  
Igen, valami ilyesmire gondoltam én is, csak nem tudom, hogy van-e valami bevett, jól működő dolog erre. Első sorban XML-re gondoltam, amíg nem csinálok hozzá dicsőséges editort, ahol össze lehet kötögetni az eseményeket. Egyelőre mondjuk scriptek se nagyon vannak, az még nincs megcsinálva, egyelőre leprogramozni kell dolgokat. Végül is lehet, hogy így fog maradni, a gráfot beolvasom file-ból, majd a megfelelő eseményt hajtom végre. Szóval nincs hozzá semmi trükk, jól van akkor.

   
M4 - Tag | 187 hsz       Online status #206196   2015.01.12 10:43 GMT+1 óra  
Nem tudom mi ennek a neve (ha van), és nem tudom biztosan, hogy mi neked ebben a bonyolult. Ha az, hogyan adjuk meg az NPC-knek külön-külön mely döntéskor hogyan módosuljanak, akkor arra írhatok valamit.
Ha sok az elágazás és npc akkor arra külön leíró nyelvet kéne kitalálni, és egy fájlba leírni az egészet. Pl 23-as elágazás esetén:
23/b: Lucy love - hate, Bela hate - friend; 24/a: ...
De adhatsz neveket is az elágazásoknak. És ha nem akarod szövegesen írni a fájlt, akkor készíthetsz szerkesztőt, ahol az npc-k combobox-ban vannak stb.

   
Asylum - Törzstag | 5444 hsz       Online status #206194   2015.01.12 10:24 GMT+1 óra  
Józan paraszti ésszel egy (történet)gráfot kell építeni, és kiírni a mentésfáljba.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Instalok - Tag | 540 hsz       Online status #206193   2015.01.12 09:20 GMT+1 óra  
Adott egy főhős, akivel játszunk. Bizonyos eseményekkor dönthet 2, vagy több lehetőség közül, aminek következtében máshogy alakul(hat) a történetszál, más lesz az NPC-k hozzáállása (azaz egyik esetben Béla lehet, hogy a barátunk lesz, máskor pedig az ellenségünk). Nem tudom hogy hívják ezt, mi ennek a neve? Foglalkozott már valaki ilyesmivel - programozás szempontból? Hogy érdemes ezt szépen és kezelhetően (könnyen módosíthatóan, bővíthetően) megcsinálni?

   
FZoli - Szerkesztő | 4892 hsz       Online status #203142   2014.05.27 21:29 GMT+1 óra  
mondjuk androidon pont máshogy kell modellezni.

Asztalon jó egyszerűsítés a cutoutos textúra, nem gond a lightmap pass a shaderen,
mobilon inkább több vertex legyen, kevesebb (0) clippes textúra, vertexcolor amin csak lehet.
Egészen meglepő mennyiségű geometriát is visz egy közepes android vas, ha egyszerűek shaderek, és ugyanilyen meglepő módon esik a sebesség akár már +1 szorzással.
Unitys tapasztalat, de gondolom máshol is ez van.
   
glezmen - Törzstag | 381 hsz       Online status #203141   2014.05.27 21:19 GMT+1 óra  
Idézet
Fisher007 :Crysis azért szép mert iszonyat tehetséges művészek csinálták? Abszolút. Lehetne szép, ha csökkentenék a polygon számot jelentősen? Abszolút nem (a jelentőst kihangsúlyozva).



Es lehetne sokkal szebb ha novelnek a polygon szamot jelentosen?
Sok szempont letezik fejlesztesnel, az egyik ilyen hogy ne pazaroljuk az eroforrasokat. Ha megfeleloen megvalasztott parameterekkel (pl. polygonszammal) jol fut egy 10 eves hardveren is, akkor miert csinalnad ugy, hogy a legujabb vason is csak docogjon? Minel kevesbe eroforrasigenyes a program/jatek, annal tobb eszkozon lesz hasznalhato, annyival tobb potencialis usered/jatekosod van.

MOD: es pl. az androidos jatekok statisztikait nezegetve igenis realis igeny hogy gyengebb eszkozon is menjen a jatek
   
Geri - Törzstag | 2188 hsz       Online status #203140   2014.05.27 21:03 GMT+1 óra  
ellenpélda: online game 3d, ahol az userek milliárd polygonos nagyságrendben fogják lekattintani a pályát szélsőséges esetekben.

   
FZoli - Szerkesztő | 4892 hsz       Online status #203139   2014.05.27 20:31 GMT+1 óra  
Frissebbek | Korábbi postok
[1] > 2 < [3] [4] [5] [6] [7] [8] [9] [10] [15] [16]