Les développeurs de jeux indépendants devraient-ils cibler du matériel plus ancien?

Un développeur avec qui je travaille me dit que les développeurs indépendants devraient cibler du matériel âgé d'environ six ans ou plus (aux paramètres maximum). J'ai l'idée que l'on devrait permettre à tous ceux qui veulent jouer à leur jeu de jouer à une cadence d'images exécutable, quel que soit l'âge de leur matériel, mais les développeurs indépendants devraient-ils se limiter à utiliser un style artistique low-poly, ou faire leurs jeux en pensant au matériel plus ancien, principalement parce que "la plupart des gens qui jouent à des jeux indépendants ont du vieux matériel?"

Y a-t-il une raison pour permettre à votre jeu de fonctionner avec les paramètres maximum pour un matériel très ancien, même si cela réduirait les possibilités graphiques pour les personnes disposant d'un matériel plus récent?

Existe-t-il des statistiques qui montrent que les jeux qui atteignent facilement leurs limites graphiques supérieures sur du matériel plus ancien réussissent mieux que les jeux qui poussent leurs limites graphiques supérieures plus haut au prix d'une expérience `` moins que la meilleure '' pour les joueurs sur du matériel plus ancien ?

Tout aperçu à ce sujet sera grandement apprécié.

À cette époque, le vieux matériel est devenu un terme inapproprié. L'ancien matériel n'est pas nécessaire lentement. 6 ans est 2009 et DirectX11 existait déjà. Nous n'avons toujours pas beaucoup de nouveautés aujourd'hui.

Vous devez considérer deux choses:

• fonctionnalités
• Puissance

fonctionnalités

Il s'agit du niveau d'instructions que le matériel prendra en charge, DirectX9,10,11 ou OpenGL (cela dépend des pilotes). Et le jeu d'instructions CPU: SSE4, AVX ..

C'est le plus gros mal de tête habituellement dans le développement, l'évolutivité face à ceux-ci est plus difficile que l'évolutivité face à la puissance. DirectX9 avait quelque chose appelé techniquedans les .fxfichiers pour se replier, pour les deux points. Mais pour les instructions CPU, vous avez besoin de plusieurs exécutables ou de grandes sections de branchement dans votre programme. Ou ne les utilisez pas.
Heureusement aujourd'hui, même 6 ans est une courte période et vous aurez accès à tout ce dont vous avez besoin, même sur du "vieux" matériel.

Puissance

C'est le point qui devrait évoluer, sur la machine d' aujourd'hui , et non sur la machine héritée. Un haut de gamme de 2009 dispose potentiellement d'une geForce GTX280, c'est très puissant et beaucoup plus puissant que votre APU AMD A6-3650 bas de gamme ou quelque chose comme ça.

Il faut comprendre le gigantesque écart de performances entre le bas de gamme et le haut de gamme de la machine d'aujourd'hui. Parce qu'il dépasse largement l'écart de performance de vos machines de la gamme 6 ans à l'échelle haut de gamme.

Ce n'est donc pas une considération de marché concernant le renouvellement, c'est une considération de marché concernant le budget d'achat d'origine. Et si vous devez cibler les ordinateurs portables ou les ordinateurs de bureau bas de gamme d'aujourd'hui, vous devrez de toute façon évoluer, et bien plus que vous ne le pensez.

Essayez de vous soucier de la résolution, du taux de remplissage des pixels et de la bande passante de la mémoire graphique. Vous jouez sur ces facteurs grâce au nombre de passages d'écran, à la largeur de votre Gbuffer si vous avez un ombrage différé (très coûteux sur les machines bas de gamme), à ​​la résolution de vos textures et à leur quantité présente à l'écran à un instant donné. La richesse en polygones ne sera pas un problème à moins que vous ne cibliez le matériel 2002. La complexité des shaders ALU / FPU ne sera pas non plus un problème, sauf si vous ciblez le matériel 2005/2006.

Je ne me souviens pas où je l'ai entendu pour la première fois, mais c'est une vieille règle empirique qui ne résiste pas à beaucoup de pensée critique. En vérité, cela se résume à des objectifs commerciaux. Si vous ne prévoyez pas de vendre le jeu, cela n'a pas d'importance.

Le fait est que plus vous pouvez prendre en charge de matériel, plus votre marché potentiel est grand. Cependant, la plupart des développeurs indépendants n'auront de toute façon pas les ressources nécessaires pour prendre en charge du matériel de pointe, car pour tirer parti de ce matériel, ils devront dépenser une quantité considérable de contenu . Tout développeur indépendant qui doit s'inquiéter de cela a généralement les ressources pour savoir quelles spécifications système il doit cibler, et ce sont probablement des informations que vous pouvez acheter. Steam, par exemple, recueille ces statistiques et les revend probablement aux développeurs.

En règle générale, plus la variété de matériel sur laquelle un programme s'exécutera est grande, plus vous aurez de possibilités de vendre une copie. La diversité que vous pouvez supporter dépend beaucoup du jeu. Un jeu comme Dwarf Fortress peut facilement être très évolutif, à la fois en termes d'exigences de traitement et de graphisme. Un FPS avec une physique réaliste comme Amnesia pas tellement. Ma suggestion serait d'écrire votre jeu afin qu'il puisse être exécuté sur la plus large gamme possible de matériel et tout de même donner une bonne expérience. Vous n'avez pas nécessairement à le prendre en charge tout de suite, mais être capable de le reconfigurer facilement pour un matériel plus récent / plus ancien / tout simplement différent sera payant à mesure que votre base de fans grandit et que la technologie progresse.

Il y a deux choses qui vous faciliteront la vie quand il s'agit de faire fonctionner votre jeu sur un large éventail d'appareils, et elles ont peu à voir avec l'âge du matériel que vous ciblez (au moins directement):

1) Si possible, séparez le backend du frontend. Si la partie qui fait le calcul sur les pièces fait quoi, où a une interface bien définie pour transmettre ces informations à la partie qui les affiche à l'écran et prend la saisie de l'utilisateur, alors vous pouvez plus facilement en ajuster une (généralement le frontend ) au nouveau matériel sans avoir à jouer avec l'autre. S'ils sont écrits de cette façon, de nombreux types de jeux peuvent être proposés, allant de graphiques 3D haut de gamme, à des sprites animés sur une page Web, à des caractères de texte ASCII purs. À ce stade, vous pouvez choisir celui à implémenter en fonction de qui, selon vous, achètera le jeu maintenant. Et vous pouvez vous étendre à de nouveaux schémas de sortie lorsque les gens manifestent de l'intérêt - sans avoir à jouer avec le cœur du jeu.

2) Autant que possible, écrivez du code portable. En fonction du comportement spécifique de DirectX 9.3c ou de tout ce qui peut vous permettre de le faire plus rapidement, mais lorsque vous réalisez que vous devez sortir une version pour Android, vous devrez refaire beaucoup de travail. Choisir des bibliothèques et des langues qui ne dépendent pas d'un seul fournisseur et qui suivent des normes ouvertes et bien définies réduira considérablement votre charge de travail à long terme. N'oubliez pas: l'écriture d'un programme représente généralement une infime partie du travail par rapport à la maintenance du programme. (Sauf si vous optez pour le modèle commercial de «l'obsolescence planifiée», mais cela ne devrait pas vous procurer une grande base de fans à long terme.)