Développement indépendant multiplateforme

Il y a quelques années, si vous écriviez en C et dans un sous-ensemble de C ++ et utilisiez un nombre suffisant d'abstractions de plate-forme (via SDL ou autre), vous pourriez exécuter toutes les plates-formes sur lesquelles un éditeur indépendant pourrait avoir accès - Linux, Windows, Mac OS, différentes versions. , des choses obscures comme BeOS, et les consoles ouvertes comme la GP2X et Dreamcast après la mort. Si vous avez un contrat pour une plate-forme fermée à un moment donné, vous pouvez également transférer votre jeu sur cette plate-forme avec des modifications de code "minimales".

Aujourd'hui, les développeurs indépendants doivent utiliser XNA pour accéder à la Xbox 360 (et au prochain téléphone Windows). ne devez pas utiliser XNA pour travailler ailleurs que sous Windows; jusqu'à récemment dû utiliser Java sur Android; Flash ne fonctionne pas sur les téléphones, HTML5 ne fonctionne pas sur IE. Contrairement à DirectX, par exemple, OpenGL ou Windows, par rapport à Unix, il s’agit de modifications apportées au langage principal dans lequel vous écrivez votre code et vous ne pouvez pas utiliser de papier sans l’écriture d’un compilateur. Vous pouvez déplacer une logique de jeu dans des scripts et inclure un interprète, sauf lorsque cela est impossible, car le kit de développement logiciel (SDK) de l'iPhone ne le permet pas et les performances s'en ressentent car personne ne permet JIT.

Alors, que pouvez-vous faire si vous voulez un jeu portable vraiment multi-plateforme, ou même juste un corps important de code moteur et logique?

N’est-ce pas un problème, car les plates-formes sont fondamentalement divergentes - il est tout simplement inutile d’essayer de cibler à la fois un iPhone et la Xbox 360 avec un code partagé, car un tel jeu serait mauvais? (Je trouve cela très improbable. Je peux facilement constater le désir de partager un jeu entre un téléphone Windows Mobile et un Android, ou une Xbox 360 et un iPad.) Les interfaces sont-elles d'un si haut niveau maintenant que le temps de transfert est négligeable? (Je pourrais le croire pour les applications professionnelles, mais pas pour les jeux dont les performances sont strictes.)

Est-ce que cela va devenir plus prononcé à l'avenir? Est-ce que la scission va être, un peu effrayante, toujours en bas de la liste des fournisseurs? Faudra-t-il tous utiliser un middleware de haut niveau tel que Flash ou Unity pour faire quelque chose de multi-plateforme?

tl; dr - Est-ce que le portage est un problème, sera-t-il un problème plus important à l'avenir, et si oui, comment le résolvons-nous?

Le moteur Unity vous procure une énorme part du chemin. Écrivez une fois et vous avez Mac / Windows autonome et basé sur le Web. Modifiez vos entrées et surveillez vos appels de tirages et vous êtes sur iOS / Android.

Pour un petit développeur indépendant, avec des fonds / temps limités (et peut-être davantage axé sur «créer quelque chose de cool» que sur «rendre quelque chose de rentable»), il pourrait être contre-productif de passer de l’avant à plusieurs plates-formes. Il faut beaucoup d'efforts pour concevoir de solides outils et technologies multi-plateformes (différentes API graphiques, endianness, périphériques de saisie, etc.) - du temps qui pourrait être consacré au côté plus créatif du développement de jeux.

Mais vous voulez probablement vous assurer que vous avez un grand jeu qui fonctionne vraiment bien sur une plate-forme avant de trop vous inquiéter de le faire sur autant de plates-formes que possible! Si le jeu est un flop, inutile de perdre du temps et des efforts pour en faire un flop multi-plateformes, n'est-ce pas?

Si vous codez en C / C ++, principalement à partir de rien, tant que vous gardez le code assez modulaire et que vous prenez des décisions judicieuses concernant les formats de données et les middleware / bibliothèques, la prise en charge ultérieure d'autres plateformes ne devrait pas être trop pénible.

Si des outils / technologies tiers multiplates-formes (par exemple, Unity) sont une option pour votre projet, cela vaut certainement la peine d'être envisagés.

Les principales «plates-formes problématiques» pour les indépendants semblent être les jeux indépendants Xbox 360 (C # uniquement, accès réseau limité, etc.) et éventuellement Android (différences énormes en termes de performances des périphériques / de taille d'écran / de périphériques d'entrée). Si vous êtes déterminé à les prendre en charge, attendez-vous à un travail de portage plus important ou prévoyez de vous concentrer exclusivement sur eux.

Vous dites développement indépendant multiplateforme . Les ressources constituent donc le principal obstacle, ce qui signifie la plupart du temps un manque de temps, mais également un manque de savoir-faire et éventuellement de finances (droits de licence, achat de dispositifs, etc.).

Indépendant ou pas, le plus gros obstacle est en réalité le design. Comme vous le dites, un jeu fonctionnant sur Xbox360 et iPad pourrait fonctionner, mais il doit également être fondamentalement différent en termes de conception. La 360 a un contrôleur, l'iPad un écran tactile. En outre, le développement de la 360 s'effectue sous Windows en utilisant C # comme langage. L'iPad ne peut être ciblé que sur des ordinateurs Mac OS et en C, C ++ ou Objective-C. Ou Javascript, si vous préférez. Certaines choses ne font pas bon ménage, quoi que vous fassiez.

Ce que vous dites à propos des différentes plateformes est vrai aujourd'hui. Utilisez C / C ++ et SDL et vous pouvez écrire votre programme multiplate-forme sur des machines de type PC, probablement beaucoup plus harmonieusement qu’il ya des années. Cependant, cela a toujours été un problème et restera toujours un problème pour porter des jeux de PC à une console sur un appareil mobile, et vice versa. Ces dernières années, il est devenu encore plus prononcé en permettant aux développeurs indépendants de programmer pour les consoles (ou aux développeurs qui piratent leur accès pour créer des jeux homebrew) et par la montée en puissance d’appareils mobiles suffisamment puissants pour faire tourner des jeux.

Le portage pose les mêmes problèmes qu'auparavant, mais il y a plus de périphériques à porter. Et certains ports n’ont tout simplement pas de sens sans reconcevoir le cœur du jeu. Ce n'est pas un problème qui peut être résolu, c'est un problème que vous devez prendre en compte avant même que vous n'écriviez votre première ligne de code. Alors ce sera gérable, ni plus, ni moins.

Je pense qu'un framework d'interface simple, portable et ouvert est vraiment nécessaire. Quelques réflexions:

Il existe actuellement quatre types courants de méthodes de saisie de jeu: les claviers, les souris, les contrôleurs et les surfaces tactiles. (Je passerai en revue les problèmes de capacités différentes entre, par exemple, les manettes de jeu et les manettes de jeu pour le moment, bien que cela doive être abordé à l'avenir.)

Dans l’idéal, notre développeur serait en mesure de spécifier de manière générale quelques interfaces utilisateur différentes qui conviennent au type de jeu en cours d’écriture. (Ils peuvent décider de fournir une interface utilisateur de clavier et de souris, une interface utilisateur de souris uniquement et une interface utilisateur multi-touch, à titre d'exemple arbitraire.)

Le framework est alors responsable de la médiation des IO entre la plate-forme et le code du jeu, de la même manière que fonctionnent les frameworks d'interface graphique multi-plateformes comme QT et GTK.

Avoir un tel cadre ne résoudrait pas le problème des exigences linguistiques incompatibles, mais encapsulerait au moins tous les appels spécifiques au système derrière une API commune, ce qui devrait rendre le portage de la langue beaucoup plus simple.

Bon, maintenant que j'ai écrit tout ça: Est-ce que quelqu'un sait si un tel cadre existe déjà?

Avec des projets tels que MonoTouch et XNATouch, il semblait que XNA pourrait vous amener sur la plupart des plates-formes avec un peu de peaufinage. Malheureusement, Apple a quelque peu torpillé cela quand ils ont modifié leurs termes et conditions pour limiter les langues que vous pouvez utiliser. L’unité couvre à peu près tout, mais sur XBOX, vous obtiendrez XBLA mais pas XBLIG, ce qui n’est donc pas une option pour les plus petits indies.

Une approche pourrait consister à créer un cadre qui utilise les mêmes conventions dans plusieurs langues / plates-formes. Il suffit ensuite de modifier la syntaxe pour mettre en place des jeux. Vous voudrez peut-être lancer votre jeu en Flash, ce qui peut être développé rapidement et toucher un large public, puis si le portage sur iPhone, XNA, etc. réussit, vous saurez ainsi que vous avez un jeu amusant avant de trop vous engager.

Je pense que c'est un problème économique, pas un problème technique. Les plates-formes telles que la xbox360 sont fortement incitées à être exclusives, car elles essaient de faire en sorte que les utilisateurs choisissent leur plate-forme plutôt qu'une autre. "Nous avons ces superbes jeux exclusifs" est bien plus intéressant que "nous pouvons aussi jouer à ces jeux que tout le monde a". L'écosystème est dominé par les fabricants de matériel.

Je pense que cela changera lorsque le gameplay en réseau social arrivera à maturité, car il est potentiellement beaucoup plus coûteux de placer tout le monde dans le même système de jeu social que de créer encore un autre FPS avec des graphismes sexy.

Je viens de découvrir Haxe et NME . Il prétend être une application multiplate-forme prenant en charge tous les principaux ordinateurs de bureau et appareils mobiles, ainsi que Flash, à partir d'une base de code. Ça vaut le coup d'oeil.

Un outil de développement multiplateforme qui est si nouveau que je ne le recommande pas nécessairement, c'est http://www.monkeycoder.co.nz/

Cela touche toutes les plateformes que vous avez mentionnées.

Bien que ce soit trop nouveau pour vraiment en juger, il possède un excellent pedigree: son créateur a précédemment conçu Blitz3D et BlitzMax, qui étaient d'excellents outils de développement pour les développeurs de jeux indépendants.

J'ai eu de la chance avec le SDK Airplay - du moins sur x86 et semble viser bien l'iPhone (même s'il me reste encore à mettre une application sur un iPhone).