Bolo ist ein Videospiel, das für die BBC Mikrocomputer durch Stuart Cheshire 1987 geschaffen ist, und später zum Macintosh in seiner populärsten Verkörperung getragen ist. Am meisten kürzlich wurde ein Windows-Klon genannt Winbolo von John Morrison entwickelt. Der Bolo von Cheshire ist ein vernetztes Mehrfachabspiellaufwerk-Spiel, das ein Zisterne-Schlachtfeld vortäuscht.

Ein ähnlich genanntes Zisterne-Spiel wurde für den Apple II 1982 geschaffen. Cheshire behauptet, dass das "ein unglücklicher Zufall" war, und dass seine Indianerfrau den Namen begeistert hat. Wie Cheshire in seiner ursprünglichen Dokumentation für das Spiel bemerkt hat, "ist Bolo das Hindi-Wort für die Kommunikation. Bolo ist über Computer, die im Netz, und wichtiger über Menschen kommunizieren, die mit einander kommunizieren, wie sie behaupten, Form-Verbindungen verhandeln, stategies, usw." abstimmen

Beschreibung

In Bolo befiehlt der Spieler einer Zisterne, die um ein Schlachtfeld gesteuert werden kann, das von oben angesehen wird. Die Zisterne ist relativ gut gepanzert und wird mehrere "Erfolge" nehmen, bevor sie zerstört wird. Zisternen können auch durch das Fahren von ihnen in auch tiefes Wasser zerstört werden.

Die primäre Waffe der Zisterne ist seine Kanone, die nur in der Richtung schießt, wird die Zisterne angespitzt und hat eine ziemlich schnelle Rate des Feuers. Die Zisterne trägt auch Gruben als eine sekundäre Waffe, die in Bewegung fallen gelassen, oder von einem Ingenieur gepflanzt sein kann, der von der Zisterne läuft und die Mine in den Boden "bohrt". In Spielen, wo die "Verborgenen Gruben" Einstellung aktiviert wird, sind solche Gruben für andere Spieler unsichtbar, bis sie ganz in der Nähe von ihnen (häufig zu nahe fahren, um rechtzeitig anzuhalten). Verborgene Gruben bleiben sichtbar dem Spieler, der sie, und anderen Mitgliedern seiner Mannschaft gepflanzt hat.

Munition, sowohl für die Kanone als auch für Gruben, kann an einer begrenzten Zahl von um die Karte gestreuten Versorgungsbasen nachgefüllt werden. Die Basen ersetzen auch Schaden zu Zisternen, aber das entleert die "Rüstung" der Basis. Der Bedarf von Basen der Munition und Rüstung füllt sich langsam wieder.

Die strategische Absicht des Spiels ist, alle Basen auf der Karte zu gewinnen. Nicht beanspruchte "neutrale" Basen können durch das einfache Fahren von jemandes Zisterne über sie gefordert werden, nach denen der Spieler und seine/ihre Mannschaft auf die Mittel solcher "freundlichen" Basen ziehen können. "Feindliche" Basen können durch das Schießen von ihnen gewonnen werden, bis ihre Rüstungsversorgung auf die Null reduziert wird, nach der jeder Spieler über sie fahren kann, um sie für jemandes eigene Mannschaft zu fordern. Basen, die kürzlich wiedergepanzerte beschädigte Zisternen haben, werden leichter gegriffen, da ihr Rüstungsbedarf Zeit in Anspruch nimmt, um sich zu regenerieren.

Eine primäre Taktik des Spiels ist die Festnahme und das Pflanzen von Pillenschachteln, die auch um die Karte gestreut werden. Pillenschachteln sind am Anfang feindlich, und werden nach jeder Zisterne schießen, die sich ihnen nähert. Wie die Versorgungsbasen kann nach Pillenschachteln, bis zerstört, geschossen werden, nach dem sie wiederaufmarschiert werden können und freundlich zur Mannschaft dieses Spielers werden. Verschieden von den Basen können Pillenschachteln vom Ingenieur der Zisterne aufgenommen, und dann zu mehr strategischen Positionen bewegt werden. In den frühen Versionen von Macintosh waren die Pillenschachteln ziemlich leicht zu töten; in späteren Versionen vergrößern Pillenschachteln progressiv ihre Rate des Feuers, weil sie angegriffen werden, schließlich äußerst tödlich werdend. Spieler haben eine Reihe von taktischen Tricks entwickelt, um schnelle Pillenschachtel-Festnahme, wie der Köder zu vollbringen (wovon ein Spieler Feuer der Pillenschachtel wegzieht, während ein Verbündeter es schießt), und verschiedener pilltakes (wohin eine oder mehr Wände und/oder freundliche Pillenschachteln gelegt werden, so dass sie die Schüsse der feindlichen Pillenschachtel blockieren, aber der Zisterne erlauben, vorbei daran an der feindlichen Pillenschachtel zu schießen).

Der Ingenieur, besser bekannt als der "LGM" (für den "kleinen unerfahrenen Mitarbeiter") kann auch Bauaufgaben durchführen. Um das zu tun, muss er zuerst in einen Wald gesandt werden, um Bäume zu schneiden, die als "Bargeld" in der Welt von Bolo handeln. Er kann dann Straßen bauen, um Reisen oder konkrete Wände zu beschleunigen, um Basen und Form-Fallen zu schützen. Der Ingenieur kann auf diesen Missionen getötet werden, und ein Ersatz wird in nach einer Verzögerung mit dem Fallschirm abspringen. Tötung feindlicher Ingenieure hat auch seinen eigenen Satz der Taktik, eines des scheußlichsten Wesens entwickelt, um eine Mine in einem Wald zu pflanzen, wo, wie man bekannt, ein Feind Bäume sammelt.

Internetspiele beginnen normalerweise mit einer Periode, in der Mannschaften aufgestellt werden, während Spieler im tiefen Meer bleiben, allgemein in den vereinbarten Startpunkte vor einem vereinbarten Signal zurückgebend, das aktiven gameplay beginnt. Die folgende Phase ist gewöhnlich eine "geführte Basis", wo Spieler versuchen, so viele neutrale Basen wie möglich schnell zu greifen. Nach dieser anfänglichen Phase können verschiedene Strategien verwendet werden. Die meisten schließen die schnelle Festnahme mehrerer neutraler Pillenschachteln ein, die defensiv verwendet werden können, um Gegner an "baseraping" zu verhindern (aggressive Angriffe auf jemandes Basen, die auf Quellenerschöpfung schnell hinauslaufen können). Pillenschachteln werden oft beleidigend, jedoch, durch das Stoßen von ihnen vorwärts zu Basen eines Gegners, das Verwenden ihrer Feuerkraft verwendet, um Territorium zu kontrollieren. Spiele zeigen oft "Vorderseiten" von gegenüberliegenden Pillenschachteln - wenn eine Seite durchbricht oder die Vorderseite des Gegners flankiert, werden sie häufig Pillenschachteln zu "Spitze"-Basen einsetzen und die Opposition zwingen, weiter zurück aufzutanken. Schließlich wird die erfolgreiche Mannschaft mehr Pillenschachteln vorwärts stoßen und/oder schlecht-verteidigte feindliche Basen greifen, progressiv das Territorium seines Gegners beschränkend, bis alle Basen des Feinds gewonnen werden oder unter dem Feuer.

Obwohl es möglich ist, eine Frist zu setzen, wurde diese Eigenschaft selten verwendet. Statt dessen "endet" das Spiel, als eine Seite alle Versorgungsbasen erfolgreich gewonnen hat, die andere Mannschaft davon abhaltend, Munition zu gewinnen. In der Praxis enden die meisten Spiele allgemein, bevor alle Basen gewonnen worden sind, weil die verlierende Mannschaft zugibt, dass seine Versorgungssituation unhaltbar wegen einer Kombination von verlorenen und Basen mit Spitzen geworden ist.

Netzwerkanschluss

Die Netzwerkanschlussunterstützung von Bolo erlaubt bis zu sechzehn Spielern, sich einem einzelnen Spiel anzuschließen. Vernetzte Spiele (im Vergleich mit Online-Spielen) waren noch gegen Ende der 1980er Jahre und derjenigen äußerst selten, die verfügbar waren, waren allgemein ziemlich einfach. Das Spiel hat nur AppleTalk unterstützt und hat so durch eine Durchführung getan, die die Basis von Cheshires Doktorarbeit für die Universität von Stanford gebildet hat.

AppleTalk hat ein Protokoll bekannt als Name Binding Protocol (NBP) eingeschlossen, das menschlich-lesbare Namen zu Netzadressen zugeteilt hat. Das wurde allgemein verwendet, um Drucker, Dateiserver und andere Netzmittel zu finden. In Bolo wurde es auch verwendet, um Spiele auf dem LAN zu finden. Auf dem Anlauf würde Bolo NBP verwenden, um ganzen Bolo "Geräte" zu finden, eine Liste von Spielen erzeugend. Diese wurden dann dem Benutzer präsentiert, ihnen erlaubend, ein vorhandenes Spiel auszuwählen, oder ein neues anzufangen. Wenn der Benutzer beschlossen hat, ein neues Spiel anzufangen, hat Bolo dann ein neues Gerät von Bolo mit NBP eingeschrieben, sagen Sie "das Bolo Spiel von Stewart". Neue Spieler, die aufspringen, konnten sich dann diesem Spiel namentlich anschließen, und wenn sie so ihre eigene Maschine täten, würde auch sich im Netz mit dem Bolo Spiel des desselben "Stewarts" einschreiben.

Das Spiel hat nur ein einzelne Paket verwendet, das von der Maschine in einem gemeinsamen Antrag Mode gesandt wurde. Jede Maschine im Spiel hat seine Adresse von AppleTalk in eines der sechzehn Ablagefächer im Paket auf einer ersten gekommenen ersten Aufschlag-Basis eingefügt. Die erste Maschine auf der Liste würde seine Spieldaten einfügen (Position, ob sie, usw. schießen) in ein Nutzlast-Gebiet, dann suchen Sie nach der folgenden Adresse auf der Liste und senden Sie das Paket dorthin. Diese Maschine würde dann den Staat des first vorlesen, sein eigenes einfügen, und dadurch wieder ausgeben. Die Liste wurde geschlungen, so würde die letzte Maschine das Paket an das erste zurücksenden. Nach einer solcher Schleife hat das Paket den Spielstaat für jeden Spieler enthalten.

Die Annäherung des einzelnen Pakets hat Netzverkehr im Vergleich zu einem System reduziert, wohin Aktualisierungen individuell an jede Maschine gesandt werden. In allgemeinsten Netzwerkanschlussschemas wird eine Maschine gewählt, um der "Gastgeber" zu sein, und die anderen Maschinen senden ihre Aktualisierungen diesem Gastgeber, der dann die angesammelten Aktualisierungen zu allen Maschinen wieder verbreitet. In Anbetracht eines Sechzehn-Spieler-Spiels wie Bolo an jedem besonderen Punkt rechtzeitig senden bis zu fünfzehn Kunden ihre Aktualisierungsdaten dem Gastgeber, der dann fünfzehn größere Pakete mit dem Spielstaat sendet, treten zurück. Die Durchführung von Bolo hatte nur ein Paket im Netz zu jeder vorgegebenen Zeit, ähnlich dem größeren "Rück"-Paket der herkömmlichen Annäherung.

Im Fall von einem kürzlich Startspiel würde die erste Maschine, um aufzuspringen, das Paket erzeugen, aber das Sehen keiner anderen Adressen in der Liste, würde nichts tun. Als ein neuer Spieler gebeten hat, sich einem Spiel anzuschließen, haben sie so getan, indem sie ein Befragungspaket an die erste Maschine gesandt haben, die geantwortet hat, als es NBP gebeten hat, das Bolo Spiel ganzen "Stewarts" Maschinen im Netz zu verzeichnen. In diesem Beispiel gibt es nur eine solche Maschine im Netz bis jetzt, so würde die neue Maschine diese Bitte an die Maschine senden, die das Spiel angefangen hat. Diese Maschine würde durch das Zurücksenden des aktuellen Spielstaates, das Einfügen der Adresse der neuen Maschine ins Paket, und dann das Reichen des Pakets davon antworten. Das Paket würde dann zwischen den zwei Maschinen springen. Wenn sich eine andere Maschine angeschlossen hat, konnte die durch NBP erzeugte Liste jede der Maschinen zurückgeben, die bereits im "Bolo Spiel von Stewart" als der erste "Erfolg" verzeichnet sind, so auf diese Mode, die sich sogar dem Spiel anschließt, wurde über die Maschinen verteilt.

Der Vorteil für dieses Design bestand darin, dass es keine "Gastgeber"-Maschine gab. Neue Spieler konnten sich anschließen, indem sie eine Bitte jedem gesandt haben, und vorhandene Spieler konnten abreisen, indem sie einfach ihre Adresse von ihrem Ablagefach im Paket entfernt haben. Das hat bedeutet, dass das Spiel "völlig kopflos" war; selbst wenn der "Startbenutzer" das Spiel verließe, würde der Rest der Maschinen im Spiel fortsetzen, das Paket zu passieren und zu antworten, um sich Bitten als normal anzuschließen. So lange es mindestens eine Maschine gab, die in jedem besonderen Spiel bleibt, würde sie fortsetzen, für neue Spieler verfügbar zu sein, um sich anzuschließen.

Die Kehrseite dieser Annäherung ist, dass jede besondere Maschine auf die komplette Hin- und Rückfahrt warten muss, um Aktualisierungen zu erhalten. So war die gesamte Latenz relativ hoch. In einem Zeitalter, als praktisch jedes Netz "lokal" war und könnte eine Hin- und Rückfahrt nur einige hundert Millisekunden nehmen das war nicht ein Problem, wohingegen der niedrige Durchfluss von LocalTalk sein konnte. Im modernen Netzwerkanschluss, wo die meisten oder alle Verbindungen wahrscheinlich über das Internet sein werden, macht die Latenz dieser Annäherung es unausführbar. Sogar mit "ziemlich lokalen" Spielern wird die Verzögerung zwischen Maschinen wahrscheinlich einige Zehnen von Millisekunden sein, und eine Hin- und Rückfahrt würde normalerweise gut mehr als eine Sekunde sein.

Ein anderes Problem mit der Durchführung bestand darin, dass auf größeren Spielen die Maschinen zum Spiel grob in der Ordnung ihrer physischen Position im Netz hinzugefügt werden mussten. Wenn Maschinen "aufs Geratewohl" hinzugefügt würden, würden alle Spiele abstürzen.

Weiterführende Literatur

• Andrew Wilson und Stephen Intille, "Einen Bolo Roboter programmierend: Das Erkennen von Handlungen Durch das Beispiel" beschreibt MIT Medialaboratorium-Fall 1995 - dieses Papier das Verwenden Bolo als ein System, für eine Programmierung durch das Beispiel-System zu entwickeln.

Außenverbindungen

• Offizielle Hausseite
• Stuart Cheshire, der Autor von Bolo
• WinBolo.net: Winbolo aktive Spiele und Foren
• Die Videofestnahme von grundlegendem WinBolo manövriert
• http://xbolo.org/bolo/?p=11, XBolo für Mac OS X