Le premier jeu sur l'unité ou ce qu'il m'a fallu six mois

Salut, Habr. Je suis développeur de jeux sur Unity (cela semblait faible) et je voudrais parler des étapes de développement de mon premier jeu. L'histoire remonte à 2 ans quand j'ai décidé d'essayer de faire des jeux. Commencé avec des guides sur YouTube. Après avoir créé quelques exemples, applications et mini-jeux, j'ai décidé de créer un jeu à part entière. Naturellement, je représentais une véritable épopée, un complot et 10 réels sur 10. Mes ambitions étaient illimitées, mais je ne savais pas ce qui m'attendait.

La toute première question que je me suis posée était de choisir une plateforme de publication. J'ai fait le choix de la plateforme à des prix ou par une méthode d'exception: sur Steam 100 $ par jeu, sur IOS 100 $ par an, le choix s'est porté sur Android. J'ai payé 25 $ sur Google Play, j'ai ouvert un compte et le développement a commencé.

J'ai décidé de m'appuyer sur les aspects les plus puissants et les plus simples du moteur. La physique 2D était la mieux adaptée à cela, sur la base de cela, j'ai décidé de construire un jeu.

Mais qu'est-ce que ce sera, quel est le concept? J'ai décidé de m'inspirer sur YouTube et j'ai trouvé une vidéo sur la façon de générer un niveau à partir d'images pixel. Je voulais la même chose.


Ce que j'ai réécrit

Réécriture du système, tracé un niveau et testé la génération. J'ai pensé: "Et ensuite?". Et puis - un aperçu. L'idée est venue instantanément et le puzzle s'est assemblé. Pourquoi le joueur ne devrait-il pas être un ballon, mais réussir à lui donner de la gravité? «Excellente idée», ai-je pensé, et j'ai commencé à créer un gameplay.

Après quoi j'ai fait face à la tâche: comment le joueur contrôlera la balle rouge. Pour tout le temps de développement, j'ai proposé 4 options:

1) Rayon

Le joueur toucherait l'écran, définissant un point de référence, par rapport à la poursuite du mouvement du doigt, la gravité a changé. La force dépendait de la plage du point de référence et de la direction de l'angle entre eux.

2) Rayon fixe

Comme Radius, seul le point de référence serait strictement au centre de l'écran

3) Deux voies (tapotement)

Lorsque vous cliquez sur le côté gauche ou droit de l'écran, vous pouvez tourner la "gravité" avec la caméra d'un certain nombre de degrés respectivement à gauche ou à droite.

4) Double face (serrage)

Le même principe que le Two-Sided (pressage), il suffisait de serrer et la rotation se faisait à vitesse fixe.

1 et 2, je les ai immédiatement renvoyés en raison de leur complexité de compréhension et de contrôle non intuitif. Il n'était pas adapté à un jeu mobile. Mais, malheureusement, 4 m'est venu à l'esprit au stade de la post-production, j'ai dû en prendre 3. Franchement, une très mauvaise décision (sérieusement, je n'en ai pas besoin de cette façon). Ce département avait deux défauts catastrophiques.

  1. Le premier était sa netteté, ses contractions. En tournant, l'image a changé de façon spectaculaire et très désagréable. J'ai donné pour tester, ils ont dit qu'à cause de la gestion ils ne comprenaient pas où aller et comment jouer, et la moitié des «testeurs» ont commencé à basculer.
  2. Le deuxième problème est purement technique: en tournant, le jeu se jouait de 0,1 à 1-2 secondes, car il ne faisait pas tourner la caméra avec gravité, mais le NIVEAU ENTIER. Et les niveaux atteignaient parfois 10 000 objets. Je pense que cela ne vaut pas la peine d'expliquer comment l'appareil a réagi à une focalisation similaire avec la trigonométrie. J'ai remarqué cela au milieu du développement, mais je n'ai pas osé le corriger, car je ne savais pas comment changer la direction de la gravité 2d (je sais, j'étais stupide) et j'étais juste paresseux.



Oui, et maintenant il n'aurait pas été possible de le réparer si simplement sans remuer les forums et la documentation. Quand j'ai voulu au moins essayer de corriger le bug, je ne l'ai pas fait, car il était impossible de changer le gameplay. La modification du contrôle pour le type 4 gâcherait les 80% finis du contenu, aiguisés pour le contrôle de type 3.

De plus, à cause de cela, 1 problème s'est fortement aggravé, et maintenant même j'ai commencé à tomber malade. Apparemment, j'ai fait de mon mieux, la vérité n'est pas ce que je voulais. "Oh bien", ai-je pensé, et j'ai continué.

J'ai commencé à programmer des puzzles, et cela m'a pris beaucoup de temps. J'ai passé les 2 mois entiers sur divers objets et scripts pour leur interaction. Les niveaux étaient de simples textures bitmap avec des pixels distincts, dont la couleur indiquait son bloc.

Désignations
Blanc - Bloc de fond
Noir - Bloc simple
Rouge - Joueur
Bleu - Fini
Nuances de jaune - Téléportation
Rouge foncé - Boule rouge
Vert - Boule verte
Just Yellow - Star
Niveaux de gris légers - blocs rectangulaires
Nuance de gris foncé - Faux blocs
Teinte jaune foncé - Faux téléporteurs
Teinte jaune moyen - Fake Stars
Bleu foncé - Faux fini
(Trop de faussetés)







Fondamentalement, tous les actifs contactés via OnTriggerEnter2D et les balises. Même maintenant, je ne peux pas deviner ce que cela m'a pris environ un mois. Le menu a pris le deuxième mois de la partie en raison du fait que je n'utilisais pas de cycles, et l'activité des 500 objets était régulée via Awake, c'est pourquoi j'ai produit plus de 2500 lignes de code.


"Votre jeu est déjà fatigué, faites-en un autre", ont déclaré des amis, mais j'ai quand même continué. J'ai prévu 100 niveaux. Il a fallu 4 mois pour les créer. Je les ai créés en parallèle avec la partie technique. En conséquence, mon plan pour les niveaux de "réflexion" ne s'est avéré presque rien. Je peux nommer de tels niveaux sur la force de 10-15 pièces, le reste était difficile pour les autres. Ils étaient compliqués par la présence de couloirs étroits, la complexité de l'orientation dans l'espace, des solutions de conception absolument masochistes et, bien sûr, des mines avec des labyrinthes. Mais ce n'est pas moi qui ai été responsable de leur création. Mes «employés embauchés» ont créé au total environ 60% du contenu du jeu.

Du fait que nous avons conçu les niveaux selon les règles, les niveaux se sont avérés passables en théorie, mais en pratique la théorie n'a pas été testée. Après avoir fait tous les niveaux, j'ai compris ce qui pouvait arriver à mon jeu, à savoir la dissonance absolue du retard aux niveaux infranchissables, à cause de laquelle il ne serait pas possible de terminer le jeu. Donc ça reste.

De plus, je n'ai pas oublié l'horaire, mais j'ai travaillé dessus pendant 2 heures, puis je ne l'ai plus touché du tout. Comme je suis tordu et que le meilleur que j'ai peint dans Photoshop est de grands cercles au lieu d'yeux, j'ai décidé que le joueur contrôlait la balle en rouge et reprenait les textures du premier pack de texture rencontré sur Minecraft (j'ai piraté comme je le pouvais).

Il y a des indices dans le jeu, mais ils ont été faits très rapidement, et par conséquent de mauvaise qualité. Au début du niveau, un texte apparaît avec mon commentaire de type "Difficile?", Ou "Pensez!".

J'ai programmé le jeu sur Unity 2017.1. Alors c'était déjà 2018 et je pouvais télécharger la version Unity 2018.2, mais je ne l'ai pas fait. Après tout, je ne voulais tout simplement pas souffrir du transfert du jeu et des éventuels bugs. Quand est venu le moment de la compilation finale, je n'ai pas pu le faire. La raison en est le manque de SDK Android. J'ai passé une semaine à chercher, à expérimenter avec une combinaison de nouvelles versions du moteur (seulement en 2017), à changer leurs paramètres et d'innombrables sdk énormes (300 Go pour 24 sdk identiques différents). En conséquence, j'ai opté pour un programme d'installation sdk tiers, la version du moteur 2017.3 et le type de proposition Intent. Comme j'étais heureux quand j'ai compilé le jeu.

Il m'a fallu 3 jours pour le publier.

La difficulté était de remplir le questionnaire et la nécessité de remplir une description en 18 langues (leçon pas trop intéressante). J'ai localisé tout cela via google translate. Il n'a pas fallu beaucoup de temps pour créer la couverture et les captures d'écran.

Couverture et captures d'écran






Malgré l'absence totale de relations publiques (à l'exception des recommandations personnelles), le jeu a des valeurs généralement stables. Chaque mois, une moyenne de 4 à 7 installations.

Le premier mois, j'ai ajusté le trafic, en disant non indifférent.


Au cours des six mois suivants, l'augmentation a été notable. Les installations de pointe ont eu lieu à la fin de l'été et à l'automne.


Même maintenant, un an après la sortie, les installations sont stables.


Au départ, la principale motivation pour le développement était le développement personnel, je n'ai poursuivi aucun objectif de revenu. En partie à cause de cela, le projet de mon auteur a tout simplement disparu dans l'oubli, sinon à cause de tous les inconvénients ci-dessus. Mais l'essentiel est que c'est juste ennuyeux de le jouer. Après tout, si j'introduisais de la publicité, je serais plus responsable des relations publiques, de la qualité du produit final et de sa présentabilité. Et donc - une telle sorte de divertissement.

Mais, en principe, je suis satisfait de mon jeu. Sa taille avec de bons niveaux montre clairement que pour le premier jeu le mien n'est pas si mal. Tout au long du développement, j'ai beaucoup appris sur la programmation et le marketing, sur les jeux et les choses connexes, mais le plus que j'ai compris était où je me suis lancé, dans quelle industrie j'ai commencé à aller.

Soit dit en passant, je suis en train de développer une suite, peut-être ce qui se passe ...

PS: Pour l'article, la remorque spécialement montée:

Source: https://habr.com/ru/post/fr452074/


All Articles