devandart

Doch es reicht theoretisch und oft praktisch für ein richtiges Projekt, aber wenn es komplexer wird, muss man ggf. diverse Aspekte doch coden. Da gebe ich Dir absolut Recht. Der Vorteil ist, das man beide Welten perfekt miteinander verschmelzen kann.

Ich rate Dir, die Scripting Referenz einfach mal durchzuschauen. Weil welche Objekte es im Unity Universum gibt, ist immer gut zu wissen. Abgesehen von den ganzen Tutorial Videos natürlich. https://docs.unity3d.com/Manual/index.html https://docs.unity3d.com/560/Documentation/ScriptReference/index.html

Mindestens um die Logik an sich zu verstehen, ist das aber dennoch ein cooler Weg für Einsteiger und mit Bolt kannst Du schon recht tief gehen, weil der "alle" Features über Reflection anbietet, die Du auch in C# machen kannst. Jetzt mal von generischem Programmieren, Interfaces und sowas abgesehen, das weiß ich nicht. Und wenn man an den Punkt kommt, dass es damit nicht geht, kann man auch auf Code oder Hybridlösungen umsteigen. Und visual scripting verstehen ist auch von Vorteil, wenn man mal mit Grafikern zusammenarbeitet, die z.B. PlayMaker verstehen.

Die Frage ist halt, wer das programmiert und wie weit das hinter den jahrelangen Platzhirschen auf dem Markt herhinkt. Aber, dass sie es einbauen wird Zeit aus Konkurrenzsicht.

An Fehlern lernt man am besten.

Visuelle Programmierwerkzeuge gibt es zu Hauf, mehr oder weniger gut und je nach Aspekt ist das eine oder das andere besser. Allerdings haben alle eins gemein: Du musst logische Abläufe von Prozessen verstehen, also wie ein Programmierer denken. Was Du nicht musst, ist die Syntax der Sprache zu lernen, in den meisten Fällen im Bezug auf Unity C#. Beispiele, welche ich persönlich empfehlen kann sind: PlayMaker, Einstieg einfacher Bolt, Einstieg auch nicht sehr schwer und man kann auch kleinteiligeren Code damit programmieren Wenn man noch gar keine Erfahrung hat oder je nach Aspekt, ist PlayMaker die bessere Wahl. Und zwar weil PlayMaker sogenannte Actions, also Funktionsblöcke, nutzt. Diese fassen oft auch relativ komplexe Abläufe in einem Block zusammen. Diese kannst Du dann in einem Zustand, der aktiv ist, verknüpfen. Z.B. Zustand "Warte auf Eingabe" und dort hast Du die Actions "Wait For Keyboard" und "Wait For Mouse" oder so. Riesenvorteil: PlayMaker hat das sogenannte "EcoSystem", eine Art App Store für Funktionsblöcke, in dem Du suchen kannst und im besten Fall gibt es für dein Problem schon eine fertige Lösung/Action. Diese kommen von der jahrelangen Community und sind kostenlos. Bei Bolt kann es auch so ähnlich sein, da heißen diese Actions dann z.B. Macros. Zusätzlich kannst Du dort aber auch "normal" programmieren mit allen Möglichkeiten des .Net Frameworks, nur dass der Code eben nicht aus Text Code besteht, sondern aus vielen kleinen Blöcken. Diese kann man aber wieder zusammenfassen und als Block nutzen. Also auch eine Geschmackssache... Wer in der Unreal Engine 4 mit Blueprints programmiert hat, würde sich wohl mit Bolt zu Hause fühlen. Bei weiteren Fragen einfach fragen.

Der Code liest sich, als wäre man nicht auf Unity Server angewiesen. Aber Forge würde ich auch empfehlen. Das Teil ist performant, relativ einfach und hat ne super Discord Community bei Problemen oder auch einfach so mal austauschen.

Es gibt die Möglichkeit, Code zur Laufzeit zu kompilieren. Eventuell hilft Dir auch das hier? http://csscript.net/

Vielleicht trotzdem interessant: Mit sogenannten Precompiler Flags (der sortiert vor dem Compiler unnötigen Kram weg) kannst Du trotzdem Editor Code nutzen, solange Du im Editor testest. Sprich, Du baust den Editor Code ein und "umklammerst" ihn dann mit #if UNITY_EDITOR ... Editor Code ... #endif Natürlich wird es dann immernoch nicht in einem Build funktionieren. Dafür brauchst Du eine andere Lösung. Für eine Build MessageBox kannst Du einen UI Canvas als Prefab speichern, den Du dann zu gegebener Zeit instanzierst.

Was Dir offensichtlich fehlt, sind die absoluten Grundkenntnisse, um mit Unity zu entwickeln. Vielleicht solltest Du statt gleich mit einer komplexen Technik wie AR erstmal ein, zwei Anfänger Tutorials von Unity Learn durcharbeiten?! https://unity3d.com/de/learn/tutorials Weil was Du tun musst, steht da ganz genau. Du sollst das Kamera GameObject selektieren, dann eine neue Komponente (Quellcodedatei) hinzufügen (erstellen) und diese "webCamScript.cs" (Dateiname) nennen. Das ist dann ein CSharp Code File, in welches Du den Code da unten schreibst.

Ich weiß jetzt nicht, wo man es in @Saschas Liste einordnen könnte, vielleicht direkt nach den statischen Variablen. Aber es gibt auch noch die Möglichkeit, eine zusätzliche Scene beim Start zu laden, welche persistent ist und in welche Objekte reinkommen, welche immer existieren müssen. Auch hier gibt es Stolperfallen, ich würde also auch eher die statischen Variablen empfehlen.

Der iOS Export in Unity exportiert erstmal ein XCode Projekt (geht auch unter Windows), welches Du dann auf dem Mac mit XCode öffnest, dort erst kompilierst, dann die App signierst und dann auf das iPad veröffentlichst. Wenn Du eine Apple Developer Lizenz hast, gibt es aber auch einen Workaround. Du brauchst nur einmal OSX mit XCode um gewisse Dateien zu kopieren und kannst dann auch von Windows alles ohne OSX aufs iPad bringen. Ich würde dies aber eher als "fortgeschrittene" Technik ansehen und wenn man wirklich kein OSX möchte. Machen kann man das dann hiermit: https://assetstore.unity.com/packages/tools/utilities/ios-project-builder-for-windows-15522

Ich glaube auch, dass es erstmal wichtig ist, aus wie vielen Würfeln dein großer Würfel bestehen soll. Sind es z.B. 8x8x8 kleine Würfel, hast Du schon 512 Objekte, die Du rendern (ohne Optimierung) musst. Das wäre vielleicht noch kein Problem, je nach Plattform und ob Du diese instanzierst. Aber je mehr, desto mehr, logisch. Andere Idee wäre ein Mesh mit x Vertices, welches Du bei Collision verformst oder Du generierst das Mesh bei Collision neu und hast nur minimal viele Vertices. Das ist natürlich etwas komplexer als viele einzelne Würfel, aber eventuell massiv performanter. Es kommt auch drauf an, was sonst noch in der Scene ist, Environment usw.

Das Wort Library/Bibliothek kommt daher, dass man bestimmte Programmlogik oft in eigene, gekapselte Dateien (z.B. DLLs = Dynamic Linked Library) auslagert. Der Grund ist unter anderem, dass man den Code dann in unterschiedlichsten Programmen nutzen kann, ohne es immer wieder neu entwickeln zu müssen oder beeinflussen zu können. Vielleicht kannst Du jetzt etwas mehr damit anfangen, wenn der Begriff fällt.

Sehr schönes Projekt, weiter so!