Unity3D

    This site uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More details

      Ich habe vor einiger Zeit den Entschluss gefasst, Programmieren zu lernen und dachte mir natürlich "bevor ich jetzt monatelang Scriptprogramme nachprogrammiere, um dann irgendwann mal Pong selbst schreiben zu können, machste direkt etwas, was ein wenig mehr Spaß machen dürfte", daher wollte ich gerne direkt mit einem Spiel anfangen und nicht erst bei "Hello World" beginnen. Was die Lernkurve angeht, wäre es sicherlich klüger, klein anzufangen und sich dann langsam hoch zu arbeiten. Aber wie ich mich kenne, würde ich dann schnell die Lust verlieren und das Ganze würde im Sand verlaufen.

      Daher habe ich mir die kostenlose Game-Engine Unity3D herunter geladen und habe nun, nach einiger Einarbeitung und ein paar Grundlagen JavaScript, angefangen etwas zu basteln. Und da ich nach wie vor ein riesiger Fan des altbekannter WipeOut 2097 bin, habe ich natürlich den Plan gefasst, einen WipeOut-Klon selbst zu basteln.

      Sicherlich gibt es noch einen ganzen Rattenschwanz von Problemen und Schwierigkeiten, aber naja. Erste Erfolge sind sichtbar. Ich wollte in diesem Thread nun mal rumfragen, wer mit Unity3D, Javascript oder generell mit dem Programmieren eigener Spiele vielleicht schon etwas Erfahrung hat. Ich stehe da selbst noch ganz am Anfang, würde mich aber wohl gerne austauschen.

      Es gibt natürlich auch Foren speziell zu diesen Dingen, aber ich dachte, ich versuche es erstmal hier, wo ich die meisten Leute ja schon kenne. :)
      Lang lebe König Staublin, Herr der Mummers vom geheimnisvollen Volk der Doom.
      Das Programmieren eines Spiels ist immer so eine Sache, gerne unterschätzt man ja, was man alles braucht. Aber ich will dich nicht davon abhalten, ich finde es gut, sich so gewissermaßen auch damit auseinanderzusetzen, wie denn die Kiste vor einem eigentlich tickt. So, und ich hoffe, ich werde jetzt nicht zu tief ins Thema einsteigen, aber ich warne schon mal vor: Ich studiere zur Zeit Informatik und hoffentlich schaffe ich es, nicht zu sehr ins Detail bei manchen Dingen mich zu verlieren.

      Was die Programmiersprache angeht, hab ich schon mal mit nen paar Komilitonen oft darüber diskutiert, was die perfekte Sprache für den Einstieg ist. Bisher leider kein Ergebnis... Aber das ist auch nicht ganz einfach. Ich finde, eine Einstiegssprache sollte es vermeiden, den Programmierer zu überfordern, vor allem am Anfang passiert das ja schnell. Eine Sprache wie C, wo man quasi alles von Hand machen muss, eignet sich also eher schlecht. C ist zwar sehr mächtig, aber das große Problem ist, dass die Sprache an sich einem nicht so sehr hilft, gute Programme zu schreiben. Speicher vor allem muss selbst verwaltet werden und wenn man einmal nen Fehler macht: Bum, crash, das Programm bricht ab. Sprachen wie C#, Visual Basic oder Java bringen beispielsweise automatische Speicherverwaltung mit, ihnen wird aber nachgesagt, langsamer als C zu sein. An sich kommt es aber vor allem darauf an, wie gut jemand programmieren kann und nicht wie schnell eine Sprache an sich ist, wenns am Ende um Performance geht. Vor allem heute, wo quasi Rechenzeit kein Problem mehr ist.
      Visual Basic und C# finde ich allerdings als nur auf Windows ausgelegte Sprachen (ok, hauptsächlich) als etwas zwiespältig... und es gibt schönere Alternativen.
      Java ist sicher zwar eine Sprache mit guten Gedanken dahinter, allerdings hat bestimmt jeder schon von all den Sicherheitslücken in den JavaVMs gehört, außerdem sind manche Dinge da nicht so gut zu schreiben.
      Nun hast du dir JavaScript ausgesucht. Vorweg, falls du es noch nicht weißt: JavaScript hat bis auf den Namen erst mal nichts mit Java zu tun. Nur zur Info ;) An sich ist das gar keine so schlechte Wahl, da JavaScript sich auf jedem Rechner ausführen lässt (ok, du brauchst nen WebBrowser, aber wer hat das heute schon nicht?) und man sich so nicht mit komplizierten Compile-Prozessen rumschlagen muss (C wird beispielsweise unter Unix zuerst von einem Programm namens "make" compilet, was zwar selber nichts großes macht, aber jede Codedatei, welche geändert wurde, an den C-Compiler schickt, welcher das ganze dann in Assemblercode überführt, der dann eigentlich automatisch in Maschinencode übersetzt wird, um dann am Ende das ganze vom Linker zu einem Programm zusammenzulinken). JavaScript hat außerdem ein schwaches Typsystem. Hier schneiden sich die Geister, ob das gut oder schlecht ist. Für den Anfänger ist das sicherlich erstmal eine Hürde weniger, die er lernen muss, auf der anderen Seite kann sowas schnell zu unsauberen Programmen führen, was einen später lange Abende mit einem Debugger beschehren kann. Aber lass dich nicht abschrecken, was du einfach vermeiden solltest ist, zu generische Namen für deine Variablen zu verwenden (beispielsweise kann es schnell nach hinten los gehen, wenn man in seinem Programm zu viele Variablen namens temp, tmp oder ähnliches hat - erstens weiß man nicht, was diese machen, zweitens überschreibt man sie schnell mit einer anderen, wenn man Code von einer Stelle zu einer anderen verschiebt/kopiert). Eine stark typisierte Sprache würde sowas in den meisten Fällen abfangen und einen Fehler anzeigen. So, das soll es über verschiedene Programmiersprachen sein.

      Was das Programmieren von Spielen angeht, so habe ich doch ein wenig Erfahrung, und die sagt vor allem eins: Geduld und Ausdauer zahlen sich aus. Ich habe beispielsweise mal vor einigen Jahren eine digitale Version von dem Brettspiel Roborally erstellt. Insgesamt habe ich da wohl ein halbes Jahr neben der Schule immer wieder dran gearbeitet, mal mehr, mal weniger. In den Sommerferien hab ich natürlich gut was schaffen können, aber auch das brauchte seine Tage. Vor allem, wenn man was zum ersten mal macht, ist sowas schwer. Aber es ist schon geil, wenn man nach 2 Tagen probieren endlich Kantenglättung aktiviert bekommt im Grafiktreiber (vom eigenen Code aus, nicht irgendwie über die Treiberoptionen in der Systemsteuerung, das sehen dann andere ja nicht) oder nach ich glaub einer Woche allen Robotern in Roborally dynamisch generiterte Schatten verpasst. Schatten verbessern das Feeling von 3D halt einfach enorm^^ Leider ist das Projekt etwas eingeschlafen, da ich zum einen nicht mehr mit Delphi unter Windows so viel programmiere, zum anderen fehlten auch Leute, die es mit einem testen wollten, vor allem, wenn die Netzwerkunterstützung des Spiels gerne Asynchron wird... Nur wie soll ich die Fehler suchen, wenn keiner mit mir testet? Naja, schade, heute habe ich andere Projekte.

      So, das war jetzt langsam mal genug. Aber ich hoffe, ich konnte ein paar Informationen über das, was ich so gelernt habe, teilen. Auch wenn ich Unity3D nicht an sich kenne, denke ich, das JavaScript schon mal ganz gut als Einstieg sein kann. Ansonsten wünsch ich dir viel Erfolg mit deinem Projekt, auch wenns manchmal so scheint, als würde man selbst nach Stundenlangem starren auf den Code und rumprobieren nicht weiter kommen. Aber je mehr Erfahrung man sammelt, desto besser wird es werden ;)
      You are (not) alone
      Ja, es ist auf jeden Fall extrem aufwändig, ein Spiel zu programmieren. Auch, wenn ich gerade erst am Anfang stehe, ist mir das schon mehr als bewusst. Allerdings bin ich (noch) recht guter Dinge, da ich durchaus Fortschritte mache. Wenn auch langsam. Mein kleiner Gleiter schwebt bereits schön stabil über dem Boden, die Lenkung klappt mittlerweile auch sehr gut. Nur beschleunigt und bremst er noch deutlich zu stark. Da muss ich mal schauen, wie ich das löse. Und die Rotation als Anpassung an die Normalen des Untergrundes, damit er schön parallel zum Boden ist, ist noch so eine Sache. Naja, wird schon werden. :)

      Ich habe mich für Unity3D als Engine entschieden, weil ich an verschiedenen Stellen gelesen habe, dass Unity3D wohl für Einsteiger ganz gut zu bewältigen sein soll und dennoch einen ordentlichen Funktionsumfang mitbringt. Kann ich beides bisher wohl bestätigen, auch wenn ich gerade erst an der Oberfläche kratze.
      Und in JavaScript schreibe ich momentan, weil Unity3D nur eine bestimmte Auswahl an Programmiersprachen unterstützt, darunter eben JavaScript und C#. C++ zum Beispiel wird nicht unterstützt. Nicht, dass ich mich da ran gewagt hätte. ;)

      Naja, wie gesagt komme ich momentan ganz gut voran und bin guter Dinge, dass ich die Probleme bei Steuerung und Rotation des Gleiters auch noch lösen werde. Natürlich sind meine Möglichkeiten aufgrund der noch sehr, sehr minimalen Programmierkenntnisse begrenzt, aber ich lese viele Beschreibungen, Scripte und Tutorials.
      Lang lebe König Staublin, Herr der Mummers vom geheimnisvollen Volk der Doom.
      So, zum Beginn des Tages mal eine gute Nachricht: das Rotationsproblem ist geschafft. Mein kleiner Gleiter schwebt jetzt immer schön parallel zum Untergrund, also hebt beispielsweise auch das Näschen, wenn es eine Steigung hinauf geht. Heute Nachmittag, nach der Arbeit, werde ich mich dann mal dran machen, Beschleunigung und Bremsung zu korrigieren, damit er nicht mehr nach vorne schießt wie die Enterprise und bremst wie ein Panzer.
      Lang lebe König Staublin, Herr der Mummers vom geheimnisvollen Volk der Doom.
      Ja, es gibt doch nichts schöneres, als selbst einen Fehler zu berichtigen oder etwas zum laufen zu bringen. Das ist wohl einer der Gründe, warum ich programmiere - um diesen Moment immer wieder zu beschwören. Doof ist nur, wenn man irgendwann mehr mit dem, was man gebaut hat, rumspielt, als daran weiter zu arbeiten ;)
      You are (not) alone
      Ja, es gibt doch nichts schöneres, als selbst einen Fehler zu berichtigen oder etwas zum laufen zu bringen.
      Allerdings. Ein schönes Gefühl. :) Habe gestern auch wieder ein bisschen was geschafft. Die zu starke Beschleunigung und Bremswirkung habe ich korrigiert. Musste mein ganzes Script zur Seuerung noch mal komplett umbauen, aber jetzt läuft es rund. Uuuuund ich habe nun endlich eine funktionierende Kollisionserkennung. Da gab es auch zuletzt ein paar Problemchen mit, weil meine Collider zum Beispiel nicht vom Boden abgeprallt, sondern darin stecken geblieben sind wie in tiefem Schlamm. Bei statischen Objekte wiederum wurde der Gleiter zuletzt entweder gar nicht als Kollisionsobjekt erkannt, ist also gerade hindurch gerast, oder er wurde bei der Kollision innerhalb einer halben Sekunde hunderte Meter hoch senkrecht in dei Luft geschleudert. Naja, das klappt jetzt jedenfalls auch alles wunderbar. Die Collider werde ich in der Form noch etwas besser an den Gleiter anpassen (das ist alles noch etwas sehr grob), aber immerhin funktioniert alles.

      Die nächsten Punkte auf meiner Liste, mit denen ich mich befassen werde, ist zum einen die Erstellung korrekter UV-Maps, damit mein kleiner Gleiter auch optisch endlich mal ein bisschen was her macht (bisher ist er nur schlicht zweifarbig) und zum anderen fange ich mit einem neuen Script an, das mir einen Countdown vor dem Start und die Messung der Rundenzeit ermöglicht.

      Ach ja, kennt zufällig jemand eine Seite, wo ich ein gutes, loop-fähiges Triebswerksgeräusch à la WipeOut her bekomme? Im Grunde ist das ja nicht mehr als ein dezentes Zischen, aber ich habe leider bisher noch nichts passendes gefunden. Zumindest nichts loop-fähiges (ohne Aussetzer oder Tonspitzen, wenn die Tonspur von vorne beginnt)...
      Lang lebe König Staublin, Herr der Mummers vom geheimnisvollen Volk der Doom.
      Hmm, was so nen Triebwerk angeht... ich hab früher meist es nicht geschafft, bis zum Sound zu kommen, das Bild hat da schon gereicht - vor allem, da ich finde, das man Bilder leichter selber erzeugen kann. Inzwischen schreibe ich eher an anderen Dingen, die zur Zeit auch gute Chancen haben, was zu werden. Aber zu deinem Problem:

      Wenn du was hast, wo der Anfang an sich gut ist, es aber nicht looped, mach doch folgendes:
      Wenn wir unser Geräusch als Welle mit W(t) auffassen, wobei t zwischen 0 und 1 unser gesamter Zeitraum is, bau dir nen neues Tonsignal mit
      V(t) = (1-t) * W(t) - t * W(1-t)
      Oder anders ausgedrückt: Fade dein Ursprungssignal aus, während du gleichzeitig es invertiert (also negiert), rückwärtslaufended einfadest. So erreichst du, dass du an den Enden V(1) = V(0) hast und damit das nahtlos übergeht - ich weiß bloß nicht, was in der Mitte genau passiert, vielleicht kommts da zu Stille oder überlagerung. Kommt wahrscheinlich auf dein Ursprungssignal drauf an. Aber es wäre eine Idee, Ton nahtlos zu machen, vielleicht bringt dir das ja was.
      You are (not) alone
      V(t) = (1-t) * W(t) - t * W(1-t)

      Das liefert natürlich nur dann das gewünschte V(0)=V(1), wenn man den Betrag des Ergebnisses bestimmt.
      also:
      V(t) = |(1-t) * W(t) - t * W(1-t)|

      Und ja, in der Mitte wird es für jede Funktion stumm (einfach für t=0,5 mal selbst ausrechnen, ist dann vom genauen W(t) unabhängig immer gleich null).

      Falls das ein Problem darstellt, wird der ganze Ansatz für die Formel oben problematisch, glaub ich. Denn eine Zickzackfunktion wird das wie gesagt nur durch Betragbildung und dann auch nur, wenn die Funktion bei t=0,5 durch V=0 geht. Und vielleicht will Aegon lebt! ja auch gar nicht die Lautstärke variieren (kann man denk ich auch bequem vorher, indem man an W(t) rumschraubt).

      andere Möglichkeiten:
      Eine periodische Funktion kann man sich auch so zusammensetzen:
      1) für t in [0 , 0.5) sei V(t)=W(t)
      2) für t in [0.5 , 1] sei V(t)=W(1-t)
      Dabei ist zu beachten, dass nur Töne W(t) im Intervall t in [0 , 0.5] berücksichtigt werden.
      Falls man für W(t) ein gleichbleibendes Geräusch nimmt, spuckt dieser Ansatz natürlich auch nur etwas Gleichbleibendes aus.
      Falls doch die Lautstärke mit reguliert werden soll, schmeiß einfach bei Teilfunktion 1) ein t oder ein t+Offset vor das W(t) und bei 2) ein (1-t) bzw ein (1+Offset-t).
      Oder mach es über den Sinus.

      edit:
      Ich glaub, Veytors Ansatz ist grundsätzlich nicht so geeignet, weil er Lautstärkeregelung und die Herstellung der Periodizität der Geräuschfunktion W(t) zusammenwirft. Hat aber beides erst mal nichts miteinander zu tun und führt mit der vorgeschlagenen Lösung dazu, dass sich 2 verschiedene Geräusche überlagern (also die zu den verschiedenen Zeitpunkten t und 1-t). Das ergibt im Normalfall unschönen Krach.

      Post was edited 1 time, last by “Keaton” ().

      Hm, kann zwar zu Unity3D nix beitragen, bin aber in C ziemlich erfahren.
      Da ist diese Vorgehensweise (einfach mal probieren, man lernt es dann schon) ziemlich das Verkehrteste was man machen kann und so ziemlich jeder, den ich kenne, der es auf diese Weise versucht hat, ist kläglich gescheitert.

      Wie es eine Abstraktionsebene "weiter oben" aussieht kann ich nicht mit Gewissheit sagen.
      Aber früher oder später wirst du vermutlich auf Probleme stossen, die dann wirklich ärgerlich sind.

      Aber: Du hast etwas was dir Spass macht, so ist es natürlich auch einfacher. Mal sehen wie das so klappt, berichte doch wenn erste (vllt. sogar testbare?) Ergebnisse vorliegen!

      Gruss
      Da ist diese Vorgehensweise (einfach mal probieren, man lernt es dann schon) ziemlich das Verkehrteste was man machen kann und so ziemlich jeder, den ich kenne, der es auf diese Weise versucht hat, ist kläglich gescheitert.
      Hmm, na gut. Profi-Programmierer werde ich damit wohl nicht, aber ich hangele mich momentan so von Problemstellung zu Problemstellung und bisher klappt das auch recht gut. :)
      Aber früher oder später wirst du vermutlich auf Probleme stossen, die dann wirklich ärgerlich sind.
      Ja, das mag stimmen. Trotzdem lasse ich mich erstmal überraschen, wie weit ich komme. Ich weiß bei mir nämlich, dass ich nicht lange durchhalten würde, wenn ich erstmal mit "Hello world" anfangen und mich danach monatelang mit Scriptprogrammen befassen "müsste", um eine Sprache von der Pike auf zu lernen. Wäre für den langfristigen Lernerfolg vermutlich besser, aber naja...
      Mal sehen wie das so klappt, berichte doch wenn erste (vllt. sogar testbare?) Ergebnisse vorliegen!
      Joa, die Steuerung meines Gleiters habe ich soweit erstmal fertig. Die Tage mache ich mich dann mal dran, einen Start-Countdown zu programmieren und irgendwas, womit ich die Rundenzeiten messen kann und dann gestalte ich mal meine erste "echte" Strecke. Bisher habe ich ja nur ein leicht hügeliges Terrain mit ein paar Bäumen drauf. Sobald ich das "gemeistert" habe, schaue ich mal wo ich den ersten "Testlevel" hochladen kann und wer möchte, kann dann natürlich gerne mal testfahren und Rückmeldung geben.
      Lang lebe König Staublin, Herr der Mummers vom geheimnisvollen Volk der Doom.
    • Users Online 1

      1 Guest