PureBoard

dafür gibt es anti-cheat-engines.. aber die sind alle lokal auf den client-pcs.. die server würde bei sowas nicht nachkommen.. naja von google abgesehen..
aber so einfach ist die ganze Sache nicht..
die erwähnten beispiele CS und Combat arms haben große Probleme mit cheatern, weil sie eben NICHT die Server- Leistung haben auchnoch alle spieler zu kontrollieren..

Cheats zu schreiben ist mit injecting und hooken gar nicht so schwer für einen programmierer, anti-cheats und multiplayer-games müssen/sollten..können.. das beachten..
der server ist aus Geschwindigkeitsgründen nur ein verbinder, weiter nichts. aber.. wenn es kein MMO shooter werden soll kann man das sicher so machen wie man will..

@Max_der_Held: Doch, mittlerweile ist das Standard, dass der Server zusätzlich eine physikalische Simulation im Hintergrund durchführt. Zusätzlich wird für die wichtigen GameObjects ein CRC Check veranlasst. Anders könnte ich es mir garnicht erklären, weshalb die Dedicated Server heutiger Spiele alle Maps, Modelle etc. und soviel RAM benötigen.

@Max_der_Held: Selbst wenn der Server alle Objekte kennt und verwaltet kann der Client noch cheaten. Wenn der Server z.B. an alle Clients ständig jede Position aller Clients schickt dann kann ein modifizierter Client die Spieler schon anvisieren wenn er eigentlich noch gar nicht wissen dürfte daß der da um die Ecke steht (das wär in PB schlicht EntityLookAt()) und sobald er freie Schussbahn hat kann er automatisch schießen. Oder er kann sich in 'nem RTS den "Fog of War" sparen und seinen Radar wirklich stets alles hinmalen lassen daß es gibt. Da ist halt dann die Frage wie weit man das Filtern am Server schon treiben will. Irgendwann muss es der Client aber wissen weil er den anderen Spieler ja auch auf den Bildschirm malen muss. Und dann kann er wiederum Cheaten wenn er automatisch auf Pos X,Y,Z zielt. Da können die Spieler aber mit Votes und so evtl. noch kompensieren wenn jemand zu auffällig ein glückliches Händchen hat.

Ich finde übrigens den Artikel was diese ganze Client-Server geschichte anbelangt für ein ziemlich lesenswertes How-To - bzw. für den Fall ab "Step Five: Security": http://www.devmaster.net/articles/building-mmorpg/


Mfg,
auser

auser hat geschrieben:Naja ich war schon ganz froh. Bis vor kurzem bin ich stets beim Laden der Meshes gescheitert weil nicht das richtige Format/Version ausgespuckt wurde ...oder eigentlich früher schon beim einfachen Starten von Beispiel-Code in Linux. Ich bin mir ziemlich sicher der funktioniert auch in PB 4.60 Beta nicht.

Da funktionieren auch in Windows nun viele nicht mehr, weil sich Parameter
geändert haben, die noch nicht in der Hilfe dokumentiert und die Beispiele
noch unangetastet sind.

Blitz3D ist in dem Fall aber unschuldig. Model + Skript hat Blender ausgespuckt. Und ehrlich gesagt habe ich auch kein schlechtes Gewissen dabei ein 3D-Model-Program zum Modelieren zu verwenden - Jaja man kann auch die einzelnen Dreiecke selber zusammen kleben.

Ich konnte auch mit den *.mesh-Dateien von Blender nicht viel Anfangen,
aber damit muss ich mich wohl noch mal beschäftigen, vielleicht ist der
Exporter nun besser geworden. Ich hab auch kein einzelnen Vertex per
Hand geschrieben, sondern die ganzen 3D-Model-Programe ausprobiert,
die ich kostenlos ausprobieren durfte. Das Model beschreibt tatsächlich nur
die ganzen Koordinaten der Vertize usw. Alles, weitere wie Textur, LOD,
Farbgebung, Schatten, usw. steht im Material-Skript. Das sind alles Dinge,
die kein Exporter unterstützt. Lediglich "OgreMax Scene Exporter" hat
brauchbare Material-Skripte ausgespuckt.

In Blitz3D hab ich mich damit auch rumgeschlagen weil mir das Terrain von Blitz3D nicht gereicht hat und ich mir mein eigenes gebaut habe. Also alles hat auch Blitz3D nicht immer out-of-the-box hergegeben. Man ist aber doch gleich viel eher motiviert wenn vieles schon von Haus aus funktioniert und nicht alles zig Anläufe braucht oder verbuggt ist.

Oh ja ...

Dann muss man die halt in der selben Weise selber bauen? Die gab's so weit ich mich erinnere in Blitz3D im Gegensatz zu PB gar nicht out of the Box ... (aber mit EntityOrder war das ziemlich prompt fertig)

Jap. Nur nicht möglich mit der aktuellen Implementierung. Ich hab's
nicht hin bekommen und dann mir noch mal die OGRE-Doku
angeschaut. Zum erstellen eines SkyDomes oder SkyBox gibs extra
Befehle in OGRE. Solche werden auch sicher von PB ausgefrufen,
doch diese haben mehr Parameter als die von PB.

setSkyPlane()
setSkyBox()
setSkyDome()
Alle haben einen Parameter, der ein Materialname erwartet. Und genau diesen
müssen wir aber selber bestimmen können, um wirklich freie Hand zu haben.
Dein "Planet" fällt übrigends in keinen "SkyXXX".
Das heißt den solltest dir tatsächlich auch so machen können. Ein Mesh als Sky
zu verwenden sollte aber auch so möglich sein, ich hab's nur leider trotzdem
noch nicht hin bekommen.

Ich hab die Kollisionserkennung selber programmiert. Wenn du keine komplexe
Physik brauchst, mach Kollisionen selber und verlass dich nicht auf die (fehlerhafte)
Implementierung.

- Noch ein Bug?

Die Physikengine ist in PB4.60 anscheinend noch mal stark erweitert/ verändert
worden ... eventuell ist diese ja nun nicht mehr so Buggy aber ja, noch mehr
Bugs.

Ich denke so in etwa hat's aber in Blitz3D funktioniert. Wobei ich nicht weiß was der Befehl da im Hintergrund wirklich alles gemacht hat. Zumal man ja nicht alles immer ständig prüfen muss. Wenn der nicht nahe genug dran ist dann interessiert er mich ja noch gar nicht und wenn er nahe genug ist dann muss auch nicht in jeder Schlaufe ständig alles erneut geprüft werden.

Und woher "weis" der Befehl, das etwas nicht nahe genug ist? Das muss
auch alles verwaltet werden. Bei einer 3D-Engine kann man aber durchaus
erwarten, dass solche Dinge gut verwaltet werden. Doch sobald die 3D-Engine
auf gerenderte Informationen zurück greift müssen diese natürlich auch
tatsächlich erst mal gerendert sein. Und das wäre im Fall von OGRE und deinem
hier beschriebenen Vorgehen mit TempCamera+CameraLookAt+PointPick 100% der Fall.

Hatte ich ja eigentlich schon geschrieben daß der Server nicht rendern muss jedoch in PB die Kollisionen mit der 3D-Engine zusammengezwirbelt sind. Und nicht nur dort sondern auch in Blitz3D. Will ich die verwenden muss das Teil auch auf meiner Zielplatform laufen. Das ist aber eigentlich eher ein Grund warum ich nicht Blitz3D verwende. In PB wird mir die Liste welche ich dann noch fertig verwenden kann immer kleiner

"Laufen" bedeutet DirectX muss vorhanden sein, was nur mit einer
kompatiblen Grafikkarte zu gewährleisten ist. Emulieren geht allerdings
ja inzwischen auch. Doch "zusammengezwirbelt" hast du gut den
Umstand beschrieben, der hier vorherscht. Es muss der aktuelle Frame
vielleicht tatsächlich nicht gerendert werden, damit ExamineWorldCollision()
funktioniert, doch wer weis, in wie weit die Grafikkarte auch ohne das
Rendern beansprucht wird. Z.B. müssen die ganzen Meshes in den
Speicher geladen werden, und dafür wird natürlich der VRAM verwendet.
Da die Physik in einer 3D-Engine liegt kann ich mir auch gut vorstellen,
dass diese die Grafikkartenbeschleunigung ebenfalls in irgend einer
weise ausnutzt. Aber die Bounding-Box, die die Physikengine verwendet
für Kollisionenen, das ist totaler Overhead. Die Mesh-Daten usw. werden
ja garnicht benötigt. Also schau dich lieber tatsächlich nach alternativen
Physikengins um, auch wenn diese dich im ersten Moment erschlagen
würden. Ogre3D würde dich auch erschlagen, wenn du wüsstest, was dir
PB da eigentlich alles schon abnimmt.

MFG PMV

physikalische Simulation im Hintergrund durchführt.

was ist eine physikalische Simulation? Also Kollisionsprüfung? wie soll das bei 100-en von spielern gehn wenn es bei einem pc schon ruckelt..

Anders könnte ich es mir garnicht erklären, weshalb die Dedicated Server heutiger Spiele alle Maps, Modelle etc. und soviel RAM benötigen.

Weil sie den Clients die Map schicken (Counter-Strike, Starcraft II), falls der die noch nicht hat. Häufig kannst du das ganze Game von den Servern herunterladen (z.B. nexon.com) RAM brauchen Sie wohl wenn viele tausend Spieler online sind.. stell dir vor jeder Spieler hätte eine komplette physikberechnung mit der Map.. das dass nicht geht liegt auf der Hand. Was geht sind Näherungsrechnungen, wie die Bewegungsgeschwindigkeit oder die Koordinaten des Clients zu testen, das wars aber auch schon. Die Physikberechnung ist immernoch Clientlastig.. aber vielleicht hast du das so auch gemeint.. in Foren lässt sich sowas bei den langen Texten und zeitversetzten Antworten immer schlecht ausmachen..

dann kann ein modifizierter Client die Spieler schon anvisieren wenn er eigentlich noch gar nicht wissen dürfte daß der da um die Ecke steht

kann er ja, das nennt man "aimbot". die Kunst ist zu prüfen ob der client modifiziert ist, wie in dem Link auch beschrieben:
http://www.devmaster.net/articles/building-mmorpg/
Kapitel 5 "security". Du musst alle daten auf Wahrheit prüfen (Entfernung der PlayerNodes, evtl Drehwinkel). Aber du kannst nicht dem Client die Rechenarbeit abnehmen. sprich: die Kollisionsprüfung muss Clientseitig sein, weil sie CPU und nicht GPU lastig ist.sonst brauchst du für jeden Spieler einen eigenen Server-rechner in deinem Keller (von der Leistung her)

Und jetzt programmier weiter, ich glaube wir alle sind gespannt auf das Ergebnis egal wie es jetzt umgesetzt ist, wir wollen an sich kein rießiges MMORPG, wir wollen ein 3D Game mit PB-OGRE. ich glaub du machst das schon, wenn was nicht geht wirst du den Code ja eh ändern bis er flüssig läuft,
so oder so:

Viel Erfolg!.

mfg Max

Max_der_Held hat geschrieben:

physikalische Simulation im Hintergrund durchführt.

was ist eine physikalische Simulation? Also Kollisionsprüfung? wie soll das bei 100-en von spielern gehn wenn es bei einem pc schon ruckelt..

Für eine Antwort darauf wird man üblicherweise bezahlt mit viel Geld . Außerdem wird da vieles simplifiziert.

hahah :D punkt für dich ^^

PMV hat geschrieben: Da funktionieren auch in Windows nun viele nicht mehr, weil sich Parameter
geändert haben, die noch nicht in der Hilfe dokumentiert und die Beispiele
noch unangetastet sind.

Ich muss das erst mal revidieren. Ich hab es eben tatsächlich ohne viel Aufwand geschafft eine 3D-Szene in 'ner LinuxVM darzustellen.

Ich konnte auch mit den *.mesh-Dateien von Blender nicht viel Anfangen,
aber damit muss ich mich wohl noch mal beschäftigen, vielleicht ist der
Exporter nun besser geworden.

"Der Exporter" ist gut. - Da gibt's verschiedene. Der offizielle war (zur Zeit wo ich mir meinen Kram zusammen gesammelt habe) hingegen nicht für die letzte Version von Blender tauglich. Also hab ich da jetzt so einen Beta-Exporter der noch gerne ein paar Abhängigkeiten erfüllt haben wollte. Aber jetzt kann ich immerhin Meshes Exportieren die ich in PB dann sehe und wenn ich den dann rot anmale dann ist er auch in PB rot.

Und woher "weis" der Befehl, das etwas nicht nahe genug ist? Das muss
auch alles verwaltet werden.

Natürlich. Das hab in dem Fall aber nicht ich gemacht sondern Blitz3D mit EntityX,Y,Z ausgelesen. Wobei ich jetzt nochmal meinen alten Blitz3D-Code durchstöbert habe. Das war nicht EntityInView sondern EntityPick und diese Funktion hat das nächste Objekt zurückgegeben das er (ohne Camera) gepickt hat. Und die Funktion war eigentlich recht schnell. In die Knie ist das ganze erst gegangen wenn ich mich zu sehr mit Partikeln und dem Hintergrund auf meiner Laptop-Grafikkarte ausgetobt habe.

Die Mesh-Daten usw. werden ja garnicht benötigt.

Nicht in jedem Fall... und man könnte das vermutlich am Server auch einfach durch ein paar lowpoly-primitive ersetzen oder Pivot/Node mit 'nem Kollisionsradius sofern so was möglich wäre - oder eben halt überhaupt nur mit 'ner eigenständigen Physikengine lösen und nur dort wo es nötig ist sphere to mesh prüfen... also z.B. wenn du ein Weltraum-spiel machst und deine Spieler ein Schlachtschiff auseinander nehmen sollen dann wär's nicht schlecht wenn die Spieler nicht durch die Schiffswand rauschen dürfen. Die Bedenken daß mir so was den Server niederreißt hätte ich eigentlich weniger.


Mfg,
auser

Max_der_Held hat geschrieben:Also Kollisionsprüfung? wie soll das bei 100-en von spielern gehn wenn es bei einem pc schon ruckelt..

Wieso soll das bei einem PC schon ruckeln? - Du weißt schon daß der Strom in deinem PC mit Lichtgeschwindigkeit durchfetzt? Das ist eigentlich ziemlich schnell - Erstaunlich daß wir es geschafft haben das überhaupt so zu drosseln. Kollisionen haben mir schon meine Spielerleben gekostet als die Parole noch gelautet hat: Flieg auf 'nem C64 in die 3D-WireFrame gerenderte Raumstation und verkauf dort dein Zeug um dir das nächste mal einen ollen Auto-Andock-Computer kaufen zu können der diese fiese Rotation der Raumstation kompensiert. Gut vielleicht war damals noch die Welt besser. Da waren die Leitungen noch solider. Man hatte hunderttausende Bytes an Arbeitsspeicher zur Verfügung und vor allem - da kannte ich Windows noch nicht. - Wenn man wo 100 Spieler oder mehr reinpacken will dann würde ich persönlich dazu tendieren mehrere Server laufen zu lassen die sich ein paar Sektoren aufteilen.

Wobei wenn wir hier wieder zum Thema Torque zurückblicken... in Tribes2 gibt's einen Server (Goon Haven) der eigentlich fast immer gut besucht ist und dort gehen 64 Spieler rein... und fast in jeder Map kannst du verschiedene Fahrzeuge bauen. Wenn man einen Bomber schräg anschießt in dem 3 reale menschliche Spieler sitzen und der kracht gegen 'ne Wand dann torkelt und explodiert der auch. Das sagt dem nicht irgend ein Client. Tribes2 ist ein altes Spiel. Darüber hinaus gibt es den TriumphMod - dort sind glaube ich über 20 Slots mit Bots belegt (die müssen natürlich alle am Server verwaltet werden). Wenn man das nicht weiß merkt man's aber nicht so schnell (oder erst wenn man in die Playerliste nach den "B" sucht). Den Triumph Mod sollte man mal als Assault gespielt haben sich in die gegnerische Base schleichen und dort beim Generator eine Green-Latern (Antigravitations-bombe) platzieren. Das ist... lustig

Weil sie den Clients die Map schicken (Counter-Strike, Starcraft II), falls der die noch nicht hat.

Ne... nicht nur. Ich hab erst viel den Online-2D-Platformer Teeworlds bzw. den Mod DDRace gespielt und bei letzterem auch sehr dezent am Code geschraubt aber auch gemappt. Das Spiel ist 2D und hat verschiedene Layer. Du kannst viele Grafiklayer übereinander legen... die sind dem Server alle wurscht (die hat er wirklich nur wenn er eine ganze Map an 'nen Client schicken muss) aber darüber hinaus gibt es auch viele andere Layer, wie Teleporter, Kill, Laser, Freeze-Zonen, Beschleuniger, Türen usw... die muss alle der Server kennen. Und wehe irgend etwas wird da nicht richtig geprüft. Das kannst du dir fast wie ein Fass vorstellen in das du Wasser reinfließen lässt. Wenn das nicht wirklich dicht ist kannst du darauf warten daß es irgend jemand heraus findet und ausnutzt und z.B. durch eine Wand durch hookt. Das ist schon beim Mappen schlimm genug. Man denkt oft gar nicht auf was für Ideen die Leute alles kommen. Mal von denen die es aus Jux einfach darauf anlegen Server von Fremden Leuten zu crashen ganz abgesehen.

Du musst alle daten auf Wahrheit prüfen (Entfernung der PlayerNodes, evtl Drehwinkel).

Entfernung reicht nicht in jeden Fall. Vor allem muss der Server ja wissen wie und ob der Spieler von A nach B überhaupt darf. Wenn du darüber hinaus wie in Tribes2 Bots einbaust sollten die vielleicht auch nicht all zu dämlich sein. Die sollten nicht anfangen auf die Decke zu schießen wenn du ein Stockwerk darüber zwar "ganz nahe" bist aber doch eine massive Wand dazwischen steht. Du musst auch wissen ob der SPieler dort überhaupt sein darf wo er vorgibt zu sein. Der Server kann es sich sparen die Physik von Effekten zu berechnen oder von Animations-Sequenzen. Wobei... genau genommen - sofern du einen Server lokal auf deiner Windows-Maschine mit Bots hostest auf den du dann auch selbst spielst dann macht er sogar selbst das noch.

die Kollisionsprüfung muss Clientseitig sein

Das kann zusätzlich nötig sein wenn du Prediction einbaust oder die Datenrate etwas drosseln willst. Wenn du ein online "Elite of Elite" bauen willst dann muss der Client eigentlich nur dann die Kollision prüfen wenn er diese auch überleben soll. Und nicht mal dann in jedem Fall. Du könntest evtl. auch einfach nur ein Stop-an-dieser-Position-weil-Kollision vom Server bekommen der dir einen Pivot vorschreibt welcher parallel zum kollidierten Face rotiert wird und so lange deine "Slide-Richtung" vorgibt bis der Server sagt daß es reicht oder dich ein Stück zurückprallen lässt.



Mfg,
auser

wie gesagt meine Meinung steht, dazu äußere ich mich nicht mehr, ich will ein Ergebnis

aber weil ich gerade physik abschlussprüfung schreibe..

Du weißt schon daß der Strom in deinem PC mit Lichtgeschwindigkeit durchfetzt? Das ist eigentlich ziemlich schnell

Strom bewegt sich NICHT mit Lichtgeschwindigkeit o.O
Strom sind Elektronen die durch einen Leiter fetzen. Sie Reagieren mit Lichtgeschwindigkeit, und bewegen sich durch Kupfer mit 0,3 mm/s. denn Elektronen haben eine Masse (ca. 9,109*10^-31 kg) und laut Einsteins Formel kann sich keine Masse mit Lichtgeschwindigkeit bewegen.
Außerdem ist mein PC mit 1.6-2.6 ghz leistungstechnisch recht begrenzt

und jetzt arbeite weiter!
lg