Dal movimento alternato al movimento quantizzato

Home Forum Meccaniche Dal movimento alternato al movimento quantizzato

Stai vedendo 1 articolo (di 1 totali)
  • Autore
    Articoli
  • #48832
    ffiorenzano
    Partecipante

    Il ragionamento che segue potrebbe risultare poco interessante, soprattutto perché riguarda il classico wargame a mappa esagonata: chi ci gioca ancora?
    Ma chi ha un po’ di tempo e di curiosità potrebbe trovare il discorso quantomeno originale (almeno credo, correggetemi pure…)

    Tempo fa, giocando a un wargame, ho notato che il movimento alternato delle pedine può causare delle incongruenze notevoli, in particole in presenza di mezzi che si muovono velocemente.

    Consideriamo due strade che si incrociano, costo di un esagono 1 Punto Movimento; su una strada, a 3 esagoni dall’incrocio c’è un mezzo, diciamo Blu, che dispone di 6 Punti Movimento per turno; sull’altra strada, a 2 esagoni dall’incrocio, un mezzo nemico, Rosso, che ha 4 Punti Movimento per turno.

    Nella realtà i due mezzi, muovendo alle rispettive velocità, si incontrerebbero nell’incrocio.
    Nella realtà simulata del gioco, invece, il Blu (è uguale se muove prima il Rosso, il ragionamento è speculare) muoverebbe di 6 esagoni attraversando l’incrocio, poi il Rosso muoverebbe di 4 esagoni e i due mezzi non si incontrerebbero.

    Per risolvere il problema ho ragionato come un film d’animazione.
    Stabiliamo che il movimento del mezzo Blu venga diviso in 6 fotogrammi, per ogni fotogramma avanza di un esagono.
    In quei 6 fotogrammi il mezzo Rosso muove di 4 esagoni.
    Guardando il film al rallentatore vedremo a un certo punto i due mezzi incontrarsi all’incrocio.
    Funziona, come logica? Pare di sì, e funzionerebbe anche con mezzi più lenti: in quei 6 fotogrammi una unità potrebbe muovere di 2 esagoni, o di 1.

    Come trasformare questo film in qualcosa di giocabile? Io l’ho risolto con dei calcoli abbastanza “noiosi” da necessitare di un software; al giorno d’oggi un qualunque cellulare potrebbe gestire comodamente la faccenda.

    Nel dettaglio: per sapere quanto dura il fotogramma di questo film occorre calcolare quello che ho chiamato il Quanto di Movimento (QM), che si ottiene dividendo i Punti Movimento (PM) dell’unità più veloce per il costo in Punti Movimento del terreno più agevole.

    Quindi 6 PM del mezzo più veloce diviso 1 PM di costo della strada (6 / 1 = 6).
    Il QM è 6, e questo numero serve a calcolare di quanto muoverà ogni pedina nel tempo di un fotogramma, basterà dividere i PM di ogni unità per QM.

    Il mezzo Blu ha 6 PM, divisi per 6 fa 1 (che io ho chiamato Punti Quantizzati, PQ).
    Il mezzo Rosso ha 4 PM, divisi per 6 fa 0.67 PQ.

    Per ogni fotogramma, il software cicla su tutte le pedine e assegna i PQ relativi.
    Poi stabilisce chi può muovere in quel fotogramma, e lo comunica ai giocatori.

    Dopo il primo fotogramma, Blu ha 1 PQ, che usa per muovere di un esagono (che costa 1).
    Dopo il primo fotogramma, Rosso ha 0.67 PQ, che non bastano per muovere di un esagono, quindi salta il turno.

    Dopo il secondo fotogramma, Blu ha 1 PQ, che usa per muovere di un altro esagono.
    Dopo il secondo fotogramma, Rosso ha 1.34 PQ, che bastano per muovere di un esagono (che costa 1) e conservare 0.34 PQ.

    Fotogramma 3:
    Blu ha 1 PQ e muove di 1 esagono.
    Rosso ha 0.34 di prima più 0.67, cioé 1.01 PQ e muove di 1 esagono e conserva 0.01.

    Fotogramma 4:
    Blu ha 1 PQ e muove di 1 esagono.
    Rosso ha 0.68 PQ e non muove.

    Fotogramma 5:
    Blu ha 1 PQ e muove di 1 esagono.
    Rosso ha 1.35 PQ e muove di 1 esagono e conserva 0.35.

    Fotogramma 6:
    Blu ha 1 PQ e muove di 1 esagono.
    Rosso ha 1.02 PQ e muove di 1 esagono e conserva 0.02.

    La logica è tutta qui. Funziona perfettamente anche in presenza di terreni con costi differenti in PM, anche con decimali. Un terreno poco meno agevole di una strada potrebbe costare 1.2 PM, i calcoli funzionano ugualmente.

    Il software non deve nemmeno conoscere la mappa, è sufficiente che sappia quante unità di ogni tipo hanno i giocatori (e i relativi PM) e quanti tipi di terreno ci sono(e il loro costo in PM).
    Quando il giocatore muove, comunica al software su che terreno si è spostato e quello servirà per capire se al fotogramma successivo avrà abbastanza PQ per muoversi.

    L’unico problema che resta è la gestione degli scontri: un attacco non può avvenire in ogni fotogramma, occorre una quantizzazione diversa. Anche questo è risolto, ma è un’altra storia (magari un altro post).

    Attachments:
    You must be logged in to view attached files.
Stai vedendo 1 articolo (di 1 totali)
  • Devi essere loggato per rispondere a questa discussione.