UnnyWorld: post-mortem

Après la fermeture de notre jeu UnnyWorld, de nombreux développeurs qui étaient amis ont demandé à écrire un post mortem sur le jeu . J'ai décidé de partager des exemples spécifiques, dont un montant décent s'est accumulé pendant la période de développement. Il y aura des erreurs que nous avons faites, je vais essayer de donner quelques conseils utiles.



Plus tôt, j'ai publié un article «Trois ans de développement de mon MMO» , qui traitait davantage de la recherche d'investissements, de l'équipe et de notre chemin vers le «succès». Malheureusement (ou heureusement?), Le projet a dû être clôturé. Dans cet article, je vais essayer de passer en revue les erreurs commises et, éventuellement, donner au moins quelques conseils utiles.

À propos du jeu en bref

Classiquement, Unnyworld peut être divisé en deux parties: City builder et Arena.
La partie sur le constructeur est un certain Clash of Clans. Vous avez votre propre planète, que vous devez équiper. Et vous pouvez attaquer d'autres planètes pour voler des ressources.



Attaquez d'autres joueurs, vous êtes l'un de vos personnages et vous le contrôlez.

Arènes - MOBA 3v3 typique avec différents modes (capture de drapeau, capture de points, etc.).



Chaque personnage a ses propres sorts, qui peuvent être combinés avec d'autres joueurs.


Avant la bataille, vous pouvez changer de sort.



Le cycle de jeu dans son ensemble ressemble à ceci:

1. Pour pomper des sorts, des parchemins sont nécessaires qui tombent des coffres. Les coffres peuvent être obtenus de différentes manières gratuites (pour une ligue, pour gagner la bataille royale, etc.) ou acheter.
2. Pour pomper le sort, vous devez construire et améliorer la construction du héros à un certain niveau.
3. Pour améliorer la construction du héros, il est nécessaire d'améliorer d'autres bâtiments (bâtiment principal, autel, etc.).

Autrement dit, nous avons essayé de concilier en quelque sorte le régime de la planète et des arènes. Nous avons probablement tout mal fait.

Absence de plan et de stratégie clairs

Oui, beaucoup de choses ont été constamment discutées, mais les ont réalisées hors de propos, sans analyser en profondeur ce qui doit être fait en premier lieu.

En conséquence, ils ont essayé de tout faire en même temps. Avez-vous besoin d'un système de guilde lorsque le jeu a un utilisateur et demi? Hmm, à peine.

Avez-vous besoin d'un système qui vous permet de créer un match personnalisé, d'inviter des amis et des co-guildes là-bas lorsque le jeu a un petit CCU? Pas sûr.

Pendant le processus de développement, nous avons essayé beaucoup de choses pour faire quelque chose qui n'avait probablement pas besoin d'être fait à ce stade. En conséquence, les choses vraiment nécessaires n'ont pas été mises en œuvre.

Manque d'expérience

Parce que Avant, nous ne travaillions principalement qu'avec des jeux à un seul jeu, puis nous avons marché sur un grand nombre de râteaux lors du choix de l'une ou l'autre technologie.

Parlons un peu de la partie technique de la question.

Sélection de technologies

Une petite clarification. Pour la plupart, nous sommes des développeurs purement clients. De toute l'équipe, seules quelques personnes avaient de l'expérience avec les technologies de serveur. Concernant l'administration, je me tais généralement. Je vais essayer de passer par des technologies spécifiques avec un petit résumé pour chacune.

Quel fournisseur de cloud utiliser? AWS? Azure? Couche souple

À cette époque, il n'y avait pas de différence fondamentale. De plus, nous avions un prêt pour SoftLayer en tant que startup.

Oh, boi, si tu savais à quel point les choses étaient mauvaises:

- Saport n'est pas particulièrement familiarisé avec le problème. Il y a eu des cas où je me suis tourné vers eux à propos d'un problème sur une certaine machine virtuelle (je n'ai pas pu me connecter, etc.). À laquelle j'ai reçu la réponse:

Nous avons redémarré la voiture, maintenant tout va bien

- Il y a eu des cas où la machine virtuelle a augmenté pendant des heures . Comme vous pouvez le voir, j'ai attendu 4 heures, mais la machine virtuelle n'a jamais été créée.



- Maintenance fréquente.



- Il arrive que sans avertissement, une voiture redémarre ou un réseau privé soit coupé.

En conséquence, ils sont passés à Azure. Il n'y avait pas de tels problèmes. Le support répond rapidement et aide toujours en cas de problème.

Bon: -

Mauvais: ils n'ont pas analysé correctement toutes les options possibles. Mais le serveur est la partie la plus importante pour un jeu en ligne = /

Donc, vous devez en quelque sorte démarrer les instances de jeu sur le serveur, les lancer via un système API après avoir autorisé le joueur à l'instance souhaitée. Qu'allons-nous faire? Et prenons une solution clé en main qui gérera cette entreprise en fonction de la charge. Wow, il y a un truc qui s'appelle Kubernetes. C'est vrai, elle est en beta ... Mais bon, essayons!

Si nous ignorons le fait que vous ayez besoin d'expérience pour travailler avec cette technologie, même avec la configuration de base de cette entreprise, elle a réussi à tomber. Certains services sont tombés, etc.

Eh bien, qu'est-ce qu'il y a d'autre? Mésosphère et Apache Mesos! Tout est pareil avec lui, c'est difficile sans expérience. Si quelque chose tombe, sans tambourin, vous ne pouvez pas résoudre le problème.

En conséquence, ils ont tout écrit eux-mêmes. Les instances commencent par le superviseur, tout comme le petit gestionnaire au-dessus d'eux (écrit en Java). Application Java ttl'it au service de la découverte de statuts (nombre de chambres libres sur les instances, etc.). Lorsque vous autorisez et demandez à créer une salle pour l'API à l'aide de ces informations sur les instances, la demande va au nœud de droite, ce qui fait monter la salle sur la bonne instance.

C'est-à-dire les instances sont toujours pré-exécutées. Avec une pénurie, nous lançons un nouveau VPS.

Bon: analysé les alternatives.

Mauvais: a passé beaucoup de temps sur le prototype. Pour la première version, vous n'aviez pas du tout à penser à ces choses, mais vous avez simplement démarré les instances sans aucune plainte. Il était possible de coder en dur directement les adresses d'instance sur le client dans le prototype.

Nous avons utilisé www.consul.io pour le service découverte, c'est probablement une de ces solutions que nous n'avons pas regrettée. Certes, il y a des problèmes comme ceux - ci lorsque la configuration s'arrête lors du redémarrage. Mais c'est rare et avec un redémarrage imprévu de la voiture. En général, pour tout le temps, c'était un plaisir de travailler avec le consul.

Bon: ils ont fait une solution toute faite, mais n'ont pas commencé à voir quelque chose eux-mêmes.

Pour le déploiement, les scripts bash ont été initialement utilisés.


Plus tard, j'ai transféré l'intégralité du déploiement à Ansible. Je ne peux pas en avoir assez à ce jour. Il y avait bien sûr des problèmes au début. Mais le système est assez simple à apprendre et la documentation en vrac.

Bon: écrire rapidement un script bash, aucune connaissance particulière n'est requise.

Mauvais: lors du passage à un système de déploiement normal, j'ai dû jeter presque tout ce qui avait été écrit auparavant.

Pour la communication entre leurs services, nous avons essayé www.rabbitmq.com . Mais il était tellement hors sujet en quelques jours. En conséquence, ils l'ont fait de manière simple - tous les services interagissent soit via des sockets tcp purs, soit avec des requêtes http avec keep-alive, si vous devez envoyer des requêtes uniquement dans un sens.

Bon: analysé les alternatives. Nous avons choisi une bonne solution.

Mauvais: manque d'expérience avec la technologie. Il n'est pas nécessaire de faire glisser des éléments en production que vous ne pouvez pas résoudre en cas de problème.

Jouer en ligne signifie que vous avez besoin d'une salle de chat. Écrivez-vous? Il est peu probable qu'il soit évolutif. Prenons quelque chose de prêt. XMPP? Ejabberd? Semble bien. En général, nous avons essayé le hérisson et MongooseIM, mais nous nous sommes finalement installés sur un hérisson. Il y a eu quelques problèmes avec son élévation sur leurs serveurs (jambages avec timings dans les messages, plantages, etc.). Nous avons décidé d'utiliser leur solution cloud ejabberd-saas.com . Oui, c'est payé. Mais cela a fonctionné sans problème.

Bon: analysé les alternatives. Choisissez l'option appropriée.

Mauvais: au lieu de trier les problèmes locaux, nous avons décidé d'utiliser une solution cloud payante. Tarifs à partir de 200 euros. Nous avions plusieurs régions de jeu. Pour une équipe indépendante, cela représente un montant très substantiel, qui serait mieux dépensé pour d'autres choses.

Au début, nous n'avions généralement pas de système de collecte de métriques sur les serveurs. Pourquoi la demande ralentit-elle? Quel est le problème avec le service? Combien de chambres sont disponibles maintenant? Oui, nous n'avons même pas pu voir combien de chambres sont actuellement disponibles!

Plus tard est venu la réalisation que quelque chose doit être fait. J'ai essayé d'utiliser Graphite + Grafana. Même l'image pré-docker a fait tout cela: github.com/Suvitruf/docker-grafana-graphite-diamond

Mais cela n'a pas fonctionné. Je ne voulais pas passer du temps là-dessus, nous avons décidé d'utiliser le quelque chose de prêt à l'emploi. Le choix s'est porté sur www.datadoghq.com

Tout est super. Compteurs, alertes, graphiques. Le pilote client est presque le même que pour le graphite. La beauté Mais ... 10 + $ pour chaque hôte par mois. III ... il sort à 200 + $ par mois.

La réalisation que nous avons pissé une tonne d'argent à ce sujet était trop tard. Nous avons néanmoins décidé de le faire sur nos serveurs. Configurez www.influxdata.com . En conséquence, une voiture pour quelques dizaines de dollars traite silencieusement les mesures de dizaines / centaines de voitures.

Bon: nous l'avons essayé rapidement. Trouvé une alternative toute faite. Ils ont réalisé (bien que tard) que la décision était erronée. Mettre en place un système pratique localement.

Mauvais: n'a pas bien compris le problème. J'ai dépensé beaucoup d'argent.

Concernant les métriques, le même problème de performances. Au début, nous ne sommes surtout ni un client ni un serveur de profils. En conséquence, des fuites de mémoire sur les instances de serveur du jeu ont été découvertes trop tard. Ils n'ont pas pu déterminer et réparer rapidement. En conséquence, ils ont écrit afin qu'après avoir créé un certain nombre de salles, l'instance de jeu redémarre.

Un peu sur les solutions conceptuelles et DG

Je ne peux pas déjà construire le bon ordre à temps pour tous ces événements, je vais nommer quelques décisions clés que nous avons prises.

Répartition du jeu par région

Les joueurs ont demandé un serveur asiatique et un serveur en Amérique du Sud (avant que ce serveur ne soit en Europe et aux USA). Pourquoi ne pas le faire, hein? Ils l'ont fait. En conséquence, un utilisateur et demi était réparti sur 4 régions. Une fois plusieurs régions, alors vous devez faire un système de transfert. Est-ce logique? Est logique.

Bon: quelques personnes ont obtenu un meilleur ping (｡ • ́︿ • ̀｡)

Mauvais: beaucoup de temps passé à créer des régions, des systèmes de transfert, etc.

Il est nécessaire d'écouter les suggestions / suggestions des joueurs, mais vous ne devez pas immédiatement vous enfuir et réaliser tout cela.

Remplacer une grille carrée par des hexagones et refaire des attaques sur les planètes

Auparavant, les planètes ressemblaient à ceci:



Et les attaques:



Le passage aux hexagones a simplifié beaucoup de choses techniquement. De plus, il avait l'air beaucoup mieux, il est plus facile de travailler avec des éléments de jeu.

Système de sorts retravaillé

Il ressemblait à ceci:



L'amélioration elle-même a été effectuée pour les pierres tombées des coffres. Tout n'était pas évident, déroutant.

En conséquence, ils ont remplacé le système de pierres par des parchemins comme dans Clash Royale.



Pour améliorer le sort, vous avez besoin d'un certain nombre de parchemins. Tout est simple et clair.

Bon: ils ont remarqué un problème et l'ont refait.

Mauvais: au départ, ils n'ont pas analysé comment les joueurs le percevraient. Beaucoup de choses sont évidentes pour les développeurs, les joueurs les perçoivent d'une manière complètement différente. Par conséquent, les commentaires doivent être collectés le plus tôt possible, organiser des tests de jeu, etc.

Shopping sur Twitch

Nous avons même convenu avec www.twitch.tv de faire des achats dans le jeu sur la page du jeu.



Mais depuis personne n'a streamé notre jeu, alors le sens d'une telle décision est généralement nul.

Bon: un endroit potentiel pour un retrait équitable des joueurs.

Mauvais: si votre jeu n'est pas diffusé, cela ne sert à rien. Juste du temps perdu.

Mode Battle royale

Dans le sillage du battage médiatique, ils ont décidé de supprimer un tel régime dans le jeu. Mais depuis Il y avait peu en ligne dans le jeu, puis dans ce mode il n'y avait presque que des bots, ce qui élimine tout à néant.

À propos des bogues

Dans un tel projet, il est difficile de ne pas faire de bugs. Il y avait beaucoup de bogues GUI relativement inoffensifs.



Il y a eu des bugs plus graves, par exemple, lorsque des joueurs sont morts instantanément au centre de l'arène. Nous n'avons pas pu réessayer ce bogue localement. Cela arrivait parfois aux joueurs, mais nous ne pouvions pas le réparer.

Un bug amusant lors du changement de personnage, le modèle du précédent n'a pas été supprimé. En conséquence, il a été possible d'organiser une fête dur.



Il y avait également des bogues liés à la plate-forme / au moteur.

Par exemple, parfois l'interface graphique entière peut simplement disparaître. Mais si vous entrez dans la hiérarchie des objets et cliquez simplement sur l'objet, il réapparaît.


Nous avons signalé ce problème Unity. Ils ont répondu qu'ils pouvaient nous donner un employé pour aider pour 10 000 $ par mois ლ (ಠ_ಠ ლ)

Sur la plate-forme Facebook, le Gameroom a eu un problème de mise à l'échelle lorsque le jeu a réagi au tachy au mauvais endroit.



Ceci, sans parler des bugs dans diverses bibliothèques. Par exemple, sur certaines machines Steamworks.NET, github.com/rlabrecque/Steamworks.NET/issues/121 peut se bloquer .

Résumé

Nous n'avons presque pas investi dans le marketing, nous espérions qu'il y aurait un afflux organique d'acteurs. En conséquence, le jeu n'a pas atteint cette masse critique, après quoi les robots ne seraient pas nécessaires et il y aurait un afflux organique de nouveaux joueurs.

Surtout, personne n'était engagé dans la gestion de contenu et la communication avec les joueurs, il n'y avait pas de newsletters.

Pendant le développement, beaucoup de temps a été perdu dans la sélection et les tests de diverses technologies.

Il n'y avait pas de plan clair pour la mise en œuvre des fonctionnalités / du contenu.

En général, la plupart de ces problèmes sont dus à l'inexpérience.

Et ensuite?

Unnyworld a été fermé. Nous avons décidé de réduire le projet dans le cadre des opportunités actuelles.

Un article ne couvre pas tout. Et ce que j'ai écrit, pour un étranger, peut sembler un ensemble de faits incohérents. Malheureusement, ce n'est pas un expert pour écrire de tels textes.

Si vous avez des questions, je me ferai un plaisir d'y répondre soit dans les commentaires soit dans un nouvel article.