Sviluppo indipendente multipiattaforma

Alcuni anni fa, se hai scritto in C e alcuni sottoinsiemi di C ++ e hai utilizzato un numero sufficiente di astrazioni di piattaforma (tramite SDL o altro), potresti eseguire su ogni piattaforma su cui un indie potrebbe accedere - Linux, Windows, Mac OS di varie versioni , cose oscure come BeOS e console aperte come GP2X e Dreamcast post-morte. Se a un certo punto hai ottenuto un contratto per una piattaforma chiusa, puoi portare il tuo gioco su quella piattaforma anche con modifiche "minime" al codice.

Oggi, gli sviluppatori indipendenti devono utilizzare XNA per accedere a Xbox 360 (e al prossimo Windows Phone); non deve usare XNA per lavorare altrove tranne Windows; fino a poco tempo fa dovevo usare Java su Android; Flash non funziona sui telefoni, HTML5 non funziona su IE. A differenza, ad esempio, di DirectX vs. OpenGL o Windows vs. Unix, si tratta di modifiche alla lingua principale in cui si scrive il codice e che non è possibile documentare senza, fondamentalmente, scrivere un compilatore. Puoi spostare alcune logiche di gioco negli script e includere un interprete, tranne quando non puoi, perché l'SDK di iPhone non lo consente e le prestazioni ne risentono perché nessuno lo consente.

Quindi cosa puoi fare se vuoi un gioco portatile davvero multipiattaforma o anche solo un corpus significativo di motore e codice logico?

Questo non è un problema perché le piattaforme sono sostanzialmente divergenti - è semplicemente inutile cercare di indirizzare sia un iPhone che la Xbox 360 con un codice condiviso perché un gioco del genere sarebbe male? (Lo trovo molto improbabile. Posso facilmente vedere la voglia di condividere un gioco tra un telefono Windows Mobile e un Android, oppure una Xbox 360 e un iPad.) Le interfacce sono così di alto livello ora che il tempo di porting è trascurabile? (Potrei crederci per le applicazioni aziendali, ma non per i giochi con severi requisiti prestazionali.)

Questo diventerà più pronunciato in futuro? La divisione sarà, ancora un po 'spaventata, ancora in ribasso rispetto alle linee di vendita? Faremo affidamento su middleware di alto livello come Flash o Unity per eseguire operazioni multipiattaforma?

tl; dr - Il porting è un problema, sarà un problema più grande in futuro, e se sì come lo risolviamo?

Il motore Unity ti fa guadagnare un bel po 'di strada. Scrivi una volta e hai Mac / Windows Standalone e basato su webplayer. Modifica i tuoi input e pensa alle tue chiamate di disegno e sei su iOS / Android.

Per un piccolo sviluppatore indipendente, con fondi / tempo limitati (e forse più incentrato sul "rendere qualcosa di interessante" piuttosto che "rendere qualcosa di redditizio"), cercare di passare da una piattaforma all'altra potrebbe essere controproducente. Ci vuole molto sforzo per progettare solidi strumenti e tecnologie multipiattaforma (diverse API grafiche, endianness, dispositivi di input e altro) - tempo che potrebbe essere speso sul lato più creativo dello sviluppo del gioco.

Ma probabilmente vuoi assicurarti di avere un ottimo gioco che funzioni davvero bene su una piattaforma prima di preoccuparti troppo di metterlo su quante più piattaforme possibile! Se il gioco è un flop, non ha senso perdere tempo e fatica a renderlo un flop multipiattaforma, vero?

Se stai codificando in C / C ++, principalmente da zero, quindi finché mantieni il codice abbastanza modulare e prendi decisioni sensate su formati di dati e middleware / librerie, il supporto di altre piattaforme in seguito non dovrebbe essere troppo doloroso.

Se la tecnologia / strumenti multipiattaforma di terze parti (ad es. Unity) è un'opzione per il tuo progetto, allora vale sicuramente la pena prendere in considerazione.

Le principali "piattaforme problematiche" per gli indie sembrano essere i giochi indie Xbox360 (solo C #, accesso limitato alla rete, ecc.) E possibilmente Android (enormi differenze nelle prestazioni dei dispositivi / dimensioni dello schermo / dispositivi di input). Se sei determinato a supportarli, aspettati un lavoro di porting più considerevole o prevedi di concentrarti esclusivamente su di essi.

Dici sviluppo indipendente multipiattaforma . Il maggiore ostacolo quindi sono le risorse, e ciò significa mancanza di tempo per la maggior parte del tempo, ma anche mancanza di know-how e possibilmente finanze (costi di licenza, dispositivi di acquisto, ecc.).

Indie o no, il più grande ostacolo è in realtà il design. Come dici tu, un gioco che funziona su Xbox 360 e iPad potrebbe funzionare, ma devono anche essere sostanzialmente diversi in termini di design. Il 360 ha un controller, l'iPad un touch screen. Inoltre, lo sviluppo per 360 è fatto in Windows usando C # come linguaggio, l'iPad può essere indirizzato solo su computer Mac OS e usando C, C ++ o Objective-C. O Javascript, se preferisci. Alcune cose non si mescolano così bene, qualunque cosa tu faccia.

Quello che dici delle diverse piattaforme è vero oggi. Usa C / C ++ e SDL e puoi scrivere il tuo programma multipiattaforma su macchine simili a PC, probabilmente molto più agevolmente di anni fa. Tuttavia, è sempre stato un problema e rimarrà sempre un problema per il porting di giochi da PC a console su cellulare e viceversa. È appena diventato più pronunciato negli ultimi anni consentendo agli sviluppatori Indie di programmare per console (o sviluppatori che vi hackerano l'accesso per creare giochi homebrew) e dall'ascesa di dispositivi mobili abbastanza potenti da eseguire giochi.

Il porting ha gli stessi problemi che abbia mai avuto, ma ci sono più dispositivi su cui effettuare il port. E alcune porte non hanno senso senza riprogettare il nucleo del gioco. Questo non è un problema che può essere risolto, è uno che devi considerare fin dall'inizio anche prima di scrivere la tua prima riga di codice. Quindi sarà gestibile, né più né meno.

Penso che sia davvero necessario un framework di interfaccia semplice, portatile e aperto. Alcune riflessioni:

Al momento sembrano esserci quattro tipi comuni di metodi di input del gioco: tastiere, mouse, controller e superfici multi-touch. (Esaminerò i problemi delle diverse capacità tra cui, ad esempio, gamepad e joystick per ora, anche se alla fine questo dovrebbe essere affrontato.)

Idealmente, il nostro sviluppatore sarebbe in grado di specificare in modo generale alcune diverse interfacce utente che abbiano senso per il tipo di gioco che viene scritto. (Potrebbero decidere di fornire un'interfaccia utente tastiera e mouse, un'interfaccia utente solo mouse e un'interfaccia utente multi-touch, come esempio arbitrario.)

Il framework è quindi responsabile della mediazione di IO tra la piattaforma e il codice di gioco, in modo simile al funzionamento dei framework GUI multipiattaforma come QT e GTK.

Avere un tale framework non risolverebbe il problema dei requisiti linguistici incompatibili, ma almeno incapsulerebbe tutte le chiamate specifiche del sistema dietro un'API comune, il che dovrebbe rendere il porting della lingua molto più semplice.

Bene, ora che ho scritto tutto questo: qualcuno sa se esiste già un framework del genere?

Con progetti come MonoTouch e XNATouch sembrava che XNA potesse portarti sulla maggior parte delle piattaforme con un po 'di modifiche. Sfortunatamente Apple ha silurato che quando hanno cambiato i loro Termini e Condizioni per limitare le lingue che puoi usare. Unity ora attraversa praticamente tutto, anche se su XBOX ti porterà su XBLA ma non su XBLIG, quindi non è un'opzione per gli indie più piccoli.

Un approccio potrebbe essere quello di creare un framework che utilizza le stesse convenzioni su più lingue / piattaforme, quindi si tratta solo di modificare la sintassi dei giochi di porta. Potresti voler avviare il tuo gioco in Flash, che può essere sviluppato rapidamente e raggiungere un vasto pubblico, quindi se ha successo port su iPhone, XNA ecc. In questo modo sai di avere un gioco divertente prima di impegnarti troppo.

Penso che questo sia un problema economico, non tecnico. Piattaforme come xbox360 hanno un forte incentivo ad essere esclusive, perché stanno cercando di indurre gli utenti a scegliere la propria piattaforma anziché un'altra piattaforma. "Abbiamo questi fantastici giochi esclusivi" è molto più interessante di "possiamo anche giocare a questi giochi che tutti gli altri hanno". L'ecosistema è dominato dai produttori di hardware.

Ho il sospetto che questo cambierà quando maturerà il gameplay sui social network, perché potenzialmente ci sono molti più soldi nel far entrare tutti nello stesso sistema di social gaming che nel creare un altro FPS con una grafica sexy.

Ho appena scoperto Haxe e NME . Sostiene di essere un'app multipiattaforma che supporta tutti i principali desktop e dispositivi mobili e Flash, da una base di codice. Vale la pena dare un'occhiata.

Uno strumento di sviluppo multipiattaforma così nuovo che non raccomando necessariamente che sia http://www.monkeycoder.co.nz/

Colpisce ogni piattaforma che hai citato.

Sebbene sia troppo nuovo per giudicare davvero, ha un grande pedigree: il suo creatore ha precedentemente creato Blitz3D e BlitzMax, che erano ottimi strumenti di sviluppo per gli sviluppatori di giochi indipendenti.

Ho avuto fortuna con l'SDK airplay - almeno su x86 e apparentemente prende di mira bene l'iPhone (anche se non ho ancora ancora messo un'app su un iPhone).