Cerca Totem's Lair su Facebook



Startup di un nuovo progetto
Successivo >


In questa serie di tutorial ho intenzione di adottare un approccio un po' diverso all'argomento. Nei precedenti tutorial ho usato come filo conduttore un unico progetto o gioco durante il cui sviluppo ho via via snocciolato le tecniche e le conoscenze richieste per procedere. Sono ancora convinto che un approccio di questo tipo sia il migliore per imparare, poiché motiva chi legge a vederne il risultato finale. Tuttavia i numerosi aspetti che XNA propone non si possono riassumere così facilmente in un percorso unico, a causa dell'eccessiva ristrettività che questo comporterebbe: usare solo grafica 2D, oppure disegnare solo un terreno o ancora usare solo modelli già pronti. Sono tutte sfaccettature dell'unica gemma. Perciò mi accingo a proporre un qualcosa del tipo "ricette di programmazione" o, se preferite, problema-soluzione: molti libri e blog su XNA procedono nello stesso modo. Prendete quindi quello che segue come un ricettacolo di problematiche comuni, spiegate e risolte nel modo più semplice ed elegante che io possa proporre.
Nei prossimi capitoli, userò come linguaggio di riferimento solamente C#. Infatti, avete potuto constatare che nonostante i miei sforzi per sposare XNA con VB.NET, questi mascalzoni non si piacciono poi tanto. In fin dei conti, è C# il principe del framework: tutti gli esempi online, tutta la documentazione, il framework stesso e la pipeline sono tutti scritti nello stesso C-esco linguaggio.


Cosa occorre
Per seguire questi tutorial occorre avere installato correttamente sulla propria macchina il framework .NET 4.0 (nessuna eccezione) e XNA Game Studio 4.0, oltre che Visual Studio 2010 o una delle relative versioni Express, come ad esempio Visual C# Express 2010, che io stesso userò nel corso di tutta l'esposizione. Se siete, come me, abbastanza pigri, vi fornisco subito tutti i link:

Nuovo progetto
Per prima cosa, dopo aver aperto l'IDE (ed eventualmente dopo averlo configurato se non eravate ancora passati a questa versione), selezionate dal menù File la voce New Project, Nuovo Progetto, quindi scegliete Windows Game 4.0. Tutti gli esempi che farò prenderanno in considerzione videogiochi per PC e non per Xbox. Ci sono alcune differenze significative tra le due versioni e se avete la console casalinga di Microsoft, vi suggerisco di documentarvi in giro prima di iniziare un nuovo progetto per Xbox. Uno dei migliori blog per XNA è questo.


Il template standard è il seguente:
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Media;

namespace XNA4_Tutorial
{
    /// <summary>
    /// This is the main type for your game
    /// </summary>
    public class Game1 : Microsoft.Xna.Framework.Game
    {
        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        public Game1()
        {
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";
        }

        /// <summary>
        /// Allows the game to perform any initialization it needs to before starting to run.
        /// This is where it can query for any required services and load any non-graphic
        /// related content.  Calling base.Initialize will enumerate through any components
        /// and initialize them as well.
        /// </summary>
        protected override void Initialize()
        {
            // TODO: Add your initialization logic here

            base.Initialize();
        }

        /// <summary>
        /// LoadContent will be called once per game and is the place to load
        /// all of your content.
        /// </summary>
        protected override void LoadContent()
        {
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);

            // TODO: use this.Content to load your game content here
        }

        /// <summary>
        /// UnloadContent will be called once per game and is the place to unload
        /// all content.
        /// </summary>
        protected override void UnloadContent()
        {
            // TODO: Unload any non ContentManager content here
        }

        /// <summary>
        /// Allows the game to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing audio.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Update(GameTime gameTime)
        {
            // Allows the game to exit
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
                this.Exit();

            // TODO: Add your update logic here

            base.Update(gameTime);
        }

        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.CornflowerBlue);

            // TODO: Add your drawing code here

            base.Draw(gameTime);
        }
    }
}
Potete tranquillamente togliere tutti i riferimenti e gli using per le seguenti librerie, a meno che non siate da subito intenzionati da usarli: Inoltre, rimuovete tutti i commenti di documentazione. Una volta visto cosa c'è scritto dentro, non vi serviranno più.


Polling vs Event-driven
Se avete seguito la mia guida sul VB.NET oppure programmate già da tempo per ambienti desktop, saprete che Windows Forms e WPF sono due tecnologie fortemente event-driven, ossia sono gli eventi che dirigono tutta l'applicazione. Il programmatore scrive solo cosa fare in risposta a un dato devento e non governa da solo il flusso di esecuzione del programma. Va da sé che la struttura ad oggetti si sposa bene con gli eventi e questi ambienti di programmazione ci hanno abituato a questo stile di pensiero. Ebbene, XNA, diversamente da quanto ci si potrebbe aspettare, non adotta lo stesso punto di vista. Il suo framework è molto più gerarchico e tipizzato ed adotta un sistema di polling per conoscere lo stato attuale dell'input. Ossia, invece di stare in ascolto di eventi e gestirli quando, ad esempio, il giocatore preme un tasto o muove il muose, il programma interroga continuamente le periferiche e ne analizza lo stato: se trova corrispondenze con gli schemi di input forniti dal programmatore, esegue una certa logica di aggiornamento. Questo approccio è abbastanza a basso livello da consentire a chi scrive il codice di separare logica di aggiornamento da logica di disegno, sapere quando esse vengono eseguite e rallentare o velocizzare l'una o l'altra a seconda delle performance desiderate.
Come avete potuto notare, lo sviluppo di un gioco si svolge attraverso l'overloading verticale dei metodi in una classe derivata da Game. Infatti il codice di avvio del gioco è veramente stringato:
using System;

namespace XNA4_Tutorial
{
#if WINDOWS || XBOX
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        static void Main(string[] args)
        {
            using (Game1 game = new Game1())
            {
                game.Run();
            }
        }
    }
#endif
}
I metodi definiti nel corpo del template vengono richiamati in ordine nel seguente modo:
  1. Game1() : il costruttore dell'oggetto Game, richiamato nel blocco using di Main, definita in Program.cs . Qui vengono inizializzati gli oggetti di gestione fondamentali, come il content manager e il graphic device manager, di cui parlerò meglio in seguito;
  2. Initialize() : contiene la logica di inizializzazione. Tutti gli oggetti che costituiscono la "business logic", oggetti che non occupano risorse se non la memoria, come ad esempio liste, dizionari, oggetti per calcoli, oggetti di gestione, eccetera... vanno inizializzati qui. Anche cambiamenti di risoluzione, della modalità fullscreen e del mouse vanno aggiunti qui. È possibile modificare questi ultimi parametri in modo semplice tramite il gestore del dispositivo grafico, contenuto nella variabile privata d'istanza graphics, ad esempio:
    protected override void Initialize()
    {
        base.Initialize();
    
        // Attiva un buffer per il multisampling, una tecnica di anti-aliasing che permette di
        // smussare linee troppo rigide e di evitare il fastidioso effetto "spezzezzato" che
        // alcune primitive possono assumere se lo schermo ha una risoluzione troppo bassa o
        // se sono troppo lontane
        graphics.PreferMultiSampling = true;
        // Imposta larghezza e altezza del back-buffer, che si riflettono direttamente sulla
        // risoluzione della scena finale. Potete modificare queste impostazioni, ad esempio,
        // caricandole da un  file di configurazione
        graphics.PreferredBackBufferWidth = 1920;
        graphics.PreferredBackBufferHeight = 1080;
        // Attiva la sincronia verticale (vsync), ossia evita che un frame sia renderizzato prima
        // che tutte le file di pixel che lo compongono siano state calcolate correttamente.
        // Riduce il frame rate, ma toglie lo sfarfallio dovuto alle operazioni di rendering
        graphics.SynchronizeWithVerticalRetrace = true;
        // Imposta un profilo di alto livello per la grafica del gioco. I due unici valori
        // consentiti dall'enumeratore sono HiDef e Reach. Tra il primo e il secondo cambiano
        // moltissimi dettagli, troppo specifici per essere spiegati ora. Comunque
        // l'utilità di questa proprietà è palese: consentire
        // all'applicazione di avere prestazioni ottime oppure sacrificarne una parte per
        // diminuire di molto i requisiti hardware richiesti.
        graphics.GraphicsProfile = GraphicsProfile.HiDef;
        // Attiva la modalità a tutto schermo
        graphics.IsFullScreen = true;
        // Applica i cambiamenti effettuati tramite graphics
        graphics.ApplyChanges();
        // Render il cursore del mouse visibile anche dentro la finestra del gioco
        this.IsMouseVisible = false;
        
        // Il gioco può essere temporizzato in due modi: fisso o variabile. Se il timestep è
        // fisso, il metodo Update, che aggiorna la scena, verrà richiamato ogni delta di tempo
        // prefissato (il valore di TargetElapsedTime). In caso contrario, verrà invocato quando
        // opportuno tra due chiamate Draw.
        this.IsFixedTimeStep = true;
        // Imposta il passo fisso a 60fps
        this.TargetElapsedTime = TimeSpan.FromSeconds(1.0 / 60.0);
    }
  3. LoadContent() : carica gli asset (risorse grafiche come texture, modelli 3D, shader, font) necessari per avviare il gioco. Inoltre, inizializza e carica i componenti di gioco
  4. Update(gameTime), Draw(gameTime) : di norma, dopo l'inizializzazione, questi due metodi vengono chiamati alternativamente. Update serve ad aggiornare il mondo di gioco, a calcolare collisioni, punteggi, nemici, scene e tutte le situazioni in generale; base.Update(gameTime) si occupa di richiamare lo stesso metodo Update su tutti i componenti del gioco (nel prossimo capitolo spiegherò meglio). Analogamente, Draw disegna tutto ciò che è visibile sulla scena, sia essa 2D o 3D, interfaccia compresa; base.Draw(gameTime) si occupa di richiamare lo stesso metodo Draw su tutti i componenti del gioco che hanno una rappresentazione grafica
  5. UnloadContent() : rilascia tutti gli asset utilizzati. Di norma non serve scrivere nulla in questo metodo, a meno di non lavorare con risorse non gestite


Successivo >