La Parte più Difficile

In attesa di finire un grosso articolo, vi sollazzerò con qualche rilessione.

Vi siete mai chiesti quale sia la parte più complessa nel fare un gioco? Io, quando ero più giovine, talune volte me lo chiedevo.

In generale, ho sempre ritenuto che la parte complessa fosse l’engine 3D, o comunque tutta la parte grafica.

Questo dev’essere stato un po’ il pensiero di tutti quanti, difatti, cercando su Internet, si trovano una valanga di engine già fatti (tra cui mi viene in mente Ogre e Irrilicht), ma bel poco di tutto il resto.

Oggi è spuntato un nuovo tema: gli engine fisici. Sviluppare un engine fisico è una cosa praticamente impossibile se non si ha una formazione dal punto di vista della fisica, ma fattibile (se vengono dati il giusto tempo e le giuste risorse) da chi invece ce l’ha.

Io non ho una formazione fisica adeguata ed immagino che molti miei colleghi non l’abbiano, difatti ci sono molti engine fisici disponibili.

Ma il resto? Il resto è tanto banale? No, assolutamente. Spesso leggiamo sulle riviste frasi come: “Che ci voleva aggiungere questo e quello? E’ banale!”

Beh, purtroppo, non esiste niente di banale. Purtroppo, l’ultima frase non era una frase fatta.

Una cosa considerata semplice e sottovalutata (fino all’avvento del Wii) è l’input, ad esempio.

Proviamo a pensarci: l’input è una cosa che avviene in maniera del tutto asincrona (ossia, quando uno schiaccia, schiaccia 😀 ), in più cambia da piattaforma a piattaforma.

Su PS2, ad esempio, abbiamo due stick analogici, un po’ di tasti analogici e qualche tasto binario (schiacciato/non schiacciato).

Su 360 abbiamo una roba simile, ma sbilanciata sui tasti binari. Su PC abbiamo un milione di tasti binari ed un mouse.

Poi arriva il Wii con i suoi due accelerometri, il suo puntatore ed i suoi tasti.

In più l’Input varia a seconda di dove siamo: nei menù ci sarà un tipo di Input, mentre nel resto del gioco un’altro tipo.

La gestione non è banale.

Ho detto menù? Ecco un vero massacro.

Gestire i menù è un problema sottovalutato, difatti non si trovano molte librerie. Le uniche buone, tra l’altro, sono a pagamento. Un SONTUOSO pagamento.

Perchè?

Perchè creare menù non significa solo scegliere qualcosa su schermo, significa tutto questo:

  • – Dare ad un grafico uno strumento per fare i menù
  • – Agganciare gli eventi dei menù a del codice
  • – Gestire una serie di controlli standard.
  • – Andare su più piattaforme.

Un’idea è usare Flash: il formato è noto e i grafici lo conoscono già.

In più non bisogna farsi lo strumento per i grafici.

Purtroppo facendo così complica molto la possibilità di fare menù con elementi 3D: Flash non lo supporta.

Credo di poter stimare che una gestione dei menù e degli overprint (ossia la roba 2d che sta sul 3d, tipo le barre di energia) copra tranquillamente un buon 20% nel making di un gioco ed un 40% del making dei tools.

Un’altra cosa spesso sottovalutata è la faccenda dei save-game. I Save-game ad oggi sono considerati assolutamente standard ed un gioco che non li abbia è considerato “limitato”, almeno su PC.

Ma perchè su PC i save-game sono fattibili “in ogni momento” mentre su console in genere ci sono i checkpoint?

Semplice: anche i save-game non sono un problema banale 😀

Pensiamoci un secondo: se voglio salvare in ogni momento, in un FPS, dovrò salvare la mia posizione, il livello in cui sono, la posizione dei nemici ed il loro stato, tutti i miei dati e tutto quello che concerne la roba già fatta (oggetti, dialoghi già seguiti e cose simili).

Se ho i checkpoint, salvo in che checkpoint sono, i miei dati ed ho risolto 🙂

La differenza sta nella dimensione: sulle console vecchie (Ps2 in giù) lo spazio per i savegame era molto limitato.

Poi ci sono i casi in cui si può salvare dove si vuole anche su console. Questo dimostra che in questo caso i save-game sono stati oggetti di analisi e di ottimizzazione.

Niente di banale, quindi.

Purtroppo il mondo è così: guardiamo i poligoni e pensiamo che il subsurface scattering (che parolone 😀 Usatelo per stupire gli amici) sia la cosa più difficile che vediamo sullo schermo, mentre probabilmente ha richiesto 3 giorni.

Il sistema che disegna e gestisce il menù dei personaggi di Final Fantasy 6, invece, probabilmente di giorni ne ha richiesti almeno il triplo (se non il decuplo).

Beh, dopotutto tutti noi lo sappiamo: il mondo è ingiusto 🙂

15 commenti su “La Parte più Difficile

  1. dal basso delle quattro banalità in croce(pure scritte male) che di solito posti,non si capisce come tu ti possa prendere il lusso di vomitare insulti su tutti i professionisti del settore o su progetti di ottimo livello come quello di babel. fossi in te un pochino mi vergognerei.

  2. riguardo a Monopoli : ma non eri stato bannato? ^^

    riguardo ai save-game su console: come posso dimenticare quando ho salvato con TOMB RAIDER 2 senza accorgermi che un proiettile era nell’aria alle mie spalle, verso la fine di un livello che consideravo impossibile?

  3. manu, sarebbero ritenuti preziosi commenti attinenti all’articolo. In particolare, potresti dimostrare che è banale indicandoci chi altro parla di queste cose (in Italia).

    JacoPOP, sì, fu bannato ed è stata una decisione travagliata reintegrarlo.

  4. Sviluppare un engine fisico è difficile per chi non conosce la fisica? Wow, chi l’avrebbe mai detto? e io che pensavo che qualsiasi casalinga con la terza media potesse farlo!

    il metodo di controllo del Wii è diverso da quello delle altre console? ma pensa un po’,e io che credevo che la gente lo comprasse per la sua potenza grafica!!

    Flash non è adatto per fare menù in 3d?? non ci sarei mai arrivato senza monopoli

    i savegame sono complicati da fare perchè bisogna salvare la posizione di tutti i nemici ecc ecc, e poi su console sono diversi da quelli su pc perchè le vecchie console avevano problemi di spazio? essì, non ne parla proprio nessuno(penso che qualsiasi ragazzo che posta in un forum di videogiochi ne sia perfettamente consapevole…)

    ovviamente se non trattasse come pezze da piedi, non perdendo occasione di dare sfoggio alla propria maleducazione, persone che scrivono cose molto meno banali (pur tirandosela molto di meno) non sarei intervenuto.

    ma vedo che a voi di ars ludica piace supportare questi personaggi.

  5. Rispondo.

    Engine fisico: Ovviamente se non si hanno conoscenze nella fisica, è difficile scriversi un engine fisico. Banale, dirai, ma molto spesso troviamo giochi con una fisica appena abbozzata, proprio perchè i programmatori, invece che utilizzare un prodotto già fatto, hanno sottostimato il problema, ritenendo che per le loro richieste non fosse necessario.
    Purtroppo, molto spesso, quando si parla di fisica, per quanto le esigenze possano essere basse, è richiesto un sistema complesso e completo.

    Flash per i menù: la ditta “Anark” sostiene che l’uso di Flash è inadatto, poichè è necessario farsi i convertitori ed un sacco di lavori per gli script. Ovviamente lo fa per spingere l’acquisto dei suoi costosi (e bellissimi, tra l’altro) tools.
    Io ritengo che invece sia adatto per i menù 2D, nonostante il costo del fare gli exporter.

    I Savegame: i ragazzi nei forum lo sanno, però spesso ci si chiede perchè il Zelda non si può salvare dove si vuole. Forse non è così scontato e banale.

    Sul mio comportamento: mi butto fondamentalmente contro i personaggi che parlano di argomenti tecnici senza sapere quel che scrivono, scrivendo lapalissiani errori.
    Ad esempio la recensione su Babel di Halo3, oppure la recensione TF2 su TGM, oppure il technoTGM sull’AI.

    Tutti questi casi mi hanno portato ad avere una opinione molto negativa dei giornalisti italiani di videogiochi, come potrai intuire: molto spesso preferiscono l’adettotica ed il vuoto sproloquio al conoscere i giochi da un punto di visto più profondo.

    Spero che questa risposta ti possa aiutare a capire. Ti prego in futuro di non offendere i miei colleghi per causa mia.

  6. ma vedo che a voi di ars ludica piace supportare questi personaggi.

    A “noi di Ars Ludica” piace dare voce alla più ampia parte di opinioni possibile. Personalmente non apprezzo molto il modo spesso “sproporzionato all’offesa” che ha Monopoli di criticare, ma i suoi articoli su questo blog si esprimono in modo costruttivo e a mio parere interessante. Questo in particolare suggerisce molti spunti di approfondimento, e se qualcosa in particolare di quanto ha scritto può essere banale, non lo è il complesso (che, per essere completo, deve includere anche il banale).

    (lo dico perché pubblicherò un mio articolo banalissimo xD)

  7. Bravo manu! però tu di sviluppo non ne sai una ceppa ed i suggerimenti
    di Monopoli per le giovani leve sono molto utili. Quelle che tu chiami
    banalità sono invece realtà, spesso trascurate: se diversi anni fa avessi
    potuto avere un punto di riferimento come gli articoli di Monopoli e come
    i suoi post su developpare, probabilmente avrei speso meno tempo nello
    sbattere la testa su determinate problematiche.

    L’angolino della vergogna è in fondo a destra.
    Ciao!

  8. Non ne ha interesse nessuno.
    Basterebbe un pò più di sale in zucca nel fare i post.
    Vabbè, do not need to feed the troll. Ho capito

  9. Personalmente m’è piaciuto e l’ho trovato interessante questo post. Ammetto di aver sempre sottovalutato la difficoltà di fare menù,che poi se ci pensate è la stessa di fare gui fighe come lo Smart Start di Nero,tanto bello quanto inutile.

  10. Articolo ben ragionato, ma su argomenti stra-conosciuti fin dalla prima “hello world” app. Tuttavia chi non sviluppa e gioca può usare queste considerazioni per capire cosa c’è dietro a quello che sta sullo schermo. Invece chi sviluppa dovrebbe già essersi avvertito da solo che tutto il lavoro ha bisogno di una solida direzione ben prima di scrivere la prima riga di codice. Ti ricordo inoltre che le CEGUI sono delle ottime librerie (licenza LGPL) per fare menu e altre amenità, e sono la scelta consigliata per OGRE. Questo per dire che hai ragione dicendo che cose “apparentemente” (ma per chi?) secondarie sono uno sbattone, ma infatti oramai ci sono librerie che fanno quasi tutto.
    Il problema – secondo me – è che le difficoltà inutili sgonfiano la creatività. Ci vorrebbero più strumenti intermedi (il famigerato middleware tipo virtools o unity3d) per sviluppare in fretta e poco sforzo le idee, vedere se funzionano, e poi casomai costruirci intorno un engine dedicato, fisica, input, e altri deliri…

    …tanto a quel punto lo sviluppo te lo paga la KONAMI 😉

  11. Ciao a tutti!

    Conosco bene la libreria CEGUI, ma purtroppo al di fuori dei prodotti non commerciali è difficile che possa uscire.

    In primo luogo gli strumenti di authoring non sono a livello: Flash è molto più potente. In più sono difficilmente portabili si console, visto che sono studiati per funzionare sull’hardware PC.
    Niente di impossibile, ma quando si valutano i costi, si immette la produzione dei tools di conversione e di authoring ed è probabile che aggiungere le funzionalità richieste a CEGUI costi di più che non usare un prodotto già fatto e noto (come Flash + qualcosa per il 3d o Anark Gameface).
    Se non ricordo male, ad esempio Halo2 ha usato director.

    Consideriamo che i menù vanno fatti dai grafici: dare a loro degli strumenti noti significa risparmiare molto tempo in formazione, avendo grafici produttivi da subito.

  12. sono in parte d’accordo. Flash è potente ma la conversione è un problema: e allora siamo dapprincipio dietro al problema di dover gestire inutile lavoro aggiuntivo. Poi il tuo punto è un po’ forzato: flash è molto potente, hai ragione, ma allora è uno “spreco” usarlo solo per il menu, perchè infatti il resto del gioco non è in flash. Allora qui c’è tutto un altro problema: flash non è un’applicazione opensource, è uno standard a cui in larga parte ti devi adeguare. Per carità, i grafici sono giustamente contenti: si leggono il manuale e via. Loro ci starebbero a farti il menu in flash. Se invece sei lo sviluppatore che deve adattare il menu alle diverse piattaforme forse non sei per nulla contento. Quindi sono d’accordo sul fatto che alcuni fattori fondamentali vengono spesso sottovalutati (leggi INPUT), ma il discorso è molto ampio. Sono punti critici perchè il mercato ha preso una piega infelice e chi risolverà il problema ne avrà un grande beneficio. Chi sviluppa vuole estendere, chi fa l’artista vorrebbe che gli strumenti fossero molto compatibili e stabili. C’è una tensione interna al sistema.
    Per questo insisto sul fatto che il futuro ed il presente dello sviluppo sia il middleware: sviluppi le idee da subito e ti fai già un’idea (se non te la sei già fatta) sul lavoro da fare.
    Unity3d è per mac ed è già ad un livello paragonabile al flash (con le dovute proporzioni): pubblica per mac Intelle e PPC, per windows, per il web (con il suo plugin per i browser) e, in futuro, wii e iphone. Anche qui però sono consapevole del fatto che il problema è l’estendibilità dello strumento, ma Unity sembra ben messo (permette la scrittura di plugin) e costa molto meno di virtools.
    199$ US per la versione Indie, non so se l’acquisterò (non sono un vero sviluppatore dopotutto) ma ci farò sicuramente un pensierino (magari faccio una partizione hackintosh sul pc di casa).

  13. >>Invece chi sviluppa dovrebbe già essersi avvertito da solo che tutto il lavoro ha bisogno di una solida direzione ben prima di scrivere la prima riga di codice

    Non è così banale come cosa, vallo a spiegare ad un perito
    appena uscito dall’istituto tecnico e prova a vedere come
    ti guarda. Personalmente reputo questi argomenti o meglio,
    considerazioni, preziosissime. Più di un blocco di codice.

Rispondi

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.