2D Spiele Engine Programmieren

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von ~blaze~.

    2D Spiele Engine Programmieren

    Moin ich mal wider :D

    Ich habe mir grade so gedacht wie würde man denn eine 2D Engine in vb.net am besten basteln, die auch ohne Programmier Kenntnisse funktioniert.
    Natürlich will ich jetzt keine HD 3D Engine programmieren, nur 2D und das über Sprites (Bilder) und Simplen Hitboxen. Außerdem soll die dann nur zum Jump'N'Run gedacht sein.
    So ich habe mir jetzt mal ein beispiel an GameMaker 8.1 (Engine (Wenn man's eine Engine nen kann :D)) gemacht. Das ist aber zu kompliziert für leute die nur ein eigenes Jump'N'Run erstellen wollen. Und ich hab nichts gefunden in der gleichen, also möchte ich das selbst in der Hand nähmen. Kurz um: Jump'N'Run Baukasten für leute die nicht Programmieren können mit Windows build (Also das man das Exportieren kann als eigenes spiel).

    Ich weis leider nur nicht wo ich da anfangen kann ?(

    *Topic verschoben*
    MfG, Martin

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Das bedeutet du willst so eine richtig schön einfache klicki-bunti Oberfläche wo man ohne irgendwelchen Code ein "Spiel" basteln kann?
    Das wird ganz schrecklich enden, denn es gibt jetzt schon genug Müll auf dem Spielemarkt... aber das ist nur meine Meinung.
    BTT: Willst du hier eine Komplette Engineer entwickeln? Oder willst du etwas entwickeln womit man sich ein paar Codeschnippsel zurecht klicken kann, die dann evtl noch mit ein paar Eigenschaften versehen und den C# Code dann in Unity o.ä einfügen kann?

    Gelöschter Benutzer schrieb:

    aber das ist nur meine Meinung
    Nein, sehe ich ganz genauso.

    Sieber Max Produktion schrieb:

    auch ohne Programmier Kenntnisse funktioniert
    Dann muss man es sein lassen. Man kann nicht alles haben. Ich kann auch kein Auto bauen, ohne zu wissen, wie es funktioniert oder was ich benötige. Wenn man nun mal ein Spiel entwickelt, dann muss man auch Ahnung von der Materie haben. Das fängt dann an mit der Mathematik dahinter, Physik, Rendertechniken etc.
    Insofern kannst Du eine Engine bauen, die das alles zur Verfügung stellt. Das wäre sinnvoll. Kennst Du Sharpex von ThuCommix?

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Trade schrieb:

    [...]
    Wenn man nun mal ein Spiel entwickelt, dann muss man auch Ahnung von der Materie haben. Das fängt dann an mit der Mathematik dahinter, Physik, Rendertechniken etc.
    [...]

    Nope, bestes Gegenbeispiel: Ubisoft. Versuch nicht mir zu erklären, dass sie wüssten was sie da tun :D
    Spaß beiseite: Das ist so Unsinn, siehe Unity. Hier kannst du ohne eine Zeile Code Physik-Puzzles basteln. Keine Mathematik, keine Physik, kein Rendering, nichts muss man dazu können.
    Da hast Du recht. ;) Aber spätestens dann, wenn man diverse Logik ins Spiel bringen will, muss man eben auch auf Skripte zurückgreifen und die grundlegenden Prinzipien verstehen. Mag sein, dass ich da paar Prefabs in die Welt setzen kann und die schon Einstellungen haben, die mir das erleichtern. Aber wirklich viel kann man damit halt nicht anstellen. Klar, mag auch Sachen wie die Event Graphs (Unity hat sie glaub nicht, aber Unreal z. B.) oder Waypoints geben, mit denen man einiges machen kann, aber das ist halt nicht die Lösung für alles. Und selbst da muss man auch etwas Wissen über die Techniken und Strukturen mitbringen.
    Was ich sagen will ist: Du kannst natürlich diverse Dinge auch ohne großartige Programmierkenntnisse machen, aber Du wirst nicht drumrumkommen, auch mal ein Skript zu schreiben, wenn es ordentlich werden soll.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    @Trade Das ding ist ich glaub da hast du etwas miss verstanden ;) Ich hab ja "Kenntnisse" jetzt nicht alle :D aber ich meine das irgendein typ ein Jump And Run erstellen kann für sich und seine freunde und das ohne Programmier kenntnisse. Also wie in Blender mit Logic Bricks. oder so, also einfach z.B wen man sagt das wenn "D" gedrückt wird das er dann auch nach Rechts gehen soll und halt auch mit einer Geschwindigkeit die der nutzer will.
    MfG, Martin
    Vielleicht fängst du mit nem Level Editor im Super Mario Style an? Wär doch auch schon mal was... Was welcher Knopf macht und so wäre dann fix.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    @Sieber Max Produktion Das habe ich dann durchaus richtig verstanden.

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:
    @mrMo Wäre eine Idee. Nur darf ich das denn in Super Mario Style? Ich meine da ist ja ein Copyright drauf, nicht das es da Probleme mit Nintendo gibt. Die sind in solchen dingen ja immer Agro.
    MfG, Martin
    Nur vom Prinzip her, keine 1:1 Kopie. Und im Privatbereich ist das alles eh kein Problem.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    iKameo schrieb:

    Willst du hier eine Komplette Engineer entwickeln? Oder willst du etwas entwickeln womit man sich ein paar Codeschnippsel zurecht klicken kann, die dann evtl noch mit ein paar Eigenschaften versehen und den C# Code dann in Unity o.ä einfügen kann?
    Naja ich möchte die dann ja am ende auch öffentlich stellen obwohl ich ja nur erstmal eine version für mich erstellen könnte und die dann halt kopieren nur mich anderen Ressourcen.

    Gelöschter Benutzer schrieb:

    iKameo schrieb:

    Willst du hier eine Komplette Engineer entwickeln? Oder willst du etwas entwickeln womit man sich ein paar Codeschnippsel zurecht klicken kann, die dann evtl noch mit ein paar Eigenschaften versehen und den C# Code dann in Unity o.ä einfügen kann?
    Ehmm... eher eigene Engine wenn man das denn so nennen darf. Es soll ja eher nur ein Jump'N'Run Editor für NP's sein.
    MfG, Martin
    Naja ich möchte die dann ja am ende auch öffentlich stellen
    wie gesagt, keine 1:1 Kopie, sondern an Super Mario angelehnt. Halt im Jump 'n run Style. Ist doch eh alles relativ ähnlich... Mach halt keinen Klempner sondern nen Hasen oder was weiß ich ;)
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Mach dir Mal über Copyright keine Gedanken, nimm einfach irgendwelche Platzhalter, das ist das kleinste Probleme, erstmal muss die Funktion stehen.

    @Zitat Antwort:
    Okay, was bist du den so für ein Typ? Ehr so der Picturebox verschieber oder der GDI+ Zeichner? :)
    Und bedenke, bei Jump n Run, gehört schon etwas Physik dazu, oder besser, Schwerkraft
    Hi
    wenn es wirklich ein sinnvolles Jump'n'run sein sollte, bist du ganz schnell in - für schulische Verhältnisse - schwierigen Gefilden unterwegs.
    Du hast
    - Rendering
    - Physik (mindestens Kollisionserkennung, Simulation von Kräften und am besten auch noch Reibung)
    - Gameplay
    - Input (Maus, Tastatur, Joystick)
    - Animation
    - Audio/Sound

    Fürs Rendering würde ich DirectX empfehlen. Da das dir vmtl. erst mal zu schwer ist, fang' am besten mit den Sachen aus System.Drawing an (d.h. Graphics und ~.Drawing2D, usw.). Beginne damit, eine anständig verwaltbare Hierarchie aufzubauen, mit der du die zu zeichnenden Einheiten (ich nenne sie jetzt einfach Renderable) verwaltest. Ich würde dazu tendieren, eine abstrakte Methode Draw einzubauen, über die sich das Element selbst zeichnet und außerdem eine Funktion, die die Abmessungen des Objekts zurückgibt (als Rechteck).

    Für die Physik würde ich für dein Vorhaben empfehlen, dass du die Klasse dann um jene physikalische Eigenschaften erweiterst, die du benötigst, d.h. zumindest Masse und, falls du Rotationen drin hast, Trägheit. Da das Thema Trägheit zu kompliziert ist, beschränke dich vorerst auf Masse. Für die "korrekt" aussehende Physik benötigst du allerdings später Trägheit, da z.B. versetzte Boxen sich rotieren.
    Insgesamt sind elementare Grundlagen nötig in Vektorrechnung, du solltest z.B. wissen, wie man einen Punkt um einen Punkt rotiert (kann man über die Matrix machen, die Drawing hergibt), wie man einen Punkt um einen Vektor verschiebt, wie man ihn skaliert, usw.

    Ich würde jetzt einfach mal sagen, dass die Physik der komplizierteste Teil des Systems ist - selbst für ein einfaches System.
    Du hast folgende Probleme zu klären:
    1. Wie erkenne ich eine Kollision zweier Objekte? Du hast nur die Rechtecke und genauere Informationen, die du dir selbst berechnen musst (die Rechtecke musst du natürlich auch selbst berechnen)
    2. Wie reagiere ich auf eine Kollision?

    Der erste Punkt ist sehr umfangreich, der zweite hängt vom ersten Punkt ab, du hast aber auf jeden Fall den Impulserhaltungssatz.
    Für die Kollisionserkennung brauchst du wiederum ein Verfahren, das dir die neue Position der Objekte angibt. Du hast folgende Informationen über den Vorgang: Zeit (entweder die Zeit, die seit dem letzten Physik-Schritt vergangen ist oder eine fixe Konstante), Geschwindigkeit (musst du dem Objekt hinzufügen), Ort (ergibt sich z.B. aus den Punkten des Rechtecks), Kraft (Gravitation und sonstige Kräfte, die du dem System hinzufügst).
    Die einfachste Lösung wäre, Gravitation zeigt immer nach unten, d.h. du hast eine konstante Beschleunigung von z.B.
    $g = -9,81 \frac{\mathrm{m}}{\mathrm{s^2}}$
    . Damit würde es genügen, das Objekt direkt unterhalb des Renderables zu bestimmen (das sich aber selbst ebenfalls bewegen kann! D.h. du solltest überlegen, erst mal vorweg zu simulieren, wo sich die Objekte nach einem Physik-Schritt befinden werden und dann auf Kollisionen testen).
    Komplizierter geht immer, aber das lasse ich jetzt vorerst mal weg.
    Also zusammengefasst:
    • Simuliere einen Physikschritt (Erinnerung:
      $x(t) = \frac{1}{2} a t^2 + v_0 t + x_0$
      , wobei x der Vektor der Position ist. Daraus ableiten lässt sich
      $v(t) = a t + v_0$
      . Die Formeln sind für den Fall, dass
      $|a| = g$
      , bzw. a konstant (und a zeigt nach unten))
      Du kannst vereinfachend annehmen, dass sich die Geschwindigkeit innerhalb eines Intervalls nicht durchgehend ändert, d.h. einfach sagen, dass die neue Geschwindigkeit sich zu
      $v_{n+1} = v_n + at$
      ergibt. Beachte, dass das alles auf Vektoren basiert.
      $v_i$
      und a sind Vektoren, t nicht.
    • Teste auf Kollisionen
      Teste erst mal, ob im neuen Physikschritt Rechtecke kollidieren und verfeinere diese Resultate danach. Das liefert zwar für schnelle Bewegungen massiv inakkurate Ergebnisse, ist aber schon mal besser, als nichts. Wenn du das hast, sag' Bescheid. Wenn du eine Kollision festgestellt hast, finde die Richtung, aus der die Kollision geschehen ist (kannst du über die Bewegungsrichtungen ermitteln) und den Kollisionszeitpunkt. Führe anschließend die Berechnung des Impulses für ellastische Stöße durch (die benötigten Konstanten musst du wieder auf dem Renderable bereitstellen) und leite daraus die neuen Geschwindigkeiten ab. Aus den neuen Geschwindigkeiten kannst du dann den neuen Ort bestimmen.

    Um es komplizierter und besser zu machen, kannst du auch z.B. (wir haben Euler verwendet, um die neue Position zu berechnen) Heun oder Runge-Kutta verwenden. IdR. würde man statt einem Eulerschritt das Bocksprung-Verfahren verwenden (ist aber nur akkurat für feste Zeitintervalle), aber das halte ich vorerst für übertrieben.
    Für die Kollisionserkennung: Du hast Tunneling, wenn du relativ schnelle Bewegungen hast (bzw. schon bei langsamen Bewegungen, wenn es blöd läuft und die Genauigkeit ist stark von der Größe der Objekte abhängig). Beliebte Lösungsansätze sind Bounding-Volume-Hierarchien (Rectangle ist bspw. ein bounding volume für genauere Objekte, wie bspw. eine Spielfigur - Z.B. kann ein Kreis alle n-Ecke enthalten. Es geht dabei darum, möglichst schnell eine Aussage treffen zu können, wenn ein Objekt sich definitiv nicht mit einem anderen überlappt.) oder swept shapes oder wie die Teile heißen (man verfolgt die Bewegung quasi nach, indem man die vom Objekt im Physikschritt überstrichenen Punkte testet). Außerdem optimiert man häufig über verschiedene Datenstrukturen die Kollisionstests, z.B. Binary-Space-Partitioning-Trees oder die Vereinfachung davon, k-d-trees oder nochmal eine Vereinfachung davon, Quadtrees, wobei BSP-Trees tatsächlich das beste Verhalten aufweisen dürften, auch wenn die Erstellung recht kompliziert ist.
    Es lohnt sich außerdem, die Punkte, an denen die Objekte kollidieren, zumindest abzuschätzen. D.h. man berechnet ungefähr Zeit und Ort eines Kollisionsauftritts, sobald man eine Kollision erwartet. Sobald man diesen Punkt (/diese Punkte) gefunden hat, kann man die Impulserhaltung durchführen. Hierzu wird eben der Trägheitsmoment (engl. inertia tensor, ist einfach nur ein reeller Wert für 2D-Objekte, für 3D-Objekte wäre das eine Matrix) benötigt und man berechnet die neuen Werte für die Winkelgeschwindigkeit, Geschwindigkeit, Rotation und Ort. Insgesamt ist es natürlich noch etwas komplizierter, va. weil die Mathematik dahinter die Schulmathematik weit übersteigt


    Für's Gameplay würde ich die Ziele benötigen, aber wenn du soweit bist, kannst du das vmtl. schon selbst, ansonsten melde dich dann nochmal, wenn du soweit bist.

    Für Input würde ich dir später Raw-Input und für die jeweilige Situation entsprechende Tools empfehlen. Beginne aber erst mal nur mit Maus und Tastatur, dafür reicht dir ja das Zeug, was die Form an sich mitbringt. Die Bewegungen sollten flüssig sein.

    Wenn das läuft, geht's wieder an etwas nicht ganz einfaches, das sehr stark mit der Physik zusammenspielt. Du bewegst die Objekte selbst, d.h. du rotierst deine Bounding-Volumes, um die du zu diesem Zeitpunkt wohl nicht mehr rumkommst. Zusätzlich dazu hast du Sprites, die die Bewegungen darstellen (und von denen die Bounding-Volumes abhängen).
    Zur Erinnerung: Bounding-Volumes sind Vereinfachungen der enthaltenen Objekte (schau' dafür in den ausgegrauten Text).

    Für Audio genügt dir vmtl. XAudio2. Die aktuellste Technologie wechselt quasi dauernd durch, weil ständig etwas neues kommt. Ich bin da auch nicht auf dem letzten Stand.

    Insgesamt hilft dir sicherlich folgende Liste
    - Beginne klein, d.h. beginne mit etwas im Stil von Pokemon (bis Feuerrot/Blattgrün), wo du feste Felder hast, mit festen Blöcken, die besuchbar oder nicht besuchbar sind
    - Mache es etwas komplizierter und entferne die feste Blockgröße (z.B. im Stil der alten Zelda-Spiele, bei denen man auch diese isometrische Ansicht hatte und die Figur sich aber quasi beliebig hat bewegen lassen)
    - Drehe die Ansicht, sodass Sprünge, usw. erkannt werden
    - Baue nach und nach die Elemente ein, die du benötigst. Schreibe immer kleine Prototypen, mit denen du bestimmte Verhaltensweisen testen kannst und setze das Spiel nach-und-nach zusammen
    - Frage nach, wenn du etwas nicht verstehst/nicht verstanden hast. Aber setze dich auch erst mal hin und versuch' zu verstehen, was du vor dir hast. Ich würde dir z.B. nicht alles vorkauen.

    Viele Grüße
    ~blaze~
    Die haben das halt quasi in dieser Art implementiert, aber es geht anscheinend ja nicht darum, ein Spiel zu programmieren, sondern auch die Logik dahinter. Die Aufgabe lautet ja "2D Engine [...] basteln", insofern geht es um was anderes.

    Übrigens bitte nicht auf zu alte Themen antworten, außer es besteht eine Frage, die nicht sinnvoller in ein neues Thema gepackt werden sollte.
    Ansonsten einfach einen neuen Thread eröffnen.

    ~blaze~: Thema geschlossen

    Viele Grüße
    ~blaze~