Russischer Fußabdruck in der skandinavischen Saga der Videospiele, Ende

Das Ende des ersten Teils der Geschichte enthüllt eine kurz erwähnte Episode im finnischen Buch "Finnische Videospiele: Geschichte und Katalog" .

In diesem Teil beschreibe ich organisatorische und technische Probleme und ziehe einige Schlussfolgerungen über die Organisation des Projekts und die Gründe, warum es erfolgreich war.

Phase 0

Nachdem ich ein kurzes schwedisches Projekt abgeschlossen und mich einige Zeit ausgeruht hatte, bekam ich einen Job in einem Unternehmen, das Inhalte unter der Marke „INFON“ produzierte (ja, dies ist das gleiche - „INFON auf Ihrem Telefon“). INFON hatte auch Pläne für die Produktion von Handyspielen im Jahr 2001, aber dieser Markt war immer noch ziemlich neblig und es fehlte die notwendige quantitative Basis an Geräten. Im Büro sah ich nur das Nokia 9110, das für die Spieleentwicklung geeignet war, aber nachdem wir damit gespielt hatten, beschlossen wir, diese Angelegenheit zu verschieben (I. Ich habe gehört, dass dieser „Ziegelstein“ später einem Gouverneur übergeben wurde. Ich war verantwortlich für Applets für die Onlinedienste des Unternehmens, die unter dem Markennamen Logoton veröffentlicht wurden und es Benutzern ermöglichten, Grafik- und Audioinhalte vorzubereiten und sie anschließend per SMS an ihre Telefone zu senden. Im Allgemeinen habe ich fast ein Jahr damit verbracht.

Phase 1

Irgendwann im März 2002 begann die Geschichte, über die Mikko Honkakorpi in seinem Interview kurz erzählte. Soweit ich mich erinnere, kam Artyom Golubchin, ein Manager der finnisch-russischen Personalvermittlungsfirma MPS-Russia (der für den finnischen Markt arbeitete), zunächst zu mir und bot mir an, ein Interview zum Thema Arbeit zu bekommen. Sie beschlossen, das Geschäft weiterzuentwickeln und in die Kategorie der Outsourcing-Entwicklung einzusteigen, indem sie die sogenannten „Kompetenzzentren“ (wie sie ihr Geschäftsmodell nannten) eröffneten. Der Hauptvorteil der „Zentren“ war die Einfachheit der Personalmanipulation durch das beschäftigende Unternehmen, nämlich die einfache Schließung und Entlassung, da es in Finnland sehr große Schwierigkeiten gibt und eine unsachgemäße Entlassung zum Konkurs des Unternehmens führen kann.

Eines der Unternehmen, das sein „Kompetenzzentrum“ platzieren wollte, war das finnische Unternehmen Akumiitti Oy. Zu dieser Zeit ein ziemlich bekannter Anbieter von Lösungen für die Organisation mobiler Dienste. Das erste Interview war ohne die Anwesenheit eines Vertreters des finnischen Unternehmens. Wenn ich mich nicht irre, wurde ich zum ersten Mal von Artem Golubchin und zwei Finnen interviewt. Einer der Finnen war der Wikinger-ähnliche Timo Multamaki (heute ein berühmter finnischer Brettspieldesigner) und ein anderer Finne, an dessen Namen ich mich nicht mehr erinnere. Ich erinnerte mich nur daran, dass sie gefragt hatten, welche Art von Spiel ich mag, worauf ich antwortete: "Operation Flashpoint". Dann gab es ein Interview mit Psychologen und nur einmal in einem Drittel gab es ein Interview mit Mikko Honkakorpi. Parallel dazu kontaktierten die Finnen Sergey Kuligin und wir wurden eingeladen, das Projekt zu besprechen.

Es stellte sich heraus, dass eines der großen Telekommunikationsunternehmen den Verkauf eines neuen preisgünstigen Siemens M50-Telefons in einem der osteuropäischen Länder plante. Da das Telefon J2ME-Unterstützung an Bord hatte, wollte der Kunde von Akumiitti ein Paket mit 20 Spielen sowie mobile Dienste erhalten. Die Hauptschwierigkeit bestand darin, dass die Frist für den 1. Juni festgelegt war und die Werft bereits Ende März war und alles an allem weniger als zwei Monate entfernt war. Aufgrund seiner reichen Spielerfahrung lehnte Sergey Kuligin das Angebot der Zusammenarbeit ab und führte an, dass es ein Glücksspiel sei, so viele Spiele in einem solchen Zeitraum zu machen, aber ich war weniger erfahren und setzte die Verhandlungen fort.

Ich wurde gebeten, Szenarien für 20 Handyspiele zu entwickeln und sie beim nächsten Treffen zu zeigen, das in wenigen Tagen stattfinden sollte. In diesen Tagen habe ich abends ein paar alte Spiele aus meinen Archiven von BK-0010 "geschaufelt" und eine Zusammenstellung geeigneter Skripte erstellt. Zu den Spielen gehörten Arcade, Glücksspiel und Logik. Nachdem ich mich einige Tage später mit Mikko und Timo getroffen hatte, präsentierte ich ihnen die Skripte. Mikko sagte, dass die Skripte zu ihnen passen und mit mir schüttelten sie und Timo sich die Hand und markierten den Abschluss eines Deals. Nun, ich habe mich angemeldet, um ein Team zu bilden und 20 Handyspiele in meinen Szenarien mit einer „Frist“ am 1. Juni 2002 zu veröffentlichen.

Phase 2

In der Phase der Teambildung gelang es dem Projekt, drei weitere Personen zu interessieren:

• Alexander Vasiliev , ein erfahrener Java-Entwickler mit Fähigkeiten zur Lösung ungelöster Probleme, habe ich mit ihm in der deutschen Firma Concept Software GmbH zusammengearbeitet.
• Evgeny Mikhailov , der kürzlich seinen Militärdienst beendet hat. Ihm wurde die Rolle des QS-Ingenieurs zugewiesen. Er hatte auch Erfahrung in der Entwicklung von Computerplattformen für Verbraucher.
• Sergey Oleinik , einer der besten russischen Künstler auf dem Gebiet der Pixelkunst, der in Teilzeit als ausgelagerter Designer eingestellt wurde, da er die Hauptbeschäftigung in Form von Arbeiten bei INFON hatte (einige Jahre später wird Sergey die Spitzenpositionen des Regisseurs erreichen in INFON).

Von allen Teammitgliedern hatten nur ich und Sergey Oleinik direkte Erfahrungen mit mobilen Geräten. Die Firma teilte uns ein Zimmer in ihrem Bürogebäude in der Bolshaya Morskaya Straße neben dem Haus der Komponisten zu. Notwendige Geräte wurden in Form von Computern und Büromöbeln geliefert. All dies war nicht neu und trug offensichtliche Anzeichen von "beushnost". Computer sind „Marken“ und, wenn ich mich nicht irre, die COMPAQ-Produktion mit vorinstalliertem Windows XP, das zu dieser Zeit neu war und mit dem nur wenige von uns zu dieser Zeit konfrontiert waren (wir bevorzugten Windows 98). All dieses „Branding“ und die Spezifität der „Hardware“ ermöglichten es uns nicht, das Betriebssystem neu zu ordnen, was zusätzliche Risiken in einem geschäftigen Projekt mit sich brachte. Wir konnten nichts dagegen tun.

Phase 3

Die nächste Phase war Design und Arbeitsplanung. Basierend auf der "Frist" habe ich berechnet, dass die durchschnittliche Zeit für ein Spiel etwa 2,5 Tage betrug (es ist klar, dass es nicht nötig war, über Wochenenden und Feiertage mit einem so vollen Zeitplan zu sprechen). Es war unrealistisch, Spiele damit nach der allgemein anerkannten Standardmethode zu entwickeln - "Auf, Sie, Programmierer, Aufgabe und mach mich gut". Da ich mich an Adam Smiths Vorschriften zur Steigerung der Produktivität mit einer Art "Förderer" erinnerte, konzentrierte ich mich auf den "Förderer" mit minimale Aufgabenumschaltung. Mit der Berechnung von Arbeitszeit und Arbeitsreihenfolge wurde ein klarer Netzwerkplan erstellt, um die Parallelisierung der Arbeit zu maximieren.

Die Rollen wurden in dieser Reihenfolge verteilt:

• Alexander Vasiliev war damit beschäftigt, plattformabhängige Module für die Anzeige des Spielraums zu entwickeln, und er erstellte auch mehrere Spielmodelle.
• Evgeny Mikhailov war damit beschäftigt, fertige Produkte zu testen. Seine Fähigkeiten beim Lösen von Rätseln beim Testen von Rätseln haben wirklich geholfen. (Bei der Implementierung des nächsten Spielpakets war er auch am Schreiben von Spielmodellen beteiligt.)
• Sergey Oleinik war nur mit der Produktion von grafischen Inhalten beschäftigt.
• Ich war an der Kommunikation mit dem Kunden, der Entwicklung von Spielmodellen und der Postproduktion mit der Vorbereitung von Veröffentlichungen beteiligt. Ich hatte auch die Rolle des Art Directors und des Renderns einiger Spielelemente (dank BK-0010 und ZX-Spectrum, die mir diese Fähigkeiten verliehen haben).

Phase 4

Wir hatten zu Beginn des Projekts kein echtes physisches Gerät (soweit ich mich erinnere, wurde es irgendwo von den Finnen eingeführt) und wir verwendeten Siemens-Emulatoren (Emulatoren für SL-45 und M50). Als endgültiges Build-System haben wir das Sun Java Wireless Toolkit verwendet . Zu diesem Zeitpunkt gab es keine Verschleierer, wir hatten auch kein Versionskontrollsystem (wir arbeiteten an einem gemeinsamen Dateiserversystem), die Automatisierung war minimal.

Da das Zielgerät sehr starke Einschränkungen hinsichtlich Leistung und Speicher aufwies, wurde beschlossen, die Belastung des "Garbage Collector" zu minimieren, indem beim Start des Spiels Spielobjekte erstellt und während der Anwendung wiederverwendet wurden, d. H. Zu Beginn haben wir sofort alles erstellt, was wir brauchten, und es hat bis zum Ende der Anwendung gelebt. Grafiken wurden in Form von PNG-Dateien gespeichert. Aufgrund des Zeitmangels haben wir die Verpackung nur minimal automatisiert (indem redundante und doppelte Informationen entfernt wurden) und dies als separates Dienstprogramm konzipiert, das grafische Ressourcen zusammenklebt. Textressourcen wurden ebenfalls separat verpackt und gespeichert, ein spezielles Dienstprogramm war dafür verantwortlich. Sie beschlossen, das Sounddesign aufgrund der mangelnden Funktionen des Geräts, des Zeitmangels und der Speicherersparnis auszuschließen. Jedes Spiel sollte durch ein JAR-Archiv mit einer Größe von 30 bis 40 Kilobyte dargestellt werden.

Da für einige Spiele Gleitkommaberechnungen erforderlich waren, CLDC 1.0 (das sich auf dem Zielgerät befand) jedoch weder Float noch Double unterstützte, haben wir, wie bei alten Computern, alle derartigen Berechnungen auf einen „festen Punkt“ übertragen (8 Bits wurden int zugewiesen) zum Bruchteil) wurden trigonometrische Funktionen durch Tabellen implementiert und eine kleine Bibliothek für diesen Datentyp implementiert. Um bei den Datentypen nicht verwirrt zu werden, haben wir eine spezielle Notation erstellt, bei der zusätzliche Daten in den Variablennamen mit einem Präfix eingefügt wurden , z. B. i8_width, das einen Wert mit einem festen Punkt von 8 Bit bezeichnet (ich konnte dann mit einer solchen Notation nicht durchkommen) )

Mit meinen früheren Entwicklungen wurde ein Spiel-Framework erstellt. Das Framework bestand aus mehreren Schnittstellen und Hilfsklassen und beschrieb ein abstraktes Standardmodell eines Handyspiels, das alle Genres aus dem geplanten Spielepaket abdeckt und den Spielprozess laden kann.

Jedes Spiel wurde nach dem Model-View-Controller- Muster entwickelt. Dies ermöglichte es, die zu entwickelnden Module zu isolieren und während des Entwicklungsprozesses zu keinem Zeitpunkt zu „hängen“, indem die Module in Stapeln vorbereitet wurden.

• StrategicBlock beschrieb das Modell und enthielt alles, was mit der Implementierung des Spielmodells und der Interaktion der in dieser Klasse enthaltenen Komponenten zu tun hatte.
• PlayerBlock war für den Controller verantwortlich . Es handelte sich um eine universelle Schnittstelle, die eine Aufzeichnung des Fortschritts oder der KI des Spielers zurückgibt. Dadurch konnten dem Benutzer automatische Demos angezeigt werden.
• GameStateRecord war das wichtigste und beschrieb den internen Zustand der Spielwelt. Dieses Objekt wurde auch in den plattformabhängigen Teil der Ansicht übertragen, in dem ein Spielfeld basierend auf seinem Status gezeichnet wurde.

Phase 5

Nach Abschluss der Vorbereitungsphasen begannen die Produktionsarbeiten. Das erste veröffentlichte Spiel, wenn ich mich nicht irre, war das Spiel "Carting" (Autorennen), dann wurde sein Spielmodell mit geringfügigen Änderungen für das Spiel "Downhill Race" (Skipiste) wiederverwendet. Während des Entwicklungsprozesses hatten alle produzierten Spiele ihre Codenamen und das fertige Produkt wurde bereits nach dem von Mikko gesendeten Namen benannt. Einige Namen der Spiele waren ziemlich seltsam (zum Beispiel hieß das Karate-Spiel „Chop Chop“), aber wenn Sie sich daran erinnern, dass die Schweden den Namen Schlachtschiffe irgendwann loswerden mussten, dann gab es ein gesundes Korn.

Die Arbeit verlief reibungslos und ich kann mich nicht an ernsthafte organisatorische und technische Probleme erinnern. Wie üblich zeigte das reale Gerät, dass die Emulation nicht immer das reale Bild der Dinge widerspiegelt, aber es gab keine kritischen Momente, die eine vollständige Wiederholung erforderten. Mit dem "unbekannten" Windows XP gab es einen "lustigen" Fall, als wir morgens zur Arbeit kamen und unerwartet selbst sahen, dass alle Computer ihr Passwort geändert hatten und wir nicht in das System eintreten mussten. Gleichzeitig wurden Computer so konfiguriert, dass wir keine Möglichkeit hatten, neue Passwörter festzulegen. Anscheinend haben wir vergessen, einige Sicherheitseinstellungen zurückzusetzen. Etwa ein halber Arbeitstag wurde mit dieser Angelegenheit verbracht, und alles endete mit einem vollständigen Hacking von Systemen mit sich ändernden Systemkennwörtern.

Gott sei Dank wurde während der Arbeitszeit niemand krank und einige Umstände höherer Gewalt traten nicht ein, da wir keine Freizeit für sie hatten. Mikko hat uns nur selten persönlich besucht, meistens mit ihm per E-Mail. Es kam vor, dass er kommen konnte und ich erfuhr es erst nachträglich. Ungefähr anderthalb Monate nach Arbeitsbeginn fotografierte er uns drei am Arbeitsplatz für den internen Newsletter von Akumiitti.

Nicht ohne Änderungen der Arbeitspläne, die sich auf den Zeitplan auswirken. Eines der Spielszenarien war am 11. September und der Spieler wurde gebeten, die Zwillingstürme vor Kamikaze-Flugzeugen zu schützen, die auf ihnen fliegen. Zuerst wurde dieses Szenario von den Finnen genehmigt und Sergey Oleinik zeichnete einen hervorragenden Bildschirmschoner (andere, die er nicht zeichnen konnte), der sogar ein Miniaturporträt von Osama bin Laden enthielt, aber irgendwann in der zweiten Hälfte der Produktionsarbeit erhielt ich eine Nachricht von Mikko, dass ich dieses Spiel ablehnen müsste , da es sich um ein sehr "schlammiges Thema" handelt und niemand wahrscheinliche Probleme mit der spirituellen Welt der Terroristen und ihrer Sympathisanten aufwerfen möchte, die das Spiel möglicherweise falsch bewerten. Daher wurde dieses Skript abgelehnt und das Spiel schnell durch ein anderes ersetzt, was einige Tage länger dauerte.

Letztendlich wurden alle 20 Spiele aufgrund von Änderungen seitens des Kunden pünktlich + 2 Tage gemacht. Das Paket wurde vollständig getestet und zuerst von Akumiitti und dann von ihnen an ihren Kunden (ein großes Mobilfunkunternehmen) versendet. Das Paket bestand aus folgenden Spielen:

• ERSTAUNLICHES MAZE (Puzzle, Labyrinth), inspiriert vom berühmten Spiel Soko-Ban
• BALLOON PARK (Arcade) inspiriertes D-Day-Spiel
• BLACK JACK (Gaming) ist nur ein Spiel in 21
• CARTING (Arcade) inspirierte den sowjetischen Spielautomaten
• CHOP CHOP (Kampfspiel) inspiriert vom Spiel KARATE-DO
• COSMIC STORM (Arcade) inspirierte das Spiel Asteroids
• DANGER ZONE (Arcade) inspiriertes Spiel LONG RAID
• DOWNHILL RACE (Spielhalle)
• LEAP OF FAITH (Arcade), inspiriert von dem Spiel, das einst auf dem PC zu sehen war
• OFFROAD (Arcade) inspiriertes Rallyespiel
• PACK RACE (Arcade) erinnert vage an Pac Man
• PING-PONG (Sport) inspiriertes Spiel TENNIS
• PITMAN (Arcade) erinnert vage an das Spiel Boulder Dash
• PUZZLE (Puzzle) basierend auf Puzzle 15
• RACKET BALL (Arcade) inspiriertes Spiel Arkanoid
• SEA BATTLE (Arcade) -Skript für die gute alte Seeschlacht
• SHIP DUEL (Arcade) inspirierte das Spiel Worms
• STAR GUN (Arcade), inspiriert vom gesehenen Star-Basisspiel
• TREASURE HUNT (Arcade, Labyrinth) inspirierte das Schatzspiel
• VIPER (Arcade, Labyrinth) Änderung des Spiels Snake

Inmitten dieser Leistung beschlossen das Management von TekLabs (der sogenannten Geschäftseinheit von MPS-Russland) und Akumiitti, diese Angelegenheit durch einen eintägigen Besuch des Managements und des Teams des skandinavischen Vorortferienhauses mit einem Galadinner und einer Sauna zu kennzeichnen. Nach einer Weile besuchte uns das „Top“ von Akumiitti Jurki Matikainen und diskutierte die Entwicklung der mobilen Richtung. Bei der Kundgebung habe ich beschrieben, welche Ressourcen erforderlich sind, um die Produktion von Handyspielen im industriellen Maßstab zu organisieren, aber nicht viel Verständnis gefunden (dies war für die Finnen keine Priorität).

Mikko kündigte nach einiger Zeit und Eero Pöyry (derzeit Rovios Entwicklungsdirektor) wurde unser Kurator von der Muttergesellschaft. Er hielt uns über die Auslieferung des veröffentlichten ersten Spielpakets auf dem Laufenden. Er erhielt Informationen, dass mehr als 1.200 mobile Anwendungen an die ersten 1000 von ihrem Kunden verkauften Siemens M50-Mobiltelefone ausgeliefert wurden, was das wahre Interesse der Benutzer an J2ME-Inhalten zeigte. Ich erhielt eine E-Mail-Versandkarte für Spiele, die die von Sergei Kuligin für mich geäußerte heuristische Regel erfüllte: „Wenn Sie möchten, dass das Spiel garantiert verkauft wird - machen Sie das Rennen“, war das Spiel „Carting“ der absolute Marktführer im Versand und nahm mehr als ein Viertel der Karte ein.

Ich denke, Sie können hier aufhören, weil meiner Meinung nach die Details und Ergebnisse des Projekts ausreichend detailliert bekannt gegeben werden.

Kleine Schlussfolgerungen

Vor dem Hintergrund all dessen möchte ich eine Reihe von Gründen formulieren, die meiner Meinung nach zum Erfolg des Projekts geführt haben:

• Es war möglich, schnell vernünftiges Personal zu finden und zu interessieren, das in der Lage war, die Arbeit zu erledigen.
• Das Team wurde von Grund auf neu erstellt. Wenn versucht wurde, ein bestehendes Team zu verbinden und es mit neuen Mitgliedern zu verwässern, würde das Überlappen und Zerlegen der Hierarchie so viel Zeit in Anspruch nehmen, dass das Projekt mit ziemlicher Sicherheit an den Rand des Todes geraten würde.
• Es wurde ein aktiver "Lead" gefunden (wenn auch praktisch ohne Englischkenntnisse), der Verantwortung übernahm und nicht erfahren genug war, um zu verstehen, dass "dies ein Glücksspiel ist".
• Das Projekt wurde zu Beginn durchdacht, die Planung und Verteilung der Rollen wurde durchgeführt. (note auth. - Tatsächlich ist dies ein sehr seltener Schritt in Projekten, obwohl jeder dies erklärt, insbesondere in Projekten, in denen "Fristen eingehalten werden". Der übliche Entwicklungszyklus durchläuft das System - "Denken Sie zu spät, tun Sie es!" )
• Vertreter von Akumiitti und Führungskräfte von TekLabs haben nicht versucht, sich in Produktionsprozesse einzumischen, Grenzen einzuhalten und nur innerhalb ihrer Geschäftsrolle zu interagieren, um der Teamleitung den nötigen Hebel zu geben.
• Im Allgemeinen verwendete der Prozess nichts, was den Teilnehmern radikal unbekannt war.

Zu den falschen Schritten, die ich erwähnen möchte, gehörten:

• Produktionsausrüstung mit unbekannter Basissoftware mit hohen Zeitanforderungen war ein unnötiges Risiko.
• Unzureichende Analyse der Spielszenarien durch den Kunden, was zum Austausch eines der Spiele führte.
• Zu stressiger Arbeitsplan führt zu Burnout.

Zusätzliche Phase, Russisch

Vor dem Hintergrund der Schritte westlicher Partner im Bereich der Handyspiele kann man nur über die Schritte berichten, die ich von russischen Spielern in diesem Bereich kenne. Wie oben erwähnt, habe ich vor dem Projekt bei INFON gearbeitet und sie wollte sich auch nicht von der Entwicklung von J2ME-Spielen fernhalten. Im Allgemeinen war INFON Akumiitti im Geschäft sehr ähnlich, mit einem kleinen Unterschied - was die Finnen für 10 Jahre zugesagt hatten, tat INFON für ein halbes Jahr oder ein Jahr.

Im Juli 2002 bat der Inhaber von INFON um ein Handyspiel zum Thema „Entenjagd“, da er mit einem der Top-Manager von NOKIA jagen wollte. ( ) Nokia 3410. , . , « », . « » . — « , ! !».

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

, ( ), Fowling Snowboard , « INFON ».

PS

, , , .

Gegen Ende des Sommers 2002 wurde eine Version des Präprozessors für die Java-Sprache erstellt, um die Assemblierung für verschiedene mobile Plattformen zu automatisieren. Ich denke, wenn dies nicht der allererste Java-Präprozessor war (der Antennen-Präprozessor erschien im selben Jahr), dann war er zumindest der leistungsstärkste, da er zwei Durchgänge hatte und sogar Daten in XML-Dateien speichern durfte. Dieses Projekt ist noch als OSS aktiv und wird beispielsweise beim Erstellen des JDBC-Treibers mit dem Befehl Postgres verwendet . Ich war sogar ein wenig überrascht, diesen Präprozessor in verschiedenen Linux-Repositorys zu finden, die als libcomment-preprocessor-java- Paket bezeichnet wurden .