C'è una riduzione dei giochi "porta e spingidisco" che non esplode la lunghezza della soluzione?

Questo documento dimostra che in un gioco con porte e piastre a pressione, è difficile per PSPACE determinare se l'avatar (del giocatore) può o meno raggiungere una determinata posizione. Ciò è dimostrato da una riduzione da TQBF e la lunghezza delle soluzioni risultanti dipende in modo esponenziale dal numero di quantificatori universali nella formula.

C'è una riduzione da una macchina NPSPACE a un gioco del genere per il quale la lunghezza delle soluzioni del gioco è polinomialmente correlata alla lunghezza dei percorsi di accettazione della macchina?

Forse puoi facilmente simulare un LBA; l'idea è la seguente:

• $G_i$

• $C_i$$C_i$

• $Z_i$$O_i$$Z_i$$O_i$

• $q_i$$i$$q_i$

• $C_i$$C_{i+1}$$C_{i-1}$

Un gadget di cella è disegnato nella figura seguente.

Le scelte non deterministiche possono essere realizzate suddividendo i corridoi nelle strutture di controllo in due o più sotto-corridoi, come mostrato nella figura seguente.

Nota: se una piastra può solo aprire / chiudere una singola porta, è possibile aggiungere una struttura ausiliaria con (lunghi) corridoi unidirezionali che (de) attivano le porte di stato distinte di ciascuna cella.

Un altro modo rapido per dimostrare il Metatheorem 2c (durezza PSPACE quando le porte sono controllate da due piastre) è utilizzare la struttura logica vincolata non deterministica ( RA Hearn ed ED Demaine, il modello logico di calcolo vincolo non deterministico: riduzioni e applicazioni ).

In questo caso è sufficiente utilizzare una serie orizzontale di coppie di corridoi verticali. Lo stato di ciascuna coppia di corridoi rappresenta la direzione (verso l'interno / verso l'esterno) di un bordo nel grafico del vincolo originale. È sufficiente simulare il gadget AND e il gadget OR, come illustrato nella figura seguente.

questo tipo di ricerca sul collegamento dei videogiochi alla complessità computazionale è piuttosto intrigante, ma è anche abbastanza nuovo, generalmente meno di un decennio. Sosterrò qui che c'è sottigliezza che a volte manca nelle analisi attuali [non ho visto / notato questo sottolineato nel documento citato o in altri documenti finora] e che impedisce di rispondere definitivamente alla domanda dichiarata.

per dimostrare una relazione con un sistema computazionale, si deve essere in grado di mappare il sistema computazionale sul gioco e viceversa. ad esempio nel documento sopra citato di Viglietta esiste un concetto secondo cui le piastre di pressione e le porte (cioè le porte di controllo delle piastre di pressione) possono essere "come" QBF. questa analogia è certamente praticabile in quanto l'hanno mappata. si può usare un QBF per risolvere un gioco con piastre a pressione e porte.

tuttavia, ecco la finezza. in un determinato gioco, i layout del gioco sono sostanzialmente fissi. nella progettazione di videogiochi il concetto di diversi layout è chiamato "layout design" e non è un "dato" di tutti i giochi. per esempio nel rivoluzionario gioco Doom, gli strumenti di progettazione del livello erano di provenienza aperta, cioè resi disponibili per i giocatori. in altre parole, il design di livello arbitrario può essere considerato parte del gioco. ma in altri giochi considerati nei giornali, i videogiochi come originariamente costruiti hanno livelli fissi. i giornali a volte non tengono esplicitamente conto di ciò.

quindi c'è un forte argomento da sostenere che nella maggior parte dei giochi senza design di livello, o layout casuali, i livelli sono fissi, e questo ha un grande impatto sulla complessità effettiva della risoluzione del "gioco". cioè, che cos'è esattamente il "gioco"? include layout casuali e / o possibilità di progettazione del livello? il level design fa parte della mappatura computazionale? questi problemi sono in qualche modo risolti nei documenti attuali.

portato all'estremo opposto degli articoli, si potrebbe sostenere che tutte le implementazioni di videogiochi reali sono risolvibili dagli FSM perché hanno una memoria limitata !

perché ci siano delle vere mappature computazionali, in pratica bisogna generalizzare il gioco per coinvolgere

• livelli con dimensioni arbitrarie! in modo che questo possa essere mappato su TM con nastri di "input" di dimensioni arbitrarie / illimitate.
• progettazione di livelli che consente la creazione di questi livelli.

un problema di mappatura leggermente simile si presenta nella ricerca CA / Automi cellulari in cui vi sono idee sull'uso di infiniti schemi periodici sulle CA come "schemi di partenza" per dimostrare l'equivalenza / completezza della MT.

quindi in generale la tua domanda non è definita in modo rigoroso fino a quando non chiarisci meglio (cioè definisci più formalmente / matematicamente ) cosa intendi per "in un gioco con porte e piastre a pressione" e in un modo che persino il foglio non definisce apparentemente rigorosamente, esp scritto su idee sulla progettazione di livelli, livelli di dimensioni illimitate, eccetera. a meno di notare che i "giochi" definiti con queste caratteristiche allora sono state astratta lontano dai videogiochi attuali / reale in un modo molto significativo.

quindi in breve penso che questa sia una ricerca interessante / utile, anche se inizia come in qualche modo informale, e merita un ulteriore progresso, ma in una certa misura la sua formalizzazione deve essere resa più rigorosa nelle definizioni di base se vuole avanzare ulteriormente. deve fare una distinzione più rigorosa / formale / trasparente tra le implementazioni e le astrazioni .