Torque-Engine ist wieder am Start

[PMV]

Selbst auf der Ogre3D Seite wird C++ nicht nur mit Vorteilen überhäuft:

Ich weis, was C/C++ ist ... und ich weis, warum ich PB bevorzuge.
Offensichtlich haben wir da beide die gleichen Gründe.
Der von dir Zitierte Text beschreibt den Umstand ziemlich treffend,
wobei ich weniger ein Problem damit hab, dass man viel "zu Fuß"
machen muss als mehr damit, dass dadurch der Entwicklungsaufwand
um ein vielfaches höher wird. (zeit mäßig)

Ich hab Blitz3D lange Zeit verwendet und ich finde es immer noch ziemlich cool.
Das was Blitz3D kann hab ich mit PureBasic nicht hinbekommen. Weder EntityAlpha, noch EntityOrder, noch EntityInView, noch EntityBlend oder GetEntityType.

Also diese ganzen Eigenschaften wie das Verhalten im Z-Puffer und
Transparens werden über die Material-Scripte gesteuert. Mit PB 4.60
wird man nun auch endlich selber Material-Scripte einem Entity zur
Laufzeit zuweisen können. Das Ändern der Werte eines geladenen
Materials ist auch begrenzt mit noch mehr Befehlen möglich. Leider
aber wohl nicht alle, naja vielleicht kann das OGRE auch garnicht.
Ein Entity hat allerdings kein "Typ", ist mir zumindest nicht bekannt.
Das musst du selber verwalten. Die MousePick() Funktion ist allerdings
in PB4.5x buggy wie vieles andere auch, weshalb wirklich viel
Funktionalität fehlt, aber das bestreite ich auch nicht. Warten ja nicht
ohne Grund auf Bugfixes für die aktuelle Beta.

Der Partikelemmiter in PB ist meiner Meinung nach zu eingeschränkt.

Jap, wobei mir persönlich mehr die Möglichkeit des Einlesens von Partikel
-Scripten fehlt, aber letzten Endes sind es am Ende nur Texturen (Billboards)
die zu Hauf dargestellt werden. Mir persönlich reicht das aber, allerdings kenn
ich auch nix anderes. ka was dadurch dann nicht möglich ist

Ne... ein Befehl reicht nicht. Ich würde eher sagen Blitz3D vermittelt den Eindruck man könnte allein ein Spiel kreiren - und es hat recht damit. - Würde ich mich mit Singleplayer oder "Direct-Play" ohne Linux-Server-Part zufrieden geben...

Naja, mir persönlich reichen die 3D-Möglichkeiten von Blitz3D absolut
nicht. Ich will kein 0-8-15 Spiel, das aussieht als wäre es für den N64.
na gut, mein können in Sachen 3D reicht eigentlich garnicht für mehr aus,
aber dafür sucht man sich halt dann andere Leute ^_^ ... nen 2D-Spiel
hab ich schon gemacht ... siehe QBasic.de, das hat die grenzen von
QBasic damals auch ausgereitzt. Nun ist PureBasic drann.

Kennst du Master of Orion2? Ich hab erst vor kurzem einiges Seufzen darüber gelesen daß es keinen wirklichen Nachfolger dazu gibt. Das Spiel ist "ödes" 2D genau so wie X-Com Terror of the Deep oder das alte Civ oder Transport Tycoon. Elite ist auch ein Titel den ich persönlich sehr cool fand und das 3D war nicht wirklich der Hammer. Viele solcher Spiele hatten meiner Meinung nach mehr "Seele" als so einige der heutigen "Eye-catcher". Ich finde auch Crysis toll aber ich selbst will kein Crysis bauen und auch keinen Kino-film drehen. Ich kann in vernünftiger Zeit 3D-Modelle bauen, Grafiken zeichnen, Musik und Sound erstellen ... wenn ich dann aber an die Anfangsequenzen von Crysis denke dann kommt man meiner Meinung nach was Animationen betriff an Motion-Capturing nur schwer vorbei. Das ist mir eine Nummer oder zwei zu groß.

Oh ja ... für so was brauchst aber auch ein großes Team + Budge. Das
haben wir nun natürlich nicht. Und RCT hat Chris Sawyer so weit ich gehört
hab in Assambler programmiert. RCT2 ist ebenfalls ein Alleinprojekt von ihm.
Auch Locomotion hat er progarmmiert (ähnlich wie TT). Lediglich RCT3 war
er "nur" noch Berater. Als 1-Mann Team muss man sich tatsächlich gut
überlegen, was man erreichen will. Ich konzentriere mich erst mal auf die
Funktionalität und habe grafisch PB-OGRE ausgeschöpft, um diese Funktio-
nalität auch praktisch testen zu können. Das Ergebnis ist bereits zu 100%
spielbar. Doch wegen der vielen PB-OGRE-Bugs kann ich es natürlich damit
nicht veröffentlichen. Noch ist aber eh einiges zu tun, bevor alle Funktionen für
einen ersten Release fertig sind und bis dahin hoff ich, dass PB so weit ist.

Ich hab keine Verwendung für die Crytek Engine sofern sie nicht eine einfache Schnittstelle zu PB bietet. Weil ich davon ohnehin vermutlich bei weitem nicht alles ausschöpfen würde wäre mir genau so ein CrytalSpace, Sauerbraten oder Ogre3D recht und sogar das Blitz3D welches auf DX7 basiert ist mir von der Qualität her völlig ausreichend. Es ist mir wichtiger weiter zu kommen als theoretisch wahnsinnig tolle Produkte zu schaffen wenn ich nur endlos viel Zeit hätte.

Ich Persönlich hab da andere Prioritäten. Es muss eine gewisse Funktionalität
bieten, darf mich aber vom Aufwand her nicht Jahrzehnte zurück werfen. Eine
gute Mischung mach's, wenn ich mich am Ende gegen OGRE entscheiden muss,
wird es aber bei der Auswahl so oder so ein 50:50 Glücksspiel, weil tatsächlich
kaum jemand sich auf dem Gebiet bisher geübt hat und vorallem nichts
Veröffentlicht wurde, was einen für eine entsprechende Engine überzeugen könnte.

Wir sind hier praktisch alle Pioniere.

MFG PMV

[auser]

Also diese ganzen Eigenschaften wie das Verhalten im Z-Puffer und
Transparens werden über die Material-Scripte gesteuert. Mit PB 4.60
wird man nun auch endlich selber Material-Scripte einem Entity zur
Laufzeit zuweisen können.

Material-Script das mir Blender über irgend so einen Beta-Exporter ausgespuckt hat hab ich schon in PB 4.60 geladen. Aber muss ich echt zum Faden von 50% Alpha auf 100% Alpha 50 verschiedene Material-Scripte laden?

Das Ändern der Werte eines geladenen
Materials ist auch begrenzt mit noch mehr Befehlen möglich.

Ja DiffuseColor und anderes Zeugs - aber ich hab nix bezüglich Alpha-Wert gefunden (und RGBA() hab ich schon probiert - das funzt nicht ). Das fände ich aber wichtig... und es stand schon mal auf einer Wunschliste im englischen PB-Forum.

Vielleicht geb ich dem PB-Ogre aber trotzdem nochmal 'ne Chance. EntityOrder brauch ich in dem Fall noch nicht (obwohl ich das sehr, sehr praktisch fand). Kollisionen könnte man mit dem Verzicht auf #PB_Any und fest gesteckten Ranges sicher akzeptabel schnell abfragen. EntityInView evtl. mit 'ner TempCamera+CameraLookAt+PointPick hinkriegen. Zumindest halbwegs.

Ich will kein 0-8-15 Spiel, das aussieht als wäre es für den N64.

Da müsste man sich mit Blitz3D aber schon anstellen. Das gibt denke ich schon ein wenig mehr her. Ob ein Spiel 0-8-15 ist liegt ja nur zu einem Teil an der Grafik. Guck dir mal an wieviele Browser MMOs daß es gibt und wie viele Leute das spielen. Viele davon haben nicht mal Sound (und doch kann eine gute Musik oder Sound ein Spiel enorm aufwerten). Wenn man sich in dem Umfeld frei genug bewegen kann, kann man auch mit eigenen Spielereien noch einiges rausquetschen. Da wär so "High-tech-Zeugs" wie freies EntityAlpha aber schon ziemlich cool. Ich spiele aber auch Schach oder Monopoly... und die "Grafik" ist da nicht unbedingt der springende Punkt.

Ich konzentriere mich erst mal auf die Funktionalität und habe grafisch PB-OGRE ausgeschöpft, um diese Funktio-
nalität auch praktisch testen zu können. Das Ergebnis ist bereits zu 100% spielbar.

Klingt ja schon mal vielversprechend.


Mfg,
auser

[tft]

Hallo @auser,

wiso braucht du eigentlich auf der Server Seite 3D?

Gruss TFT

[auser]

Ich brauch auf der Server-Seite nicht 3D rendern. Jedoch all die Positionen, Bewegungen, Rotationen und Kollisionen der mathematischen 3D-Welt muss der Server verwalten.
Auch NPCs müssen am Server rotiert, bewegt und geprüft werden. Also zum Beispiel: Soll der NPC jetzt überhaupt feuern oder steht dazwischen ein riesiges Objekt welches die Sicht eigentlich blockieren müsste und den sinnlosen Schuss auf der anderen Seite des Objekts dann eher dämlich oder seltsam aussehen lässt.

Da fällt mir ein... damit wäre mein vorhin vorgedachtes selbst gebasteltes EntityInView das auf 'nem CameraLookAt und irgend 'nem Pick (PointPick wäre vermutlich eh falsch sondern eher MousePick weil ich das Entity ermitteln will) basieren würde in dem Fall dann eigentlich so wie so Mist. Zudem hab ich mich schon geärgert daß die Kamera da in Prozent der Screengröße angegeben werden muss. In Blitz3D konnte man eine Kamera ja auch schön dafür verwenden um eigentlich dann auf eine Texturen zu rendern. Also Quasi Spiegeleffekte oder ähnliches zu erzeugen.

Was aber den Server betrifft evtl. würde dafür ja auch ein Bullet-Wrapper oder was ähnliches reichen (wobei ich mir nicht sicher bin ob das all das abdecken würde)... aber die Clients dürfen jedenfalls nicht unkontrolliert bestimmen ob da jetzt eine Kollision statt zu finden hat oder nicht. Nachdem Kollisionen in PB an die 3D-Engine gezwirbelt sind müsste es damit auch auf der Server-Seite kompilierbar sein. Ansonsten könnte ein modifizierter Client ja alles mögliche behaupten. Die tatsächlich gültigen Größen, Positionen, Rotationen und Kollisionen, Beschleunigungen usw. muss der Server wissen. Der Client darf maximal sagen: Ich will vorwärts. Wie weit das ist irrelevant. Das muss der Server wissen. Oder: Ich will jetzt bitte schießen. Oder: Ich hab jetzt auf "rotiere-mich-nach-links" gedrückt. Der Server muss dann ein MoveEntity mit der entsprechend maximalend Speed machen und dem Client zurückschicken daß es gilt oder ein CreateBullet nach entsprechdem ReloadDelay und wissen wenn's dann wo kracht oder ein "ok ich rotier dich jetzt mal bis du mir signalisierst daß du den Knopf ausgelassen hast - und dann sag ich dir wie deine Rotation jetzt im Endergebnis aussieht - auch wenn du selbst meinst daß du da ja schon über eine gewisse Vorahnung eigenmächtig rotiert hast". Daß der Client das auch machen und abbilden muss ist fast schon zweitrangig.

Mal davon abgesehen fände ich eine Linux-Client-Version aber schon auch sehr erfreulich. Das sollte ja theoretisch auch klappen wenn man sich die PB-Startseite durchliest. Ich hab Windows privat die letzten Jahre nur sehr wenig gestartet... erst die letzte Zeit wieder.


Mfg,
auser

[PMV]

Material-Script das mir Blender über irgend so einen Beta-Exporter ausgespuckt hat hab ich schon in PB 4.60 geladen. Aber muss ich echt zum Faden von 50% Alpha auf 100% Alpha 50 verschiedene Material-Scripte laden?

Blender-Exporter ist mist ... ich hab alle Material-Scripte bisher selber geschrieben.
Und wenn man sich damit mal außeinander setzt fällt einem vieles auf. Wie schon
geschrieben, Blitz3D nimmt einem viel ab, schränkt einen dadurch auch ein.
Aber nun gut, natürlich erschwert es dadurch auch einfache Dinge wie
Transparents ziemlich. Bisher hab ich das immer über Texturen geregelt, aber es
geht auch über die einfachen Farben, schließlich haben die auch extra Alphawerte.

Ja DiffuseColor und anderes Zeugs - aber ich hab nix bezüglich Alpha-Wert gefunden (und RGBA() hab ich schon probiert - das funzt nicht ). Das fände ich aber wichtig... und es stand schon mal auf einer Wunschliste im englischen PB-Forum.

Jaaa, RGBA() ... man, warum bin ich da nicht selber drauf gekommen, man
kann mit PB ja nun auf einfachste weise 32-Bit Farbwerte mit Alpha generieren.
Der rest ist einfach nur Wissen, wie Material-Scripte funktionieren.

Um etwas Transparent erscheinen zu lassen muss im Material erst mal sicher
gestellt werden, dass dahinter liegendes auch weiter hin gerendert wird, daher
muss "depth_write off" im Materialscript stehen. Desweiteren muss auch die
Mischung mit der Umgebung auf Alphablend gesetzt sein, also im Script
muss "scene_blend alpha_blend" stehen. Ist das der Fall, kann nun z.B. der
Alphawert der Diffusecolor dazu genutzt werden, um die Transparenz zu
ändern.

Und genau das geht alles auch mit PB-Befehlen:

Code: Alles auswählen

MaterialBlendingMode(#Material, #PB_Material_AlphaBlend)
MaterialDepthWrite(#Material, #False)
MaterialDiffuseColor(#Material, RGBA(255, 255, 255, 255/2))

Das sollte übrigends auch mit älteren PB Versionen funktionieren. Glaub
RGBA() gibs seit PB4.50
Probiert hab ichs aber jetzt nur mal mit PB4.60 Beta 3 ... klappt perfekt.
Der interessante Wert ist natürlich der letzte in RGBA()

Vielleicht geb ich dem PB-Ogre aber trotzdem nochmal 'ne Chance. EntityOrder brauch ich in dem Fall noch nicht (obwohl ich das sehr, sehr praktisch fand).

Die meisten Dinge stecken nun mal im Material-Script. Beschäftige
dich damit und lerne sie zu verstehen. depth_write:
http://www.ogre3d.org/docs/manual/manual_16.html#SEC50
Sollte hier eine gute Lösung bieten. "depth_write off" macht, dass jedes
andere Entity, egal ob es sich vor oder hinter dem Planeten-Entity befindet,
gerendert wird. Somit erscheint das Entity immer im Hintergrund. Es darf
allerdings hier kein SkyBox oder SkyDome existieren, da der sicherlich dann
den Planeten ebenfalls überschreibt. Im normalen OGRE könnte man hier
evt. auch noch entsprechende Attribute setzen, damit das nicht passiert.
Aber mit PureBasic haben wir ja leider keine Möglichkeit SkyBox oder SkyDome
selber zu definieren. Setz die Hintergrundfarbe der Kamera dann noch auf
Schwarz, wobei das glaub der Defaultwert ist, um die dunkelheit der Galaxy
zu "simulieren" und es sollte passen.
Es gibt aber sicher auch andere Möglichkeiten mit den depth_xxx Attributen
des Material-Scripts, den Planeten an die "richtige Stelle" rendern zu lassen.

Kollisionen könnte man mit dem Verzicht auf #PB_Any und fest gesteckten Ranges sicher akzeptabel schnell abfragen.

Ich hab die Kollisionserkennung selber programmiert. Wenn du keine komplexe
Physik brauchst, mach Kollisionen selber und verlass dich nicht auf die (fehlerhafte)
Implementierung. So wie so sind erst jetzt bei PB 4.60 Physikspielerreihen
möglich, die man nicht mal eben selber programmieren kann. Und bevor man diese
tatsächlich verwendet, sollte das ganze eh erst stabil sein.

EntityInView evtl. mit 'ner TempCamera+CameraLookAt+PointPick hinkriegen. Zumindest halbwegs.

Das klingt nach einem sehr rechenintensiven Befehl. Oder
ging der Befehl nur für die aktuelle Kameraansicht? Auf keinen Fall geht das
so, wie du da beschreibst. Das zwingt jede noch so neue Hardware in die Knie.

Dafür musst du dich in der Tat etwas mehr anstrengen.
Alle Objekte, die sich auf der Schussbahn befinden können, müssen überprüft
werden. Gleichzeitig muss diese Menge aber so gering wie möglich gehalten
werden. Da durch wird die Last geringer. Da allerdings die eingebaute Kollisions-
erkennung der Physikengine nicht einfach nur zwei Entities vergleichen kann, ist
diese für das Problem hier leider nutzlos. Einfach mit hoher Geschwindigkeit ein
Entity durch die Szene jagen funktioniert tatsächlich nicht.


Und wegen 3D auf Server: seit wann benötigen Server 3D Beschleunigung,
obwohl diese keine Grafikausgabe haben? ... also korrigiere mich,
wenn ich falsch liege, aber Server nutzen viel CPU, RAM und Festplatten-
speicher ... aber doch keine Grafikkartenfarm. ... für den Server braucht
es so oder so eine eigene Routine um die vom Client gewünschten
aktionen nach vollziehen zu können und zu bestätigen. Oder vielleicht sogar
besser ... diese selber aus zu führen und dem Client nur das Ergebnis zu
senden.

MFG PMV

[Max_der_Held]

Also PMV, ich glaube er will die Kollisionsprüfung mit den 3D Engine Befehlen oder anderen physik Befehlen auf Serverseite laufen lassen, dafür muss er die Map laden.

ist aber zu viel Text um alles zu lesen..

Ich schlage eine Alternativlösung vor:

Kob und ich haben vor Urzeiten mal einen Ferien 3D Shooter gebastelt (nie veröffentlicht)

Jeder Spieler macht beim Schießen einen PICK sagt dann dem getroffenen Spieler per TCP: "Du bist getroffen". und irgendwann sagt Dieser dann an alle "ICH bin TOT". So läufts flüssig und der Server verteilt nur noch die Packete (so soll es sein)

CODE + EXE + INFO
lg
max =D

Als Beispiel und Anregung.

[TomS]

Und was machste bei nem Lag?
Wenn der Server alles handelt und es laggt bei einem Spieler, bleibt dieser kurz stehen, oder so und wird eindeutig getroffen.
Mit deiner Methode wirst du auch getroffen, wenn's beim Schützen laggt.
Schlimmer noch (was bei einem Spiel unter Freunden eher nicht zutrifft): Man könnte einen Trainer bauen, der alle Spieler Clientseitig einfriert.
Dann müsste man wieder mehr Traffic investieren um ständig zu überprüfen ob die Playerpositionen bei jedem Client identisch sind.

[Max_der_Held]

Achso: nein der Server handelt eben nichts, er verschickt nur Daten zwischen den Clients.
die Clients bekommen alle ständig die Positionen der gegner geschickt und zeigen da das Gegnermesh an.

wenns spiel natürlich direkt mit 15 fps beim Client laggt kann man keinen shooter spielen, aber:

Ping Problem:

• aber sagen wir, spieler "horst" hat einen hohen ping.
• "thomas" sieht ihn und schießt.
• ENTWEDER: horst geht in deckung , wird aber trotzdem getroffen, weil er vor einer sekunde ja noch im level war.
• ODER: thomas schießt 20 mal auf Horst, trifft ihn, aber da Horst aus dessen Sicht in Deckung ist wird ihm nichts abgezogen..

für beide ungerecht, aber Notwendig

Anders geht es nicht, weil horsts ping einfach durchs Internet schlecht ist.. da ist es egal ob der server oder der client die kollisionsprüfung macht.. wenn Horsts PC so langsam ist dass das spiel kaum läuft, dann können die anderen ihn einfach erschießen, man kann für ihn nicht 10 andere warten lassen...

siehe z.B. Combat Arms oder counter-strike.. hab jetzt WOW nicht gespielt..

[auser]

Blender-Exporter ist mist ... ich hab alle Material-Scripte bisher selber 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.

Und wenn man sich damit mal außeinander setzt fällt einem vieles auf. Wie schon
geschrieben, Blitz3D nimmt einem viel ab, schränkt einen dadurch auch ein.

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. 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.

Der rest ist einfach nur Wissen, wie Material-Scripte funktionieren.

Hmm... Ich hab das Material-Skript wohl unterschätzt.

Es darf allerdings hier kein SkyBox oder SkyDome existieren, da der sicherlich dann
den Planeten ebenfalls überschreibt.

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)

Es gibt aber sicher auch andere Möglichkeiten mit den depth_xxx Attributen
des Material-Scripts, den Planeten an die "richtige Stelle" rendern zu lassen.

Klingt jedenfalls nach etwas das man selber basteln kann... Sieht mir jetzt schon besser aus. Danke für den Hinweis.

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?

Das zwingt jede noch so neue Hardware in die Knie.

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 wegen 3D auf Server: seit wann benötigen Server 3D Beschleunigung,
obwohl diese keine Grafikausgabe haben? ... also korrigiere mich,
wenn ich falsch liege,

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

für den Server braucht es so oder so eine eigene Routine um die vom Client gewünschten
aktionen nach vollziehen zu können und zu bestätigen. Oder vielleicht sogar
besser ... diese selber aus zu führen und dem Client nur das Ergebnis zu
senden.

Hab ich ja schon geschrieben. Der Client darf da gar nicht viel mehr machen als zu sagen: Ich will vorwärts. Ich will schießen. Ich hab jetzt auf den "rechts rotieren Knopf gedrückt". Und der Server sagt ihm: Ok ... oder eben nicht. Die gültigen Werte für all die Positionen, Rotationen, Beschleunigungen Verzögerungen für Reload bei Waffen usw. muss der Server verwalten und der muss auch in erster Linie die ganzen Objekte durch die Gegend schubsen. Der Client kriegt es so weit er es zum Abbilden benötigt und darf höchstens über Prediction schon mal etwas früher damit anfangen und erraten was da gerade am Server passiert und sich über UDP etwas orientieren (und bei den Zwischenschritten darf dann auch durchaus mal was droppen). Der Client hinkt immer hinterher. Ist das was der Client macht aber absichtlicher Blödsinn und ignoriert er auch Positionsupdates oder absolute Stop und Start-Befehle dann ist es mir ehrlich gesagt egal was der Client sieht. Wenn der Server sagt: Jetzt muss du explodieren dann ist der für alle richtig funktionierenden und nicht-cheatenden Clients kaputt. Der braucht auch gar nicht unbedingt alle Spielerpositionen zu kennen. Und er soll mir auch gar nicht sagen wie schnell er sich gerne bewegt hätte. Da könnte ja jeder Client daher kommen und mir irgend was erzählen. Das muss der Server wissen. Der hat also auch eine ganze Menge von der 3D-Welt zu berücksichtigen... aber... dafür soll er tatsächlich keine Grafikkarte brauchen. Man könnte das also sehr wohl in Physik-Engine und Render-Engine trennen... aber das ist weder in Blitz3D noch in PB der Fall. Und ich bin eigentlich erst mal davon ausgegangen daß wenn ich die Ogre3D implementierung verwende ich eben auch die Kollisionen und Physik daraus verwende. Wobei ich mir da jetzt nicht mehr so sicher bin. Ich schrieb aber schon vorhin daß dafür möglicherweise ein Bullet-Wrapper (Bullet ist 'ne Physik Engine) ausreicht. Nur so gerade mal eben ist das auch nicht gemacht. Ich hab mir das vorhin angesehen und der Umfang von Bullet hat mich ziemlich erschlagen.


Mfg,
auser

[auser]

Achso: nein der Server handelt eben nichts, er verschickt nur Daten zwischen den Clients.

Das kannst du meiner Meinung nach höchstens unter Freunden machen. Im Internet kannst du dich nicht darauf verlassen daß jeder fair spielt. Da muss der Server sagen ob etwas gilt oder nicht und ist damit auch mehr als nur ein Zwischenpuffer der rein und raus schiebt.


Mfg,
auser