Endyr Entwicklerblog

Endyr auf Desura

Kein grosser Eintrag, aber wenn ihr auf Desura (indieDB/modDB) registriert seid, könnt ihr euch Endyr dort nun auch anschliessen:

• [http] www.indiedb.com/games/endyr

Der lange Arm

Ich gebe zu, ich mag es kompliziert. Das heisst, ich mag es nicht an sich, weil es kompliziert ist, sondern weil es nach einem gewissen Aufwand die Dinge einfacher macht. Ihr habt keine Ahnung, worauf ich hinaus will...

Ich rede von Interaktionen. Hier zeig sich einmal mehr, wie sich Erfahrung in der Programmierung auswirkt. Als Neuling tendiert man zu einfachen Systemen, die schnell umgesetzt sind und wenig Planung erfordern. Nehmen wir das konkrete Beispiel "Rollenspiel", ein Genre, welches von Interaktionen nur so sprüht. Unser Neuling fängt mit einer Grafik-Engine an und kommt irgendwann an den grossen Punkt namens "Inventar", was vornehmlich aus Gegenständen besteht. Waffen, Rüstungen, aber auch Werkzeuge wie Hämmer, Meissel, Schaufeln und Zangen. Schnell kommt einem der Gedanke, diese Werkzeuge einzusetzen, etwa um einem toten Bären das Fell abzuziehen oder seine Zähne rauszureissen. Dies ist die heutige Ausgangssituation.

Unser Anfänger macht das kurz und schmerzlos, indem er für jeden Gegenstand ein passendes Werkzeug erstellt und jedem Werkzeug eine Aktion zuweist. Für die Zähne gibts also eine Zange und für das Fell ein Häutungsmesser (bei einer Kuh kann stattdessen auch gut Leder herauskommen), wobei diese Werkzeuge sonst im ganzen Spiel keine Verwendung finden. Und wenn doch, kann man genau dort eine Ausnahme skripten, à la "Du benötigst hier eine Zange, um das rauszuziehen", welche einfach nur abfragt, ob der Spieler eine Zange dabei hat. Vielleicht kommt er irgendwann auch noch auf die Idee, man könnte ja die Augen und das Herz auch noch sammeln - statt neuer Werkzeuge gibt es dafür dann Lehrmeister, welche einem die entsprechende Fähigkeit geben - per Klick auf den toten Bären werden diese Sachen dann einfach offengelegt (vielleicht sogar mit einer kleinen Skriptzeile dazwischen, die abfragt, ob man ein Messer dabei hat).
Dieses kleine Beispiel funktioniert wunderbar, solange es klein bleibt. Jedes Werkzeug ist massgeschneidert für seine Aufgabe und alles weitere löst man eben anders. Programmieren kann so einfach sein :-)

Der Haken der Sache liegt im Verständnis des Spielers. Geht es beispielsweise darum, toten Insekten die Flügel abzutrennen, zweifle ich bereits an der Notwendigkeit einer speziellen Flügelschere. Vor allem, wenn es zusätzlich eine Stoffschere, Lederschere, Fellschere und den allseits beliebten Dolch gibt. Oder wozu braucht man eine spezielle Zange, wenn man die Zähne auch einfach rausschlagen oder -brechen kann? Diese Gedankengänge münden in einem System, bei dem ein Werkzeug mehrere Anwendungen findet. Man muss dabei nur berücksichtigen, dass mit einer speziellen Flügelschere die Chance höher ist, die Dinger sauber abzutrennen.
Auch hier gibt es wieder mehrere Wege, das umzusetzen. Eine einfache "Gewaltlösung" besteht darin, jede mögliche Aktion aufzulisten, also sowas wie Dolch->Flügel abschneiden, Dolch->Krallen rauspulen, Dolch->Haut abtrennen, usw. und dann dasselbe für Zange->Zähne rausziehen, Zange->Krallen abklemmen, usw. Mit einer derartigen Liste kann man genau steuern, welche Aktionen welches Werkzeug ausführen kann. Der Krux dabei ist: Man muss das auch vollständig tun, denn sonst wundern sich die Spieler, warum man mit einem Werkzeug etwas bestimmtes nicht tun kann (z.B. mit dem Götterhammer keine Nägel einschlagen, wo es doch eigentlich auch ein Hammer wäre).

Um diesem Aufwand zu entgehen habe ich mich bei Endyr für eine kompliziertere Lösung entschieden. Bisher gab es immer eine direkte Verknüpfung von Werkzeug zu Beute, nun wird aber eine dritte Ebene dazwischengeschaltet: Die Aktion.
In meinem System hat ein Messer z.B. die Aktionen "schneiden", "abziehen", "stechen" und "herauspulen" und die Spielobjekte eine Liste von Aktionen, die man auf sie anwenden kann. Ein toter Bär kennt also mindestens "abziehen" (für das Fell), "herauspulen" (Zähne, Krallen, Augen) und "schneiden" (Zunge, Herz). Wie im letzten Screenshot gezeigt wird der Bär nur dann blau umrahmt, wenn mindestens eine dieser Aktionen mit dem Werkzeug übereinstimmt. Sind es mehrere, erhält der Spieler ein Auswahlmenü, was er z.B. mit der Zange nun machen möchte (Zähne oder Krallen rausziehen?).

Klingt mein System nun intuitiver als das des Anfängers weiter oben? Für mich schon, vor allem aber nimmt es mir die meiste Arbeit ab. Ich muss mir die Gegenstände nur ansehen und überlegen, was man damit tun kann - und wenn ich einem Säbel die Aktion "schneiden" zuweise, kann er ganz automatisch auch ein Messer ersetzen. Einen kleinen Haken hat das Ganze aber natürlich: Man muss sich viel mehr Gedanken darüber machen, welche Aktionen man denn nun definiert. Gerade schneiden ist nicht gleich schneiden - auch eine Papierkante kann schneiden, aber davon kann man sich keine Brotscheibe abschneiden. Statt ein generelles "Schneiden" verwende ich daher genauer definierte Begriffe.

Fazit: mit einem einfachen System kommt man recht weit, aber irgendwann ist der Punkt der Überforderung erreicht, und spätestens dann wünscht man sich einen komplexeren Unterbau. So spät lässt sich das aber nicht mehr ohne Weiteres auswechseln, darum implementiere ich von Anfang an das beschriebene System. Wie so vieles wird sich das (hoffentlich) langfristig lohnen.

Technische Freiheiten

Dass Programmieren eine ziemlich technische Angelegenheit ist, lässt sich kaum bestreiten. Nun ist Technik aber ein ziemlich umfassendes Gebiet und es gibt mindestens soviele Lösungen auf der Welt wie Techniker, die an einem Problem arbeiten. Beim Programmieren, wo man nicht mit Werkstoffen und realen Bauteilen arbeitet, wird dies mitunter in die Extreme getrieben, denn was nicht funktioniert wird einfach geändert oder komplett gelöscht und nochmal neu geschrieben. Ressourcen verliert man dabei keine, ausser natürlich Zeit und Lust. Dabei lässt sich schwer überhaupt beurteilen, ob eine funktionierende Lösung auch wirklich eine gute Lösung ist. Ich möchte euch deshalb im Folgenden gleich 12 verschiedene Möglichkeiten eines JavaScript-Programmierers, um eine Zahl zu verdoppeln. Viel Spass damit:

1)



2)



3)



4)



5)



6)



7)



8)



9)



10)



11)



12)



Gegen unten werden die Codeschnipsel immer länger, weil die Einzeiler in Funktionen verpackt wurden. Das mag beim konkreten Verdoppeln sinnlos erscheinen, bei komplexeren Operationen ist ein Auslagern in einzelne Funktionen aber das Erste, was man macht (statt den Code immer und immer wieder zu kopieren).
Selbst das Verdoppeln "von Hand", also wie in der Schule die Zahlen einzeln durchzugehen und zu verdoppeln, kann Sinn machen, z.B. wenn man mit 2000-stelligen Zahlen hantiert – auf den hier gezeigten Wegen käme der Computer mit solchen Zahlen nicht klar.

PS: Statt zu verdoppeln könnte man die Zahl natürlich auch um die Hälfte halbieren:


Divisionen sind jedoch generell böse.

Der Kreis schliesst sich

Ein neues Projekt anzufangen ist immer ein sehr aufregender Moment - man steckt voller Ideen und Tatendrang, ungestört von technischen und konzeptionellen Problemen. Wo immer etwas nicht passt, findet man sofort eine Lösung, weil alles noch in den Wolken steht und entsprechend flexibel ist. Und dann fängt man an irgendeinem Zipfel mit der Entwicklung an.

Die ersten Meter strotzt man vor Energie und mit jedem Schritt wächst und gedeiht das Projekt, von Tag zu Tag kommen neue Features hinzu und der Strom der Umsetzung scheint kein Ende zu finden. Bis dann die ersten Probleme auftauchen. Bald wird klar, was man übersehen hat, oder man findet neue Anforderungen, an die man bisher nicht gedacht hat. Im Falle von Letzterem muss man sich entweder einschränken und die Anforderung so umgehen, oder zum Teil tief im Quelltext wühlen, um das gewünschte Feature nachträglich einzubauen. Könnte das jemand visualisieren, würde er wohl einen verdreckten Mechaniker in einem Schlachtfeld aus Zahnrädern, Schrauben und skurril geformten Metallstücken vor sich sehen - zweifelnd an der Tatsache, dass der ganze Schrott mal ein kompletter Motor war, und es auch bald wieder sein wird. Während Motoren (desselben Modells) aber zumindest immer gleich sind und es dafür Bauanleitungen gibt, hat man für die "eigene Engine" keine Referenz und keine Ingenieure, die man im Zweifelsfall anrufen kann. Man muss komplett auf das vertrauen, was man vor sich sieht und was man noch in der Erinnerung hat. Je grösser das Projekt und je später dieser Umbau stattfindet, desto weniger dürfte das sein. Natürlich kriegt man den Motor wieder zusammen und man kann schliesslich testen, ob er wieder läuft. Wenn aber am Ende ein paar Schrauben und Rädchen übrig bleiben, kann man sich bloss auf die Lippen beissen und hoffen, dass die dadurch entstandenen Probleme sich möglichst früh zeigen, damit man sie beheben kann. Ja, wir reden jetzt von Bugs, die durch kleine Unachtsamkeiten entstehen und die Kernfunktionalität nicht beeinflussen.

Ungefähr in dieser Situation befindet sich Endyr im Augenblick - der Motor (das Skriptsystem) ist wieder zusammengebaut, ein paar Schrauben liegen auf dem Tisch und obwohl er sauber läuft, könnten unter bestimmten Bedingungen doch noch Probleme auftauchen. Davon abgesehen hat sich der Umbau aber gelohnt, wie die jüngsten Screenshots zum Thema "Tiere ausnehmen" zeigen. Viele Ausnahmen sind weggefallen und der Programmablauf wurde vereinheitlicht; alles fühlt sich intuitiver und flexibler an und es macht Freude, die alten Skripte anzupassen - sie werden dabei nicht nur kürzer sondern auch übersichtlicher. ...und genau das werde ich nun fortsetzen, das Ende der Schreibwut ist hiermit erreicht.

Es kompliziert sich

Das Einfachste ist doch immer das Schwierigste... mein heutiges Problem sah folgendermassen aus: Spieler können ja neuerdings Objekte wie z.B. einen Amboss selbst herstellen und in der Welt platzieren. Nun ist ein Amboss ein benutzbares Objekt, d.h. bei Klick öffnet sich das Baufenster und man kann etwas schmieden. Nun soll der Amboss aber nicht ewig da stehen bleiben sondern vielleicht umplatziert oder komplett entfernt werden. Oder ein anderer Spieler möchte ihn haben. Eigentlich ein typischer Fall für ein Menü, nennen wir es direkt "Systemmenü". Wenn nun aber bei jedem Amboss-Klick erst das Menü kommt, oder sei es auch nur eine Auswahl "Benutzen / Systemmenü", so wäre das ein ziemlich lästiger Klick, da so ein Amboss ja fast nur benutzt und äusserst selten umplatziert wird. Wir haben es also mit selten genutzen Optionen zu tun, die in anderen Spielen gerne irgendwo versteckt werden, z.B. in einem extra-Tab, Untermenü oder sie sind nur per Spezialtaste zugänglich – was dann dazu führt, dass die Spieler das Menü nicht finden und viele Foreneinträge, Hilferufe oder einfach nur Frust erzeugen. Ausserdem kann man Spezialtasten (selbst den Rechtsklick) vergessen, sobald es auch auf Touch-Geräten laufen soll. Bleiben wir direkt bei Touch-Geräten, denn entsprechend hat sich auf diesen Geräten etwas anderes durchgesetzt: Der lange Klick (etwa 1s den Finger draufdrücken bzw. die Maustaste halten). Nun kommt aber erschwerend hinzu, dass Endyr diesen langen Klick bereits belegt, nämlich zur Fortbewegung (während Mausbenutzer bequem mit der rechten Maustaste herumlaufen können).

Die Lösung für das Dilemma war nun folgender Kompromiss: Maustaste halten ist weiterhin für die Fortbewegung zuständig, es sei denn der Klick erfolgt auf ein Objekt mit Systemmenü. Zur Verdeutlichung färbt sich dabei das Highlight in weiss. Diese Ereignis-Überlagerung ist ziemlich kompliziert und auch keine optimale Lösung, aber doch recht intuitiv, wenn man schon mit Tabletts gearbeitet hat. Nun wird sich zeigen, ob der "lange Klick" noch tiefer ins System integriert werden muss, damit man z.B. auch bei Inventargegenständen ein Spezialmenü erreichen kann.

Ene mene mu, wo bist du?

Wenn jemand an uns vorbeiläuft, merken wir das in der Regel recht schnell. Ganz anders sieht das bei NPCs bzw. Gegnern in Videospielen aus. Woher soll der NPC wissen, dass ein Spieler auf ihn zusteuert? Prinzipbedingt gibt es zwei Methoden, dieses Problem zu lösen. Die erste heisst "Polling" und bedeutet, dass der NPC regelmässig die Distanz zum Spieler misst. Ist diese Distanz ausreichend gering, darf er den Spieler bemerken und entsprechend agieren. Diese Methode kann man gut bei Singleplayer-Spielen einsetzen, wo mit jedem Bild (ca. 60 Mal pro Sekunde) auch die ganze Logik berechnet wird. Ein NPC kann hier also etwa alle 20 ms schauen was um ihn herum passiert.

Wie früher bereits erwähnt ist dieses Vorgehen jedoch unzuverlässig. Angenommen, die Framerate bricht extrem ein, weil Windows gerade Updates installiert. Der Spieler könnte dabei in einem Frame noch meilenweit vom NPC entfernt sein und bereits im nächsten Frame ein gutes Stück hinter ihm stehen. Da zwischen den Frames kein Polling stattfinden kann, würde der NPC davon nichts bemerken. Dies gilt natürlich nur, wenn die Bewegung des Spielers an die Zeit statt an die Framerate gekoppelt ist – bei besonders billigen Spielen wird die Figur einmal pro Frame ein Stück weit bewegt, meist auch direkt abhängig davon, ob eine Pfeiltaste bzw. WASD in diesem Frame gedrückt ist. Kleiner Exkurs: Diese Konstellation ist umso unzuverlässiger, je schneller der Spieler sich bewegt. Angenommen er bewegt sich normalerweise mit 4 Pixeln pro Frame über eine Tile-Map à jeweils 16x16 Pixel, funktioniert das noch ganz gut. Beschleunigt er aber irgendwie auf 32 Pixel pro Frame, würde er einzelne Tiles glatt überspringen, was die Kollisionsabfrage sabotiert.

Zurück zu Endyr, wo oben genannte Lösung nicht nur unzuverlässig sondern unmöglich zu implementieren wäre, denn der Server berechnet keine Frames. Im besten Fall kennt er die Position, wo der Spieler zu Laufen beginnt, und erst wieder die, wo er nach seinem Weg zum Stehen kommt. Ich sage "bester Fall" weil dabei absolut nichts berechnet werden muss, was die Serverauslastung gering hält. Der Server muss dabei nur wissen, wie lange der Spieler für seinen Weg braucht. Ist dieser Zeit abgelaufen, stellt er ihn auf den Zielpunkt und interessiert sich nicht weiter dafür, wo er tatsächlich langgelaufen ist. Aber halt, ermöglicht das kein Cheating? Kurze Antwort: Nein. Der Trick ist, den Weg im Voraus zu prüfen und zu schauen, ob alles seine Richtigkeit hat. Statt also 60x pro Sekunde den Weg häppchenweise abzulaufen und Kollisionen zu testen geschieht das alles in dem Moment, wo der Spieler losläuft. Und hier liegt nun auch der Hund begraben, wenn es darum geht, dass ein NPC den Spieler bemerken soll. Statt dass der NPC Polling betreibt und quasi jeden Schritt des Spielers beobachtet, prüft der Server zu Beginn, ob der Spieler bei einem oder mehreren NPCs vorbeikommt. Falls ja, werden Timer gesetzt und im entsprechenden Moment die NPCs über die Annäherung informiert. Ausser natürlich, der Spieler würde unterwegs eine neue Route einschlagen oder stehen bleiben – in diesem Fall werden alle Timer aktualisiert bzw. entfernt.

Das alles dient freilich nur der Performance – Alternativ kann auch jeder NPC regelmässig (sagen wir gnädigerweise 1x die Sekunde) die Spieler beobachten. Was das "kostet" kann man dabei selbst ausrechnen; angenommen es wuseln 20 Gegner und 3 Spieler im Level herum bedeutet dies 20 Skripts pro Sekunde, von denen jedes eine Schleife mit 3 Spielern abarbeitet bzw. zu jedem die Distanz misst. Polling ist eben teuer. Und damit endet unser kleiner Einblick ins effiziente NPC-Skripting.

Alpha in Sicht

Es dämmert am Horizont, und zwar schnell. Am 21. Dezember 2012 ging die erste Alphaversion von Endyr an den Start und nun, ein Jahr später, soll die zweite Alpha folgen. Dazwischen hat sich viel getan; es kam viel Neues hinzu und das Vorhandene wurde optimiert und flexibler gestaltet. Die Steuerung wurde mehrfach überarbeitet, das Schadensmodell verfeinert und auch grafisch gab es nochmal Fortschritte. Um den Aufwand unter Kontrolle zu halten gab es ausserdem ein neues Tutorial-Startlevel, welches als komplette Spielfläche für die Alpha dient. Nicht zu vergessen der Umzug nach St. Gallen und andere RL-Angelegenheiten.

Nun bin ich dabei, die letzten Funktionen dieses Startlevels zu implementieren. Im Grunde wird dort bereits alles abgedeckt; man kann gegen Monster und Tiere kämpfen, Letztere ausweiden, Bäume fällen, Steine abbauen, Ackerbau betreiben, Waffen schmieden, die Mine sprengen, und und und... Was als so simple Idee begann erweist sich zunehmend als komplexes Spiel mit vielen Möglichkeiten – ich kann wohl einfach nicht anders. Aber, je "breiter" dieses Spiel gefächert ist, desto mehr Grundlage bildet es für die weiteren Projekte, die auf der Endyr-Engine basieren sollen.

Übrigens wurden die letzten Alpha-Tester heute akzeptiert und per E-Mail benachrichtigt. Ich hoffe, im Alphatest werden die letzten Kinderkrankheiten ausgemerzt und das Konzept ausgereift – einige Features (wie etwa der Friedhof) werden ja erst noch implementiert. Wer keine E-Mail erhalten hat, muss sich wohl oder übel bis zum geschlossenen Betatest gedulden, der im Frühjahr 2014 stattfinden wird.

Alpha vorbei

Puh, das waren einige anstrengende Tage – oh nein, nicht wegen Endyr; eine Auftragsarbeit wollte erledigt werden und so blieb der Alphatest zwei statt nur einer Woche online. Die Testberichte waren stellenweise sehr hilfreich (danke nochmal an alle Beteiligten!) und die nächste Zeit werde ich damit verbringen, die aufgezeigten Mängel auszubügeln. Der nächste Meilenstein wird dann entweder eine dritte Alpha (zum Thema "PvP") oder direkt die Beta (mit reduziertem Spielumfang).

Die Dinge kommen langsam ins Rollen...

Eigene Grafiken

Auch wenn es meine Zeit eigentlich nicht zulässt, stelle ich neuerdings fast täglich Pixelgrafiken für Endyr her. Die Gründe dafür liegen auf der Hand; selbstgemachte Grafiken haben alle denselben Stil, passen entsprechend gut zueinander, vermitteln die Seele des Spiels und oft sind sie auch schlichtweg aus technischen Gründen unumgänglich. Einen Vorgeschmack dazu gibt es bereits in der Galerie unter "Endyr", für eine spätere Dokumentation habe ich die Grafiken aber auch in der Library untergebracht:

• lib.yhoko.com/de/Endyr/Mobiliar/

Von diesem Bremsklotz abgesehen geht die Entwicklung gut voran; Gebäude können mittlerweile von Spielern errichtet werden und die Innenräume (Böden und Wände) lassen sich ebenfalls gestalten, vom Platzieren des oben gezeigten Mobiliars mal ganz zu schweigen. Das alles stand zwar nicht wirklich auf dem Plan, tut dem Spiel aber letztendlich sehr gut. Für mich entfällt damit auch die Pflicht, den Spielern eine Basis herzurichten – sollen sie ruhig selbst eine aufbauen, wo auch immer sie möchten. Noch unklar ist dabei nur, wo man überall bauen kann. Rein schon aus technischen Gründen muss es Einschränkungen geben, aber voraussichtlich werden alle grösseren Wiesenflecke in Bauland umgewandelt.

Aktionspunkte

Es hilft eben nichts; was man immer wieder vor sich herschiebt, wird einen irgendwann einholen. Ich rede diesmal von den Objekten wie Amboss, Schrank, Herd und Bett. Diese Dinge haben eines gemeinsam; man kann sie benutzen bzw. bedienen und zwar solange sie in Reichweite sind. Anfangs war das nur eine Distanz-Prüfung; ein simpler Pythagoras. Aber was, wenn das Objekt ausser Reichweite war? Um die Sache einfach zu halten versuchte das Skript, die Spielfigur möglichst nahe zum Objekt zu bewegen und es dann erneut zu bedienen. Das klappt auch - meistens. Nicht so bei der Statue, denn die war ziemlich gross und belegte mehrere Felder in der Kollision-Map. Kam der Spieler also von der Seite oder von hinten heran, lag der Mittelpunkt immer noch ausser Reichweite. Da der Mittelpunkt glücklicherweise meist unten in der Mitte der Grafik liegt, war es dann naheliegend, das als Zielpunkt der Bewegung festzulegen. Und falls die Figur am Ende doch von der Seite her kam, etwa weil der Weg zur Mitte blockiert war, liess ich weiterhin die Abstandsberechnung nicht mehr nur zum Mittelpunkt sondern auch zu jedem Kollisionsfeld hin gelten. Und siehe da, auch Statuen waren nun nutzbar.

Gestern jedoch wollte ich einen Schrank öffnen, und dieser Schrank stand seitlich, man sah also nur die Seitenwand und der Mittelpunkt lag bei dieser unten zentriert. Klickte man den Schrank an, wanderte die Figur dorthin und öffnete von da den Schrank. Sah komisch aus. Schlimmer noch; stand die Figur schön korrekt vor dem Schrank, war der Mittelpunkt ausser Reichweite und sie marschierte wieder erst neben den Schrank. Gut, damit könnte man leben, aber was passiert wohl, wenn neben dem Schrank ein Tisch steht? Richtig, dann wäre der Mittelpunkt des Schranks quasi im Tisch und damit unerreichbar. Gut, der Server hätte das akzeptiert, denn er berechnete die Distanz nun ja auch zu jedem Kollisionsfeld, aber der Client wusste ja nicht, welche Felder zum Schrank gehören. Konnte er nicht, und wird er auch nie. Das war also eine Sackgasse.

Lösung? Schweren Herzens musste ich das Umsetzen, was von Anfang an hätte sein sollen: Aktionspunkte. Bei jedem Objekt ist nun festgelegt, von wo aus man es bedienen kann. Der Schrank hat z.B. je einen Aktionspunkt links und rechts, der Amboss davor und dahinter, das Zeichenbrett nur einen davor. Es kostete mich deutlich mehr Arbeit (und die CPU jeweils deutlich mehr Rechenzyklen), aber wenn man jetzt ein Objekt anklickt, sucht die Engine den Pfad zum nächsten Aktionspunkt, bewegt die Figur dorthin, dreht sie passend zum Objekt und führt dann die Tätigkeit aus.

Als kleiner Bonus hat sich nun noch etwas ergeben: War ein Objekt bisher von mehreren Spielern gleichzeitig bedienbar (sagen wir mal ein Tisch für 4 Personen), so konnten diese bei der Benutzung irgendwo in Reichweite stehen - selbst übereinander, bzw. sogar sehrwahrscheinlich übereinander, da sich aufgrund des Clients alle in der Nähe des Mittelpunkte befanden. Nun aber besetzt jeder einen eigenen Aktionspunkt und es ist vorgegeben, wo sich diese befinden (mit einem kleinen Spielraum, falls man bereits in der Nähe steht). Zudem weiss der Client nun bereits im Vorfeld, ob überhaupt noch ein Platz am Objekt frei ist.

Manchmal macht man die Arbeit eben doppelt, wenn man sie sich spart.