I selettori di Minecraft permettono ai comandi di individuare giocatori ed entità senza scriverne ogni volta il nome. I quattro simboli più importanti sono @p, @a, @e e @s: rispettivamente giocatore più vicino, tutti i giocatori, tutte le entità e l’esecutore corrente. A questi si aggiunge spesso @r, che seleziona un giocatore casuale nelle sintassi compatibili.

Capire i selettori è essenziale per passare dai comandi manuali alle vere automazioni. Un semplice /effect può dare Speed a tutti i partecipanti; /kill può eliminare soltanto i Creeper in una zona; /spawnpoint può assegnare un checkpoint a chi attraversa una porta; /execute può eseguire una logica per ciascuna entità selezionata. Senza filtri, però, un selettore può essere troppo ampio e causare risultati indesiderati.

In questa guida vediamo significato di @p, @a, @e, @s e @r, filtri per tipo, distanza, nome, tag, gamemode e punteggio, differenze Java/Bedrock, Command Block, origine di esecuzione, esempi pratici e strategie di sicurezza. Microsoft documenta attualmente per Bedrock i player selector @a, @p, @r e @s, mentre il target selector generale include anche @e.

Che cos’è un selettore

Un selettore è un’espressione che restituisce uno o più target. Il comando successivo agisce su quei target. Per esempio:

/give @p diamond 1

non contiene il nome di un giocatore: Minecraft calcola chi è il player più vicino all’origine del comando e gli dà un diamante.

@p: giocatore più vicino

@p significa nearest player. È molto comodo per pulsanti, negozi, checkpoint e stazioni in cui il giocatore interagisce fisicamente con un Command Block vicino.

/effect give @p minecraft:speed 30 0

In Java questo esempio dà Speed I al giocatore più vicino. In Bedrock devi adattare la forma di /effect.

Da dove viene misurata la distanza di @p?

La distanza viene calcolata dall’origine di esecuzione. Se scrivi il comando in chat, l’origine è legata al tuo contesto; se lo esegue un Command Block, il riferimento è il blocco; se usi /execute at, puoi spostare l’origine su un’entità.

Questa è la ragione per cui @p a volte “sceglie la persona sbagliata”: non è il giocatore più vicino a te in senso intuitivo, ma il più vicino all’origine effettiva del comando.

@a: tutti i giocatori

@a seleziona tutti i player compatibili con i filtri. Esempio:

/gamemode adventure @a

La posizione degli argomenti cambia tra comandi, ma il selector rappresenta sempre l’insieme dei giocatori.

Quando usare @a

È ideale per avviare un minigioco, dare un effetto a tutti, teletrasportare partecipanti, mostrare un titolo globale o cambiare una regola di partita. Tuttavia, in un server con lobby e più modalità, @a può includere anche persone che non partecipano. Filtralo con tag, team, distanza o punteggio.

@e: tutte le entità

@e seleziona le entità, includendo mob, giocatori e molte altre categorie. È il selector più potente e più pericoloso.

/kill @e

è un esempio da non usare casualmente: può rimuovere una quantità enorme di entità importanti. Quasi sempre @e dovrebbe essere accompagnato da filtri.

Filtrare @e per tipo

In Java:

@e[type=minecraft:zombie]

seleziona zombie. Puoi quindi usarlo con /kill, /effect, /tp e altri comandi compatibili.

@s: self, cioè l’esecutore

@s rappresenta chi sta eseguendo il comando nel contesto corrente. È fondamentale con /execute as. Esempio:

/execute as @a run say Sono @s

Concettualmente, il comando viene eseguito una volta per ogni player selezionato, e @s rappresenta quel player.

Perché @s non è sempre un giocatore

Se il comando è eseguito da un Command Block, l’esecutore iniziale non è un player. Un comando che richiede un giocatore può quindi non funzionare con @s finché non cambi contesto usando /execute as.

@r: giocatore casuale

@r seleziona un player casuale nelle sintassi che lo supportano. È utile per lotterie, scelte casuali, minigiochi e assegnazione di ruoli. Se devi scegliere tra i soli partecipanti, aggiungi filtri appropriati.

Argomenti tra parentesi quadre

I filtri vengono inseriti dopo il selector:

@e[type=minecraft:zombie,distance=..20]

La sintassi specifica differisce tra Java e Bedrock, ma il concetto è simile: restringi l’insieme dei target.

Filtro type

type limita il tipo di entità. È essenziale con @e. Esempio Java:

@e[type=minecraft:creeper]

Puoi usarlo per selezionare Creeper senza coinvolgere giocatori, villager o item.

Escludere un tipo

Java consente forme di negazione nei selector, per esempio escludere player o un EntityType. Bedrock possiede i propri argomenti e regole. Prima di usare una negazione in un comando distruttivo, verifica l’autocompletamento dell’edizione.

Filtro distance in Java

Java usa intervalli come:

@a[distance=..10]

che significa fino a 10 blocchi. Puoi usare intervalli minimi, massimi o completi.

Raggio in Bedrock

Bedrock usa argomenti specifici come r e rm in molte sintassi di selector. La filosofia è equivalente ma i nomi non sono identici a Java. Per guide multipiattaforma, scrivi sempre due esempi separati.

Filtro name

Puoi selezionare un’entità con un determinato nome visualizzato secondo le regole dell’edizione. Per logica tecnica, però, i tag sono spesso più robusti perché un nome può essere modificato per ragioni narrative o estetiche.

Filtro tag

I tag sono etichette testuali assegnate alle entità:

/tag @p add partecipante

Poi puoi selezionare:

@a[tag=partecipante]

È uno dei pattern migliori per mappe e minigiochi.

Tag positivi e negativi

Puoi costruire sistemi che includono chi possiede un tag e, dove la sintassi lo permette, escludono chi ne possiede un altro. Per esempio partecipanti sì, eliminati no.

Filtro gamemode

In Java puoi filtrare per modalità, per esempio giocatori in Adventure o Spectator. È utile per non applicare un comando agli amministratori in Creative.

Filtro team

Java supporta selezione in base ai team scoreboard. Puoi rivolgere comandi al team rosso o blu. Bedrock utilizza strumenti diversi per alcune logiche di gruppo.

Filtro scores

Uno dei filtri più potenti è lo scoreboard:

@a[scores={points=10..}]

La documentazione Bedrock mostra un esempio analogo per selezionare giocatori con almeno 10 punti. Questo permette di costruire progressione, livelli e condizioni senza decine di Command Block separati.

Combinare filtri

Puoi usare più condizioni insieme. Esempio Java concettuale:

@e[type=minecraft:zombie,distance=..20,tag=arena]

Seleziona soltanto zombie dell’arena entro 20 blocchi. Più il comando è distruttivo, più conviene essere specifici.

Ordine dei filtri

L’ordine logico non cambia sempre il risultato, ma mantenere uno stile coerente migliora leggibilità. Una convenzione utile è: tipo, distanza/posizione, tag/team, punteggio, limite.

Limitare il numero di target

Java offre opzioni come limit e ordinamento. Bedrock possiede parametri propri. Questo è utile se vuoi selezionare una sola entità di un tipo invece di tutte.

Selezionare l’entità più vicina

@p riguarda player. Per trovare l’entità più vicina di un tipo in Java puoi usare @e con sort e limit. Esempio concettuale:

@e[type=minecraft:zombie,sort=nearest,limit=1]

Selezionare entità casuali

In Java puoi combinare sort=random e limit, mentre Bedrock dispone di @r e filtri specifici. È utile per minigiochi, loot, target casuali e AI custom.

Coordinate x y z nei selector

Alcuni filtri possono ridefinire la posizione di riferimento o una box di selezione. In Bedrock sono comuni argomenti x, y, z, dx, dy e dz. In Java esistono strumenti simili. Questi filtri permettono di selezionare chi si trova dentro una stanza rettangolare.

Selezione per box

Una box è spesso migliore del semplice raggio quando la stanza ha forma rettangolare. Puoi rilevare giocatori dentro una porta, un corridoio o un’arena senza includere zone vicine su altri piani.

Problema dei piani sovrapposti

Un raggio sferico può includere giocatori sopra o sotto il Command Block. In edifici multipiano, usa una box o controlli sulle coordinate per evitare falsi positivi.

Selettori e /give

/give può consegnare item a @p, @a o altri player selector. Per un premio individuale, filtra il partecipante che ha completato la condizione.

Selettori e /effect

/effect diventa molto potente con target di zona. Puoi dare Speed solo ai giocatori in una pista o Poison alle entità in una nube tossica.

Selettori e /kill

/kill richiede la massima prudenza. Non usare @e senza filtri in un mondo importante.

Selettori e /spawnpoint

/spawnpoint accetta player target. @p è comodo per checkpoint semplici; @s con /execute è più robusto nei sistemi avanzati.

Selettori e /summon

/summon crea una nuova entità e non usa un selector come target principale, ma puoi usare /execute at @a o @e per evocare qualcosa presso ogni target selezionato.

Selettori e /execute

È il matrimonio più importante. /execute as @a at @s run ... consente di eseguire un comando per ogni giocatore e usare la sua posizione come origine.

Differenza tra as e at

as cambia l’esecutore; at cambia la posizione di esecuzione. Se usi soltanto as, la posizione può restare quella originale. Se vuoi eseguire qualcosa “come e presso” ogni player, spesso servono entrambi.

Perché @s è fondamentale con execute

Dopo execute as @a, @s rappresenta ogni giocatore selezionato in ciascuna iterazione. Puoi quindi scrivere comandi generici e riutilizzabili.

Selettori nei Command Block

Un Command Block esegue da una posizione fissa. @p, distance e box vengono calcolati rispetto a quel contesto se non usi /execute per modificarlo. Disegna la mappa sapendo dove si trova il blocco o usa coordinate esplicite.

Always Active e selettori

Un Repeat Command Block Always Active valuta il selector continuamente. Se il target è @e senza filtri, può elaborare moltissime entità ogni tick. Limita la selezione per migliorare performance.

Selettori e performance

I problemi non derivano dal simbolo @e in sé, ma da selezioni molto ampie ripetute spesso, seguite da comandi costosi. Filtra tipo e zona e riduci la frequenza quando non serve un controllo ogni tick.

Come testare un selector

Prima di usarlo con kill, tp o altri comandi invasivi, provalo con un output innocuo. Puoi mostrare un messaggio, applicare Glowing temporaneo o usare strumenti di conteggio. Se i target sono corretti, sostituisci il comando di test.

Debug con Glowing

In Java, applicare Glowing ai target per pochi secondi è un ottimo modo per vedere visivamente chi è stato selezionato. Non modificare permanentemente la mappa e ricorda di rimuovere l’effetto dopo il test.

Problema: @p sceglie il player sbagliato

Controlla l’origine di esecuzione. In multiplayer, limita il raggio o usa /execute as con una condizione più precisa.

Problema: @s non trova nessuno

Se il comando è eseguito da un Command Block, @s non è automaticamente un player. Cambia executor con /execute as.

Problema: @e colpisce anche i player

I giocatori sono entità. Usa type o un selector specifico per player quando necessario.

Problema: il filtro distance non funziona in Bedrock

Probabilmente stai usando sintassi Java. Bedrock usa argomenti diversi per il raggio. Non mescolare esempi tra edizioni.

Problema: scores non trova il player

Verifica che l’obiettivo esista, che il giocatore abbia un valore e che l’intervallo sia scritto correttamente. Un player senza score inizializzato può comportarsi diversamente da uno con zero esplicito.

Problema: tag non trovato

Controlla maiuscole, minuscole e spelling. I tag tecnici dovrebbero avere nomi semplici e coerenti, senza spazi inutili.

Java e Bedrock

Entrambe le edizioni condividono @a, @p, @e, @s e concetti di filtering, ma gli argomenti interni non sono completamente identici. Microsoft documenta per Bedrock i target selector e i player selector moderni. Java ha una sintassi estremamente ricca per distance, scores, advancements, nbt, predicates e altro.

Non copiare selector avanzati da un’edizione all’altra

Un comando semplice come @p è portabile concettualmente. Una selezione complessa con distance, sort, limit, NBT o altri filtri può essere specifica di Java. In Bedrock usa la documentazione e l’autocompletamento della versione.

Una convenzione per i tag

Usa prefissi coerenti: game_participant, game_eliminated, boss_arena1, npc_persistent. Questo rende leggibili i selector e riduce collisioni tra sistemi.

Una convenzione per gli scoreboard

Usa nomi brevi ma chiari: points, stage, lives, timer. Documenta quale sistema li modifica. Nei progetti grandi evita che due meccaniche usino lo stesso objective per scopi diversi.

Selettori e sicurezza amministrativa

Su server reali, prova i comandi su un ambiente di staging o backup. Un selector sbagliato con /clear, /kill o /tp può influenzare molti utenti. La sintassi può essere corretta ma il target logicamente sbagliato.

Selettori per aree rettangolari

Non tutte le zone di gioco sono circolari. Una stanza, un corridoio o una piattaforma spesso si descrivono meglio come volume rettangolare. In Bedrock sono comuni coordinate di riferimento insieme a estensioni dx, dy e dz; Java offre forme equivalenti per definire volumi. Questo evita che un raggio includa giocatori al piano superiore o dietro una parete vicina. Quando progetti una mappa verticale, una box è spesso la scelta più affidabile.

Selettori e rotazione

Le sintassi avanzate possono filtrare anche in base alla rotazione o orientamento. È utile per sistemi che reagiscono quando un giocatore guarda in una certa direzione, ma aumenta la complessità. Prima di introdurre filtri di rotazione, assicurati di comprendere bene origine, assi e coordinate locali.

Selettori e livello esperienza

Java può filtrare player secondo livelli o altri parametri specifici. In un server RPG potresti aprire una porta soltanto a chi ha raggiunto una soglia. In Bedrock usa gli strumenti supportati dalla versione, spesso scoreboard quando vuoi una condizione numerica controllabile e multipiattaforma.

Selettori e advancement in Java

Java può usare filtri legati agli advancement in sistemi avanzati. Questo permette di selezionare chi ha completato un obiettivo vanilla o custom. È molto potente per datapack e mappe Java, ma non è un concetto da trasferire direttamente a Bedrock. Per progetti multipiattaforma, scoreboard e tag sono spesso più facili da replicare.

Selettori e NBT in Java

Java consente filtri NBT estremamente dettagliati, capaci di controllare dati di entità. Sono potenti ma possono essere costosi se usati in modo indiscriminato ogni tick su grandi quantità di entità. Quando puoi ottenere lo stesso risultato con tag, score o predicate, valuta la soluzione più efficiente e leggibile.

Predicate e selector Java

I predicate dei datapack permettono di spostare condizioni complesse fuori dal comando e richiamarle in modo più ordinato. Se un progetto cresce oltre pochi Command Block, questa organizzazione può essere molto più mantenibile. La guida base ai selector, però, dovrebbe partire da type, distance, tag e scores.

Selettori per un negozio

Immagina un negozio con un pulsante. Se usi semplicemente @p, una persona accanto potrebbe ricevere l’oggetto al posto dell’acquirente. Crea una piccola area individuale, limita la distanza e, se possibile, assegna un tag temporaneo a chi avvia l’acquisto. Poi tutti i comandi della catena usano quel tag. Alla fine rimuovilo.

Selettori per una porta automatica

Un Repeat Command Block può rilevare player in una zona e aprire una porta tramite /setblock, /fill o redstone. In questo caso @a con filtro di area è migliore di @p, perché più giocatori possono attraversare contemporaneamente. Il sistema deve chiudere la porta soltanto quando la zona è vuota.

Selettori per un checkpoint

Quando il player attraversa il checkpoint, selezionalo con una box stretta e usa /spawnpoint @s dentro un execute. Questo evita che un amico vicino riceva accidentalmente lo spawn. Aggiungi un tag “checkpoint_attivato” per impedire messaggi ripetuti ogni tick.

Selettori per un boss

Non selezionare il boss soltanto con il tipo di mob se possono esistere altre entità uguali. Dagli un tag univoco, per esempio boss_tempio. Tutti i comandi di vita, effetti, teleport e reset usano quel tag. Il sistema diventa più stabile e leggibile.

Selettori per spettatori

In un minigioco, filtra gli utenti Spectator fuori dai comandi destinati ai partecipanti. Se usi @a senza filtro, potresti dare kit, effetti o teletrasporti anche agli osservatori. Un tag partecipante è spesso più semplice di affidarsi soltanto alla gamemode.

Come evitare selezioni multiple indesiderate

Se un’azione deve riguardare una sola persona, assicurati che il selector possa restituire un solo target. @p lo fa per definizione, ma un selector @a filtrato potrebbe restituirne molti. In Java usa limit quando appropriato; in Bedrock usa gli strumenti equivalenti. Non affidarti al fatto che “normalmente c’è una sola persona”.

Come costruire selector leggibili

Un selector tecnicamente corretto ma lungo decine di argomenti può diventare difficile da mantenere. Usa tag per rappresentare stati complessi. Invece di ripetere cinque condizioni in ogni Command Block, un primo sistema assegna il tag eligible e le azioni successive selezionano @a[tag=eligible].

Tag temporanei

I tag temporanei sono molto utili per sequenze. All’inizio selezioni il target e aggiungi un tag. Tutta la Chain lavora su quel tag. Alla fine lo rimuovi. Così la persona scelta resta coerente anche se nel frattempo altri giocatori si avvicinano al Command Block.

Selector e funzioni

Nei datapack Java e nei behavior pack/ambienti Creator Bedrock, i comandi possono essere organizzati in funzioni. I selector restano gli stessi concettualmente, ma la struttura è più facile da mantenere rispetto a centinaia di Command Block fisici. Per progetti grandi considera questa evoluzione.

Esempi pratici Java

Tutti i player entro 10 blocchi

@a[distance=..10]

Tutti gli zombie entro 20

@e[type=minecraft:zombie,distance=..20]

Partecipanti con tag

@a[tag=partecipante]

Player con almeno 10 punti

@a[scores={points=10..}]

Zombie più vicino

@e[type=minecraft:zombie,sort=nearest,limit=1]

Esempi Bedrock

Bedrock usa @a, @p, @r, @s per player selector e @e per target generali. Filtri come tipo, raggio e box seguono la sintassi Bedrock. Usa /help e autocompletamento per verificare gli argomenti disponibili nel client aggiornato.

Checklist per un selector sicuro

1. Scegli il selector base.
2. Decidi se deve includere player o entità.
3. Filtra type se usi @e.
4. Limita zona o distanza.
5. Aggiungi tag/team/score se serve.
6. Controlla l’origine del comando.
7. Testa con un comando innocuo.
8. Solo dopo usa comandi distruttivi.

FAQ sui selettori

Cosa significa @p?

Il giocatore più vicino all’origine di esecuzione.

Cosa significa @a?

Tutti i giocatori compatibili con i filtri.

Cosa significa @e?

Tutte le entità compatibili con i filtri, inclusi i player.

Cosa significa @s?

L’esecutore corrente del comando.

Cosa significa @r?

Un giocatore casuale nelle sintassi compatibili.

Posso combinare più filtri?

Sì, ed è spesso la scelta migliore.

Java e Bedrock hanno gli stessi filtri?

No. I selector base sono simili, ma molti argomenti avanzati differiscono.

Conclusione

I selettori Minecraft sono la grammatica fondamentale dei sistemi a comandi. @p, @a, @e e @s permettono di sostituire nomi statici con target dinamici e, grazie ai filtri, di controllare esattamente chi deve ricevere un effetto, un item, un teletrasporto, uno spawnpoint o qualunque altra azione.

Dopo i selector, il passo successivo è capire le coordinate relative ~ e ^ e il comando /execute. I selettori dicono “chi”; le coordinate dicono “dove”; execute permette di cambiare “chi, dove e in quali condizioni” prima di eseguire il comando finale.