Wie soll es weiter gehen?

Coordinator
Jan 17, 2015 at 11:02 PM
Hallo liebe Freunde von OctoAwesome.

Gerade habe ich Folge 48 fertig gestellt und bin an einem weiteren Punkt der Entscheidungen. Unsere 3D-Szene rendert jetzt halbwegs so wie vorher und es stellt sich die Frage, welche Baustelle ich als nächstes aufreißen soll. Es stehen folgende Dinge zur Auswahl

Map Layout

Das ist auch gleichzeitig mein Favorit, weil er etwas essenzieller für das Spiel ist als die anderen Optionen. Es geht nämlich um das Design unserer Maps. Aktuell weißt unser Konzept ein paar Probleme auf: Wir haben nur Zellen, keine Blöcke. Dadurch können wir keine Höheninformationen mit bringen. Außerdem sind unsere Block-Typen bisher noch hart kodiert in einem fixen Enum.

Wir müssen uns also baldmöglichst mal um ein potentielles Map-Layout kümmern, damit wir auch baldmöglichst die Erweiterungsmöglichkeit für Blocks und Maps haben werden. Dieser Punkt würde also einen Remake das Karten-Formats und deren Repräsentation im Spiel mit sich bringen.

Drauf folgend natürlich weitere Fragend es Spiels die ohne ein Map-Remake erstmal nicht möglich sind:
  • Block Extensions
  • Map-Chunks (undendliche Karte)
  • Map Generator

Extension Framework

Wir hatten ja bereits im Stream beschlossen, dass ein wichtiger Punkt in OctoAwesome die Erweiterbarkeit des Spiels sein muss. Wie so etwas aussehen kann, muss aber noch entworfen werden. Extensions können angefangen bei Blocks über Map Items bis hin zu NPCs oder Spieler Bots alles mögliche sein.

Der grundsätzliche Mechanismus dafür muss aber noch geschaffen werden. Das kann gerne noch vor dem Map Remake passieren. Das ist auch was, was nicht allzulange dauern wird - zumindest was die Basics angeht.

OctoAwesome Physik

Nein, ich habe die Bug Reports und Kommentare zur fehlerhaften Kollision nicht ignoriert, sondern nur aufgeschoben. Wohlwissend, dass wir früher oder später nochmal unsere Physik anfassen müssen. Aktuell bewegt sich Adam ja nur in x und y-Richtung und das auch relativ geradlinig nach der Lenkrichtung des Spielers.

Für eine glaubwürdige Interaktion mit der Umgebung (Hüpfen, Kollidieren, Fallen,...) braucht es etwas mehr Nähe zur Physik. Wir müssen die Bewegung von Adam also unbedingt auf Kräfte und Gegenkräfte inkl Gravitation umstellen.

Dieser Punkt hätte sinnvollerweise direkt Platz hinter dem neuen Map-System, da wir mit Höhen und Tiefen etwas mehr zum Testen hätten. Aber wenn ihr das lieber vorher haben wollt, geht das natürlich auch.

HUD & UI Framework

Das ist durchaus was, was wir dazwischen schieben können. Wir haben bisher ja keinerlei Möglichkeiten was am Screen anzuzeigen. Weder haben wir eine Lebensanzeige, noch einen Kompass oder sonstwas. Auch die Interaktion mit der Kiste ist aktuell nicht möglich, weil uns das UI fehlt.

Das ließe sich zwar auf die Schnelle hinfummeln, aber wir sollten das lieber weißtläufig durchdenken, da wir sicher noch ganz viele UIs brauchen werden - im Idealfall sogar konfigurierbar, damit später auch Extensions darauf zugreifen können.

Multiplayer

Ein Punkt, der zum aktuellen Zeitpunkt vielleicht noch etwas früh ist. Schließlich ist die API und das Spiel noch zu wackelig für eine Multiplayer Plattform. Aber ich wollte es mal zur Diskussion geben.

So! Das wären so meine Vorschläge und ich bin gespannt auf eure Wünsche, Kritik, Warnungen, Hinweise, Beiträge, Senf,... ihr wisst schon. Lasst mich also bitte wissen wie ihr euch die weiteren Folgen so wünscht und was ich euch für die einzelnen Themen im Detail vorgestellt habt. Gerne hier, gerne in Facebook, Youtube, egal...

Cheers
Tom
Jan 20, 2015 at 9:47 AM
Hi,

erst mal auch hier auf Codeplex nochmals vielen Dank für das Let's code.
Auch wenn im WinForms-Teil noch nicht wirklich was dabei war was ich nicht auch schon gemacht hätte, fand ich es wirklich sehr
kurzweilig und unterhaltsam. Außerdem hab ich zwar schon selber gemalt etc. aber bislang immer in Business-Anwendungen und noch nie für ein Spiel.
Ich war erstaunt wie gut das mit WinForms dann doch geht. Es war genau richtig klein anzufangen um mal zu sehen wie das funktioniert. Und jetzt geht's ja so langsam ab :)

Nun zur Frage wie es weiter gehen soll:

Ich wäre zunächst für das Map Layout. Ich nehme mal an, dass die meisten Extensions nochmal angepasst werden müssten sobald die Map umgebaut wurde. Also wäre es sinnvoll den Umbau davor zu machen.

Anschließend wäre ich für Physik, da ich vermute, dass das gedanklich gut zum Map-Thema passt. (hast du ja auch schon angedeutet)

Da jetzt der für mich interessantere Teil mit Mono Game (nicht mehr WinForms) kommt, werde ich jetzt dann damit anfangen den Code abzurufen und mich damit zu beschäftigen (selber neben dran was rum basten um ein Gefühl dafür zu bekommen).
Deshalb kann von mir aus dann auch erst noch das UI-Framework kommen und erst danach die Extensions. Ich bin ja beschäftigt ;)
Allerdings ist es mir auch egal wenn zuerst die Extensions kommen und dann das UI. Die Reihenfolge wird bei den beiden Themen vermutlich nicht die große Rolle spielen.

Den Multiplayer würde ich an den Schluss setzen. Denn auch wenn mehrere Männchen/Fräuchen in der Welt rum laufen kommt vermutlich nicht so viel Freude auf bevor nicht irgendwelche sinnvollen Spielelemente vorhanden sind oder Extensions in irgendeiner Form etwas Spielspaß rein bringen.

Das wäre meine persönliche Reihenfolge. Und jetzt schließt euch an oder steinigt mich ;)

Viele Grüße

P.S.: auch wenn es schon eine Weile her ist: im Zuge des letzten Live-Streams wurde beim Thema Kommunikation SignalR angesprochen. Ich würde gerne meine Stimme dafür aussprechen. Habe zwar keine Erfahrungen damit aber es scheint für solche Sachen gemacht zu sein und ich wollte es schon lange mal ausprobieren.
Scheint ja ähnlich "kompliziert" wie die ASP.NET WebAPI zu sein, also verdammt einfach. Und Plattformübergreifend funktioniert es wohl auch so wie es aussieht.
Coordinator
Jan 20, 2015 at 10:23 PM
Vielen Dank für deine Einschätzung. Das deckt sich von der Themenreihenfolge aktuell mit meinem Plan. SignalR habe ich nicht vergessen ;) Gemacht habe ich damit noch nichts, aber die Spec klingt vielversprechend. Ich muss damit mal den einen oder anderen Test machen.
Jan 21, 2015 at 9:07 AM
Hallöle,

Map Layout ist wirklich wichtig. Da fände ich eine mischung aus unendlicher Map und "Levelmaps" nicht schlecht. Dabei sollten wir auch nicht zur sehr Minecraft als Vorbild nehmen. Sondern eventuel was eigens Überlegen sollten. Ich überlege gerade in was für ein Genre das Spiel fallen sollte.

Ich denke jetzt wäre es sinnvoll an der U-I und am Multiplayer zu arbieten. Der Multiplayer kann ja soweit schon vorbereitet werden in der Form das es einfache NPC in der Welt existieren und später kann das ja voll ausgebaut werden.

Physik auf jeden Fall ein Spannendes Thema, aber auf jeden fall erst nach der Map sinnvoll.

Extension müssen glaub ich in den Einzelnen Teilen schon vorbereitet werden, aber können nach dem HUD gemacht werden.

Und Multiplayer sollte auch kein goßes Problem mehr sein, wenn es schon einfache NPC existieren. Und kann es jetzt voll jusgebaut werden.

viele grüße
Jan 21, 2015 at 9:50 AM
Hi,

Ich bins noh mal. Vielleicht noch ml ein Wort zur Map, weil sie mir relativ wichtig ist.

Ich würde vorschlagen wir machen ein Teil Autogenerierer Map (ala Minecraft) und Teile der Map können von Spielern bezogen werden.

Meine Idee wäre das die Welt auf Wasser besteht. Und in der Welt können nun Inseln und Kontinente spawnen. Die Inseln/Kontinente können dabei autogeneriert werden oder Externe Maps von Mitspielern sein mit eigener Story.

Ich glaub damit kann man ein bissel von jedem machen und in das Let's Code einbringen und mich würde es auch am meisten reizen.

Wenn dir der Vorschlag gefallen sollte können wir das gerne mal in der Community besprechen, wenn nicht ist das alles auch kein Problem.

viele grüße
Developer
Jan 21, 2015 at 12:46 PM
Hallo zusammen,

Ich kann ich dem hier geschriebenen von alderschwede und Lassi nur anschließen, erst Map, dann Physik, UI und Extentions und Multiplayer, trotzdem sollte man alles so versuchen zu designen, das es nicht dem nächsten Schritt im weg steht oder neu geschrieben werden muss.
Ich denke auch keiner würde schlecht reden, wenn es eben mal mehrere Folgen dauert, bis eine neue Funktion steht, und man eben 2-3 Folgen braucht bis man was sieht.

Die Idee von Lassi, sich nicht so sehr nach dem "Vorbild" Minecraft zu richten ist bestimmt auch richtig, schließlich wollen wir ja etwas Neues machen und ein "Spiel" für Programmierer erschaffen. das mit den verschiedenen Kontinenten ist vlt auch eine ganz gut Idee, da sich so vlt. auch Spielinhalten von Strategiespielen einbringen lassen... Ich denke dabei jetzt nicht an irgend welche Echtzeitkriegssimulationen sondern eher an Ressourcen Gewinnung und vlt auch eine Art Globaler Marktwirtschaft, die von aller Mitspielern beeinflusst werden kann. Hier kommt vlt auch die Wichtigkeit von Extensions ins spiel, z.b. die Idee der freien Marktwirtschaft. es werden also Dinge wie eine Übersicht(Markthalle) und eine Währung benötigt. und genau diese Sachen könnten von Spielern selber per Extensions aufgebaut werden.
Vlt. stehe ich mit der Idee völlig alleine da, aber mich würde ein spiel, welches quasi in Echtzeit von Spielern erweitert werden kann und eigentlich keine Grenzen setzt wirklich freuen und vlt. legen wir damit ja auch den Grundstein für ein völlig neues Gerne :)

Es sind also noch unendlich viele Dinge zu entwickeln und ausarbeiten, lasst uns also Anfangen :9

Gruß PatteKi
Coordinator
Jan 26, 2015 at 4:18 PM
Hallo Leute,

geile Vorschläge! Die Idee mit den Spieler generierten Maps finde ich super. Gepaart mit der "runden" Welt (Zeitzonen und Klimazonen) könnte das Ganze echt vielseitig werden. Unter anderem deshalb, weil man vielleicht für unterschiedliche Rohstoffe echt weit reisen müsste. Das würde das globale Handelssystem, das Patte angesprochen hat, wichtig und cool machen.

Außerdem gerade per Email von Ralf rein gekommen die vermutlich geilste Idee was die Rechtfertigung des Namens angeht: Blöcke haben keine feste Größe, sondern sind pauschal erstmal sehr groß (vielleicht ein 100x100-Block) und werden dank Bearbeitung des Spielers bei jeder Bearbeitung "halbiert" - bei 3D bedeutet das eine Achtelung des Blocks. Das hat einerseits einen netten Komprimierungsaspekt und würde andererseits dem Spieler eine feiere Bauweise erlauben wo es notwendig ist.

Da muss ich zwar nochmal drüber nachdenken, weil dadurch das Level-Speicherkonzept sicher komplizierter wird und sicher auch weitere Nebeneffekte bei der Definition von Block-Typen birgt. Aber das sind wirklich tolle Ideen! Danke, danke, danke!

Aloha
Tom
Jan 26, 2015 at 10:12 PM
Hallo ihr ,

ich hätte da noch eine Idee es nicht wie in Minecraft aussehen zu lassen, so könnte man statt der Würfel ja auch Hexagone nehmen.
Macht zwar das das berechnen der Map und der Kollisionen etwas komplizierter, aber es würde sich so von Minecraft etwas abheben.

Hier ist ein Bild wie das aussehen könnte:

Image

ASSOLI
Jan 26, 2015 at 10:41 PM
Stilecht müsste das dann aber ein Oktagon sein, aber im Gegensatz zu einem Quadrat hätten wir direkt mal ein paar mehr Dreiecke an der Oberfläche.
Jan 27, 2015 at 7:35 AM
Bezüglich der "Runden" Welten ist mir im nachhinein zum Stream auch noch was eingefallen.

Bestimmt ist vielen das Spiel "No Man's Sky" bekannt, weiß jetzt nicht wie kompliziert das abspeichern wäre, aber wenn man schon Runde Welten hat, dann sollte doch auch eine art "Universum" möglich sein, (auch wenn es erst mal nur durch Tore von Planet zu Planet geht).

So könnte man so gesehen "Unendliche" Welten generieren (wenn wir mal einzig und allein bei der Integer Begrenzung bleiben und den Speicherplatz außen vor lassen, würde es bedeuten wir können im laufe des Spiels 4.294.967.295 Planeten generieren, die trotzdem jeweils nur der Integer Beschränkung unterliegen.

Viel Langsamer würde es das ganze ja an sich (außer der IO auf dem Server) ja nicht machen da man chunks von Planeten auf denen man sich nicht befinden ja nicht laden muss und auch nicht aus versehen in ihre nähe kommt.
Developer
Jan 27, 2015 at 8:36 AM
Guten Morgen

Das mit den Hexa-/Oktagonen klingt ganz net, glaube aber das sich das nur schwer verwirklichen oder zumindest das Ganze deutlich schwieriger werden lässt.
Alleine das bauen von einer einfachen Mauer wäre dann schon nicht mehr so einfach, bzw. es gäbe mehr oder weniger keine größeren geraden Flächen außer dem Boden.

Ich finde die Idee mit den Planeten auch genial und das mit den Toren erinnert mich das irgend wie an Stargates das würde vlt auch einem Ressourcen System zu gute kommen da so nicht alle Ressourcen überall vorhanden wären... aber vlt sollte man das im Hinterkopf behalten und sich erst mal darauf konzentrieren, eine "runde" Map hinzubekommen und später erst das System mit anderen Planeten zu erweitern. Aber generell bin ich ein großer Fan von solch "unbegrenzten" Welten.
Eine Idee, die mir jetzt noch so grade kommt: man könnte ja vlt auch statt einem großen Server viele kleine nehmen, um verschiedene Welten zu haben, man muss eben irgendwie sie mit einander verbinden, aber ich denke da würde uns schon was einfallen :)

Gruß PatteKi
Coordinator
Jan 27, 2015 at 9:22 AM
Wohooo. Jetzt gehts ja richtig ab hier! :)

Sechsecke
Interessanter Vorschlag mit den Sechsecken. Das würde auf alle Fälle einen frischen Wind rein bringen und den Stil entsprechend filigraner erscheinen lassen. Technisch wäre das ein wenig komplizierter. Wenn schon Sechseck, dann bitte auf allen Achsen ;) Also ein Oktaeder in diesem Fall. Und so schließt sich der Kreis, Beaucarigan. Ein Oktaeder ist quasi das dreidimensionale Gegenstück zur Raute.

Darüber habe ich bereits nachgedacht. Für den Erd-Abbau und das Terraforming wäre das tatsächlich denkbar. Allerdings liefert diese Form keine Möglichkeit einer flachen Ebene. Und das Problem all dieser komplexeren Körperformen ist das Konstruieren von Bauwerken. Quader/Würfel sind, wie PatteKi schon geschrieben hat, einfach die beste Möglichkeit schöne rechtwinklige Häuser zu bauen.

Ich mag unseren "Kompromiss" mit den 50cm Blöcken. Das wirkt automatisch filigraner als Minecraft, von daher moderner und detailreicher. Außerdem mag ich den Gedanken, dass man, wenn man einen 1m-Meter Block halbiert, 8 unserer 50cm-Blöcke bekommt - also achtfacher Spaß mit einem Block :D Für den Fall, dass das Abbauen dieser kleineren Blöcke zu mühsam ist, können wir ja Werkzeuge einführen, die einfach ein 2x2x2 oder 3x3x3 Grid auf einen Schlag abbauen können. Das gibt uns sogar noch viel mehr Möglichkeiten des Werkzeug-Craftings.

verschiedene Welten
Dass wir grundsätzlich eine Rundwelt wollen, find ich super. Das mit den Zeitzonen fand ich persönlich ein Meisterstück. Mal sehen, ob sich das auch so simpel realisieren lässt. Ich mache mir noch ein bisschen Sorgen um den Algorithmus, der die Welt generieren soll. Schließlich wollen wir ja, dass das Ende der Welt im Westen auch nahtlos an das Ostende passt. Naja... wir werden mal sehen wie es läuft.

Bezüglich EldoranDevs Vorschlag einfach weitere Planeten ins All zu klatschen, falls der Platz nicht reicht, find ich super. Das ist einerseits eine geile Möglichkeit die Welten voneinander zu trennen (und somit die Berechnung der Simulation bequem auf unterschiedliche Server auszulagern ohne mühsame Handovers). Andererseits eröffnet das dem Skill-/Crafting-/Maschinenbau Thema viiiiele, viiiiele neue Möglichkeiten. Schließlich braucht man erstmal Fusionsreaktoren, bevor man Raumschiffe oder Teleporter bauen kann.

Ihr habt hier echt super Ideen! Vielen Dank für euer Beiträge!!!

Cheers
Tom
Jan 27, 2015 at 4:42 PM
Hi,

also Oktaeder wären ja schon alleine vom Namen her passend zum Spiel eine Überlegung wert. Aber vermutlich sind die 50cm Blöcke doch der sinnvollere Kompromiss.

Habe mir inzwischen den "Live"stream angeschaut.
Eine runde Welt inkl. Zeitzonen und evtl. lokalem Wetter finde ich eine absolut geniale Vorstellung. Wenn das jetzt noch mehrere Planeten werden... Hammer!

Auch das Kapseln von Logik in die einzelnen Blöcke finde ich gut. Wasserblöcke die abhängig vom Wetter gefrieren können etc.

Habe ich das mit den Blöcken jetzt eigentlich richtig verstanden (habe Minecraft nie gespielt - sollte ich evtl. mal):
  • Die Kollision basiert immer auf einem ganzen Block, d.h. ein Zaun bspw. wird wohl nicht so dick dargestellt werden wie der ganze Block, oder doch? Somit würde die Kollision optisch schon kurz vor dem Zaun stattfinden. (Ich will nicht nörgeln, nur verstehen)
  • Und in der Höhe kann ich entweder auf höhere Blöcke drauf springen oder es gibt alternativ irgendwelche Rampen die mich beim drüber laufen hoch heben. Richtig?
Und zu der Frage im Stream ob es in Ordnung geht wenn du die Assemblies ohne Framework selber lädst: Wegen mir gerne. Mach ich auch immer so, is ja recht einfach machbar. Frage mich eher wie man das mit dem Unload von Assemblies macht (eigene App-Domain?) - oder starten wir dann den Service neu?

Aber bzgl. Extensions/Server würde mich viel mehr interessieren wie du dir da das Sicherheitskonzept vorstellst bzw. ob es überhaupt Möglichkeiten gibt da etwas zu machen.
Ich meine, wenn wir hier gemeinsam irgendwo zocken wollen brauchen wir auch einen gemeinsamen Server. Solange es sich hier noch um eine geringe Anzahl an Personen handelt kann ich mir das evtl. noch vorstellen. Aber sobald es an etwas größeres öffentlicheres geht frage ich mich, wer bitteschön freiwillig einen Server mitten im Netz hostet, auf den jeder beliebigen Code hoch laden und ausführen kann.

Viele Grüße
Alex
Coordinator
Jan 27, 2015 at 6:11 PM
Servus Alex,

du sprichst da ein paar wirklich wichtige Fragen an. Wie wir das am Ende machen werden, weiß ich noch nicht. Aber in meinem Kopf gibts natürlich schon ein paar Überlegungen:

Block-Kollision
Wie du schon schreibst, ist die Kollision für Blöcke erstmal immer gleich. Das würde in der Tat für Zäune und Blumen bedeuten, dass die Kollision für den Spieler trotzdem die volle Box bedeutet. Vorerst. Ich könnte mir vorstellen, dass im Falle von Spezial-Blöcken im Sonderfall der Block selbst eine Collision-Box liefert. Nutzt der Block das nicht, ist es die Default-Box. Aber im Falle einer Blume kann das eine kleinere Kiste sein, im Falle eines Zaunes auch eine wesentlich Höhere (Zäune in Minecraft beispielsweise sind auch höher als ein Block, damit man trotz niedrigem Erscheinungsbild trotzdem nicht drüber springen kann).

Unload und Security von Fremd-Assemblies
Ein wirklich superwichtiges Thema, wenn es um das Laden von anderen (nicht vertrauenswürdigen) Programmierern geht. Das betrifft nicht nur den Code für Server Extentions, als auch den Code, den man für seine Bots und Pets einfügen kann. Grundsätzlich funktioniert das in .NET mit AppDomains - da führt kein Weg dran vorbei. Die Frage ist nur, auf welcher Ebene wir die Kapselung machen (also jede Extention kapseln, auf Chunk-Ebene, auf Service-Ebene,...). Das müssen wir testen. In AntMe! beispielsweise läuft diese Kapselung pro Domain, weil die Kapselung auf KI-Ebene zu performance-hungrig war.
Feb 6, 2015 at 1:24 PM
Hallo,

ich hab gerade den neusten Commit auspobiert und war etwas Überrascht von der Physik von Adam. Ich weis nicht ob das was ich anspreche Tom schon in seinen Videos anspricht, wenn ja ist das Ok, aber wenn nicht ist hier schon mal ein bissel Input.

Also hier muss man aufjeden Fall aufpassen zwischen den Bewegungsarten verschiedener Objekte. Die jetzige "Physik" ist eher für eine rollende Fortbewegung bei der ist es sinnvoll mit Kräften zuarbeiten. Nur ist Adam kein Ball und rollt nicht.

Hier sollte man Zwei Zustände unterschieden die selbst Verursachte Bewegung und die Fremdverursachte Bewegung. Es ist dabei vielleicht Sinnvoll mit Leistungen zurechnen Adam hat eine bestimmte Leistung zurverfügung und will eine gewiße Zielgeschwindigkeit erreichen. De Bewegung erfogt daraus nahezus sofort, wenn diese denn mit der Leistung erreichbar ist. Im endeffekt gibt es eine Startgeschwindigkeit und wenn diese kleiner ist als die Zielgeschwindigkeit kann man eine nötige Beschleunigung/Kraft errechnen die zur Zielgeschwindigkeit führt. Umgekehrt ist es ähnlich.

Also man muss bei den Bewegungen aufpassen ob das Objekt selber bewegt oder nur Bewegt wird.

viele grüße
Lassi
Coordinator
Feb 6, 2015 at 2:02 PM
Hallo Lassi,

ich hab doch keinen Plan :D Also das was du gesehen hast, ist in der Tat der letzte Stand der "Physik". Die Unterscheidung zwischen Eigenantrieb und Fremdwirkung klingt schlüssig. Dennoch scheint mir der Weg über die Reibung (Unterscheidung zwischen Haft/Roll/bla-Reibung mal weggelassen) wesentlich realistischer als eine instant-Beschleunigung auf das Maximum.

Magst du das mal weiter ausführen? Ich würde jetzt nämlich im nächsten Schritt "nur noch" mit den Parametern spielen, damit das halbwegs vernünftig läuft.

Cheers
Tom
Feb 6, 2015 at 5:07 PM
Hallo,

Es ist auch realistischer und macht es später auch einfacher. Ich kann mich gerne darum kümmern, aber das Model mit Adam als Kugel ist etwas nahja.

viele grüße
Lassi
Feb 7, 2015 at 12:41 PM
Edited Feb 7, 2015 at 12:55 PM
Hallo,

vielleicht mal ein Grundkonzept. Adam hat folgende Eigenschaften
float Power = 50f;
float Mass = 100f;
vector3 Velocity,
vector3 VelocityDirection;
float Friction;
Das Grundkonzept ist eigentlich einfach Ausgangspunkt ist die kinetische Energie mit E = m/2 * v * v;
Umgetselltnach der Geschwindigkeit v = Sqrt( 2/m * E). E ist das Integral der Leistung über die Zeit.

Durch die Umwandlung des Integral in eine Summe kann man die Geschwindigkeit als Rekrusiveformel darstellen.
v[n] = v[n-1] + sqrt( 2/m * P * delta_t). Weil aber P durch die höhere Geschwindigkeit durch die Reibung immer kleiner wird, bekommt man.

v[n] = v[n-1] + sqrt( 2/m * (P - F * v[n-1]) * delta_t). Und das kann man zur berechnung der Geschwindigkeit nehmen.
Angle += (float)frameTime.ElapsedGameTime.TotalSeconds * input.HeadX;

float lookX = (float)Math.Cos(Angle);
float lookY = (float)Math.Sin(Angle);



var VelocityDirection = new Vector3(lookX, lookY,0 ) * input.MoveY;
float stafeX = (float)Math.Cos(Angle + MathHelper.PiOver2);
float stafeY = (float)Math.Sin(Angle + MathHelper.PiOver2);
VelocityDirection += new Vector3(stafeX, stafeY,0 ) * input.MoveX;

float Friction = 10;

Vector3 powerdirection = Power * VelocityDirection;

Vector3 VelocityChange = 2.0f / Mass * (powerdirection - Friction * Velocity);

Velocity += new Vector3((float)(VelocityChange.X < 0 ? -Math.Sqrt(-VelocityChange.X) : Math.Sqrt(VelocityChange.X))
           ,(float)(VelocityChange.Y< 0 ? -Math.Sqrt(-VelocityChange.Y) : Math.Sqrt(VelocityChange.Y))
           ,(float)(VelocityChange.Z< 0 ? -Math.Sqrt(-VelocityChange.Z) : Math.Sqrt(VelocityChange.Z)));
Die letzte Zeile ist sokompliziert, weil man durch die Wurzel ins Komplexe kommen würde.

Aus diesen Werten kann man jetzt auch Energieanteile berechnen in welche Richtung diese Verteilt sind. Wenn man kleine Friction einsetzt sieht man auch das die Berechnung näherungsweise korrekt sind. Für ein Sprung müsste nur die VelocityDirection verändert werden so das diese für den kurzen Moment nach oben Zeigt.

Es ist vielleicht auch Sinnvoll für die Reibung auch als Vektor darzustellen. Mit den Werten müsste man zwar etwas rumspielen aber dann sollte es gut laufen.

Die Fallbeschleunigung muss am besten in der World geschehen, weil dafür natürlich Kollisionen notwendig sind. Die Fallbeschleunigung wird dann nur noch von der Geschwindigkeit abgezogen.

viele grüße
Lassi

PS: Diese + ist ein Plus keine Plan warum das so ist
Coordinator
Feb 7, 2015 at 7:39 PM
Edited Feb 7, 2015 at 7:39 PM
Servus Lassi,

sehr geil! Ist in Folge 59 eingebaut und funktioniert einwandfrei.
Herzlichen Dank für den super Lösungsansatz.

Cheers
Tom
Feb 8, 2015 at 8:11 PM
Hi,

schön, aber ein Haken hat die Geschichte. Also Schande über mein Haupt.

Ist mir im Video aufgefallen das ich hab eine Zeit unterschlagen habe.
VelocityChange *= (float)frameTime.ElapsedGameTime.TotalSeconds
Diese Zeit müsste noch rein, also noch vor der Berrechnung der Geschwindigkeit.
Also so sieht es.
Vector3 VelocityChange = 2.0f / Mass * (powerdirection - Friction * Velocity);
VelocityChange *= (float)frameTime.ElapsedGameTime.TotalSeconds;
Die muss woll irgendwo beim Aufräumen verschwunden sein. Adam bewegt sich bei der Updaterate um den Faktor 10 zu schnell.
Sry.


vielen Dank
Lassi