Come gestire diverse velocità di azione nei giochi RogueLike?


14

Come gestire diverse velocità di azione nei giochi RogueLike?

Quello che voglio dire è che i giochi a turni possono avere attori che agiscono a "velocità" diverse, a seconda dell'azione e di alcune altre caratteristiche. Gli attori quindi eseguono effettivamente più azioni / svolte rispetto agli altri se hanno una maggiore velocità o meno.

Come determinare quando un attore dovrebbe essere in grado di recitare (girare la programmazione?)?

Sembra che ci siano diversi modi per farlo? Puoi spiegarne alcuni con gli algoritmi?


7
Ho la sensazione che se descrivi in ​​dettaglio le caratteristiche che desideri, un algoritmo diventerà ovvio.
Tetrad,

Come diceva Tetrad, oltre a cosa intendi per "velocità delle azioni"? I Roguelike sono in genere a turni, quindi non riesco a vedere come questo possa applicarsi a loro.
Laurent Couvidou,

2
Anche nei giochi a turni, alcune entità si muoveranno più velocemente o più lentamente di altre, avendo più o meno curve rispetto alle altre. Ho risolto la domanda.
Klaim,

3
@Patrick Hughes Nethack, uno dei roguelike più antichi e popolari, ha un attributo di velocità molto importante. nethackwiki.com/wiki/Speed
Harry Stern,

1
@HarryStern Ho giocato male per tutto questo tempo? Ciò potrebbe spiegare alcune cose ... =)
Patrick Hughes,

Risposte:


12

Nel mio gioco roguelike Tyrant ho usato un sistema di punti azione e velocità.

Fondamentalmente:

  • La maggior parte delle azioni aveva un costo in PA di 100
  • La maggior parte delle creature ha una velocità di 100

Quindi il ciclo di gioco sarebbe il seguente.

  • L'eroe compie un'azione.
  • Il tempo trascorso viene calcolato come hero action AP cost * 100 / hero speed
  • A tutte le creature vengono assegnati AP pari a creature speed * elapsed time / 100
  • Le creature intraprendono azioni e subiscono la sottrazione degli AP fino a quando i loro AP non sono <= 0
  • Ripetere

Questo sistema ha funzionato molto bene nel complesso, ad esempio funzioni interessanti:

  • Se hai un eroe molto veloce (forse a causa di un bonus alla velocità magica), puoi fare diverse mosse prima che una singola creatura possa muoversi (i suoi AP sarebbero negativi per alcuni turni perché il tempo trascorso sarebbe piccolo)
  • È possibile rendere alcune azioni più o meno costose variando il costo dell'AP
  • Puoi ritardare le creature sottraendo gli AP o dare loro una spinta improvvisa una tantum aggiungendo AP

Sto cercando di avvolgere la mia testa attorno a questo. Se hai 1 giocatore e 4 giocatori. Questo non fa in modo che il tempo trascorso dallo stack dell'ultimo giocatore sia sempre di più. Permettendogli di compiere forse 4 azioni e la seconda volta intorno alle 8 di fila ??
Dr.Denis McCracleJizz,

4

Punti d'azione. Dai a ciascuna entità una "velocità" in modo che gli attori più veloci ottengano più punti ogni turno. Fai completare ad ogni azione un determinato numero di punti per il completamento e sottrai quel numero dai punti del giocatore per quel turno quando compie un'azione. Se un'azione prende più punti di quanti il ​​giocatore ha lasciato, segnalo come "parzialmente completato" e lascia che finisca il turno successivo.


2

Vuoi dire che le azioni hanno più turni (cioè dormire per 50 turni di fila)?

Quello che vorrei fare è mantenere un oggetto, player.currentAction. currentAction potrebbe contenere quanti turni richiederebbe l'azione, qual è la risoluzione dell'azione e un elenco di stati che annullano l'azione (in pericolo, essere attaccato, troppo caldo, ecc.). Ad ogni turno, prima di controllare l'input del giocatore, verificheremmo se il giocatore era attualmente nel mezzo di un'azione, quindi fare qualcosa di simile a ...

if(!player.currentAction.interrupted())
{
 if(player.currentAction.complete() == true)
   {
    player.currentAction.doAction(); //Some actions, like casting a spell, would have something happen here. Others, like sleeping, may or may not, depending on how you coded it.
    player.currentAction = null;
   }
else player.currentAction.decreaseTimer(); //Decrease our timer by one.
}
else 
{
 player.currentAction.interrupt(); //Let the player know he's been interrupted. Bungle the spell, cancel sleep, etc.
 player.currentAction = null;
}

2

Puoi andare con punti azione ma senza turni di per sé ma con zecche, che sono molto più piccole. Supponiamo che ogni attore abbia una velocità di accumulo del punto di azione (ad es. 2 AP per tick). Inizia un'azione che vale, diciamo, 10 AP. Il gioco avanza di 5 tick in avanti (perché questo è il tempo impiegato dall'attore per pagare il prezzo AP dell'azione).

Quando ci sono diversi attori. Il gioco avanza tick by tick fino a quando qualcuno non ha pagato il prezzo AP nel momento in cui questa azione viene eseguita.

L'approccio è simile a quello di @ mikera, solo che non ci sono AP negativi.


Questo è molto più complicato, in quanto è necessario memorizzare l'azione "prevista" della creatura. Alcune azioni dipendono dallo stato che può cambiare prima che il mob abbia accumulato abbastanza punti.
Warwick Allison,

Forse non è perfetto, ma riflette la vita reale, quando decidi di colpire, devi prima oscillare e poi colpire - quindi è l'azione di preparazione delle decisioni, che è ciò che questo sistema consente. Inoltre, questo consente di scegliere l'azione di blocco in base alla situazione reale.
zzandy,

Preferisco andare nella direzione opposta: mob sceglie un'azione con costo di n-tick e quindi non può scegliere una nuova azione fino a quando n-tick scade. Può essere implementato come un singolo valore che viene decrementato su ogni segno di spunta.
kitsu.eb,

-1

Tempo ad alta risoluzione

Se il pugno fa 400 giri, e calcio fa 1000 turni, posso darti un pugno almeno due volte prima che tu mi dia un calcio, e posso darti un pugno 5 volte quando mi dai un calcio due volte.

Facendo girare molte cose, hai molto controllo su quanto tempo impiegano.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.