Quelle est la limitation la plus sérieuse d'Unity? [fermé]

Après avoir lu cette question passionnée sur Unity vs UDK vs ID quelque chose, je suis curieux de savoir: quelle est la ou les limitations les plus paralysantes de Unity?

Afin de garder cette question non subjective, encore une fois, je parle des principaux délinquants répétés d'Unity. En tant qu'utilisateur Unity, vous souhaiteriez vraiment que quelqu'un vous en parle avant de commencer à l'utiliser.

J'ai entendu quelqu'un dire que Unity ne gère pas bien le contrôle de version, car il génère beaucoup de fichiers binaires (qui ne sont pas diffiables). Pour moi, cela n'est pas vraiment handicapant car je travaille seul.

Pensées?

Permettez-moi de dire ceci que les gars d'Unity ont été assez bons pour entendre les scrupules majeurs auxquels leur communauté est confrontée et finissent par promettre d'améliorer les choses. Il y a aussi beaucoup de problèmes qui ne surviennent que sur certaines plateformes ou qui sont une question de préférence personnelle ou de problèmes spécifiques du jeu sur lequel vous travaillez.

Cela étant dit:

1) Mauvaise intégration du contrôle des sources et grands outils d'équipe. Comme vous l'avez mentionné, beaucoup de fichiers binaires non diffiables. L'éditeur ignore l'indicateur de lecture seule pour les fichiers de scène. Les fichiers réels que vous devez archiver ne sont pas immédiatement évidents. Certains de ces problèmes sont en cours de correction dans la version 3.5 avec l'intégration SVN et P4. Il y a aussi des promesses de formats de scène basés sur du texte. MISE À JOUR: Le format de scène textuel est désormais disponible dans la version Pro d'Unity. Voyez ici .

2) Outils d'interface utilisateur lents et centrés sur le programmeur. Chaque widget est son propre appel de tirage, qui a beaucoup de frais généraux sur les plates-formes mobiles. Il n'y a pas le concept de choses comme des panneaux avec des animations et toutes ces autres choses fantaisistes qui font que l'interface utilisateur se sent bien sans la faire rouler vous-même. Il y a une promesse d'un nouveau système d'interface utilisateur sur la feuille de route (3.6?). Il existe des outils tiers, mais ils ne sont pas géniaux.

3) Édition de particules vraiment rudimentaire. Ils promettent cependant un nouveau système basé sur les courbes en 3.5. MISE À JOUR: Ce système basé sur une courbe, appelé Shuriken, est maintenant disponible. Voyez ici .

4) Vous ne pouvez pas imbriquer des préfabriqués. Un petit problème, mais lorsque vous avez l'habitude de travailler avec le système préfabriqué et toute la puissance qu'il vous fournit, cela peut devenir frustrant. Cela a été promis mais pas de date précise. MISE À JOUR: Vous pouvez maintenant imbriquer des préfabriqués.

5) Il est presque impossible d'obtenir un jeu iOS sous la limite de diffusion. Le binaire seul est comme 8 Mo dans le meilleur des cas. Ce n'est pas quelque chose qui est facilement réparable.

6) Les plates-formes de crash d'exceptions de référence nulles qui n'autorisent pas le code compilé JIT. Sur les versions autonomes ou Web, les NRE sont interceptés. C'est toujours une exception non capturée, mais au moins l'application va essayer de continuer à fonctionner. Sur iOS, il bloque l'appareil. Vous pouvez le mettre en mode débogage et intercepter certains types d'exceptions, mais les performances en souffrent.

7) Lorsque vous travaillez sur un jeu multiplateforme, chaque fois que vous changez de cible de construction, vous devez tout réimporter et cela prend beaucoup de temps. J'ai travaillé autour de cela en ayant simplement plusieurs copies du projet sur le disque. Apparemment, un serveur de ressources importé arrive en 3.5.

Lorsque moi et un ami evalutad Unity pour un projet plus important, nous avons constaté que l'un des plus gros problèmes était la performance de leur skin de logiciel. Si je me souviens bien, nous avions quelque chose comme 10 objets animés avec environ 1000 verts chacun et j'ai obtenu 20 images par seconde en utilisant un ordinateur de milieu de gamme ... Pas très bon ...

Mon problème numéro un était le contrôle des versions. La solution? Utilisez simplement DropBox pour les projets Unity. À condition de le configurer correctement (c'est-à-dire de payer pour leur service "PackRat"), il conserve l'historique des révisions. Il est également beaucoup plus facile de collaborer avec des concepteurs, de cette façon, qui ne veulent pas connaître le contrôle de version traditionnel, DropBox leur donne une solution transparente. L'inconvénient est que les branchements / fusions ne sont pas vraiment pris en charge comme ils le sont par exemple. git, SVN.

Pour ceux qui doutent ...

Alors que Dropbox fonctionne comme un service de stockage, il se concentre sur la synchronisation et le partage. Il prend en charge l'historique des révisions, de sorte que les fichiers supprimés du dossier Dropbox peuvent être récupérés à partir de n'importe quel ordinateur synchronisé. [33] [34] Le contrôle de version de Dropbox aide également les utilisateurs à connaître l'historique d'un fichier sur lequel ils sont actuellement en train de travailler, permettant à plus d'une personne de modifier et de publier à nouveau des fichiers sans complications de perdre sa forme précédente. [35] L'historique des versions est limité à 30 jours. Une option payante pour un historique des versions illimité appelé "Pack-Rat" est disponible.

Voir ici pour une référence solide sur les forums Unity.

En dehors de cela, la seule chose que j'ai trouvée ennuyeuse à propos de Unity est qu'il n'a pas de point d'entrée d'application comme le fait C (main ()) ou AS3 (classe de document). Mais vous venez de mettre votre application init sur un GameObject vide, ce n'est pas grave. Le flux de code est également un peu différent autour de cette structure inhérente, mais encore une fois, rien de trop difficile à maîtriser.

En ce qui concerne la licence, la plupart des gens ne réalisent pas (et je parle en particulier des petites opérations indépendantes et des amateurs qui n'ont peut-être pas l'argent pour payer une licence pro et l'addon Asset Manager) que vous pouvez faire à peu près tout ce que vous pourriez jamais voulu avec l'édition de base / gratuite. Vraiment, ce n'est pas une énorme barrière, l'équipe d'Unity a été très généreuse.

J'ai pensé à une autre limitation majeure qui m'ennuie quotidiennement, donc je posterai ceci séparément.

Unity3D souhaite que vous modifiiez vos scripts dans MonoDevelop, en particulier une ancienne version de MonoDevelop qu'ils distribuent. La fonctionnalité "Rechercher dans les fichiers" de cette version est rompue, en ce sens que son utilisation entraîne généralement le blocage de l'EDI, le rendant inutile.

Ce serait une grosse irritation avec n'importe quel moteur, mais c'est une énorme irritation avec Unity car cela encourage un système très décentralisé de composants séparés agissant sur les différents objets du jeu. Mais comment savoir quels composants accèdent à quelles propriétés si vous ne pouvez même pas rechercher parmi les différents composants?

EDIT: Cette réponse a été publiée en 2011: le bogue Find In Files a été corrigé il y a quelque temps, heureusement. Et comme le disent les commentateurs, vous pouvez modifier votre code dans d'autres éditeurs (bien que votre choix soit limité si vous voulez pouvoir exécuter dans le débogueur).

Pour moi, la limitation la plus sérieuse se trouve dans le CLUF:

"Restrictions sur les jeux de hasard Vous ne pouvez pas distribuer ni publier de contenu sous licence en relation avec des activités de jeu sans une licence distincte d'Unity."

Cela signifie que depuis la v4.0, vous ne pouvez pas utiliser Unity pour les jeux impliquant de l'argent / chance, à moins que vous ou vos clients ne soyez prêts à payer des frais de licence supplémentaires qui sont négociés au cas par cas. C'est-à-dire qu'ils voient combien vous valez et vous taxent en conséquence, avec 6 chiffres cités.

Plus troublant, c'est que qui sait ce qu'ils ajouteront à la CLUF v5. Peut-être tous les jeux sociaux? Peut-être tous les jeux multi-joueurs?

Tout développeur utilisant Unity risque d'être tenu en rançon dans une future version.

Bonne question. Pour moi, le plus gros problème est l'interface graphique. Cela ne me dérange pas que ce soit centré sur le programmeur, mais je me préoccupe de la façon horrible dont les objets GUI sont des fonctions plutôt qu'un objet, et que la gestion de l'interface graphique est tout bourrée dans un appel de fonction qui est utilisé pour le rendu et pour la gestion des événements, et qu'il n'y a pas d'intégration avec le système d'entrée (ce qui signifie que les clics sur les éléments de l'interface graphique peuvent être interprétés comme des clics dans le monde), etc.

Un problème secondaire est le manque de prise en charge adéquate du contrôle de version (principalement parce que le système utilise la disposition du répertoire comme disposition du projet, ce qui confond le VCS lorsque vous déplacez ou renommez des choses), mais cela peut être contourné et n'est pas un problème pour Tout le monde.