Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation since 07/19/2018 in all areas

  1. 4 points
    Moin zusammen, wir bei PHOS Digital, mein Kollege und ich, arbeiten an einem "postapokalyptischen racing shooter" im Stil von Mad Max und Co. und ich möchte euch unseren Titel kurz vorstellen. Seit Anfang des Jahres arbeiten wir daran und noch sind wir mitten in der Preproduction, aber ich denke zum zeigen ist es schon ganz ordentlich. Wer Interesse an dem Titel gefällt, kann uns gerne auf www.phosdigital.com über den Newsletter folgen oder uns auf Facebook / Twitter finden. Es wird typische Rundenrennen und andere Spieltypen gegen KI oder Online Konkurrenten geben, in denen ihr euch gegenseitig bekämpfen könnt... Ob mit guten Zeiten oder Waffen, ist euch selbst überlassen. :-) Hier ein paar Screenshots
  2. 2 points
    Ohwe ohwe war ich hier lange nicht mehr unterwegs... Kennt mich hier überhaupt noch jemand? Das Studium frisst einen auf... Aber: Ich kann endlich mal wieder was (öffentlich) von meiner Arbeit zeigen! Und noch dazu ein Unity-Projekt, was doch eher untypisch ist. In den letzten 4 Monaten habe ich im Rahmen des 5. Semesters ein Augmented Reality Sandbox Game entwickelt - vielleicht kennt ihr das aus Museen, Sea Life, etc, manchmal gibt es da so Sandkästen, auf die mehr oder weniger in Echtzeit Höhenlinien projeziert werden. Ich habe das gesehen und mir gedacht: Da muss man doch mehr mit machen können. Und nach viel viel Arbeit kann ich euch meine erste Installation präsentieren: Basic Info: Man nutzt den Schatten seiner Hände um herumwirbelnde Natur-Teilchen einzufangen, diese kann man in vorher gegrabenen Mulden sammeln und so Stück für Stück die Landschaft vergrößern. Technischer Breakdown: Ich nutze eine Microsoft Kinect 2 um die Höheninformationen des Sandes und der Hände zu bekommen. Aber: Das "Raw" Kinect Tiefenbild ist für diesen Zweck eigentlich komplett unbrauchbar. Das rauscht wie verrückt, und immer wenn es eine harte Kante gibt werden die Höheninfos an dieser Kante einfach null - lauter so Zeug. Deshalb war mein erster Schritt das Kinect Bild möglichst performant und vor allem schnell zu filtern und zu smoothen. Dieses GIF zeigt den Effekt. Normalerweise ist es ja so, dass wenn man seine Hand jetzt über den Sandkasten hält, diese Höheninformation auch in die Projektion aufgenommen wird und dort ein sehr hoher Berg entsteht (einer der Gründe für die große Verzögerung der bekannten AR Sandboxes). Ich wollte das auf keinen Fall, weshalb ich nach einem Weg gesucht habe, die Hände aus den Höheninformationen herauszufiltern. Das funktioniert viel billiger als man vielleicht annimmt: Man kalibriert den Tisch einmal ohne Hände und ab diesem Moment werden alle Informationen, die über einem bestimmten Threshold sind, einfach ignoriert. Sobald man die Hand 3cm über den Sand hält, wird diese wieder als Terrain wahrgenommen (Es gibt dann mehrere Thresholds für schnelle Bewegungen etc.) Das Resultat fühlt sich nach einer sehr "magischen" Interaktion an, da eben nur die wirklichen Sandinteraktionen auch Änderungen in der Projektion hervorrufen. Zugleich bekomme ich aus den gefilterten Höhendaten dann eine Maske für die Hände, mit der ich über OpenCV Handgesten und Formen für den Game Input erkennen kann. Da dieses ganze System dann doch immer langsamer und nicht richtig "befriedigend" auf den Input reagiert habe ich das Kinect Bild in 8, sich überlappende Teile aufgeteilt, die auf unterschiedlichen Threads verarbeitet werden. Threading (und vor allem Multi Core Threading) ist in Unity ja bekanntermaßen eher, nennen wir es mal: kompliziert. Aber für ein Spiel wie dieses war es super essentiell, dass alles so schnell wie möglich reagiert. Ich berechne die Positionen der Hand Schatten aus der Projekterposition und den Kinect Daten, um die Spieler damit Objekte einfangen zu lassen - da will man natürlich keinen Lag haben. Und auch das Graben fühlt sich so richtig gut an. Visuall Stuff Das Terrain wird aus einer Displacement Map (die aus den verbesserten Höheninfos generiert wird) erstellt. Der Rest passiert dann in einem Shader: Ich berechne mir die Normalen aus der Heightmap, indem einfach ein Vektor aus einem umliegenden Dreieck von Höhendaten berechnet wird - die Normalmap brauche ich für die richtige Beleuchtung der Landschaft. Wenn man jetzt die Höhe vom Mittelpunkt dieses Dreiecks mit der Höhe von den Eckpunkten vergleicht, kann man eine Realtime Curvature Map berechnen - die ist für schöne Schneebedeckte Bergspitzen und saftig grüne Täler. Die Steigung der Normalen wird auch noch dazu berechnet um Felsen an Steilwänden zu erzeugen und die Wälder an solchen Stellen auszumaskieren. Hier mal eine kleiner Debug Ansicht davon: Der ganze Landschaftsshader ist dann doch sehr groß - es gibt eine Art "Fake"-Erosion, damit die Felsen schick aussehen und eine riesige Anzahl Noises um die Sandstrände, Schneeverteilung, Wälderfarben, Meereswellen etc. zu erzeugen. Das ist aber nur die Landschaft! Es gibt auch noch die dunkle, zerglitchte Welt mit dem selben Setup, aber eben anderen erzeugten Effekten. Da sich das Spiel ja um das Fangen und Verbinden von Natur-Fragmenten dreht sollte diese "Verbindungs-Interaktion" etwas ganz besonderes werden und dem Spieler das visuelle Feedback geben, etwas richtiges getan zu haben. Mithilfe eines Voronoi Effekts habe ich die ganzen Natur-Teile sich miteinander verbinden lassen - jedes Natur Objekt kann sich über einen Shader so hin morphen, dass es in seine umgebenden Voronoi Positionen passt. Das erzeugt einen sehr coolen, snappy Effekt als ob man ein passendes Puzzlestück gefunden hat. Solltet ihr in zwei Wochen zufällig in Stuttgart sein könnt ihr gerne auf der FMX Conference 2018 vorbeischauen, wo das Spiel öffentlich präsentiert wird und dann auch tagsüber spielbar ist. Wenn nicht - ich versuche gerade Museen und Ausstellungen ausfindig zu machen, die sich für so ein Exponat interessieren könnten. Wenn ihr da Ideen habt, schreibt mir doch gerne! Zum Abschluss noch zwei schöne Making Of Bilder Vielen Dank fürs Lesen & ich freue mich auf Fragen und Feedback!
  3. 2 points
    In dem Fall ist deine Berechnung von dem t Parameter falsch. Da t nur aus dem intervall von [0, 1] sein darf muss deine Formel angepasst werden: (Time.time - startZeit) * geschwindigkeit Da Time.time in Sekunden ist wäre bei geschwindigkeit = 2 bereits bei einer halben Sekunde t = 1. Je kleiner geschwindigkeit wird desto länger würde es dauern z.B geschwindigkeit = 0.5 sorgt dafür das t erst bei 2 Sekunden auf 1 gesetzt wird. Was du willst ist: (Time.time - startZeit) / geschwindigkeit Zudem musst du nicht abfragen ob die Farben gleich sind, prüf einfach ob t >= 1 ist. Zusätzlich darfst du niemals die gesetzte Farbe von den Textboxen wiedeverwenden da es sonst keine lineare interpolation mehr ist. Du musst immer die start und endfarbe wiederverwenden: public void Update() { var t = (Time.time - this.startTime) / geschwindigkeit; foreach(Text text in this.texte) text.color = Color32.Lerp(this.startColor, this.targetColor, t); if(t >= 1) // t = 1 bedeutet wir haben targetColor erreicht { this.startColor = this.targetColor; this.targetColor = // Berechne random Farbe } }
  4. 2 points
  5. 1 point
    Leider noch nicht, aber ich hoffe, dass wir bald ein qualitativ hochwertiges Gameplay (vom fahrerischen Können abgesehen) aufnehmen können. Spielbar ist es intern natürlich schon, aber nichts zum nach draußen zeigen. Wenn dann sollen die Features auch gut rüberkommen. Ich glaube, dass auch das Spiel mit eingeflossen ist, ja. Danke! Wir auch!
  6. 1 point
  7. 1 point
  8. 1 point
    Hey, euer Projekt sieht wirklich gut aus :-). Mich erinnert es etwas an Crashday, also vom Look. Habt ihr euch da etwas inspirieren lassen?
  9. 1 point
    Schaut richtig gut aus. Kannst Du auch einen kleinen Clip zeigen wo ein Rennen gefahren wird?
  10. 1 point
    Audio aufnehmen in meinem Hobel. Und 2. Map in Arbeit.
  11. 1 point
    Doch, wenn man die Kanten scharf zeichnen lässt, splittet Unity die Vertices beim Import.
  12. 1 point
    Grüße! Ich hab nen kleines Script für Works geschrieben, welches die Textfarbe per Zufall ändert. An sich funktioniert der ganze Spaß: using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; public class Text_Zufallsfarbe : MonoBehaviour { [Header("Min. und Max. von Rot")] [Range(0, 255)] public int minRot; [Range(0, 255)] public int maxRot; [Header("Min. und Max. von Gelb")] [Range(0, 255)] public int minGelb; [Range(0, 255)] public int maxGelb; [Header("Min. und Max. von Blau")] [Range(0, 255)] public int minBlau; [Range(0, 255)] public int maxBlau; [Header("Startfarbe für alle Texte")] public Color32 colStart; private Color32 colZiel; [Header("Texte zum Farbwechseln")] public Text[] texte = new Text[0]; [Header("Farbwechsel bei Spielstart?")] public bool farbwechselStart = true; public bool farbeWechseln = false; [Header("Farbwechselgeschwindigkeit")] public float geschwindigkeit = 1f; private float startZeit; void Start() { if (texte.Length == 0) { Debug.Log("FEHLER: Keine Texte zum Farbwechsel angegeben im GameObject: " + this.gameObject.name); return; } else { for (int i = 0; i < texte.Length; i++) { texte[i].color = new Color32(colStart.r, colStart.g, colStart.b, 255); } } if (minRot > maxRot) { Debug.Log("FEHLER: Min. Rot ist größer als Max Rot in GameObject: " + this.gameObject.name); return; } if (minGelb > maxGelb) { Debug.Log("FEHLER: Min. Gelb ist größer als Max Gelb in GameObject: " + this.gameObject.name); return; } if (minBlau > maxBlau) { Debug.Log("FEHLER: Min. Blau ist größer als Max Blau in GameObject: " + this.gameObject.name); return; } if (((int)colStart.r >= minRot & (int)colStart.r <= maxRot) & ((int)colStart.g >= minGelb & (int)colStart.g <= maxGelb) & ((int)colStart.b >= minBlau & (int)colStart.b <= maxBlau)) { // Alle ingestellten Startparameter stimmen! } else { Debug.Log("FEHLER: Die Startfarbe ist außerhalb des Bereiches das für RGB angegeben wurde. GameObject: " + this.gameObject.name); return; } if (farbwechselStart == true) { startZeit = Time.time; FarbwechselAktivieren(); } } private void Update () { if (farbeWechseln == true) { FarbeWechseln(); } } private void FarbeWechseln() { Color32 c1 = texte[0].color; Color32 c2 = colZiel; if (c1.Equals(c2)) { startZeit = Time.time; ZufallsfarbeErmitteln(); } float t = (Time.time - startZeit) * geschwindigkeit; for (int i = 0; i < texte.Length; i++) { texte[0].color = Color32.Lerp(texte[0].color, colZiel, t); } } public void FarbwechselAktivieren() { ZufallsfarbeErmitteln(); farbeWechseln = true; } public void FarbwechselDeaktivieren() { farbeWechseln = false; } private void ZufallsfarbeErmitteln() { colZiel = new Color32(((byte)Random.Range(minRot, maxRot)), ((byte)Random.Range(minGelb, maxGelb)), ((byte)Random.Range(minBlau, maxBlau)), 255); } } Hier ist mein Bug: Color32 c1 = texte[0].color; Color32 c2 = colZiel; if (c1.Equals(c2)) { startZeit = Time.time; ZufallsfarbeErmitteln(); } Ich möchte überprüfen ob die aktuelle Farbe ungefähr der Zielfarbe entspricht. Da ich der einfachheitshalber mit Color32 arbeite braucht er mit Equals extrem lange bis endlich True erreicht ist. Im Endeffekt sieht es so aus, dass die eine Farbe in die andere übergleitet dann paar Sekunden da bleibt und dann erst in die nächste geht. Er braucht halt sehr lange für Equals. Habt ihr ne Idee, wie ich das besser abfragen kann? Grüße Kojote
  13. 1 point
    Kurzes Update: Ihr seid alle herzlich eingeladen mich auf der Gamescom vom 21. bis 26. August in der Campus Area mit dem Sandkasten zu treffen und selber zu spielen! Da kommen doch sicher ein paar Leute aus dem Forum zusammen! Wo? Halle 10.2 Stand B035 Ich freue mich auf euch! Liebe Grüße, Dominik
  14. 1 point
    Du willst einfach nur alle X-Sekunden die Farbe wechseln. Lerp ist dazu da zwischen Farben zu interpolieren, dementsprechend macht es schon keinen Sinn Lerp zu nutzen, zudem musst du nicht prüfen ob du bereits bei der Farbe bist wenn du eigentlich nur schauen musst ob die X-Sekunden bereits vergangen sind. Zudem würde ich dir empfehlen nicht soviele Methoden für kleinkram zu erstellen. z.B ZufallsfarbeErmitteln macht deinen Code nur unnötig schwerer zu lesen für eine Zeile Code. Wie dem auch sei: private void Update() { if((Time.time - this.startTime) >= geschwindigkeit) { // Erzeuge eine random Farbe und weise diese allen Texten zu this.startTime = Time.time } }
  15. 1 point
    Ich denke am einfachsten gebe ich dir gleich das Package, dann siehst du auch wo was ist. Ist jetzt alles Sprite basiert. Den MSAdvancedCameraController Ordner kannst du ignorieren, ist nur ein gratis orbit Kamera controller Asset. Mit gedrückter rechten Maustaste kannst du die Kamera rotieren, mit Pfeiltaste links/rechts kannst du den Player drehen. Mit dem Wert Offset kannst du die Blickrichtung ändern, wenn du z.B. die Blickrichtung von Hinten statt von Vorne haben möchtest, ist aber im Script beschrieben. Ob das Script was taugt garantiere ich natürlich nicht, wie immer gilt: viele Wege führen nach Rom. Edit: https://www.dropbox.com/s/2k6jqqsojm42wpn/SpriteUI2.unitypackage?dl=0
  16. 1 point
    Also Batches sind eigentlich Drawcalls, kannst also von den selben Werten ausgehen.
  17. 1 point
    Würde ich auch meinen, vorallem am Anfang bei der Entwicklung wenn du noch nicht genau weisst wo die Reise hin geht. Performance ist eine Sache die man eigentlich macht wenn das Spiel soweit ist wie es sein soll, dann kannst du dir gedanken machen wie man was Batchen kann oder wo man was Baken kann. Dazu gibts auch jede menge Tuts z.B. auf YT. Natürlich wenn man von Anfang an drauf achtet, hat man später weniger Arbeit.
  18. 1 point
    Meinte mal gelesen zu haben für Mobile liegt so die Grenze bei 100-200 drawcalls und bei PC 1000-2000 drawcalls je nach Rechner. Spielen natürlich auch andere Faktoren wie Polycount und Script-Performance eine Rolle, sowie Texturauflösung, echtzeit Licht und Schatten, Reflextionen, Global Illuminatin usw.
  19. 1 point
    @Kojote Hast du dir das so vorgestellt?
  20. 1 point
    Achso, und entsprechend werden immer alle im UI angezeigt, nicht nur die Figur die gerade bewegt/ bzw. am Zug ist? 1. Denke ist eher der Auwand die ganzen Sprites zu machen und den Überblick zu behalten. Vom Script her wäre man ja mit 4 Abfragen dabei (<0<90<180<270). Könnte man auch für alle Chars das gleiche anwenden und einfach die Sprites entsprechend reinsetzen. 2.Ja wie das Performance technisch aussieht weiss ich leider nicht.
  21. 1 point
    Version: 1.25 Entwicklerforum: Canyonbreed Forum DiscordChannel: https://discord.gg/NRaJKe2 Update: Reisesystem Ich habe ein einfaches Reisesystem integriert, bei dem sich der Spieler wärend des Fluges an Bord des Shuttles frei bewegen kann. Um das Video kurz zu halten, habe ich die Reisezeit stark verkürzt. Das Shuttle ist noch nicht dekoriert und auch die Aussenansicht des Shuttles passt noch nicht zum inneren Design. Es ist vorerst nur ein Platzhalter. Das Reisesystem löst den reinen Teleporter ab, bei dem man quasi instant von A nach B teleportiert wurde. Es ist quasi eine interaktive Zwischensequenz, bei der die Reisezeit nicht realistisch sein soll, aber immerhin - je nach Entfernung - 1-2 Minuten dauern wird. Ich hoffe es gefällt euch und erhalte ein paar Rückmeldungen. Cliplänge: 1:03
  22. 1 point
    Ich hab den Algorithmus ein wenig angepasst, um das Problem mit den weichen Ecken zu lösen. Im Grunde schau ich mir einfach die vertices an, die nicht ganz korrekt sind, addier alle Normalen zusammen (nennen wir das Ergebnis einen Vektor A) und interpoliere dann von diesem Vertex aus in die Richtung A bis die SDF an diesem Punkt = 0 ist. Ich musste allerdings einen kleinen Bias einbauen, aber ich denke das sind einfach bloß Genauigkeitsprobleme, da die Implementation aktuell komplett auf floats setzt. Die schwarzen Linien am Ende zeigen das Ergebnis der Normalen (Vektor A) bei den Vertices, die zunächst gesmoothed wurden. Ich werd noch mehr testen müssen, um zu schauen, ob die Lösung so allgemein aufrecht erhalten werden kann.
  23. 1 point
    Hey, Ich experimentier aktuell mit meiner eigenen Idee rum, Oberflächen aus Distanzfunktionen (signed distance function, SDF) zu generieren. Ihr könnt meinen Ansatz in diesem Thread verfolgen, falls ihr euch für so Voxel Zeugs interessiert: https://www.gamedev.net/forums/topic/697431-a-novel-approach-to-non-manifold-dual-contouring/ Im Grunde gehts darum Eckpunkte (vertices) durch Schnittpunkte von Oberflächenkanten (surface edges) ausfinding zu machen. Die 2D Methode scheint ohne probleme zu funktionieren, und ermöglicht so auch scharfe geometrische Features wie Ecken. (dabei ist's auch deutlich einfacher zu verstehen, als 2D Dual Contouring) Mit dem 3D Ansatz bin ich aktuell noch ein wenig am kämpfen, aber erste Ergebnisse gibts dazu auch schon, wie ihr hier nochmal sehen könnt:
  24. 1 point
    Time.time "This is the time in seconds since the start of the game." In der zweiten Szene bekommst du also nicht die Zeit seit dem Beginn des 2. Levels, sondern seit Start des Spieles. Ich würde einfach jeden Frame die vergangene Zeit seit dem letzten Frame zu 'zeit' addieren. Also: zeit += Time.deltaTime;
  25. 1 point
    Hier mal ein Bild von meinem Beby. Büschen tiefer und so Kleinkram. Sonst alles original. Nicht ganz so Rückenschonend auf blöden Straßen. Aber macht Laune im Kartfeeling.

Announcements

Hy, wir programmieren für dich Apps(Android & iOS):

Weiterleitung zum Entwickler "daubit"



×