Unity3D

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

Veytor: Von Programmiererin zu Programmierer - Chapeau für Deinen ausführlichen Beitrag über Spiele-Programmierung!
Und an Aegon: Nur nicht entmutigen lassen! Du packst das. Bestimmt!

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

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.

Zitat

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.

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