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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2193
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1654
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [44]
Marcsello - Tag | 228 hsz       Online status #198518   2013.10.23 22:49 GMT+1 óra  
Manapság nagyon faja kis szerverek vannak, amik a leglaggosabb játékból is elvisznek 100-200 klienst is (csak ha mást nem futtatnak mellette) szóval egyenlőre ezen nem aggódom, mondjuk az én gépemen (Celeron M 1.7Ghz 2GB Ram) 5000 kockánál már valami szaggat, de szerintem csak a kirajzolásnál (lássuk csak, 5000x6 = 30000 polygon, nem is sok, de nem gáz) tehát csak a saját gépem teljesítménye korlátozhat meg ebben.
Most alkottam egy ko-számításos cuccost, aminek akármilyen hülye értékeket adok jól modellez, amit nem tudok hogy a továbbgondolt csomagküldés miatt van (ami mellesleg pont a várt eredményt nem hozza, mert még mindig kb. 570 bájtosak a csomagok, csak kicsit gyorsabbak), vagy mert működik, de a megjósolt ugrálással seholsem találkoztam amiről nem tudom, jó-e vagy sem. De az előző verzión ugyanannyi kockaszámmal beszaggat, (csak abban még a csomagküldés is a régi) szóval ezt majd nagy ping mellett kell tesztelnem, mégtöbb kockával, mert nem tudom eldönteni jó-e ez vagy sem...

Egyébként Lazarus-ban (FreePascal)-ban dolgozom. Azért a végére írtam, mert vannak akik meglátják, és nem olvassák tovább
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
StrykerKKD - Tag | 30 hsz       Online status #198516   2013.10.23 21:58 GMT+1 óra  
Én óvakodnék attól ,hogy túl sok mindent számoljon a szerver ,mert minél több a kliens annál többet kell a szervernek számolnia és egy idő után megharagszik a szerver.

Egyébként miben fejleszted a kísérletedet?
   
Marcsello - Tag | 228 hsz       Online status #198507   2013.10.23 17:06 GMT+1 óra  
igen ez megvan, inkább olyan megoldáson gondolkodom, hogy megy a szimuláció a kliens oldalon is, a teljes world-ről és a szerveren is megy ugyan ez. De a szerver folyamatosan küldi az infókat a world-ről, és ugyanúgy frissíti a kockákat. És kis mákkal így realtime fizika lesz, ami megegyezik mindenhun. Elméletben ez jó, de gyakorlatban ez valószínüleg ugrálni fognak a kockák (amikor megjön a hivatalos infó, és lecseréli a központira a helyit) mert én eddig ahányszor lefuttattam valamit, az mindig más eredményt hozott (Newton Game Dynamics-ot használok ).

Viszont most fennakadtam mégvalami, a max 50 bájtosnak ítélt csomagomról, kiderült, hogy 570 bájtos szóval nem csoda hogy lassan megy át, mert valami bug miatt string ként küldte át, ami a fogadó szempontjából mindegy volt, csak a csomag mérete nem mindegy. szóval erre megvan már a megoldás, szóval nem ez a lényeg, csak megjegyeztem .
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #198506   2013.10.23 16:12 GMT+1 óra  
Ami egyébként nem érdekes gameplay szempontjából, azt csak a kliens számolja nyilván. De a játékosok mozgása, nézési iránya, lövése, stb. tipikusan nem ilyen. Azt mind a kettő számolja.
A fáról lehulló alma (ha nincs gameplay-beli szerepe) csak kliens oldalon számolt. Mint pl. a ragdoll. Nekünk fordult már elő multizás közben, hogy észrevettük, hogy egy kicsit eltért a két kliens gépen az infó a halál pillanatáról, ezért más pozícióban kötött ki a test ragdoll után.

   
Marcsello - Tag | 228 hsz       Online status #198505   2013.10.23 14:44 GMT+1 óra  
Idézet
StrykerKKD :
Nem értem ,hogy miért nem lehet ezt csak kliens oldalon megcsinálni. Hiszen ez az 500 kocka gondolom mindig ugyan úgy esik le ,hogyha a kliens nem tud belezavarni. ...


Itt most nem az a lényeg, hogy ugyanúgy esik-e le, vagy sem, persze, bele lesz zavarva, de ez most még csak próbaképp esnek a kockák, persze, nem ez lesz majd a játékban, itt most csak tesztelem és amíg nem tökéletes, addig nem megyek tovább (a gömbökre )

jah, köszi, kipróbálom minél nagyobb csomagokkal is majd, mert ebben van valami, mert a legelső verzióban 16 csomag tartozott egy kockához. mondjuk így sem olyan nagyok a csomagok. 16x4byte + 1 byte + a többi(10-30 byte).
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
StrykerKKD - Tag | 30 hsz       Online status #198503   2013.10.23 13:17 GMT+1 óra  
Nem értem ,hogy miért nem lehet ezt csak kliens oldalon megcsinálni. Hiszen ez az 500 kocka gondolom mindig ugyan úgy esik le ,hogyha a kliens nem tud belezavarni.
Ha a kliens belezavarna az már más kérdés lenne. Akkor én úgy csinálnám ,hogy a belezavarás idejekor küldeném el az üzenetet a szervernek. és az pedig leellenőrizni ,hogy lehetséges-e az a művelet ,amit csináltam.

Másik észrevételem ,hogy inkább küldj 1 nagy üzenetet mint 500 kicsit.
Egy jó kiss cikk a témában

Egyébként én is gondolkodok egy jó kis valósidejű multi játékban csak nincs rá időm.
   
Marcsello - Tag | 228 hsz       Online status #198501   2013.10.23 12:22 GMT+1 óra  
tehát, gyakorlatilag mind a két oldalon számolunk, aztán ezt majd egységesítjük.
igazából ebben a pre-alfa-demo-prototype cuccban, csak annyi tôrténik hogy meghatározott számú kockákok leesnek, tehát, irányításról szó sincs még . csak ugye nálam minden kocka egy csomag, amit a szerver küld a kliensnek. Ebben van a mátrixa, meg még néhány plusz infó. És 5 kockánál ötször kiküldeni nem nagy kunszt (persze alacsony pingel) de ha van 500 kocka, az 500 csomagot jelent, ami már elég sok idő, mire végig ér mind az 500-on, persze nem vár vsenki választ a másiktól, annyi a visszacsatolás, hogy ha összeomlik a kapcsolat, akkor mind két oldalon jelzik, hogy lekapcsolódtak. tehát a ping annyira nem játszik közre, persze azért ha retek a kapcsolat, és elveszik néhány csomag, az azért már elég gáz, de ott még nem tartok teszetelés ügyileg.

A lényeg a lényeg, hogy nekem a szervertől visszajövő információkat kell folyamatossá tennem, hogy úgy tűnjön, nos...., mintha folyamatos lenne a kockák hullása, addig is, amíg végig ér mind az 500 kockán, mert úgy működik, hogy szervertől jön egy csomag, abban benne van a kocka azonosítója, meg a hozzá tartozó mátrix. Amint ezt a csomagot megkapja a kliens, szépen alkalmazza a mátrixot a hozzá tartozó kockára, és vár a következő csomagra (ez persze a képfrissítéstől, meg ezektől független) és ezt a végtelenségig csinálja. Ami mind szép és jó, csak 500 kockánál, egy adott kocka elég ritkásan frissül, és addig, amíg nem frissül, addig egyhelyben lebeg, vagy áll, vagy ilyesmi, és ez szemmel láthatóan nem az igazi. Szóval két frissítés között kell valamit kezdeni vele, hogy úgy tűnjön mint ha mozogna, de a következő frissítésnél ne a szomszédba ugorjon át az adott kocka. Vagy, ha kell az egész megoldást újra írni (mivel a jelenlegit én kombináltam ki saját kútfőböl) hogy más adatokat máshogy küldjön.
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
Pretender - Törzstag | 2498 hsz       Online status #198500   2013.10.23 11:46 GMT+1 óra  
Vannak rá különféle technikák, de az alap általában a következő szokott lenni:

Alap esetben a kliens csak kontrol információkat küld át a szervernek (pl. melyik billentyű lett lenyomva, én most éppen előre akarok menni, egér pozíció esetleg, ilyesmik). Ez ugye addig jól működhet, amíg nagyon kicsi a latency, és kb. csak 1-2 player van bent. Amint egy kicsit növekedik, már erőteljes késés figyelhető meg. Ugyanis a kliens nem számol pozíciót, hanem amit leküldött infót, abból a szerver számolja ki, majd küldi vissza - ezzel elkerülve az "ugrálós" csalásokat pl.
Csak ugye a nagyobb latency / több player miatt ez nem jó megoldás: lenyomod az előre haladás billentyűt, de csak fél-1mp-el később indulsz el. Ez nyilván nem elfogadható.

Azonban van egy client-side prediction-nek nevezett dolog. Ez nagyjából annyit tesz, hogy a kliens is számolja a saját pozícióját, és egy bizonyos tresholdig azt használja. Természetesen a kontrol infók ugyan úgy lemennek a szervernek, és ugyan úgy ad vissza választ. Ekkor a szervernek bele kell számolnia a késést, azt, hogy mennyi idő múlva érkezik vissza a klienshez a csomag, stb. Igazából egy ~becslést ad arra, hogy a játékos x idő múlva (mire megkapja a választ) hol lesz majd.

A kliens oldalról ez úgy néz ki, hogy mivel magadnak is számolod a transzformációdat, az indulás azonnali lesz (nem kell a válaszra várni), viszont a szerver egy bizonyos tűréshatáron felül felülbírálja a pozíciódat. Azaz ha írsz egy olyan hack programot, amivel 10x gyorsabban szaladsz (kliens oldalon), és mondjuk kikötsz a (0,0,100) pontban, de a szerver szerint a (0,0,10)-ben lehetsz csak, akkor szépen visszadob a (0,0,10)-be, mert a bizonyos tűréshatáron túlmutatott a diff.

Nem biztos, hogy sikerült elmondani, amit akartam, de azért remélem valamennyire érthető lett. Client side prediction - erre találni fogsz pár cikket is.

   
Marcsello - Tag | 228 hsz       Online status #198499   2013.10.23 11:33 GMT+1 óra  
Hello mindenki, a napokban sokat gondolkodtam azon, hogy vajon a "profi" meg egyébként is a legtöbb játékban, hogy van megoldva a fizikai modellezés multiplayer-en. Jelenleg nálam a teljes modellezés szerver oldalon folyik, és csak a kirajzoláshoz szükséges mátrixokat küldöm a klienseknek. Ez 5 kockával (mert csak kockák vannak benne) nagyon jól is működik, de 500 kockával már elég látványosan szaggat. Szóval itt valami kliens oldali huncutságnak is kell lennie, vagy valami más módszerrel alkotnak folyamatosságot, de vajon mivel......?
Az élet szép, csak tele van Bugokkal
http://marcsello.com/
   
ddbwo - Tag | 1654 hsz       Online status #198480   2013.10.21 22:51 GMT+1 óra  
Idézet
Torrents :
és ha én magasról indítom az sem emészt fel több erőforrást?



Az attól függ, hogy mennyi mindent lehet látni, vagy kell szűrni egyszerre. Üres sivatagban majdnem mindegy, tömött városnál ki kell szűrni a sok polygont.
Meg általában az néz ki jól messziről, amit direkt úgy terveznek, hogy messziről kell nézni. Ha nem trükköznek és nem a fekete kép alatt töltik be, mint ennél, akkor LOD-okat használnak. Közel érve lecserélődik minden a memóriába töltött cuccokkal. Meg vsz egy kis négyzet terrain nem lenne valami szép fentről, a nagy kocka terrain meg költséges.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Torrents - Tag | 79 hsz       Online status #198479   2013.10.21 19:48 GMT+1 óra  
Idézet
fpeti :
Idézet
Torrents :
Sziasztok azon töprengek hogy mint a halo 3-ban : http://youtu.be/N0tUabllApw?t=6m12s a játékos valóban olyan rohadt magasról indul, vagy ez máshogy van megoldva?


Mivel egy ablakon keresztül nézi a dolgokat, akár egy renderelt filmet is lejátszhatnának mögötte,és arra raknák a ablak/fülke geometriáját. vagy csak simán elmozgatják az ablak előtt a dolgokat szkriptekkel és kész. Mivel vágás van a leérkezéskor, nagyon valószínű, hogy csalnak.



és ha én magasról indítom az sem emészt fel több erőforrást?

   
fpeti - Törzstag | 1295 hsz       Online status #198478   2013.10.21 19:33 GMT+1 óra  
Idézet
Torrents :
Sziasztok azon töprengek hogy mint a halo 3-ban : http://youtu.be/N0tUabllApw?t=6m12s a játékos valóban olyan rohadt magasról indul, vagy ez máshogy van megoldva?


Mivel egy ablakon keresztül nézi a dolgokat, akár egy renderelt filmet is lejátszhatnának mögötte,és arra raknák a ablak/fülke geometriáját. vagy csak simán elmozgatják az ablak előtt a dolgokat szkriptekkel és kész. Mivel vágás van a leérkezéskor, nagyon valószínű, hogy csalnak.
   
Torrents - Tag | 79 hsz       Online status #198477   2013.10.21 19:07 GMT+1 óra  
Sziasztok azon töprengek hogy mint a halo 3-ban : http://youtu.be/N0tUabllApw?t=6m12s a játékos valóban olyan rohadt magasról indul, vagy ez máshogy van megoldva?

   
StrykerKKD - Tag | 30 hsz       Online status #198475   2013.10.21 18:33 GMT+1 óra  
Idézet
husudosu :
....



Ha Linuxon akarsz C#-pal fejleszteni akkor majdnem biztos ,hogy Mono-t kell használnod.
Gyakorlatilag könnyű a választás ,mert csak monogame az ,amit tudnál így használni. Mást nem találtam.
   
glezmen - Törzstag | 381 hsz       Online status #198474   2013.10.21 18:02 GMT+1 óra  
Idézet
husudosu :
Hali!

Szeretnék játék fejlesztéssel foglalkozni (hobbi szinten), viszont nem tudom hogy milyen motorral lenne érdemes foglalkoznom. Van tapasztalatom C# programozásban, tehát olyat szeretnék ami:
- C# nyelven tudok alkalmazást írni
- Egyszerűen tanulható
- Linux kompatibilis fejlesztőeszközök vannak hozzá

Köszi előre is a segítséget!



C# es Linux? ezt hogy hoztad ossze?
ettol meg nem lehetetlen persze, de erosen beszukitetted a lehetosegeidet...
Elegge adna magat a Unity, de sajnos az meg mindig hadilabon all a Linuxszal
   
husudosu - Tag | 1 hsz       Online status #198473   2013.10.21 17:07 GMT+1 óra  
Hali!

Szeretnék játék fejlesztéssel foglalkozni (hobbi szinten), viszont nem tudom hogy milyen motorral lenne érdemes foglalkoznom. Van tapasztalatom C# programozásban, tehát olyat szeretnék ami:
- C# nyelven tudok alkalmazást írni
- Egyszerűen tanulható
- Linux kompatibilis fejlesztőeszközök vannak hozzá

Köszi előre is a segítséget!

   
Ravic_IV - Tag | 2 hsz       Online status #198466   2013.10.21 09:49 GMT+1 óra  
Sziasztok Mindenki!

Új vagyok errefelé. Gondolom itt is illik bemutatkozni az újaknak.

2 évig voltam Game designer egy brovseres startégiai játéknál, most sima php, js, css ilyesmi fejlesztgetéssel foglalkozom.

Szívesen foglalkoznék újra játék fejlesztéssel... Asszem ennyi

   
Tunyu - Tag | 449 hsz       Online status #198429   2013.10.18 20:14 GMT+1 óra  
Módosítanom kellett az AddForce-t AddRelativeForce-ra,eddig nem figyeltem hogy a globális tér irányában repítettem.Finomítottam a gyorsuláson is,és számolgattam kicsit.Ha minden igaz simán csinálhatok egy 8 köb exameter méretű teret,de ez még mindig kevés ahoz hogy a föld és a hold egy pályán legyen.De az is lehet hogy tudok 8000 köb exameter méretű teret,de akkor a kamera a ParticleSystem kezelése már nehézkes lenne,de viszont akkor már a hold benne lenne.

   
ddbwo - Tag | 1654 hsz       Online status #198422   2013.10.18 18:32 GMT+1 óra  
Ja, ja. Pontosabban nullával nem szabad osztani.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Pretender - Törzstag | 2498 hsz       Online status #198412   2013.10.18 06:12 GMT+1 óra  
Idézet
ddbwo :
Meg nullát nem szabad osztani. Az hibás művelet.


Nullát szabad osztani.
Nullával nem.

   
Tunyu - Tag | 449 hsz       Online status #198411   2013.10.18 04:24 GMT+1 óra  
Mióta kivettem a meghajtásból az időt (Time.deltaTime) azóta gyorsul ilyen durván addig egyenletes volt.Majd finomítok rajta.A játék fps-e jó, a gpu minimális kihasználtsága melett 80-100fps.De ahogy itt olvasgattam ha elkészül lehet 10fps alatt lesz majd a néhány száz objektum miatt. Csak a videó lett kicsit gyatra pedig felvettem 20 képkockára,de a felvevő eléggé zabálja a gépem az unity mellett.

Ezt a hozzászólást Tunyu módosította (2013.10.18 04:33 GMT+1 óra, ---)

   
ddbwo - Tag | 1654 hsz       Online status #198408   2013.10.17 22:50 GMT+1 óra  
jó ez. Általában azért érdemes átállni fixedUpdate-re, hogy egyenletes legyen a force adagolása is. Olyankor csak a deltaTime helyett (1.0/60.0)-al kell pl szorozni. Vagy ahány frame/sec van.

Meg nullát nem szabad osztani. Az hibás művelet. A Unity nem tudom figyeli-e...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198406   2013.10.17 21:10 GMT+1 óra  


Jelenleg így működik.

Ezt a hozzászólást Tunyu módosította (2013.10.17 21:27 GMT+1 óra, ---)

   
ddbwo - Tag | 1654 hsz       Online status #198404   2013.10.17 20:17 GMT+1 óra  
Jó, mindegy. annyira nem számít. Ha jó, akkor jó. A többi nem lényeg.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198403   2013.10.17 20:11 GMT+1 óra  
Na jó, nekem ez már kicsit bonyolult.Ha nagyon akarod foglakozhatsz vele, de nekem így is jó ahogy van /pillanat. Nagyobb tömegek mozgatásánál lehet etűnik majd az a kis sebesség túllépés.

   
ddbwo - Tag | 1654 hsz       Online status #198402   2013.10.17 20:03 GMT+1 óra  
Az az osztály cuccaitól függ. Hogy private vagy public. Meg lehet kötni, hogy mi legyen módosítható. A minta meg azt követi.

Pl. ha a magnitude-t csak kiszámolja a folyamat közbe és nem az a kiinduló pont, akkor private és nem hiszed azt, hogy számít. Lehet, hogy vector-ként van a force valahol. A magnitude meg a hossza.
---

"valahol"... most néztem csak rendesen. a velocity a vektor, és annak a hossza lesz a magnitude.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198401   2013.10.17 19:59 GMT+1 óra  
Igen jól sejtettem,már mikor olvastam a kódot akkor volt egy olyan érzésem hogy nem fog működni mivel a magnitude csak olvasható,de azért biztos ami biztos kipróbáltam, és sajnos nem működött.
Persze nem is olyan könnyű így ez a dolog,gondolom java és java közt is van külömbség.
Annyira nem is fontos hogy pontos legyen,első játéknak indul és ki csinál tökéletest elsőnek.
Na meg később még csiszolgatok rajta így is hol ezt hol azt csinálom benne.Próbálok egy kis videót csinálni róla de mivel nem nagyon bika a gépem,és még a codeket sem tudtam kiválasztani így néhány másodperc 200+Mb.

Ezt a hozzászólást Tunyu módosította (2013.10.17 20:08 GMT+1 óra, ---)

   
ddbwo - Tag | 1654 hsz       Online status #198400   2013.10.17 19:39 GMT+1 óra  
Nem gondoltam végig, hogy mi akar lenni, de a kód alapján ez jönne ki matek szerint gyors szemlével:
Kód:
if(speed >= maxspeed * throttle)
{
    rigidbody.velocity.magnitude = maxspeed * throttle * Time.deltaTime;
    speed = rigidbody.velocity.magnitude / Time.deltaTime;
}


Ha a lenti működik...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198399   2013.10.17 19:30 GMT+1 óra  
És ezt te hogy érnéd el hogy maximumon legyen a sebesség? Nekem nem olyan egyszerű a nyomatékot kezelni mintha csak simán térben tologatnám.

   
ddbwo - Tag | 1654 hsz       Online status #198398   2013.10.17 19:24 GMT+1 óra  
Vagy mi. Kimaradt egy kis részlet. Ha túllépi a maximumot, akkor be is állíthatod a sebességet maximumra. Ha nem akarod megengedni, hogy gyorsabb legyen...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198397   2013.10.17 19:23 GMT+1 óra  
Ha jól értelmezem akkor azt akarod mondani hogy ha még értenék hozzá akkor sem tudnám egyenlőre kihozni.

   
ddbwo - Tag | 1654 hsz       Online status #198396   2013.10.17 18:55 GMT+1 óra  
A FixedUpdate lényege, hogy fix időközönként megtörténik. Erre azért van szükség, mert ha leakad a gép, akár át is ugorhat több falat például egy kocsi.

A deltaTime. idő különbséget jelent. A legutóbbi frissítés óta eltelt idő. Ami azért lényeges, mert a használata nélkül attól függ például a kocsi sebessége, hogy milyen gyors a PC-d.

FixedUpdate-nél a fix egység időre kell számolni, mivel maga az esemény fix időközönként történik.
---

A RigidBody fizikája a háttérben autómatikusan fixedUpdate-et használ. De az erő módosítások így nem fixek.
---

Kód:
(speed >= maxspeed * throttle)

Nagyobb vagy egyenlő. Ha átugrotta, akkor is érvényes. És működik a <= is. Illetve < vagy >

Ezt a hozzászólást ddbwo módosította (2013.10.17 19:08 GMT+1 óra, ---)
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
   
Tunyu - Tag | 449 hsz       Online status #198395   2013.10.17 18:05 GMT+1 óra  
speed = rigidbody.velocity.magnitude / Time.deltaTime; Ez az aktuális sebességet mutatja és nem az eltelt idővel mert akkor Time.time lenne.De az is lehet hogy tévedek,nem vagyok programozó. A FixedUpdate vagy sima Update igazából szerintem semmit nem számít,legalább is a program ugyan úgy fut. Végül sikerült megoldanom a sebesség tartást egy egyszerű módszerrel,igaz nem teljesen pontos egy kicsit mindíg nagyobb a sebesség mint ahogy a gázkar áll de ennyi belefér.
Kód:
if(speed >= maxspeed * throttle){
impulse = 0;
}
else {
impulse = throttle;
}

Teljesen egyenlőre nem tudom kihozni (speed == maxspeed * throttle) , mert akkor átugorja valamiért, lehet hogy a sebesség olyan gyorsan változik hogy mire újra lefut a program már átlépi a sebességhatárt .
Az sem kizárt hogy int-t kéne alkalmaznom és nem float-ot akkor lehet pontosan lehetne használni.

Ezt a hozzászólást Tunyu módosította (2013.10.17 19:25 GMT+1 óra, ---)

   
Elodin - Tag | 180 hsz       Online status #198393   2013.10.17 15:45 GMT+1 óra  
c/c++ háziaim sdl-ben összerakott bombermanszerűségek voltak. Ott fix volt a pálya, és hogy optimálisan fusson, úgy oldottam meg, hogy a pálya adott, és mindig csak azt a részt rajzoltam újra a képből, ami változott.

Most java-ban a swing library-t kell használni. Nagyjából ugyanaz a kategória teljesítményügyileg, mint az sdl, ha jól tudom. Az a kérdés, hogy az alap primitíveket (kitöltött téglalap mondjuk) mennyivel rajzolja optimálisabban, mint ha képekből másolgatom össze? Tehát ha a terep mondjuk kitöltött négyzetekből áll, és csak a karakter betöltött kép, akkor egy oldalnézetes játékot el tud vinni úgy értelmes felbontással, hogy folyamatosan az egész képet újra kell rajzolni? Mert ha nem fixálom le a pálya méretét a képernyő méretére, akkor ugye a terep is, tehát minden újrarajzolásra szorul.

Szerk.: mindegy, megpróbálom. Max addig csökkentem a felbontást, amíg el nem döcög a laptopomon is...

Ezt a hozzászólást Elodin módosította (2013.10.17 18:09 GMT+1 óra, ---)

   
StrykerKKD - Tag | 30 hsz       Online status #198391   2013.10.17 14:26 GMT+1 óra  
Szerintem vezess be egy gyorsulás változót. Sokkal áttekinthetőbb lesz akkor a kód.

Először azt hittem ,hogy a speed a gyorsulás ,emiatt:
speed = rigidbody.velocity.magnitude / Time.deltaTime;
De wikipédián elolvastam ,hogy a gyorsulás az a sebesség különbség osztva eltelt idővel és ez meg csak aktuális sebesség osztva eltelt idővel.

Egyébként érdemesebb FixedUpdate-et használni sima Update helyett , ha addForce-ot használsz.
Forrás
   
Tunyu - Tag | 449 hsz       Online status #198383   2013.10.17 05:54 GMT+1 óra  
Nem írtam teljes magyarázatot a kódhoz sajnos. A maxStartSpeed ,minStartSpeed,startSpeed,afterburner-t nem kell figyelembe venni az csak egy látványelemhez van maga a lágcsóva a rakéta után ami különböző gázállásokra reagál.Az idő fontos tényező itt mert a gázkarnál elérem vele hogy fokozatmentesen lehessen növelni és csökkenteni ,igaz a meghajtásnál már tényleg felesleges volt. A translation példával az a gond hogy az egy állandó sebességet ad,de viszont semmit nem vesz figyelembe,ellentétben a Force-val ami nyomatékot ad a a rakétának így egyenletes gyorsulást ér el,és figyelembe veszi a tömeget is, tehát ha nagyobb a tömeg lassabban gyorsul.

   
StrykerKKD - Tag | 30 hsz       Online status #198381   2013.10.16 23:41 GMT+1 óra  
Nem vagyok Unity fejlesztő ,ezt hozzáfűzzön, habár Javascripthez értek.

Nem ártana a kód részleteket inkább pastebin vagy gist-re felrakni ,mert úgy átláthatóbb lenne az egész.
Egyébként debuggoláshoz ajánlom a gumi kacsa módszert ,vagyis próbáld elmagyarázni ,hogy hogyan is működik a kódod egy gumi kacsának. Meglepően jó módszer.

Másik módszer ,hogy kiíratod ,hogy a gázállás értékeit ,illetve azokat a változókat ,amik azt befolyásolják.

Amit eddig észrevettem az ,hogy sebességhez miért adsz hozzá időt ,illetve miért vonsz ki?
Na meg a gázállásnál is ugyanez hmmm.

Itt egy egyszerű példa

Így ebben az esetben translation = Time.deltatime * speed és speed = maxspeed * throttle és 20% gázadás esetén throttle értéke 0.2 .
Ha besegít az afterburner akkor szerintem elég a speed értékét megváltoztatni.
Akkor a speed tárolná az aktuális sebességet.
   
Tunyu - Tag | 449 hsz       Online status #198377   2013.10.16 22:05 GMT+1 óra  
Sziasztok! Néhány napja belefogtam egy játék készítésébe, amit már régóta tervezgettem,de most picit meg akadtam és segítséget kérnék ha lehet.Előre szólok sosem tanultam programozást,így nagyon sokat ne várjatok el a külalakban vagy bármi másban. A problémám az hogy egy rakéta meghajtásánál szeretném elérni azt hogy pl.: a 20%-os gázállásnál a maximum sebesség 20%-át érje el és ne tartson állandóan a maximum sebesség felé.Beírok egy régebbi kódot, az alap ugyan az de már nem ezt használom.Ja és Unity3D (Js). Ha tudtok, segítsetek. Előre is köszönöm.
Kód:
#pragma strict
var afterburner:ParticleSystem;
private var startSpeed:float;
var maxStartSpeed:float = 1;
var minStartSpeed:float = 0;
var engine:Transform;
var throttle:float = 0;
var throttleX:float = 1;
private var maxThrottle:float = 1;
var speed:float = 0;
var maxspeed:float = 3.2;
var engineOn = false;
var H2 = false;
var O2 = false;
var power = false;


function Update () {
afterburner.enableEmission = false;
if (speed >= maxspeed) {
throttle = 0;
}

if (Input.GetKey(KeyCode.LeftShift)){
afterburner.startSpeed = afterburner.startSpeed + Time.deltaTime;
if (afterburner.startSpeed >= maxStartSpeed) {
afterburner.startSpeed = maxStartSpeed;
}
if (throttle >= maxThrottle) {
  throttle = maxThrottle;
   }
throttle = throttle + Time.deltaTime;
}
if (power) {
if (engineOn) {
  if (H2) {
   if (O2) {
   afterburner.enableEmission = true;
   
rigidbody.AddForce(Vector3.forward * throttle *Time.deltaTime * throttleX);
    }
   }
  }
}
if (Input.GetKey(KeyCode.LeftControl)){
afterburner.startSpeed = afterburner.startSpeed - Time.deltaTime;
if (afterburner.startSpeed <= minStartSpeed) {
afterburner.startSpeed = minStartSpeed;
}
throttle = throttle-Time.deltaTime;
if (throttle <= 0) {
throttle = 0;
  }
}
speed = rigidbody.velocity.magnitude / Time.deltaTime;
}

Ezt a hozzászólást Tunyu módosította (2013.10.17 19:24 GMT+1 óra, ---)

   
glezmen - Törzstag | 381 hsz       Online status #198359   2013.10.16 09:42 GMT+1 óra  
Idézet
Pretender :
A cégnél Xperia Arc S-el rohangál néhány ember, és az is akadozik. Mármint úgy az alap oprendszer. Például át akarok görgetni egyik ablakból a másikba. Akadással megy át. Meg akarom nyitni pl. a kamerát. Hát, várnom kell rá 5-10mp-et biztosan.


Az Xperia Arc S azert nem mai telefon, nem is kifejezetten 2013-as hardware-rel. Az teny hogy az Android idovel be tud lassulni, foleg ha az ember csak pakolja fel ra az appokat esz nelkul, de azert 2 ev az eleg hosszu ido.
Az en 140 dollaros Lenovom teljesen jol teljesit
A Java meg... en mar a 'butafonos' idoben sem ertettem hogy miert pont Java, amikor a nagyon gyenge prociknak az mar komoly terheles, es a kulonfele kijelzofelbontasok miatt amugy sem voltak igazan hordozhatoak az alkalmazasok. A mai hardware-eknel ez mar kevesbe problema, raadasul a sebessegkritikus reszek amugy is nativ kodban vannak megirva
   
Pretender - Törzstag | 2498 hsz       Online status #198358   2013.10.16 09:36 GMT+1 óra  
A cégnél Xperia Arc S-el rohangál néhány ember, és az is akadozik. Mármint úgy az alap oprendszer. Például át akarok görgetni egyik ablakból a másikba. Akadással megy át. Meg akarom nyitni pl. a kamerát. Hát, várnom kell rá 5-10mp-et biztosan.
Tesztekkel bizonyítható lenne, hogy a Java lassabb, mint valami natív kód. Eleve ott ketyeg a háttérben a JVM, ami interpretálgatja a kódot. Na de nem is lényeg, egy kezdőnek biztosan nagy segítséget jelent, hogy cserébe viszont rengeteg minden van benne.

   
pendrivedealer - Tag | 19 hsz       Online status #198341   2013.10.15 17:07 GMT+1 óra  
Sziasztok!
Nekem egy Game Maker 8.1-esem van, és most kezdek belekóstolni a játék készítésbe.
Már sikerült készítenem egy 10 pályás faltörős játékot.
Most úgy gondoltam, hogy megpróbálok egy zuhatag játékot készíteni, de valahogy nem tudok hozzákezdeni.
Tudtok nekem segíteni?
Esetleg valami segédanyag létezik a témába?

Előre is köszönöm

   
Matzi - Szerkesztő | 2524 hsz       Online status #198336   2013.10.15 12:59 GMT+1 óra  
Pretender:
Az én telefonom nem volt 200 ezer, de mégis jó. Az iPhone meg még drágább is volt, de a régiek mégis lassúak. Sajnos a számítástechnika olyan ágazat, ahol fontos a hardver. A régi és az olcsó általában gyenge, nem érdemes őket az újhoz és a drágához mérni. Viszont nem is a java miatt lassú.
Mellesleg egy beugró szintű telefonnál is elég tűrhetően mennek az alap alkalmazások, a játékok meg nem javában íródnak, az nem azért lassú.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Pretender - Törzstag | 2498 hsz       Online status #198335   2013.10.15 12:45 GMT+1 óra  
Idézet
DMG :
Idézet
Pretender :
Java-t nem ajánlom, ha tényleg játékfejlesztés érdekel. Nem véletlenül lassúak, akadoznak az androidos telefonok...


Ezt kifejthetnéd, mikor akadoznak az androidos telefonok? Csak nem arra gonodlsz, hogy a 20.000 forintos belépő android nem annyira gördülékeny, mint a 200.000 ezres IPHONE? Na ettől kapok agyhugykövet, talán a felső kategóriát kéne összehasonlítani, máris nincs akadás. Ha PC-ről beszélünk akkor egyértelműen el lehet felejteni a Java-t, de azért androidnál használható nyelv, okosan kell használni.


Ha egy 200 ezer ft értékű hardware-t kell vennem ahhoz, hogy elfogadhatóan menjen (mondjuk akadás-mentesen), akkor ez továbbra sem egy jó rendszer.

   
Matzi - Szerkesztő | 2524 hsz       Online status #198334   2013.10.15 11:05 GMT+1 óra  
Idézet
Java-t nem ajánlom, ha tényleg játékfejlesztés érdekel. Nem véletlenül lassúak, akadoznak az androidos telefonok... de ez most mindegy.
Az én androidos telefonom (S3) nem akadozik. Ráadásul androidra is többnyire c++ban írják a játékokat. Harmadrészt meg nem lassú a java, csak úgy kell méretezni. Kezdésnek a java egyszerűség hatalmas előny tud lenni, akkor is ha játékot fejleszt az ember.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Seeting - Törzstag | 2306 hsz       Online status #198333   2013.10.15 10:53 GMT+1 óra  
Idézet
DMG :
Csak nem arra gonodlsz, hogy a 20.000 forintos belépő android nem annyira gördülékeny, mint a 200.000 ezres IPHONE? Na ettől kapok agyhugykövet, talán a felső kategóriát kéne összehasonlítani, máris nincs akadás.



   
Parallax - Tag | 603 hsz       Online status #198332   2013.10.15 07:48 GMT+1 óra  
Idézet
DMG :
Ha PC-ről beszélünk akkor egyértelműen el lehet felejteni a Java-t, de azért androidnál használható nyelv, okosan kell használni.


Pont fordítva. PC-nél van elég teljesítmény ahhoz, hogy a Java, vagy más managed rendszer * lassúságát elfedje a mobil viszont gyenge hardver ott nem érdemes pazarolni az erőforrásokat feleslegesen.

*újabban a .NET is egyre inkább az interpreter felé halad -már nem generál natív kódot- lehet a Java is ebbe az irányba halad, mert üzleti programoknál ez nagy rugalmaságot tesz lehetővé (debug módban kód módosítás és tovább futtatás), ugyanakkor egy játékmotornál mind a memória kezelés, mind a futtatás milyensége elfogadhatatlan, de a logikai részhez ott a LUA.

   
pendrivedealer - Tag | 19 hsz       Online status #198323   2013.10.14 17:13 GMT+1 óra  
Sziasztok!


Nemrég készítettem Game Makerel egy kicsi faltörős játékot, megspékelve egy kis kvízjátékkal!
Egy barátom megpróbálta kirakni a Weboldalára (direkt neki készült, ezzel akarja népszerűsíteni a honlapját), a játék el is indul, de a mentési pontok, amire rá kell kattintani, nem működnek, így nem lehet menteni.
Valamint, a játék nem ér véget, ha elfogy a golyó, hanem mínuszba kezd el számolni.
Ha exe-be mentem, és feltelepítem a gépre, akkor minden tökéletesen működik.
A kérdésem az, hogy ez miért van?
Valaki tapasztalt már ilyen hibát?
Meg lehet oldani a mentést?
Lehet az a probléma, hogy a weboldal eredetileg nem Html 5, hanem asszem 4-es, vagy 4.5-es? Az Explorer nem is indítsa el mert azt írja ki, hogy nem kompatibilis, a Firefoxnál elindul, csak nem ment.
Elnézést kérek, weboldalra még sose raktam fel játékot.

Előre is köszönöm a választ.

Üdv Dániel

   
Levente - Tag | 24 hsz       Online status #197025   2013.08.30 08:07 GMT+1 óra  
Köszönöm a tanácsokat akkor úgy néz ki c++ tanulás jön.

   
DMG - Szerkesztő | 3172 hsz       Online status #197024   2013.08.30 06:27 GMT+1 óra  
Idézet
Pretender :
Java-t nem ajánlom, ha tényleg játékfejlesztés érdekel. Nem véletlenül lassúak, akadoznak az androidos telefonok...


Ezt kifejthetnéd, mikor akadoznak az androidos telefonok? Csak nem arra gonodlsz, hogy a 20.000 forintos belépő android nem annyira gördülékeny, mint a 200.000 ezres IPHONE? Na ettől kapok agyhugykövet, talán a felső kategóriát kéne összehasonlítani, máris nincs akadás. Ha PC-ről beszélünk akkor egyértelműen el lehet felejteni a Java-t, de azért androidnál használható nyelv, okosan kell használni.
-----------------------------------------
Dont Listen to the Naysayers
   
Pretender - Törzstag | 2498 hsz       Online status #197023   2013.08.30 06:21 GMT+1 óra  
Java-t nem ajánlom, ha tényleg játékfejlesztés érdekel. Nem véletlenül lassúak, akadoznak az androidos telefonok... de ez most mindegy. Ráadásul c++al lehet androidra is fejleszteni.

Magyar könyvekkel nem érdemes foglalkozni: vagy elavultak, vagy hülyeségeket írnak. Az alapokra esetleg jó lehet, ahhoz viszont a c#-ot is beizzíthatod.
Azon megtanulod az alapokat (változó, függvény, osztály, öröklődés, stb.) - ott sokkal jobban rá is vagy kényszerítve ezekre, nem lehet mindenféle globális vackokkal dobálózni.

Ha ezeket az alapokat biztosnak érzed, el lehet kezdeni "tanulni a c++"-t, ami az eddigiekhez képest annyiból állna, hogy meg tanulod, mi az az érték szerinti, pointer, referencia, stb., miért kell headert használni, illetve milyen nyelvi elemekkel gazdagabb a c++ a többi c-s nyelvnél (beleértve a Java-t, mert az szintaxira néhány különbséggel egy az egyben c# - vagy fordítva ).

Miután megvan egy stabil alap (tehát ha kell, tudsz magadtól írni egy jó kis konzolos alkalmazást, egyéb), akkor lehet csak utánajárni az engine fejlesztésnek. Arról meg később

   
Frissebbek | Korábbi postok
[1] [2] [3] > 4 < [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] [44]