[Tutorial Java] Un FPS (nel senso del gioco)
 

Naturalmente non è un fps completo, è più che altro la descrizione delle meccaniche di base. E tutto sommato di meccanica ce n'è anche poca perchè il 99.9% lo fanno le librerie. Insomma, sono 300 linee di codice da cui salta fuori che ci si muove qua e là sparando a qualcosa, con un'idea di framework logico che, a mio giudizio, rende la faccenda anche più facile.

tutorial.pdf
game.zip

Buon divertimento (spero).

Interessante tutorial, anche non sapere utilizzare strumenti come Blender, rende tutto "meno figo" :D
Forse in questo caso sarebbe utile oltre a fornire i sorgenti, anche i file obj di esempio.

Comunque questo JMonkey non sembra male, ho visto qualche gioco nella sezione "Games" del sito e vengono fuori delle cose divertenti.

Grazie all'autore per la sua capacità di sintesi e spiegazione.

In effetti ha senso fornire anche il progetto completo. Per pigrizia l'ho zippato e caricato in blocco (link in prima pagina). Per lanciare il programma dovrebbe bastare un doppio click su "game.jar" (in dist/lib).

Per ricompilarlo bisogna prima copiare la cartella dist/lib da qualche parte, poi eliminare tutte le dipendenze originali del progetto (che fanno riferimento alla configurazione di netbeans locale), quindi aggiungere alle librerie del progetto tutti i jar contenuti in dist/lib. Clean and build e via.

gokan centra in pieno il punto: la meccanica di un gioco 3d (chiaramente del genere sviluppabile da una persona sola) è tutto fuorchè complicata, il problema è che bisogna applicarla a dei modelli 3D e quelli non c'è API che li generi. Persino quella schifezza di livello che c'è nel tutorial apparirebbe "da urlo" se al posto dei bersagli del nonno osvaldo ci fosse un bel modello animato e anzichè lo stanzone da caserma in abbandono ci fosse qualcosa di curato, con tutte quelle mappe e mappine (dai riflessi alla rugosità) che il motore supporta in pieno ma che bisogna pur sempre creare.

:D Brutti bastardi, 100 visite e neanche un vadaviaiciap? :D

Qualcuno ha provato a fare qualcosa? E' davvero "facile" come sembra a me?

ho provato ad aprire l'applicazione ma dopo aver cliccato su ok per le impostazioni del display mi si chiude la finestra

Prova ad eseguirlo da linea di comando. Ti porti nella cartella "dist" e lanci il comando "java -jar game.jar". Sulla console dovrebbe apparire la traccia dell'eccezione generata.

PGI-Bis , da lo stesso problema anche a me.

Comunque il tutoria è veramente interessante:) :)

Prova ad eseguire il jar "game.jar" da linea di comando e dimmi che eccezione stampa sulla console. Potrebbe essere un problema col programma che ho scritto (testato su un solo pc con win7 a 64bit, magari non ho messo le librerie per i sistemi a 32 bit) oppure potrebbe essere l'engine (che è ancora in alpha) o il sistema di esecuzione (il motore richiede dei driver aggiornati e supporto ad opengl 1.2).

Cioè farlo partire tramite l'interprete dei comandi (Ms-dos)?

sì. Nello zip c'è una cartella di nome dist. Bisogna spostare la directory di lavoro là dentro (es. cd d:\game\dist), digitare "java -jar game.jar" premere invio e vedere cosa scrive sulla console. Dovrebbe chiacchiarare un po' e, subito prima di impastarsi, stampare la traccia dell'eccezione che causa il problema.

Ho eseguito il game.jar" da linea di comando, ma non da nessuna eccezione .

Credo non sollevi eccezioni , perché anche quando lancio il programma da linea di comando, "la faccia con lo scimmiotto" compare , il problema è che dopo aver cliccato su ok sembra non succedere niente.

a me funziona alla perfezione. ;)
Se può esserti utile come sistema operativo ho windows 7 home premium a 64 bit.

Forse allora è un problema del mio S.O. , vista a 32bit

Opterei per i driver video. Prova, se vuoi/puoi, a eseguire questo gioco (usa le stesse librerie):

http://mythruna.com/mediawiki/index....ine_Test_Build

Se questo funziona il problema è chiaramente nel programma che ho scritto io. Altrimenti è da qualche altra parte.

Lo farò certamente , appena rientro a casa però ,ora sono fuori .

Nulla , non parte nemmeno il gioco da te (PGI) segnalatomi... evidentemente è un problema "del mio pc" .

Può essere la scheda video o i driver. Il motore usa esclusivamente gli shader per il rendering dei materiali e credo che questo richieda il supporto ad una certa versione di opengl (butto lì una 1.2).

C'è un tale Minecraft che vorrebbe parlarti :D

Comunque tutorial carino, complimenti! M'è piaciuta la parte sulla logica di gioco (anche se io non faccio così)... di solito nei tutorial è tutto un'ugly mess senza alcuna struttura, mentre anche giochi semplici hanno bisogno di una gestione degli stati di gioco.

Magari la faccenda delle operazioni logiche generiche è appunto troppo generica, credo che sarebbe più semplice usare una macchina a stati in cui gli stati ti specificano appunto lo stato, e quindi le condizioni.

Per il resto critico l'incapacità delle librerie Java nel fare il "meno possibile". Caricare Bullet3D per gestire le collisioni di questo coso?
E' veramente ammazzare le mosche col bazooka, e credo che un gamedev DEBBA saper fare da solo la sua fisica quando serve.

PS: opengGL dovrebbe essere 2.0. :read:

Per me se parliamo di sviluppo amatoriale di tripla z (e per tripla z intendo fare oggi un Doom3 o Quake4, cioè giochi di quattro o cinque quattro generazioni fa) essere efficienti è assurdo quanto pretendere di poter scrivere amatorialmente, oggi, Crysis 2 (o un qualsiasi altro tripla a).

Nota che parlo di scrivere un gioco per divertimento, non di farne una professione: "dai gino, facciamo un fps", questo genere.

Non "adesso faccio un gioco per l'aifon' che ci facci i migliardi" o "Valve non capisce una minchia adesso gli faccio vedere io gli faccio" :D. No, facciamo giochi nello stesso senso in cui facciamo i giri in bicicletta: ambiamo segretamente alla maglia rosa ma sappiamo benissimo che a malapena passiamo la rampa del garage.

Ecco, in quest'ottica io trovo assurdo che si trovino centinaia di giochi amatoriali in 2d e praticamente nessuno degno di nota in 3D.

Assurdità che, secondo me, nasce da questa insana pretesa di essere efficienti. Non serve essere efficienti perchè tanto non hai le risorse materiali per doverlo essere.

Materialmente non ce la fai da solo a creare abbastanza asset, abbastanza complicati, da dover andare a caccia di quel mezzo millisecondo che ti permette di stare in bilico sui 30 frame al secondo.

Non è tanto un problema di API di alto livello quanto una questione di sovradimensionamento dell'hardware. Uno può non farci caso se non programma da un bel po' di anni ma un PC da supermercato di oggi, per fini amatoriali, è una macchina di potenza stratosferica.

A vedere certi forum di sviluppatori di giochi per diletto sembra che stiamo ancora coi 486.

Per me vedi la questione dal punto di vista sbagliato.

I giochi 3D indie non esistono quasi, perchè il 3D o si fa bene o non si fa per niente.
Non esiste che esci OGGI con un gioco che era AAA nel 2003.
Ok si potrebbe fare, sarebbe possibile (anche se comunque molto complesso e costoso rispetto al 2D) ma farebbe comunque cagare.
Abituati come siamo agli AAA moderni, la grafica 3D di un gioco vecchio oggi è semplicemente improponibile.

Il problema è che i giochi 3D vecchi, sono appunto vecchi. Rendono male e si trovano in svantaggio come qualità sia rispetto agli AAA veri, sia rispetto a giochi 2D con giocabilità nuova e grafica comunque gradevole.

E poi un gioco 3D è per sua natura meno immediato e più difficile da creare, per vari motivi che non sto a elencare qua.

E comunque, minecraft.