Die Alpha ist gerade veröffentlicht. Hier mal ein Screen, wie es auf dem Server aussieht.

Ja, die Zeit vergeht. Abitur, Studium, Arbeit muss sein, doch das Projekt lässt mich nicht gehen.

Ich habe Herbst 2014 im Urlaub ein lange vorgenommenes Projekt fast komplett umgesetzt. Das Implementieren von RMI als Modul in BlitzMax. Das war quasi der Grundstein, dafür, dass ich in 2,5 Monaten mit einer leeren Seite angefangen, die Idee so weit umgesetzt habe, wie sie noch nie war.



Im Screenshot zu sehen sind der Server, der Client und ein extra "KI"-Client. Die Grundfunktionalitäten implementiert, die wir uns für die "Version 1" überlegt hatten: Der Client soll sich Knarren für sein Raumschiff kaufen können und damit jemanden abballern. Dazu muss er frei rumliegendes Erz einsammeln und verkaufen, um sich von dem Erlös die Knarren leisten zu können und sie an sein Schiff bauen. Von der Open World, wie sie noch in der ersten Version 2007 geplant war, haben wir zugunsten von Netzwerktraffic und Auswertung auf dem Server (wer ist nah genug an dem Client dran, dass es sich lohnt, die Koordinaten zu senden?) fallen gelassen. Dafür gibt es jetzt Sektoren und davon erst mal 2.
Die Verwendung meiner RMI-Implementierung in einem richtigen Projekt (und nicht nur in den einfachen Test-Cases, die ich geschrieben hatte) machte mich auf eine ganze Reihe von Problematiken aufmerksam.
Unter anderem wurde mir bekannt, dass Timer immer erst alle Ticks abarbeiten, bis der nächste Timer oder andere Events an der Reihe sind. Das führte bei RMI, das auf den EmitEventHook gehookt war, dann zu Problemen, wenn Methoden aufgerufen wurden, die etwas länger dauern. Aber auch das Ausführen von Grafik-Befehlen, die mit EmitEventHook an einen Timer gebunden wurden, ließen die Hauptschleife Repeat-PollEvent-Forever nicht zu, da ihr Timer alle anderen Events blockierte. Das führte zu einer "klassischen" Hauptschleife, die Events abarbeitet, RenderWorld und anschließend 2D-Ausgaben ausführt und vor Flip 0-Cls noch mit WaitTimer die FPS hält.
Außerdem wollte ich zunächst einige RMI-Methoden synchron ausführen. Da der Server allerdings gleichzeitig, regelmäßig asynchrone oder synchrone Methodenaufrufe auf den Stream gepackt hat (Positionsupdates etc.), kamen manchmal Aufträge für Methodenaufrufe auf dem Client dann an, als der Client gerade auf einen Rückgabewert gewartet hat.
Eine gute Lösung dafür habe ich bereits im Kopf, legte diese aber zugunsten einer vollständig Asynchronen Implementierung beiseite. Da das Ganze singlethreaded ist, und die Asynchrone Antworten an ganz anderer Stelle reinkamen, als die Aufrufe rausgingen, stellte mich das auf eine kleine logistische Herausforderung bei der Zuordnung der Antworten zu den Anfragen. Ein Vorteil ist, das der Client nicht hängen bleibt, wenn der Server etwas länger braucht. Man hat dafür an Mancher Stelle mehr das Gefühl des Nachladens auf einer Web 2.0 Website, wenn kurz auftaucht.

Geplant sind jetzt folgende Schritte:

1. Neue RMI-Version dokumentieren und Problem mit synchroner Ausführung beheben.
   Das wird wahrscheinlich die Implementierung von FSCOM.ThreadPool und/oder FSCOM.Async enden.
   
2. Bugs ausbessern und Optimierungen an dem aktuellen Code vornehmen.
   
3. Projektthread und Betaversion
   
4. Feedback einholen und Plan für Version 2.
   

Mein Teamkollege Evolver01 sitzt derweil am Ausbau von den Grafiken, damit es mehr zu Sehen gibt.

P.S.
Geholfen hat wohl auch das Informationstechnik Studium, bei dem man so hochkomplexe Sachen lernt, wie ein Lasten- und Pflichtenheft anzulegen: Man schreib auf, was umgesetzt werden soll, und man macht dann auch nicht mehr (immer ein großes Problem gewesen für mich). Ich habe das professionell auf der Rückseite eines alten Briefumschlags angefertigt:

Irgendwie hatte ich das mit den Events nicht so ganz geschnallt... Für was Post- und EmitEvent genau zuständig waren erschloss sich mir erst heute. Da ich aber beide bereits eingesetzt habe, musste ich eute wieder 12 Tonnen code in die Tonne treten. Wieder alles 500fach einfacher. Wo sich vorher eine ganze datei mit 2 Hooks um das Hauptmenü gekümmert haben ist heute nur noch ein Fenster. Ach Fenster... stimmt. Ich hab die Fenster endlich zum Laufen gebracht:



Die Auffälligen Farben waren vor allem beim Testen des Fensters von Vorteil. Die Rahmen, und der Mittelteil können nach Fenstergröße verschieden gestreckt werden. Alle dazu nötigen Daten incl. Farben befinden sich in einer ini und lassen so dem Spieler die Möglichkeit skins downzuloaden.

Momentan teste ich das Netzwerk und setze das Protokoll weiter um. Wer sich das mal rein interessehalber ansehen will:
BlitzMax: [AUSKLAPPEN] [EINKLAPPEN]

Rem  __PROTOCOL DOCUMENTATION__

    byte C_UDP_MYSHIP|S_UDP_UPSHIP
    int id
    float X
    float Y
    float Z
    int cx
    int cy
    int cz
    float Pitch
    float Yaw
    float Roll
    float sx
    float sy
    float sz
    
    byte S_UDP_CUBE
    int cx
    int cy
    int cy
    
    byte C_UDP_LOGIN|C_TCP_LOGIN
    bbString name
    bbString pass[..md5]
    $!TODO! password is doubble md5__COMMENT1__
    $so no clearly visible passwords are sent and the db is save too.
    
    byte S_TCP_LOGIN|S_UDP_LOGIN
    byte isLoggedin{True;False}
    
    byte C_TCP_CHAT
    int channel
    bbString text
    $channel=0: 1 cuberadius
    $channel!=0:send on a channel
    
    byte C_TCP_COMMAND
    bbString cmd
    $answer will be unformatd stdout (ReadString ReadAvail)
    
    byte S_TCP_CHAT
    int channel
    bbString text
    $channel=0: 1 cuberadius
    $channel!=0:send on a channel
    
    byte S_TCP_RESETSHIP
    $client deletes all ships
    
    byte S_TCP_REMOVESHIP
    int id
    
    byte S_TCP_ADDSHIP
    int id
    bbString kind.name
    bbString name
    bbString playername
    $for i=0 to slots.length-1(
    bbString slots[i].kind.name
    $)
    
    byte C_TCP_LOADABLE_SET
    int shipid
    int slot/-storageid
    bbString varname
    bbString name
    $this is only a request: the server decides weather this is set or not
    
    byte S_TCP_LOADABLE_SET
    int shipid
    int slot/-storageid
    bbString varname
    bbString name
    
    byte C_TCP_LOADABLE_CPBL
    int shipid
    int slot/-storageid
    bbString kindname
    int storageid

    byte S_TCP_LOADABLE_CPBL
    int shipid
    int slot/-storageid
    bbString kindname
    int storageid
    
    byte C_TCP_REQUEST
    byte REQID

    byte S_TCP_OWNSHIP
    bbString kind.name
    bbString name
    $for i=0 to slots.length-1(
    bbString slots[i].kind.name
    $)
    $for i=0 to storage.length-1(
    bbString slots[i].kind.name
    $)
    bbString accessplayer
End Rem

ein bbString ist übrigens das was B3D bei ReadString ausgelesen und geschrieben hat: 4Bytes Länge und dann der String, nicht wie Blitzmax rein den string und beim auslesen die länge wissen wollen. Wer hier schon die großen Cheaterlücken o.ä. findet: Kommentare erwünscht.

Sonst ist nicht viel zu sagen. Es passiert viel Hintergrundarbeit, weil viel code noch ungetestet liegt. Weil der Server eine Funktionalität hat aber der client nicht etc.

Latetest Bug: die UDP-Connection vom Client wird serverseitig irgendwie nicht geschlossen.

RealSpace - Ich bin zu müde für nen Werbespruch

Das hat zwar alles unter B3D schon funktioniert aber das hantieren mit Sockets und Streams ist in BMax doch ein anderes. Habe daher eine BB-Ähnlich Version des Ganzen geschrieben um etwas vertrauter meine Daten zu senden. Nebenbei habe ich auch bemerkt, dass BMAX kein Interface zum Empfangen von UDP-Nachrichten bereitstellt... Naja ist nun alles geregelt.

Server und Client haben heute einen ersten Kontakt geschlossen. Meine protocol.bmx spezifiert zwar schon massig Nachrichten, doch die einzige die beide implementiert haben ist die Login-Kette. Danach war auch schon wieder Schluss. Es war aber mal ein Act den Client überhaupt zu compilen. Kenne mich mit der Dynamischen Event-Basierten struktur wohl doch noch nicht so aus. Alle 2 Minuten fange ich an Kilobytes von prozeturalen Code zu löschen und OOP-Like wieder umgeschrieben wieder einzubauen. Es sind wohl schon einige Muster festgefahren, wenn man an nem Projekt schon fast 4 Jahre hängt.

Nun denn. Der Anfang der GUI ist (codetechnisch) gemacht. Windows, Buttons, Labels sind schon drin. Beim Client fehlen sicherlich noch einige Graphiken. Der Server lässt sich per Kommandozeile steuern.

Ich habe mich übrigens entschlossen, allgemein nützlichen Code, wie schon TCollectingStream, öffentlich zu machen. dabei wären TMirrorStream, meine GUI, TReversableStream und noch einige andere.

Realspace - Bist du Krieger oder Händler.... oder beides?

EDIT:
Screenshot: rechts=Server - links=Steuerkonsole

Es ist in der Nacht. Ein Mann gräbt auf einem Friedhof eine Leiche aus. Er nimmt sie mit nach Hause. Dort wird sie auf den Tisch gelegt und obduziert. Viele Organe sind unterentwickelt. Das alte Kranke Herz "B3D" wird heraus gerissen und ein neues, junges eingesetzt. Der Schritt der ihm einst so schwer fiel ist nun hinter sich. Nun müssen nur noch die Organe an das neue System angepasst werden und dann wird die Leiche zu neuem Leben erweckt werden.
Ja dann wird Realspace neu aufleben.

Kurz gesagt. Es lässt mir keine Ruhe. Noch nichts in meinem Leben hat mich so gequält und gefesselt wie dieses Spiel und BlitzMax mit seinen dynamischeren Strukturen und der neuen Grafik-Schnittstelle ist die ideale Wahl um diese Altlast irgendwann ad Acta legen zu können.

Leider sind alle Grafiken meinerseits auf meiner vom Tisch gefallenen Festplatte verschwunden. Ist aber im Moment nicht so wichtig. Ich möchte dieses Mal das Projekt etwas richtiger beginnen; habe Konzepte, Protokolle und sogar einige Storyelemente geschrieben, gemalt, beschrieben und fest gehalten. Ich weiß, ich habe es schon oft gedacht, aber dieser Ansatz muss einfach funktionieren.
Nun denn! Auf ein Neues.

Die Jagt nach den Käfern ist vorübergehend geschafft. Wir können nun mit stolz verkünden: Ruckelfrei! Und zwar trotz Extremer Entfernungen (zB ca 600,000,000 BlitzEinheiten zum Pluto). Und das in extrem kleinen Bereichen (bei ca 1 BlitzEinheit/Frame innerhalb einer Station). Eigendlich nicht viel für einen Worklog aber man soll wissen woran wir die letzten Wochen gearbeitet haben. Und es ging mir wie immer. Ich gehe vorerst davon aus, dass die neuste Formel die ich 3 mal getestet habe, läuft...... GROßER FEHLER..... Evo kuk in das Spiel und sagt intuitiv: "Da stimmt was an der Berechnung nich....". Also zurück an'nen Code. Hier! Da! Wo wird da die Entfernung eingegrenzt? Wie wird das berechnet? Und ich natürlich: "Neue Formel! Frisch getestet! Is' nicht Falsch!" Nunja.... was soll ich sagen.... im test war die Speed 1 getestet. Dass da was verdoppelt wurde,was nicht verdoppelt werden sollte, fällt bei der Zahl nicht auf.... Wenn man aber durch die Gravitation, der Erde mit ca 500 durchs All geschleudert wird, schon.... Beim Übergang, der Entfernungsbegrenzer kam es deshalb immer zu einem Ruck... Ekelhaft, WÄ!!!! Zum Glück ist das weg! Aber nicht zu früh freuen, denn Evo plant schon die nächste Hürde. Evtl mach ich demnächst auch mal n neuen Screen.

EDIT. Ach ja! Solltet ihr eine Version des Clients haben. Es gibt testweise eine 2. Station beim Pluto (irgend wie mussten wir das Ruckelfreie testen)...

cnRS - Diesmal ohne Werbespruch

Hallöchen dadrüben wie gehts. Etwas was wir 2 Lange nicht sagen konnten, denn obwohl alle Übertragungen glatt zu laufen schienen lief nichts.... Gott hätte ich das früher geahnt.....

Aber fangen wir von vorne an: Nach dem hundertsten Versuch den KI-Script, sowie andere wichtige Nachrichten, via UDP zu übertragen bracht mich mein Grafiker wieder mal auf den Boden der Tatsachen zurück und sagte "Nimm doch einfach TCP!". An diese Möglichkeit hatte ich garnichtmehr gedacht. zu verbissen war mein Kampf gegen die Verlustrate. Nachrichten bekamen ids die bestätigt werden mussten, aber nur dann, wenn sie von einem bestimmten Typ waren... Types namens "got" oder "savemessage" und all der Käse, der alle 120 Versuche 1 mal lief, machte mich völlig blind.... nun gut meine udp.bb behaust nun auch TCP und es ging gleich fröhlich ans Code löschen, denn zB der Timeout, der vorher die Aktivität überwachte und ggf einen Client für tot erklärte, flog, denn wenn der Client tot ist bricht der TCP ab.... Auch etwas anderes ist nun vollkommen geworden durch den TCP-Stream: der Chat ist da!

Nach dem ein ingame Chat in all seiner Reife (*hust*ingame IRC Fenster*hust*) sich darstellte konnten wir verblüffend feststellen dass wir uns nicht finden konnten. Tatsächlich stellten wir es da Fest als Schnittlauch und Mas93 mal zum Testen da waren. Ich hatte mich mal wieder überschätzt und gedacht ach das kleine ding machste noch schnell, doch mein 1500 WLAN-DSL war sogar schneller. Die anderen waren einsatzbereit. Die EXE nicht . Blöd für uns alle, denn ich hatte mich schon auf Alpha-Tests gefreut. Ich also ran an den Code. Geguckt. Mal hier. Mal da. Und dann was ausgebessert und mal und einfach uns beide an die Position 10000,10000,10000 gesetzt. Plopp. Zum ersten Mal "Hallo Evo ". und da flog das andere Schiff los und alles flüssig trotz der 10FPS gedrosselte Übertragung und dann eine schöne Rechts-Kurve. WTF Boing Boing Boing. In zwei Richtungen gleichzeitig flog ein Zeptor Light an mir vorbei... O M G... was nun! wo liegt das Problem? noch dringender: was ist die Lösung? Man fühlt sich wie bei dem Release von "Team Fortures 2" (Es kam über 9 Jahre zu spät nachdem Valve sagte "bald" kommt es raus....)! Ich hatte damit gerechnet das im Sommer 2007 evtl. schon der ingame Verkauf steht aber so wird das sicher nichts.... Sommer 2008 vllt?? Hoffen wir das Beste. Die Suche nach dem Bug ging weiter... auf dem Weg dorthin hab min 64 Bugs platt gemacht, die nichts mit dem Problem zutun hatten, und 1024, die was damit zu tun hatten, aber nichts half wirklich. Ich sagte ich schlaf' mal drüber. Ich schlief mehrere Wochen über mein Praktikum hinweg. Immer mal wieder schaute ich in den Code und so kam es auch dass ich den Fehler fand. Doch das brachte mich der Lösung 0 Schritte näher. Ich schien sogar rückwärts zu gehen. Die X und Z Koordinate waren vertauscht, aber nicht bei beiden sondern der eine war zB bei 200,0,0 und der andere bei 0,0,200. Ingame konnten wir uns sehen (weiß Gott warum) aber die Drehung wurde nicht übertragen weil die Entfernung zu groß war und der Traffic-Sparer zuschlug. Das hackte im Endeffekt dann auch so grässlich ingame, denn ich wollte nicht, dass Lagger so öde in der gegend stehen (wie bei Counter Strike) sie sollten einfach dei tote zeit grade aus fliegen und so tun als ob... Doch das alles machte keinen Sinn: wir haben 1:1 den selben Client! Wie kommt es dass der eine xyz hat und der andere zyx??

Heute kam die Erlösung:
Code: [AUSKLAPPEN] [EINKLAPPEN]
ich nahm an dass die ReadFloats von links nach rechts abgearbeitet werden. aber das nette ding ehier beweist es:Code: [AUSKLAPPEN] [EINKLAPPEN]
Die Parameter werden irgenwie willkürlich rausgefischt... RND würde Evo sagen....
Umgehen kann man den Effekt mit dem Vorspeichern der Werte und das war's. Wir machen an. Ich flieg zu ihm. TADA "Hi EVO!!!!" Nun wird's lustig, denn es kann weiter gehen. Auf der Liste stehen Kolli und Schüsse und dann der Release!!! Es wird übrigens Freeware mit Premium sein.... Preis überlegen wir uns noch, aber nicht sonderlich teuer. Jeder soll einen Premium sich leisten können. Bis dahin:

cnRS - wirst du einer unter Vielen oder der Eine unter Vielen?

Lasset die Korken knallen: Das Graphical-User-Interface ist vollbracht!!
Im Zuge der letzten Tage habe ich es geschafft das GUI wiederherzustellen. Und sie ist besser als Vorher. Die Schriftarten haben noch mit uns zu kämpfen aber mein Windows-Font->D3D-Font Converter hat seinen Zweck erfüllt. Die Feinabstimmung blieb wieder an Evo hängen aber der macht das ja gerne.... stimmts Evo? Nun denn es steht noch viel auf der Features-Liste was noch nicht im Spiel ist zB dieser Wunderschöne mit Paint gekritzelte Stammbaum, auf dem vermerkt ist welches Schiff welche Teile für welches andere Schiff produziert, den ich heute morgen freudestrahlend entgegen nahm. Das ganze wird immer Komplizierter und ich frage mich immer öfter auf was ich mich da eingelassen habe.... eigentlich wollte er doch nur ne Freelancer-Steuerung.... Nun welch Glück: Das GUI ist wieder da! Aber nicht dass ich denke ich häte Feierabend komme ich auf das Thema Kollision....

Nun da sind viele Schiffe mit vielen Polys geb ich den allen die Kugel-Poly Kollision von BB hab ich die oft zitierte "Diashow mit 2 Bildern pro Minute". Nun kam ja der Geniale Einfall: Moment Schilde sind doch Rund. Aha! Nun In der allgemeinen Raumschlacht werden alle ihre Schilde oben haben. Da reicht also Kugel-Kugel-Kollision. Die ist auch annehmbar schnell. Nun irgenwie muss man zB in die UtilityStation der SpacePolice kommen um sich dort Waffen und Sonstigen Kleinkram zu kaufen. Da fällt mir ein: Nur dieses eine Schiff brauch dann Poly......... Die Natur liefer das Vorbild: Wir lassen Permissions über den Chat laufen. Es gibt 255 Channel und da die Ersten 5 eh schon für Positionsangabeu sw Verwendet werden belegen wir Channel 6 für die Anfrage auf Schildeintrittserlaubnis. Nun Das ganze muss ja steuerbar sein. Auch von Nem KI-Script, denn die SpacePolice soll als einziger NPC sich selbst verwalten können.

Der KI-Script muss also um Funktionen erweitert werden. Die bisherigen Möglichkeiten, turnto, planet, ship, %warp% und andere Befehle reichen dazu nicht mehr aus.... Es muss was richtiges her. Man muss bedingungen serten können: WENN die anfrage kommt DANN Anfrageschiff reinlassen. ein IF muss her... wie konstruirt man if in einer sprache die so aussieht:
Code: [AUSKLAPPEN] [EINKLAPPEN]
kein platz für If und endif..... da fiel mir AVS von Winamp ein. Da hat die Sprache das selbe muster. Die lösten if so:
Code: [AUSKLAPPEN] [EINKLAPPEN]
nach dem gleichen Schema funktioniert nun auch mein if nur dass die anzahl der Parameter ergal ist: wird der erste als Int <>0 dann werden die anderen Parmameter nach der rihe ausgeführt. Nochetwas gibt es neues in meinem Script, was es vorher nicht gab: Strings. Und die Funktion Equal erledigt dann den Rest.
Variablen gab es schon Vorher. und zwar dos-like: %Hans%. Man kann übrigens mit diesen auch die DoS Variablen auslesen, aber außer dass vllt irgendwann einer die Variable %path% von allen Clients durch den Chat haut kann ich mir nix weltbewegend schlimmes Vorstellen was man damit Unfug treiben könnte. Damit man nun auf Chat-Msgs, wie so eine Schildeintrittserlaubnis-Anfrage antworten kann wurden neue Systemvariablen zu den alten hinzugefügt:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Damit und mit diesen Befehlen:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Kann man zB schon eine Fernsteuerung für Schiffe bauen. Oder in einer Nahen Zukunft schreiben:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Neben bei ship(28) ist die Utillity Station von der SpacePolice.....MUHAHA:

cnRS - Defeat all NPCs

Nun will ich mich mal über das Mega-Giga-Projekt cnRS auslassen: Das ganze war als MMORPG geplant hat aber seinen Charakter in Richtung Massiv-Mulitplayer-Online-Weltraum-Aufbauspiel gebracht.
Jener Schicksalhafte Thread (pitch bei Entitypoint (Gelöst)) hatte mich verleitet dieses Projekt von Evolver zu übernehmen. Der code war zu der Zeit noch Egozentrisch^^ dh es gab eine Player-variable, eine ship-variable usw usf... an LAN version oder Gar Inernet-Multiplayer war gar nicht zu denken und noch ein großes Problem stellte sich für mich dar: In dem Spiel ist alles Variabel. NIX ist wirklich fest und ich lernte die fehlende OOP-Möglichkeit von Blitz zu schätzen. Da gibt es eine ungewisse Menge an Spielern, die eine ungewisse Menge an schiffen besitzen, die eine ungewisse Menge an Waffen haben. Mit geordneten Listen läuft das sogar ganz annehmbar schnell^^

Das(?) GUI ist das aktuelle Problem. Mit dem Erscheinen, der Draw3D war klar dass wir umsteigen. Schließlich gibt es nur ein 640*480-Fenster, dass beim erstellen kopiert und in der Größe geändert wurde. Mit 2D eine Qual für den User. Draw3D bringt Abhilfe: Nun kann man Fenster-Farbe einstellen, Transparenz und Größe sind kein Problem mehr und Live-Scalen gehört zu den Standardaufgaben. Anders sieht es mit dem Umschreiben der Grafik aus. Die ganze 2D-Koordinaten müssen nun 3D-Konform gemacht werden. Meine Draw3D ist schon voll umgebaut. Mit der d3dcam mit nem Range der fast nur die Fenster erwischt wird d3d gerendert unabhängig von der Position des Spielers oder auch solcher Konstruktionen:

Fenster
Schrift
Fenster
Schrift

Man lässt einfach nach der ersten Schrift die d3d rendern und die Grafik leeren. Am Ende sieht das Ergebnis besser als in 2D aus und ist trotzdem schneller.

Das Brücken der Riesen-Positionen war ein bereits von Evolver gelöstes Problem. Die Floats werden bei zu großen werten ungenau. Nun ist Pluto halt weit von der Sonne entfernt. Wer einfach so dort hinfliegt dem schießt die Grafik um die Ohren: Teile des Schiffes werden woanders hingesetzt, Draw3d positioniert die Maus in Alaska und was mit den Schüssen passiert bleibt dem Zufall überlassen. Lösung: Chuck Norris läuft nicht vorwärts. Er tritt das Universum nach hinten. Mit Blitz kein Problem.

Über das Spiel

Das Spiel baut auf etwas auf, das eine Gegenposition zu den gängigen MMORPGs darstellt: Die Quests haben einen tieferen Sinn. Es sind keine NPCs die sagen: Renn von A nach B hole Trank C und besiege auf dem weg Monster D. Es sind Menschen die Missionen aufgeben: Ich geb dir 100 RS-Credits wenn du den umlegst. Und dann wird's schwierig... tu ich's oder tu ich's nicht? Was hat denn die Gegenseite zu bieten... Weiß die überhaupt dass der andere hinter denen her ist? Ich kenne kein MMORPG wo man mit dem Monster drüber reden kann den Trank so rauszurücken oder dem Monster helfen kann den Auftragsgeber umzulegen. Es wird keine Grenzen geben. Handel auf die alte weise: 1000 RS-Credits oder tot? Das Gruppenverhalten wird gefördert, denn sobald ich eine Mission mache helfe ich einer Gilde/Gruppe/Allianz und mach mir somit Feinde und Freunde. Thema NPCs: Es gibt keine im klassischen Sinne - zu tötendes Monster/unbesiegbarer Auftraggeber - sondern mehr einen Standard-Spieler, der am Anfang da ist und durch ne kleine KI sich am Leben erhält. Er lebt durch Handel und hat die gleichen Schiffe, die alle anderen auch erwerben können. Das heißt zum Einen, dass er dass Spiel ins rollen bringt, denn wer ihn angreift hat mit Kopfgeld zu rechnen und wer nimmt nicht gerne eine von 2568 Missionen an, in der es heißt: Bring den da um. Sogar als Vollnoob hat man vllt ne Chanse den Finalen Schuss, der ihn umbringt, los zu lassen und somit das Kopfgeld zu erhaschen. Sollte sich irgendwann einer Stark genug fühlen gegen die SpacePolice, wie sich diese KI nennt, zu Kämpfen und so ihren Platz als zentrale Handelsgewalt zu übernehmen kann er es ruhig versuchen. Die SpacePolice hat nichts was ein anderer Spieler nicht hat. Sogar die KI kann man seinen Schiffen geben, sodass sie Offline weiterkämpfen. Jeder findet in diesem Universum seinen Platz, er muss nur ein Teil vom Ganzen sein.

cnRS - Be part of it