Stampa

Effettua l'accesso o una nuova registrazione.
1 ora 1 giorno 1 settimana 1 mese Sempre
Inserisci il nome utente, la password e la durata della sessione.

[OniTakeda]

Figurati, anzi, apprezzo il consiglio, il fatto è che concettualmente secondo me funzionerebbe pure, praticamente l'implementazione è più complicata di quanto pensassi e ora come ora rende male

[Cherno]

Faccio il finto ignorante e domando: perchè quando spawnano gli avversari vengo buttato giù dalla piattaforma sulla quale mi trovo?
Seconda cosa: capita che arrivi un avversario, io stia fermo e questi non faccia assolutamente nulla finchè non mi muovo.
Terza cosa: a cosa servono le monete?

[OniTakeda]

1.Perchè gestire nemici che saltano pure su finistre e tetti era troppo complicato, così abbiamo deciso di annullare le collisioni in quei punti quando spawnano!
2.In pratica ogni 3 secondi il nemico decide cosa fare in modo random, può capitare che stia fermo per tanto, ma è difficile! (ogni 3 secondi c'è un 10% di probabilità che non faccia nulla)
3.puoi comprarci il caffè alla macchinetta per rigenerare i cuori! Cappuccino e the costano 0,10€, il resto 0,05€

[Cherno]

1.Perchè gestire nemici che saltano pure su finistre e tetti era troppo complicato, così abbiamo deciso di annullare le collisioni in quei punti quando spawnano!
2.In pratica ogni 3 secondi il nemico decide cosa fare in modo random, può capitare che stia fermo per tanto, ma è difficile! (ogni 3 secondi c'è un 10% di probabilità che non faccia nulla)
3.puoi comprarci il caffè alla macchinetta per rigenerare i cuori! Cappuccino e the costano 0,10€, il resto 0,05€

1.Non è una giustificatione per me giocatore!!! Comunque problema potenzialmente risolvibile eliminando le piattaforme a mezzaria, che a quanto pare servono solo per le monetine (vedi punto 3).

2.Immaginavo un'implementazione simile. Tre secondi sono tanti, ma è anche vero che se lo riducete l'avversario sembrerebbe uno schizofrenico.
Cambiare la logica implementativa? Magari invece di fare un idle dove l'avversario sta fermo e basta, potrebbe muoversi nello spazio seconda un pattern preciso e la distanza che ha dal giocatore. Poi potreste triggerare un evento quando questi capisce che il giocatore è a portata di tiro e switchare allo stato 'rompigli il culo'. Fra l'altro: gli avversari hanno la stamina? è implementato il guard break?

3.Allora invece di mettere le monete su altre piattaforme, perchè non mettere i classici "bidoni" alla final fight dove si trovano le monete?
Tanto ora come ora non è richiesta alcuna abilità particolare per prenderle ed il level design non ti porta ad esplorare la mappa per posti nascosti

3.bis.Non so quanto sia lungo il livello perchè non ce l'ho fatta ad arrivare in fondo ( ), ma considera questo: quanta voglia ha un giocatore
di tornare indietro a comprare qualcosa dalle macchinette? Magari potete piazzarne diverse nel livello!

[OniTakeda]

1.E lo so, ma era troppo un casino XD

2.La cosa di non farli stare fermi è buona, per il resto c'è sempre il problema che poi diventano troppo forti, anche perchè ne compaiono anche 4 contemporaneamente, comunque si anche i nemici hanno stamina e gli si rompe la parata!

3.I bidoni sono una buona idea, si possono implementare, ma di macchinette ce ne sono almeno 3 durante il gioco

[Ziggybee]

Cherno, in una fase implementativa così acerba parlare di level design o di meccaniche di gioco avanzate è come bullarsi della propria forza con una bambina di cinque anni

Come è sbagliato il titolo. Non si fa Game Design su poco più di una tech demo dove tutto è autogestito. Il focus è un altro.
O lo si fa su un tool per lo sviluppo prototipale oppure lo si fa su altri media.

Paradossalmente sarebbe stato più utile un prototipo su Game Maker, per parlare di design.

[Cherno]

Se devo vedere dal punto di vista tecnico l'aspirante gioco posso dire che:

gli asset sono brutti.
la trashata del 3 hit combo + risata su gameover è sostanzialmente evitabile.
Supportare una risoluzione HD senza avere un artista che la valorizzi è da pazzi.
c'è un problema con la gestione degli stati di gioco: vedi bug segnalato poi.
le feature principali di un picchia picchia ci sono e funzionano, seppur calibrate male: insomma se premo in qualsiasi direzione il personaggio si muove correttamente, se schiaccio il pugno questo viene sferrato, stessa cosa per il calcio, l'input del salto viene recepito, così come quello del doppio salto. Le collisioni funzionano, i nemici quando colpiti staggerano e via discorrendo.

Quindi una base sulla quale sperimentare a livello di design c'è eccome.

A costo di annoiare alla morte: il punto focale di un videogame è il suo gameplay, quindi ci stà parlare di game design ancora prima di parlare di un bug che ha bloccato il gioco quando ho provato a fare continue. Ma a chi importa se stanno usando java o game maker scusa? Chiaro che se il progetto chiedeva esplicitamente di un videogioco, senza imporre una tecnologia, è un errore non utilizzare qualche tool già fatto...ma va bè, sticazzi?

Poi, ti prego...non è bullarsi, è dare input: onitakeda ha chiesto esplicitamente consigli di gamedesign, i quali trascendono la tecnologia impiegata per implementarlo.

[OniTakeda]

Ma infatti, non l'ho considerato bullismo.
Comunque ci tengo a precisare che il progetto aveva come finalità quella di riuscire a programmare un videogioco da 0, solo in codice, quindi tutto ciò che si fa è stato creato e gestito da noi, dalle collisioni, alle combo e via discorrendo.
La grafica e il sonoro sono stati buttati li giusto per capire come si mettono la grafica e il sonoro in un videogioco, non avevano nessun altra pretesa, anche perchè come ho già scritto siamo tutti informatici e nessuno di noi sa disengare.
Detto questo, quello che mi interessava era appunto sapere le meccaniche che funzionavano e quelle che non funzionavo.

p.s.
che poi la scelta del progetto era a propria discrezione, la maggior parte dei miei colleghi hanno fatto cose in mySQL, tanto per far capire che non abbiamo seguito nessun corso apposito ma solo quello classico di programmazione orientata agli oggetti 2 anni fa.

[Ziggybee]

No, non fraintendetemi.
E' che comunque c'è troppa carne al fuoco.

Se uno vuole input sul design deve presentare un design.
Se vuole input sulle caratteristiche tecniche presenta una demo.

A fare tutto insieme si corre il rischio di non fare nulla bene, se una meccanica non la testi, è difficile svilupparla. Se la testi con qualcosa di sviluppato da te rischi di non capire se l'errore sia di sviluppo o di design e così via... Viceversa se sviluppi per testare il design corri il rischio di avere codice troppo prototipale per andare avanti quando devi maturare tutto... Un paio di mesi di concettualizzazione a volte ti fanno risparmiare molti mesi di lavoro vero.

[Cherno]

Indubbiamente, ma visto che Onitakeda non ha chiesto nulla di tecnico ne ha esposto le sue implementazioni, è un pò difficile consigliarlo in quel senso.

Per quanto riguarda il discorso troppa roba, concordo anch'io. Secondo me per un primo tentativo di sviluppo di un beat'em'up, che già presenta il suo grado di complessità, aggiungergli la raccolta monete, azione su più piani, doppi salti, calcio, pugno, parata, stamina ecc ecc. è troppo.

Più che altro farlo senza esperienza è troppo.
Personalmente se il focus era lo sviluppo del codice, avrei fatto una sorta di Final Fight: attacco singolo(che fa combo automaticamente), salto, mossa speciale che succhia un pò di vita, bidoni e boss di fine livello. Insomma una formula rodata.

Fra l'altro è stata la prima cosa che ho suggerito all'inizio del thread, ma del resto i ragazzi hanno fatto un'altra scelta, perciò amen

[Cherno]

Un paio di mesi di concettualizzazione a volte ti fanno risparmiare molti mesi di lavoro vero.

Stra-d'accordo