Empreinte russe dans la saga scandinave des jeux vidéo, fin

La fin de la première partie de l'histoire , révélant un épisode brièvement mentionné dans le livre finlandais "Finnish Video Games: History and Catalog" .

Dans cette partie, je décris les problèmes organisationnels et techniques et tire quelques conclusions sur l'organisation du projet et les raisons de son succès.

Phase 0

Donc, après avoir terminé un court projet suédois et m'être reposé pendant un certain temps, j'ai obtenu un emploi dans une entreprise produisant du contenu sous la marque «INFON» (oui, c'est le même - «INFON sur votre téléphone»). INFON avait également des plans pour la production de jeux mobiles en 2001, mais ce marché était encore assez brumeux et manquait de la base quantitative nécessaire d'appareils, au bureau, je n'ai vu que le téléphone Nokia 9110 adapté au développement de jeux, mais après avoir joué avec, nous avons décidé de reporter cette question (je J'ai entendu que plus tard cette «brique» a été présentée à un gouverneur). J'ai été mis en charge des applets pour les services en ligne de l'entreprise, publiées sous la marque Logoton, permettant aux utilisateurs de préparer du contenu graphique et audio, puis de les envoyer sur leur téléphone via SMS. En général, j'ai passé près d'un an à le faire.

Phase 1

Quelque part en mars 2002, l'histoire a commencé dont Mikko Honkakorpi a brièvement parlé dans son interview. Pour autant que je m'en souvienne, Artyom Golubchin, un responsable de la société de recrutement finno-russe MPS-Russie (qui travaillait pour le marché finlandais), est d'abord venu vers moi et m'a proposé d'être interviewé pour le sujet du travail. Ils ont décidé de développer l'entreprise et d'entrer dans la catégorie du développement de l'externalisation, en ouvrant les soi-disant «centres de compétences» (comme ils appelaient leur modèle d'entreprise). Le principal avantage des «centres» était la simplicité de la manipulation du personnel par l'entreprise employeuse, à savoir la facilité de fermeture et de licenciement, car en Finlande il existe de très grandes difficultés et un licenciement abusif peut entraîner la faillite de l'entreprise.

L'une des entreprises qui souhaitait installer son «centre de compétences» était la société finlandaise Akumiitti Oy. A cette époque, un fournisseur assez connu de solutions pour l'organisation de services mobiles. Le premier entretien s'est déroulé sans la présence d'un représentant de la société finlandaise. Si je ne me trompe pas, la première fois que j'ai été interviewé par Artem Golubchin et deux Finlandais. L'un des Finlandais était un Timo Multamaki de style viking (maintenant un célèbre concepteur de jeux de société finlandais) et un autre Finlandais dont je ne me souviens plus du nom. Je me suis seulement souvenu qu'ils avaient demandé quel genre de jeu j'aimais, auquel j'ai répondu "Operation Flashpoint". Puis il y a eu un entretien avec des psychologues, et seulement une fois sur un tiers il y a eu un entretien avec Mikko Honkakorpi. En parallèle, les Finlandais ont contacté Sergey Kuligin et nous avons été invités à discuter du projet.

Il s'est avéré que l'une des principales sociétés de télécommunications prévoyait de commencer à vendre un nouveau téléphone Siemens M50 à petit budget dans l'un des pays d'Europe de l'Est et comme le téléphone avait à bord le support J2ME à bord, le client souhaitait recevoir d'Akumiitti un ensemble de 20 jeux avec des services mobiles. La principale difficulté était que l'échéance était prévue pour le 1er juin, et le chantier était déjà fin mars, et tout dans tout était à moins de deux mois. Sur la base de sa riche expérience de jeu, Sergey Kuligin a rejeté l'offre de coopération, citant que faire autant de jeux dans une telle période est un pari, mais j'étais moins expérimenté et poursuivais les négociations.

On m'a demandé de développer des scénarios pour 20 jeux mobiles et de les montrer lors de la prochaine réunion, qui devait avoir lieu dans quelques jours. Le soir, pendant ces jours, j'ai "pelleté" un tas de vieux jeux de mes archives de BK-0010, faisant une compilation de scripts appropriés. Les jeux incluaient l'arcade, le jeu et la logique. Après avoir rencontré Mikko et Timo quelques jours plus tard, je leur ai présenté les scripts. Mikko a dit que les scripts leur convenaient et avec moi, eux et Timo se sont serrés la main, marquant la conclusion d'un accord. Eh bien, je me suis inscrit pour créer une équipe et sortir 20 jeux mobiles dans mes scénarios avec une «date limite» le 1er juin 2002.

Phase 2

Dans la phase de team building, le projet a réussi à intéresser trois personnes supplémentaires:

• Alexander Vasiliev , un développeur Java expérimenté ayant des compétences pour résoudre des problèmes non résolus, j'ai travaillé avec lui dans la société allemande Concept Software GmbH.
• Evgeny Mikhailov , qui a récemment quitté son service militaire. Il s'est vu confier le rôle d'ingénieur QA, il avait également de l'expérience dans le développement de plateformes informatiques grand public.
• Sergey Oleinik , l'un des meilleurs artistes russes dans le domaine du pixel art, qui a été embauché à temps partiel en tant que designer externalisé, car il avait le principal emploi sous forme de travail chez INFON (quelques années plus tard, Sergey accède aux postes de directeur dans INFON).

De tous les membres de l'équipe, seuls moi et Sergey Oleinik avaient une expérience directe avec les appareils mobiles. La société nous a attribué une chambre dans son immeuble de bureaux sur la rue Bolshaya Morskaya, à côté de la maison des compositeurs. Le matériel nécessaire a été livré sous forme d'ordinateurs et de mobilier de bureau. Tout cela n'était pas nouveau et portait des signes évidents de "beushnost". Les ordinateurs sont «de marque» et, si je ne me trompe pas, la production de COMPAQ, avec Windows XP préinstallé, qui était nouveau à l'époque, auquel peu d'entre nous à l'époque étaient confrontés (nous avons préféré Windows 98). Tout ce «branding» et la spécificité du «hardware» ne nous ont pas permis de réorganiser l'OS, ce qui a apporté des risques supplémentaires dans un projet chargé, nous n'avons rien pu y faire.

Phase 3

La phase suivante a été la conception et la planification du travail. Sur la base de la «date limite», j’ai calculé que la durée moyenne d’un match était d’environ 2,5 jours (il est clair qu’il n’était pas nécessaire de parler de week-ends et de vacances avec un horaire aussi chargé). Développer des jeux avec cela selon la méthodologie généralement acceptée - «on, vous, programmeur, tâchez et faites-moi bien» était irréaliste et puisque je me souvenais des préceptes d'Adam Smith sur l'augmentation de la productivité avec une sorte de «convoyeur», je me suis concentré sur le «convoyeur» avec changement de tâche minimal. Un calendrier de réseau clair a été compilé avec le calcul du temps et de l'ordre de travail pour maximiser la parallélisation du travail.

Les rôles ont été répartis dans cet ordre:

• Alexander Vasiliev était occupé à développer des modules dépendants de la plate-forme pour afficher l'espace de jeu, et il a également créé plusieurs modèles de jeu.
• Evgeny Mikhailov était occupé à tester les produits finis. Ses compétences dans la résolution d'énigmes tout en testant des énigmes l'ont vraiment aidé. (Dans la mise en œuvre du prochain package de jeu, il a également été impliqué dans la rédaction de modèles de jeu)
• Sergey Oleinik n'était occupé que dans la production de contenu graphique.
• J'ai été impliqué dans la communication avec le client, le développement de modèles de jeux et la post-production avec la préparation des sorties. J'ai également eu le rôle de directeur artistique et de rendu de certains éléments du jeu (grâce à BK-0010 et ZX-Spectrum qui m'ont donné ces compétences).

Phase 4

Nous n'avions pas de véritable appareil physique au début du projet (pour autant que je m'en souvienne, il a été introduit quelque part par les Finlandais) et nous avons utilisé des émulateurs Siemens (émulateurs pour SL-45 et M50). En tant que système de construction final, nous avons utilisé la boîte à outils sans fil Sun Java . Il n'y avait pas d'obscurcisseur à l'époque, nous n'avions pas non plus de système de contrôle de version (nous travaillions sur un système de serveur de fichiers commun), l'automatisation était minime.

Étant donné que le périphérique cible avait des limitations très sévères sur les performances et la mémoire, il a été décidé de minimiser la charge sur le "garbage collector" en créant des objets de jeu lorsque le jeu démarre et en les réutilisant pendant l'application, c'est-à-dire au début, nous avons immédiatement créé tout ce dont nous avions besoin et cela a duré jusqu'à la fin de l'application. Les graphiques ont été stockés sous forme de fichiers PNG, et en raison du manque de temps, nous avons fait une automatisation minimale de leur emballage (en supprimant les informations redondantes et en double) et conçu cela comme un utilitaire distinct qui colle les ressources graphiques ensemble. Les ressources textuelles étaient également emballées et stockées séparément, un utilitaire spécial en était responsable. Ils ont décidé d'exclure la conception sonore en raison de la pauvreté des capacités de l'appareil, du manque de temps et des économies de mémoire. Chaque jeu était censé être représenté par une archive JAR de 30 à 40 kilo-octets.

Étant donné que certains jeux nécessitaient des calculs en virgule flottante, mais que CLDC 1.0 (qui était sur le périphérique cible) ne supportait ni flottant ni double, nous, comme sur les anciens ordinateurs, nous sommes sortis en transférant tous ces calculs vers un «point fixe» (8 bits ont été alloués à int à la partie fractionnaire), des fonctions trigonométriques ont été implémentées à travers des tableaux et une petite bibliothèque a été implémentée pour ce type de données. Afin de ne pas être confondu dans les types de données, puisque tout était int, nous avons fait une notation spéciale, où des données supplémentaires sont entrées dans le nom de la variable avec un préfixe, par exemple, i8_width dénotait une valeur avec un point fixe de 8 bits (je ne pouvais alors pas me permettre d'utiliser une telle notation )

En utilisant mes développements précédents, un framework de jeu a été créé. Le cadre se composait de plusieurs interfaces et classes auxiliaires et décrivait un modèle abstrait standard d'un jeu mobile, qui couvrirait tous les genres de l'ensemble de jeux prévu avec la possibilité de charger-sauvegarder le processus de jeu.

Chaque jeu a été développé selon le modèle Model-View-Controller , ce qui a permis d'isoler les modules en cours de développement et de ne pas "geler" pendant le processus de développement à n'importe quelle étape en préparant les modules par lots.

• StrategicBlock décrit le modèle et contient tout ce qui concerne la mise en œuvre du modèle de jeu et l'interaction des composants contenus dans cette classe.
• PlayerBlock était responsable du contrôleur , c'était une interface universelle qui renvoie un enregistrement de la progression du joueur ou de l'IA, cela a permis aux jeux de démonstration automatiques d'être montrés à l'utilisateur.
• GameStateRecord était le plus important et décrivait l'état interne du monde du jeu. Cet objet a également été transféré dans la partie dépendante de la plate-forme de la vue, où un champ de jeu a été tracé en fonction de son état.

Phase 5

Une fois les phases préparatoires terminées, ils ont commencé les travaux de production. Le premier jeu sorti, si je ne me trompe pas, était le jeu "Carting" (course automobile), puis son modèle de jeu a été réutilisé avec des modifications mineures pour le jeu "Downhill race" (piste de ski). Dans le processus de développement, tous les jeux produits avaient leurs noms de code, et le produit fini était déjà nommé d'après le nom envoyé par Mikko. Certains noms des jeux étaient plutôt étranges (par exemple, le jeu de karaté s'appelait "Chop Chop"), mais si vous vous souvenez que les Suédois devaient se débarrasser du nom Battleships à un moment donné, il y avait alors un grain de son.

Le travail s'est bien déroulé et je ne me souviens pas de graves problèmes organisationnels et techniques. Comme d'habitude, le vrai appareil a montré que l'émulation ne reflétait pas toujours l'image réelle des choses, mais il n'y avait pas de moments critiques nécessitant une refonte totale. Avec Windows XP «peu familier», il y a eu un cas «drôle» lorsque nous sommes arrivés au travail le matin et que nous avons constaté de manière inattendue que tous les ordinateurs avaient changé de mot de passe et que nous n'avions pas à entrer dans le système. Dans le même temps, les ordinateurs ont été configurés de sorte que nous n'avons pas eu la possibilité de définir de nouveaux mots de passe, apparemment, nous avons oublié de réinitialiser certains paramètres de sécurité. Environ une demi-journée de travail a été consacrée à ce problème et tout s'est terminé par un piratage total des systèmes avec des mots de passe système changeants.

Dieu merci, personne pendant la période de travail n'est tombé malade et certaines circonstances de force majeure ne se sont pas produites, car nous n'avions pas de temps libre pour eux. Mikko nous a personnellement rendu visite rarement, principalement avec sa correspondance par e-mail. Il est arrivé qu'il puisse venir et je ne l'ai découvert qu'après coup. Environ un mois et demi après le début des travaux, il nous a photographiés tous les trois sur le lieu de travail pour le bulletin interne d'Akumiitti.

Non sans changements dans les plans de travail affectant le calendrier. L'un des scénarios du jeu était le 11 septembre et le joueur a été invité à protéger les tours jumelles contre les avions kamikazes volant dessus. Au début, ce scénario a été approuvé par les Finlandais et Sergey Oleinik a dessiné un excellent économiseur d'écran (d'autres qu'il ne savait pas dessiner) contenant même un portrait miniature d'Oussama ben Laden, mais quelque part dans la seconde moitié du travail de production, j'ai reçu un message de Mikko que je devrais refuser ce jeu , car il s'agit d'un «sujet très boueux» et personne ne veut soulever des problèmes probables avec le monde spirituel des terroristes et de leurs sympathisants, qui peuvent mal évaluer le jeu. Ce script a donc été rejeté et le jeu a été rapidement remplacé par un autre, ce qui a nécessité quelques jours supplémentaires.

En fin de compte, les 20 jeux ont tous été réalisés à temps + 2 jours en raison de changements de la part du client. Le colis a été entièrement testé et expédié d'abord par Akumiitti, puis par eux à leur client (une grande entreprise de téléphonie mobile). Le package comprenait les jeux suivants:

• AMAZING MAZE (puzzle, labyrinthe) inspiré du célèbre jeu Soko-Ban
• Jeu inspiré du D-Day de BALLOON PARK (arcade)
• BLACK JACK (gaming) n'est qu'un jeu sur 21
• CARTING (arcade) inspiré de la machine à sous soviétique
• CHOP CHOP (jeu de combat) inspiré du jeu KARATE-DO
• COSMIC STORM (arcade) jeu inspiré des astéroïdes
• DANGER ZONE (arcade) jeu inspiré LONG RAID
• COURSE DE DESCENTE (arcade)
• LEAP OF FAITH (arcade) inspiré du jeu une fois vu sur PC
• Jeu de rallye inspiré de OFFROAD (arcade)
• PACK RACE (arcade) rappelle vaguement Pac Man
• TENNIS inspiré du PING-PONG (sport)
• PITMAN (arcade) rappelle vaguement le jeu Boulder dash
• PUZZLE (puzzle) réalisé à partir du puzzle 15
• Jeu d'inspiration RACKET BALL (arcade) Arkanoid
• SEA BATTLE (arcade) script pour la bonne vieille bataille navale
• SHIP DUEL (arcade) inspiré du jeu Worms
• STAR GUN (arcade) inspiré du jeu de base Star vu
• TREASURE HUNT (arcade, labyrinthe) jeu de trésor inspiré
• VIPER (arcade, labyrinthe) altération du jeu Snake

Au milieu d'une telle réussite, la direction de TekLabs (la soi-disant unité commerciale de MPS-Russie) et Akumiitti ont décidé de marquer cette affaire à travers une visite d'une journée par la direction et l'équipe de la maison de vacances de banlieue scandinave avec un dîner de gala et un sauna. Ainsi, après un certain temps, le «top» d'Akumiitti Jurki Matikainen nous a rendu visite et a discuté du développement de la direction mobile. Lors du rallye, j'ai décrit les ressources nécessaires pour organiser la production de jeux mobiles à l'échelle industrielle, mais n'a pas rencontré beaucoup de compréhension (ce n'était pas une priorité pour les Finlandais).

Mikko a démissionné après un certain temps et Eero Pöyry (actuellement directeur du développement de Rovio) est devenu notre commissaire de la société mère. Il nous a tenus informés des expéditions du premier package de jeu publié. Il a reçu des informations selon lesquelles plus de 1 200 applications mobiles ont été expédiées vers les 1 000 premiers téléphones mobiles Siemens M50 vendus par leur client, ce qui a montré l'intérêt réel des utilisateurs pour le contenu J2ME. J'ai reçu un tableau d'expédition par e-mail pour les jeux et il remplissait la règle heuristique exprimée par Sergei Kuligin pour moi - "si vous voulez que le jeu soit garanti d'être vendu - faites la course", le jeu "Carting" était le leader absolu de l'expédition et occupait plus d'un quart du graphique.

Je pense que vous pouvez vous arrêter ici, car à mon avis, les détails et les résultats du projet sont divulgués de manière suffisamment détaillée.

Petites conclusions

Dans le contexte de tout ce qui précède, je voudrais formuler un certain nombre de raisons qui, à mon avis, ont conduit au succès du projet:

• Il a été possible de trouver rapidement et d'intéresser du personnel sensé capable de faire le travail.
• L'équipe a été créée à partir de zéro, s'il y avait une tentative de connecter une équipe existante et de la diluer avec de nouveaux membres, le rodage et le désassemblage de la hiérarchie prendraient tellement de temps que cela mettrait presque certainement le projet au bord de la mort.
• Un "lead" actif a été trouvé (quoique pratiquement sans connaissance de l'anglais), qui a assumé la responsabilité et n'était pas suffisamment expérimenté pour comprendre que "c'est un pari".
• Le projet a été pensé au départ, la planification et la répartition des rôles ont été effectuées. (note auth. - En fait, c'est une étape très rare dans les projets, malgré le fait que tout le monde le déclare, surtout dans les projets où "les délais sont respectés". Le cycle de développement habituel passe par le système - "pensez trop tard, faites-le!" )
• Les représentants d'Akumiitti et les dirigeants de TekLabs n'ont pas essayé d'interférer dans les processus de production, respectant les limites et n'interagissant que dans le cadre de leur rôle commercial, fournissant au leadership de l'équipe tous les leviers nécessaires.
• En général, le processus n'a pas utilisé quelque chose de radicalement inconnu des participants.

Parmi les mauvaises étapes que je voudrais noter, mentionnons:

• L'équipement de production avec un logiciel de base inconnu, avec des exigences de temps strictes, était un risque inutile.
• Analyse inadéquate des scénarios de jeu par le client, ce qui a conduit au remplacement de l'un des jeux.
• Horaire de travail trop stressant entraînant l'épuisement professionnel.

Phase supplémentaire, russe

Dans le contexte des étapes dans le domaine des jeux mobiles par les partenaires occidentaux, on ne peut que parler des étapes que je connais des joueurs russes dans ce domaine. Comme indiqué ci-dessus, avant le projet, je travaillais chez INFON et elle ne voulait pas non plus s'éloigner du développement de jeux J2ME. En général, INFON était très similaire à Akumiitti dans les affaires, avec une petite différence - ce que les Finlandais ont promis pendant 10 ans ont fait dans INFON pendant six mois ou un an.

En juillet 2002, le propriétaire d'INFON a demandé de réaliser un jeu mobile sur le thème de la «chasse au canard», car il allait chasser avec l'un des top managers de NOKIA. ( ) Nokia 3410. , . , « », . « » . — « , ! !».

INFON ( Nokia Totally Board, 2002 ). Snowboard NOKIA 3410, . INFON Penalty Drive OFF. .

, ( ), Fowling Snowboard , « INFON ».

PS

, , , .

- 2002 , , Java. Java- ( Antenna ), , XML . OSS JDBC Postgres . , Linux libcomment-preprocessor-java .