AMBUSH POINTS
Vi piace un gioco frenetico ma volete pure provare il piacere di subire imboscate dai vostri amici robot? Posizionate un paio di "AmbushPoint" allora...
Se nella mappa che avete disegnato ci sono punti vantaggiosi da cui fare i cecchini (bello...) con tanto di SniperRifle o ShockRifle, non dovete far altro che posizionare nel punto esatto un "AmbushPoint", che troverete nel solito menu' "NavigationPoint"; unica preoccupazione sara' rendere davvero utile, per un bot, un punto di agguato. Questo Actor infatti e' DIREZIONALE; dovrete cioe' ruotarlo nella direzione in cui dovra' guardare il bot "bastardo", e dovrete pure settare il "Cecchinaggio" e la distanza massima alla quale il bot "reagira'". Nelle proprieta' dell'AmbushPoint, proprio sotto la voce "AmbushPoint", troverete due sole opzioni:
"bSniping": se settato su TRUE il bot cecchinera' col fucile mantenendo la posizione
"SightRadius": di default 5000, rappresenta la distanza ideale alla quale il bot prestera' attenzione.
NON SOLO DEATHMATCH...
Per chi si volesse cimentare nella realizzazione di mappe CTF (Cattura la Bandiera), e' fondamentale saper posizionare le basi con rispettiva bandiera per ogni squadra. Il Navigation Point in questione e' il "FlagBase", selezionabile direttamente nel menu' NavigationPoint, all'interno di quello degli Actors. L'unica opzione da settare nelle sue proprieta' e' proprio sotto la voce, udite udite, "FlagBase"; "TEAM" dovra' valere 0 o 1 (Rosso o Blu). Posizionate quindi le due FlagBase all'interno delle basi avversarie e personalizzatene una rossa e l'altra...uhmmm....blu?...
L'equivalente della bandiera per la modalita' di gioco DOMINATION e' il "ControlPoint", rappresentato nel gioco e nello stesso UnrealED come una grossa X rotante. Non ci sono particolari opzioni da settare ed e' sufficiente posizionarne 3 (almeno cosi' e' la norma) andando a selezionarli nel menu' NavigationPoint.
Sia la modalita' di gioco CTF che la Domination, prevedono la possibilita' di inserire, in punti particolarmente strategici, uno o piu' "DefensePoint" per i bot, che altro non sono che postazioni di difesa particolarmente favorevoli, dalle quali proteggere la propria bandiera o il ControlPoint appena conquistato; in questo caso si tratta di espandere la voce "AmbushPoint" e selezionare "DefensePoint". Nelle proprieta' dell'actor, aprendo la voce "DefensePoint", potrete attribuirlo ad una squadra in particolare (per il CTF) e, soprattutto, dare alla postazione una sua priorita'; i bot, cioe', assumeranno prima le posizioni di difesa con priorita' piu' alta (valori minori). Ricordatevi anche che il DefensePoint e' direzionale proprio come l'AmbushPoint: sta a voi quindi orientarlo al meglio perche' sia rivolto...dove serva!
EDITING: Lez. Avanzata n°1- OTTIMIZZAZIONE: I "POLIGONI ROSA"
E' MEGLIO ROSA?
Giusto l'altra sera (14.9.2000) era venuta fuori una discussione animata sui reali vantaggi nell'utilizzo nell'UnrealED dei poligoni "rosa" al posto di quelli "normali". Bisogna intanto chiarire, per quanto possibile, cosa volesse dire "rosa" e "normale".
Quando noi andiamo ad aggiungere, usando la funzione "ADD", un qualunque poligono di una qualsivoglia forma, questo viene rappresentato di default con il colore BLU. Immaginiamo quindi una colonna, un tavolo, una tubatura...etc..
Abbiamo diverse possibilita', in realta', di aggiungere uno stesso poligono; avrei voluto parlare di queste cose solo piu' avanti nelle lezioni normali, ma qui saro' comunque molto conciso e poco tecnico. Ad ogni modo, una volta stampato il poligono, esiste, nelle sue proprieta' sotto la voce "BRUSH", un'opzione chiamata "POLY FLAGS"; di default vale 0 (zero), ed apparentemente non ci sono altre scelte preimpostate e dobbiamo inserire manualmente NOI altri valori.
Se inseriamo 32 al posto di 0 avremo il famoso poligono "rosa". La domanda sorge spontanea: perche' mai dovremmo andare ad editare delle proprieta' dei normali poligoni, quando questi sembrano gia' andar bene cosi'? Semplice! I poligoni rosa vengono considerati diversamente dal motore del gioco...diciamo..."meno importanti" se si puo' dire cosi'. Un poligono normale ha consistenza, mostra le "decals" e si comporta con usuale solidita'; lo stesso vale per il poligono rosa. Il poligono rosa pero' è piu' "leggero" da muovere in quanto viene definito, in fase di "rebuild", da un minor numero di nodi; e chi usa l'UnrealED sa che guadagno questo rappresenti in termini di frame rate finale...
Per dimostrare la validita' di cio' che dico e' sufficiente costruirsi una stanza cubica e posizionare un sacco di poligoni (cubi o cilindri...o quello che volete), in maniera da avere una loro vista d'insieme almeno da un punto della stanza. La stessa mappa di prova verra' tirata su una seconda volta TOTALMENTE IDENTICA MA CON POLIGONI ROSA; bastera' misurare il frame rate dell'una e dell'altra per accorgersi...di alcune cosette.
A questo scopo ho inserito nella mia stanza un buon numero di "travi" e due cilindri: non erano importanti le dimensioni, ma il numero dei nodi che li componevano! Siccome poi il frame rate sarebbe risultato troppo alto per fare comparazioni, ho posizionato due belle luci rosse che appesantissero il carico di lavoro finale. Questo era lo "schifo" da me realizzato per il test: veramente ottimo per lo scopo!
La foto e' una sola, proprio perche', all'apparenza, non si notano differenze tra le due stanze! La prima ha travi e cilindri "normali", la seconda ha gli stessi "rosa".
Ebbene, utilizzando il "timedemo" (da console o da menu', e' indifferente), ho ottenuto questi risultati, per un primo punto di vista:
POLYS NODES BSP ratio frames/sec
STANZA "NORMALE" 212 518 2.44:1 58.5
STANZA "ROSA" 203 337 1.66:1 65.5
Questo punto di vista inquadrava tutte le strutture aggiunte, viste da media distanza.
Il frame rate e' stato poi misurato da una seconda visuale, molto piu' vicina ai poligoni in questione, e sono stati ottenuti questi risultati:
STANZA "NORMALE": 48.1 frames/sec
STANZA "ROSA": 58.7 frames/sec (!!)
Da tutte queste cose, cosa si deduce? Tanto per cominciare si nota, per i poligoni con POLY FLAGS=32 anziche' 0, un notevole calo (quasi la meta') del numero di nodi considerati e, di fatto, calcolati e mossi, unitamente ad un conseguente miglioramento del valore di BSP. Valori alti corrispondono infatti a mappe piu' pesanti, a parita' di numero di poligoni.
Altra cosa interessante riguarda il fatto che, avvicinandosi alle strutture interessate (e rendendo quindi ininfluente il "peso" della stanza in se', comunque da calcolare), la differenza di prestazioni si fa piu' decisa!
Se infatti e' evidente che non notiamo differenze apprezzabili tra 58 e 65 fps, e' altresi' ovvio che per mappe vere e proprie dove spesso si scende sotto i 20 fps, l'utilizzo o meno di questi poligoni puo' significare MAGGIORE FLUIDITA' APPREZZABILE! Probabilmente, ripetendo il test con un numero decuplicato di strutture, avremmo notato una spiccata, se non fondamentale, importanza nella nostra scelta del POLY FLAGS, che ne dite? Ognuno poi ha una sua macchina su cui far girare UT; processori piu' "anziani" risentiranno sicuramente in misura maggiore di queste accortezze...
DOVE STA LA FREGATURA???
Gia', perche' la fregatura c'e', e bisogna tenerne conto. Non e' assolutamente possibile infatti realizzare una mappa totalmente composta da poligoni aggiunti "rosa"; questo a causa delle caratteristiche degli stessi, che li rendono si piu' efficienti in fase di rebuild di una mappa, ma che spesso causano errori di BSP o fenomeni di intersezioni o collisioni "poco simpatiche" al momento del gioco vero e proprio. Mi spiego meglio.
In poche parole si tende a far uso di un poligono rosa quando questo non viene direttamente in contatto con i giocatori all'interno della mappa. Strutture poste in alto o comunque lontane, decorazioni come torri "di figura", pennoni o travi sui soffitti, non verranno necessariamente in contatto con i giocatori, e manterranno intatte tutte le caratteristiche di fisicita' dei poligoni normali. Se provaste a fare un pavimento rosa, potrebbe non andarvi come volete: potreste per esempio (e' capitato a me) camminarci dentro fino al vostro ginocchio virtuale! Una colonna puramente di figura, invece, potra' tutt'al piu' trovarsi a contrasto laterale con voi, che certo non ci dovrete camminare sopra!
Nei poligoni rosa poi, NON si puo' scavare o sottrarre alcunche', con conseguente limitazione nel loro uso. Solo poligoni "pieni", quindi, e non troppo "a rischio".
Ovvio pero' che, dove questo sia possibile, e' doveroso (ammesso che vogliate ottimizzare la mappa..) utilizzare un poligono rosa al posto di uno...blu! Per capire al volo cosa normalmente costruire rosa, basta aprire con l'editor una mappa del gioco originale e vedere che uso fanno di quei poligoni i "grossi" level designers; se poi un poligono inizialmente rosa vi dovesse creare problemi, bastera' scrivere nuovamente 0 alla voce POLY FLAGS (sotto "BRUSH") e ricompilare il tutto. Tutto qui.
EDITING: Lez. Avanzata n°2- BOTS: PERCORSI "ROSSI" E "BLU"
(tutorial a cura di Marco Sabbadini)
Quando UnrealED ricostruisce i percorsi che connettono i vari pathnodes della mappa cosi' come gli oggetti, attribuisce alle direttrici (le linee visibili di interconnessione) una priorita' . Durante il gioco, i bot seguiranno di preferenza la strada piu' breve per raggiungere il proprio object-order e la scelta verra' condizionata anche dall'attributo di priorita' assegnato da UnrealED alle direttrici. Le linee blu identificano i percorsi preferenziali, mentre quelli secondari sono indicati con un tratto rosso. Di norma, i bot eviteranno di seguire i percorsi rossi: puo' accadere che certe zone della mappa collegate solo tramite percorsi secondari non vengano mai esplorante nonostante contengano armi o bonus. Per "incentivare" i bot e' possbile incrementare l'appetibilita' degli oggetti in queste zone (Inventory>MaxDesireability) o disseminare lungo il percorso munizioni o HealthVial +10.
In base a quali parametri UnrealED decide se la direttrice sara' principale o secondaria? Costruiamo una semplice stanza vuota ai cui opposti estremi metteremo dei pathnodes
Ricompilando la mappa, noteremo che una direttrice blu collega i due NavigationPoints. Ora costruiamo 2 ostacoli che metteremo uno di fronte all'altro ai lati della direttrice. Se il passaggio che si viene a creare e' piu' stretto di 128 World Units, ricompilando la mappa, il percorso verra' identificato come rosso e' cioe' secondario:
Dunque possiamo concludere che un importante criterio utilizzato UnrealED per determinare la priorita' dei percorsi e' la dimensione dei passaggi. Sebbene i bot possano utilizzare aperture larghe anche solo 64 World Units, nei giochi di squadra potrebbe crearsi qualche "ingorgo" nei passaggi piu' stretti di 128 World Units. Si veda a proposito un'immagine tratta da una mia mappa Assault:
UnrealED non permette di posizionare pathnode in passaggi stretti, caratteristica che molti tendono ad imputare erroneamente ad un bug del programma, e che aggirano trascinando nella posizione voluta dei NavigationPoints creati altrove.
Per osservare e comprendere meglio il comportamento dei bot consiglio di utilizzare l'utilissimo mutator Mind Reader che permette di vedere i percorsi intrapresi, e il comportamneto dell'intelligenza artificiale nelle vostre mappe.
EDITING: Lez. Avanzata n°3- L'ATTRIBUTO SPECIAL LIT
(tutorial a cura di Marco Sabbadini)
Fra le proprieta' delle luci alla voce "Lighting" vi e' un attributo molto importante, usato frequentemente nelle mappe di UT, di cui molte persone ignorano, pero', l'esistenza. Per comprendere meglio il funzionamento di quest'estensione, ho realizzato un semplice esempio che guida, passo dopo passo, alla comprensione del suo funzionamento, e dei suoi molti vantaggi.
Con UnrealED, creariamo una semplice stanza rettangolare, ai cui estremi opposti mettiamo due sorgenti di luce. Per distinguere meglio il contributo che queste apportano all'illuminazione della stanza, assegnamo a loro due colori diversi (Es. Rosso e Blu). Compilando la mappa, otterremo qualcosa di molto simile a questa figura:
Ora agiamo sulle proprieta' della luce rossa, impostando l'attributo "bSpecialLit" su "True":
Ripetiamo di nuovo il raytracing e cosi' constatiamo che la luce rossa non e' piu' utilizzata nel calcolo delle sorgenti luminose che contribuiscono all'illuminazione della stanza:
Modifichiamo, ora, le proprieta' di una delle pareti della stanza, selezionando l'attributo "Special Lit":
Eseguendo un nuovo raytracing constateremo come questa parete venga illuminata dalla sola luce rossa, cioe' da quella il cui attributo "bSpecialLit" e' impostato su "True":
Si vengono a creare due sistemi di illuminazione fra di loro indipendenti, i cui effetti NON si sovrappongono. Basta confrontare la figura 1 con la figura 5 per rendersi conto della differenza. Inoltre tutte le superfici che possiedono l'attributo "Special Lit" sono aree statiche, non risentono degli effetti di illuminazionedovuti ad esplosioni, sorgenti dinamiche ecc. Per contro le sorgenti di luce con attributo "bSpecialLit", non influenzano gli attori e tutte quelle strutture con illuminazione dinamica (ScreenShot: la pistola e' illuminata dalla sola luce blu).
E' ragionevole pensare che le superfici "Special Lit" siano piu' veloci da processare e che stressino in maniera minore UnrealEngine. L'uso dell'iiluminazione speciale e' spesso associato alla proprieta' "Bright Corners", nei modelli di lampade con superfici molto luminose (o con colori brillanti e diversi dalla luce neutra), senza, per questo creare problemi all'illuminazione delle zone circostanti.
That's All Folks!!!!
Se volete vi passo la mia mappa!!!!