Archief - [ALG]java javagames

Ik kan java ongeveer, maar nu zit ik met de vraag hoe ik nu kan beginnen met games te maken (3D).
Wat ik daar voor nodig heb en op wat ik moet letten enzo..

Zembla

Java3D heb je nodig (best zoek je de officiele tutorial van sun om het te leren).

Als je de OO-structuur van Java goed doorhebt kan je misschien C++ leren, daar is veel meer documentatie voor beschikbaar toegespitst om het maken van games.

De meeste mods zijn geschreven in C++, trouwens.

Ik wil nu niet beginnen zagen, maar zou je niet beter met wat eenvoudige games beginnen, als je "Java ongeveer kunt"? Minesweeper, een schuifpuzzel, Tetris, Space Invaders, ... Daar komt meer bij kijken dan je denkt hoor.

Persoonlijk zou ik ook beginnen met een aantal 2D games, om de algemene concepten te leren kennen.
Als je een 3D java game wenst te maken dan kan je naast Java3D ook gebruik maken van opengl voor java ofwel jogl. Dit is beter dan Java3D omdat efficiënter is en vooral omdat het een algemeen aanvaarde library is om 3D engines mee te maken, de tegenvariant van directx.
Je start ook best met een java 3D engine ipv er zelf één te schrijven. De enige java 3D engine die ik ken heet jmonkeyengine en is te vinden op www.jmonkeyengine.com. Er staan ook een aantal demo's op.

Groeten

Forceflow zei:

Als je de OO-structuur van Java goed doorhebt kan je misschien C++ leren, daar is veel meer documentatie voor beschikbaar toegespitst om het maken van games.

De meeste mods zijn geschreven in C++, trouwens.

Klik om te vergroten...

Voor basis java games vind je ook al redelijk wat info, en das nog steeds zeer handig om het concept "gamedevelopment" uit te leren, want in 1-2-3 een 3D game maken is niet simpel tenzij je er al een tijdje mee bezig bent.

Dus, zoals gezegd: 2D gamepjes proberen (begin me pong, dan iets zoals space invaders, ...).

Naar 3D overschakelen: je kan ook in java blijven ze, maar dan zou ik opteren om opengl met java te gebruiken ipv java3D . Als je echt naar advanced 3D stuff wilt zal je wrsch wel moeten overschakelen naar C++ (of bv. c++ voor onderliggende engines en dan bindings verzorgen naar java voor de gewone game-logica), maar voor amateur-games kun je er denk ik nog vlot geraken met java + opengl binding.

Aanvulling op hierboven: je start idd best op een bestaande enigne als je het puur op gamedevelopment te doen is. Als je ook zwaar geïnteresseerd bent in de iets meer onderliggende zaken ivm rendering bv. kan je altijd achteraf een eigen engine proberen maken (let wel: zelfs dan nog is het vrij handig te beginnen met een bestaande engine!)

Kent er hier iemand eigenlijk sites met informatie over gamegenres en hun achterliggende logica? Ik ben dus niet op zoek naar echte code, maar naar de principes die erachter zitten, bijvoorbeeld hoe collision detection in 2D platform games gebeurt.

forloRn_ zei:

Kent er hier iemand eigenlijk sites met informatie over gamegenres en hun achterliggende logica? Ik ben dus niet op zoek naar echte code, maar naar de principes die erachter zitten, bijvoorbeeld hoe collision detection in 2D platform games gebeurt.

Klik om te vergroten...

dmv vormen (of als je echt detail wilt -> pixel detection).

Simpelste -> rechthoek rond uw object.

Ma ge kunt verschillende zaken gebruiken eh (mathematisch toch ).

Op gamedev.net vinde daar wel wat artikels over, ze zitten enkel soms goed verstopt ^^, das vaak wel met vb code natuurlijk, maar ze hebben het voordeel van een extreem grote db met vaak extreem uitgebreide artikels, geschreven door mannen dat er al wat van kunnen .

Voor jouw vraag zou ik hier beginnen zoeken, das algemeen game progging.

Bedankt voor de link.

Wat jij daar noemt vind ik overal, en dat is dus geen collision detection. Als twee objecten in elkaars richting vliegen tegen hoge snelheid, vliegen ze "door" elkaar, zonder dat er ooit overlapping heeft plaatsgevonden, en dan wordt de botsing niet opgemerkt.

forloRn_ zei:

Bedankt voor de link.

Wat jij daar noemt vind ik overal, en dat is dus geen collision detection. Als twee objecten in elkaars richting vliegen tegen hoge snelheid, vliegen ze "door" elkaar, zonder dat er ooit overlapping heeft plaatsgevonden, en dan wordt de botsing niet opgemerkt.

Klik om te vergroten...

Hoe bedoel je?

dat je zoiets krijgt (A en B zijn objecten)

Sit1:

A --> <--B

Sit2:
AB

Sit3:
<--BA-->

En dat je game de collision niet detecteert omdat het te snel gaat of zo (dus de botsing tussen 2 en 3 vindt in de gameengine niet plaats).

Das idd wel een probleem , dan zulde al me geadvanceerd vectorwerk moeten beginnen & beweging van objecten tussen evaluaties (frames dus) moeten gaan berekenen.

Dus bv. in frame A neemt je box A posities (0,0) -> (1,2) in (corner coörd). Je hebt een snelheidsvector, een tijd, daarmee kan je berekenen in je nieuwe frame welke plaats dit ding heeft ingenomen (stel tijd 2 en je snelheidsvector is (0.5, 0), dan is de ingenomen plaats tussen die frames IN HET ALGEMEEN (0,0)->(2,2)). Dan kan je collision detection gaan doen met die uitgebreide area. Je werkt dus met een plaats over een tijd-interval ipv met absolute tijd. Natuurlijk krijg je hiermee ook incorrectheden (dat je zogezegd gaat botsen terwijl dat onmogelijk is).

Maar in principe zou je engine toch snel genoeg moeten geconstrueerd zijn zodat je zoiets niet moet gaan gebruiken (aangezien het nogal rekenintensiever is). Het is ook het beste dat je je tijdsinterval min of meer aan je "frames" koppelt in serverside-berekeningen (dus berekening van de gamewereld zelf == server, dit slaat ook op SP), zodat een plotse framedrop bij de speler dergelijke problemen niet veroorzaakt . Dus je zegt bv. dat tussen elk frame maximaal 0.05 seconden is verlopen .

Ik weet wel niet of dat algemene techniek is of zo ze , heb ek beetje ter plekke uitgevonden .

Hmm, nu je 't zegt. In plaats van enkel te kijken of je objecten overlappen, ga je kijken of hun pad overlapt. Heb nu te weinig tijd om er veel over na te denken, maar het klinkt wel bijzonder logisch natuurlijk.

Als de examens achter de rug zijn, zal ik mijn platformspel eens verder bouwen. De snelheid van het spel onafhankelijk maken van de snelheid van de pc had ik al gedaan. Dat vond mijn docent wel mooi trouwens.

@ Zembla: Houd ons op de hoogte van die MMORPG die je wil maken

Rectangle intersects
Threads synchroniseren
per beweging van uw bewegend voorwerp checken op elk object of hij daarmee intersects. Dit gaat natuurlijk voor twee rechthoeken. Voor twee bollen ist een ander zaak.

http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Rectangle.html

killgore zei:

En dat je game de collision niet detecteert omdat het te snel gaat of zo (dus de botsing tussen 2 en 3 vindt in de gameengine niet plaats).

Klik om te vergroten...

te snel? Ga je al uw stilstaande voorwerpen ook laten checken op collision? Als ge bij uw bewegend voorwerp per beweging kijkt of hij botst is alles toch ok en merkt hij toch elke botsing op.

jodeman zei:

te snel? Ga je al uw stilstaande voorwerpen ook laten checken op collision? Als ge bij uw bewegend voorwerp per beweging kijkt of hij botst is alles toch ok en merkt hij toch elke botsing op.

Klik om te vergroten...

Kijk, stel object A staat stil en neemt coördinaten in van (0,0) -> (1,1)

Object B begint (frame 1) als (-3,0)->(-2.1,1) en beweegt met een snelheidvector (40,0) (eenheden per seconde)

Jij stelt bv. elk frame gelijk met 0.05 seconden (20 fps is nu ook niet alles, maar kom ).

Dan krijgen we dit
Frame 2 : Object B wordt herberekend, krijgt nu coördinaten (-1,0)->(-0.1,1) => geen collission detection
Frame 3 : Object B wordt herberekend en krijgt nu coördinaten (1,0)->(1.9,1). Weerom is er geen collision, hoewel tussen Frame 2 en 3 het eigenlijk zou moeten gebotst zijn.

Ik betwijfel da ge veel van dergelijke situaties zult tegenkomen als uw frametijd nauw genoeg is (en aangezien meeste engines toch aan een 50-60 fps std werken lijkt me die kans extreem miniem).

En idd, normaal gade enkel bewegende objecten echt collision testing laten doen, ma da heeft niet echt iets te maken met de fout die hij bedoelt .

ah yep sjust, gewoon nog nooit tegengekomen.

jodeman zei:

ah yep sjust, gewoon nog nooit tegengekomen.

Klik om te vergroten...

khad er ook nog nooit aan gedacht tot em die vraag stelde ze

Voor zoiets moete toch al vreselijk snelle objecten hebben denkek .

Als je met valversnellingen werkt is het een reëel probleem. Of wanneer je objecten heel smal zijn.

forloRn_ zei:

Als je met valversnellingen werkt is het een reëel probleem. Of wanneer je objecten heel smal zijn.

Klik om te vergroten...

bij die heel smalle objecten kan ik me da nog voorstellen (vb gordijnen en zo)
Die valversnelling doet er echt niet toe denk ik. Zoals ik zei: aan 60 fps moete toch al extreem snel gaan om objecten van een normale omvang elkaar te doen passeren op die manier en dus een vreselijk lange val hebben ^^.

Ma kom, ge hebt een oplossing he .

http://www.realtimerendering.com/int/

alle collision detection die ge ooit zult nodig hebben