Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation since 09/20/2019 in all areas

  1. 2 points
    Ich hab da mal ein kleines Attribut geschrieben, mit dem man die entstehenden Schönheitsfehler eines kleinen Tricks korrigieren kann, mit dem das kürzer aussieht: [field: SerializeField, UsePropertyName] public int number { get; private set; } Ist ein bisschen kürzer... Geschmackssache
  2. 2 points
    Moin, hier mal wieder ein kleines Update von mit. 🙂 Ich habe den SGT Planeten Shader erweitert so das ich jetzt den Planeten bessere Texturen verpassen kann. Ich kann jetzt statt einer vier verschiedene Texturen verwenden die über die RGB Kanäle einer Mask Map gesteuert werden können. Da bald Winter ist spiele ich gerade mit Schnee herum und erweitere den Shader so das ich auf den Planeten auch Schnee Rendern kann. Dabei soll man im Shader einstellen können wo der Schnee anfängt und wie weit er runter gehen soll.
  3. 2 points
    Ich bin zwar noch kräftig am malen, aber der neue Tisch kann sich schon sehen lassen.
  4. 2 points
    Du würfelst eine Zufallszahl zwischen 0 und der Summe der Wahrscheinlichkeiten, dann iterierst du über dein Array, bis die Summe aller bisher gesehenen Wahrscheinlichkeiten größer als deine Zufallszahl sind. var sumOfChances = spawnablePrefabs.Sum(item => item.spawnChance); Das hier kannst du direkt vor dem Folgenden machen, aber eleganter wäre es in Start() und dann in ein privates Feld gespeichert, vorausgesetzt, die Werte ändern sich zur Laufzeit nicht mehr. public GameObject GetRandomPrefab() { var roll = Random.Range(0f, sumOfChances); var currentChanceSum = 0f; foreach (var item in spawnablePrefabs) { currentChanceSum += item.spawnChance; if (currentChanceSum >= roll) { return item.prefab; } } return spawnablePrefabs[spawnablePrefabs.Length].prefab; } Die letzte Zeile ist als Sicherheits-Fallback für den Fall von floating point-Ungenauigkeiten.
  5. 2 points
    100 Schiffe kämpfen ohne Network Culling. Das bedeutet alle bekommen Daten unabhängig davon wie weit sie weg von einander sind. Lasst euch nicht von dem Arrow gewackel nicht irritieren. Es laggt nicht sondern, es sucht den Mittelpunkt und durch den Particles versetzt sich das jedes mal (hab vergessen den Mode zu ändern). https://i.imgur.com/aEuVL7w.gifv
  6. 1 point
    Transform.forward ist ja auch die Richtung in der Welt. Das ist nix anderes als Vector3(0,0,1). Ist also einfach in Z Richtung der Welt. Das kannst du mit Norden vergleichen. Du guckst natürlich nicht immer nach Norden. Also einfach mal die Scriptingreferenz befragt, was es denn alles für Transform Befehle gibt, und schwupps kommt das bei raus: https://docs.unity3d.com/ScriptReference/Transform.TransformDirection.html Und nutzen kannst du das so: transform ich =Camera.main.transform; Vector3 meinVorneImBezugZurWelt = ich.TransformDierction(ich.forward);
  7. 1 point
    Moin, ich wollte hier mal kurz mein Spiel vorstellen an dem ich seit 1,5 Jahren arbeite. Das Spiel ist ein sogenanntes "Fast Pace" Racing Spiel im Weltraum. In dem Spiel gibt es aktuell 4 Planeten und eine Raumstation von der aus man startet. Diese Station ist die Basis für den Spieler. Dort kann man das Leaderboard ansehen, sein Schiff wählen, seine Statistik ansehen etc.. Es soll eigentlich alles ingame stattfinden ohne auf irgendeine Webseite gehen zu müssen. Das Spiel hat ein 6DoF physikbasiertes Flugmodel und ist Open World, so dass später auch neue Sonnensystem möglich sind. Am Anfang wollte ich die Rennstrecken in einzelne Szenen packen, konnte aber das Wechseln von einer Szene zur anderen nie ohne kleine Lags hinbekommen. Deshalb habe ich dann alles auf Open World umgebaut, was im Nachhinein eine gute Entscheidung war, denn jetzt gibt es keine Grenzen mehr in der Größe. 🙂 Desweiteren benutze ich ein für mein Spiel angepasstes floating origin system mit double precision. Das Sonnensystem hat aktuell einen Durchmesser von ca. 160000 Km mit Planeten die einen Durchmesser von 400 - 500Km haben. Die Rennstrecken befinden sich auf den Planeten oder im Weltraum, z.B. im Asteroidengürtel. Die Rennstrecken sind verschieden schwer und können auch mal auf der Nachtseite liegen. Außerdem muss man bevor man ein Schiff betritt auswählen welchen Controller man benutzt (Joystick, Maus / Tastatur oder Gamepad). Das Leaderboard ist dann nach Rennstrecke und Controller aufgeteilt. Das mache ich deshalb, weil ich aus anderen Spielen die ständigen Diskussionen kenne, das man diesem oder jenem Controller im Vorteil ist. Das Spiel ist als Single Player geplant mit einem Leaderboard in dem alle Spieler ihre Rennzeiten vergleichen können. Development Progress Unity Connect So genug gelabert, hier was zum gucken zeitlich geordnet. 🙂 Hier ein erstes Video wo ich die Machbarkeit getestet habe. Ein Video zur Autolanding Mechanik Character Test Video Trailer für ein Schiff Video zur Überarbeitung der Planeten
  8. 1 point
    Lustig, ich hatte selbe Idea und ich habe sogar das selbe ship benutzt, aber nach dem ich eine Demo gemacht habe, hat es sich angefühlt als ob was felt. Es ist nicht so einfach eine schone Scene zu basteln wie in EVE z.b, zonst hätte ich so ein spiel schon bei Steam ) edit Ich meine natürlich nur das Imspace teil. Bei mir gabt es einfach eine Strecke aus Rings von der Erder zum Mond und Zuruck.
  9. 1 point
    Vorteile bei xml oder ähnlichen (z.b. json) können sein wie z.B., dass du einen geeigneten Programm dafür schreiben kannst und viel übersichtlicher alles gestalten kannst. Ich musste mal ein Auftrag erledigen und jemanden bei einem DialogSystem helfen. Er hatte da sich was im AssetStore geholt. Die z.B. unterstützten viele solche Formate. Ich glaube es gab sogar eine Seite wo man solche Dialoge erstellen kann und dann in Unity reinladen usw. Oder man kann z.B., wenn du wegen ein Rechtschreibfehler nicht das ganze Spiel nochmal builden willst direkt an der Datei bearbeiten. Mehrere Sprachen könnten leichter übersetzbar sein.. usw. Allerdings sind auch ScriptableObjects Assets glaube auch mit einem Texteditor lesbar und editierbar. Nur muss man da sehr aufpassen. Sie könnte man daher auch außerhalb lagern, wenn man es möchte.
  10. 1 point
    Du machst dir halt ein serialisiertes Feld und ziehst da das richtige ScriptableObject rein: public Dialog DialogMittagessen; public Dialog DialogKeinGeldMehr;
  11. 1 point
    Kannst du machen, aber eigentlich reicht das Script. Du hast halt das Interface IInput, und das definiert diese Propertys: public float Acceleration { get { return m_Acceleration; } } Das KartMovement-Script liest die Werte dieser Propertys aus und entscheidet dann, wie das Kart sich bewegen soll. Um eine andere Input-Methode zu bauen, musst du eine neue Klasse bauen, die ebenfalls dieses Interface implementiert. public class TouchInput : MonoBehaviour, IInput { public float Acceleration { get { return ???; } } public float Steering { get { return ???; } } // usw. Jetzt müssen diese Propertys immer den richtigen Wert zurückgeben. Beim Keyboard-Script wird in Update nachgeschaut, was die Input-Klasse über die aktuellen Tastatur-Tasten sagt (mit Input.GetKey und so). Die Werte werden in Feldern gespeichert (m_Acceleration und so weiter) und die Propertys geben den Wert dieser Felder zurück. Bei einer Touch-Steuerung brauchst du sichtbare Knöpfe. Diese würden beim Drücken die Werte ebenfalls den Wert von Feldern setzen, deren Wert denn von den Propertys zurückgegeben wird. Es ist vielleicht nicht die eleganteste Methode, aber anfangs recht einfach, wenn du die Felder öffentlich machst. public float m_Acceleration; public float m_Steering; // usw. Wenn das deine einzige Änderung wäre, sieht das Script erstmal so aus: https://pastebin.com/zvqcsMsZ Das kannst du zum Verständnis auch einfach mal auf dein Kart packen und aktivieren. Die Felder tauchen jetzt im Inspektor auf, und du kannst das Kart über den Inspektor steuern. Wenn du jetzt einen Button in dein UI baust, kannst du dem Button sagen, dass er diese Werte beeinflussen soll. Dazu benutzt du ein UnityEvent, wie das "On Click"-Ding im Inspektor des Buttons. Da muss man sich einmal reinfuchsen, ist aber super: Du kannst damit dem Button sagen, dass er eine bestimmte Sache machen soll, wenn er gedrückt wird, ohne extra Code zu schreiben. OnClick ist allerdings hier unpraktisch, da das Event ausgelöst wird, wenn man den Button einmal drückt und wieder loslässt. Du willst ja, dass etwas passiert, wenn der Knopf runtergedrückt wird (z.B. Beschleunings-Wert erhöhen) und wenn er wieder losgelassen wird (z.B. den Wert wieder senken). Dabei hilft dir die "EventTrigger"-Komponente. Dort kannst du auf weitere Events reagieren - von "Mauszeiger ist neuerdings über dem Objekt" bis hin zu "der Button wurde losgelassen. Auch hier wirst du dich ein bisschen reinfuchsen müssen, aber das wird schon. Du willst dann dem Button über diese Events beibringen, die Werte deiner TouchInput-Komponente zu ändern. Da fehlt dann noch einiges, aber damit hast du erstmal eine Menge zu tun.
  12. 1 point
    Ich würde ja nicht in "per tick", sondern pro Sekunde arbeiten wollen. Tust du ja mit damageIncreasePerTick auch. Was dein Problem angeht, verstehe ich nicht ganz, was du da machen willst... oder wo das Problem ist. Wenn dein damagePerTick sich ändern soll, ändere ihn. Wenn dein damageIncreasePerTick sich ändern soll... ändere ihn! public void EatSomething() { damagePerSecond = 0f; damageIncreasePerSecond = initialDamageIncreasePerSecond; }
  13. 1 point
  14. 1 point
    Das war jetzt auch eher der saubere Weg. Mit einem public Feld geht das natürlich auch. Ich würde das ganze eher so machen, damit man von außen nicht ausversehen im Code den Wert verändert. Aber super, dass du damit zurechtkommst. [CreateAssetMenu(menuName = "My Game Assets/Animal Data")] public class AnimalData : ScriptableObject { [SerializeField] private string animalName = "Animal Name"; [SerializeField] private int meatValue; //öffentliches Property public int MeatValue { get { return meatValue; } } }
  15. 1 point
    Gerne. ScriptableObjects sind nicht so viel anders als z.B. eine Komponente. Du erstellst ein "Skript", sprich eine C# Klasse Darin erbst du von ScriptableObject Erstellst die Felder, die du brauchst Nun kannst du im Asset Explorer mit Rechtsklick über das Kontextmenü dein Objekt bzw. eine Instanz dessen erstellen und die Werte im Inspector editieren [CreateAssetMenu(menuName = "My Game Assets/Animal Data")] public class AnimalData : ScriptableObject { [SerializeField] private string animalName = "Animal Name"; [SerializeField] private int meatValue; } Nun kannst du über Rechtsklick - Create - My Game Assets - Animal Data eine Instanz erstellen und diese benennen (z.B. "Zebra"). Anschließend kannst du in jedem Skript ein Feld vom Typ AnimalData anlegen und das ScriptableObject über den Inspector in dem Slot zuweisen. public class Zebra : MonoBehaviour { [SerializeField] private AnimalData data; } Und immer, wenn du in dem einen ScriptableObject "Zebra" den Wert meatValue änderst, kriegen alle Objekte, die dieses zugewiesen haben, die neuen Werte. Ich hoffe, es ist verständlich.
  16. 1 point
    Genau für sowas gibt es ScriptableObjects.
  17. 1 point
    Du hast also EIN Enum mit den Werten Zebra, Gnu usw.? Dann so: enum AnimalType { Zebra = 30, Gnu = 20 } //... AnimalType animal = AnimalType.Zebra; int value = (int)animal; Aber abgesehen davon könntest Du auch ein ScriptableObject machen, welches z.B. eine Basisklasse Animal hat. Dann kannst Du Zebra, Gnu etc. davon ableiten und deine Objekte im Inspector auch weitergehend bearbeiten, sofern es nicht nur bei dem einen Wert bleibt. Dann hat dein Fleisch einfach einen ScriptableObject "Animal" Slot, wo Du dann das entsprechende SO aus den Assets reinziehst. Aber ich weiß ja nicht, wie komplex die Logik da wird.
  18. 1 point
    Jetzt hab ichs raus gefunden! Type[] arguments = prop.GetValue(obj).GetType().GetGenericArguments(); Type keyType = arguments[0]; Type valueType = arguments[1]; Type dictType = typeof(Dictionary<,>).MakeGenericType(keyType, valueType); var dict = Activator.CreateInstance(dictType);
  19. 1 point
    ScriptableObjects können dafür schon ganz gut sein. Ich würde empfehlen, bei der Idee erstmal zu bleiben. Klar, so wie alles andere auch: public class Dialogue : ScriptableObject { // string nur als Beispiel, ist natürlich keine gute Idee public string[] lines; public void StartDialogue(Dialogue dialogue) Auch hier ist die Antwort "wir bei allem anderen auch": foreach (var line in dialogue.lines) { textComponent.text = line; // Nur ein Platzhalter WaitForClick(); }
  20. 1 point
    Hi Ich kenne mich mit ScriptableObjects nicht aus, aber ich habe ein einfaches Dialog System entwickelt. Dazu habe ich einfach ein LUA File (XML würde auch gehen) verwendet. Darin habe ich verschiedene "Stages" definiert. Jede stage enthält entweder Informationen, was der Npc sagt oder Auswahlmöglichkeiten, die der Spieler Antworten kann. Die Variable "nextStage" gibt an, welche Stage als nächstes kommt (wieder NPC sagt was oder Spieler antwortet was). Dazu habe ich noch eine "requirements" Variable bei den Antwortmöglichkeiten gemacht. Die Antwort erscheint also nur, wenn der Spieler die "requirements" erfüllt... zum Beispiel ein bestimmter Gegenstand im Inventar hat. Ist leider ziemlich kompliziert die Datei zu schreiben. Wenn du ein System entwickeln willst, um die Dialoge auf komfortable Art zu designen, wäre ich sehr interessiert 🙂 So sieht so eine Datei aus: defineDialog { id = "sailorfrank", name = "Frank", startStageId = "s0", autoStartRadius = 0, stages = { s0 = { say = { speaker = "npc", text = "Warum nur immer ich?", audio = "", actions = nil, nextStage = "s1" }, options = nil }, s1 = { say = nil, options = { option1 = { text = "Was ist los?", requirements = nil, actions = nil, nextStage = "s2" }, option2 = { text = "Ich muss weiter.", requirements = nil, actions = nil, nextStage = "" } } }, s2 = { say = { speaker = "npc", text = "Jemand hat meine Schuhe geklaut! Gestern hatte ich sie noch.", audio = "", actions = nil, nextStage = "s3" }, options = nil }, s3 = { say = { speaker = "npc", text = "Es sind ganz normale Schiffsstiefel.", audio = "", actions = nil, nextStage = "s4" }, options = nil }, s4 = { say = nil, options = { option1 = { text = "Wenn ich sie sehe, werde ich bescheid geben.", requirements = nil, actions = { SetStage = "s6" }, nextStage = "s5" }, option2 = { text = "Viel Glück!", requirements = nil, actions = nil, nextStage = "" } } }, s5 = { say = { speaker = "npc", text = "Das wäre super!", audio = "", actions = nil, nextStage = "" }, options = nil }, s6 = { say = nil, options = { option1 = { text = "Wegen deinen Stiefeln...", requirements = nil, actions = nil, nextStage = "s7" }, option2 = { text = "Ich gehe jetzt.", requirements = nil, actions = nil, nextStage = "" } } }, s7 = { say = { speaker = "npc", text = "Ja?", audio = "", actions = nil, nextStage = "s8" }, options = nil }, s8 = { say = nil, options = { option1 = { text = "Ich habe sie gefunden. Hier sind sie.", requirements = { InventoryContainsItem = "BOOTS=1" }, actions = nil, nextStage = "s10" }, option2 = { text = "Noch nichts neues.", requirements = { InventoryNotContainsItem = "BOOTS=1" }, actions = nil, nextStage = "s9" } } }, s9 = { say = { speaker = "npc", text = "Dann such weiter, ok?", audio = "", actions = nil, nextStage = "s6" }, options = nil }, s10 = { say = { speaker = "npc", text = "Das war echt nett von dir! Vielen Dank!", audio = "", actions = { SetStage = "s11" }, nextStage = "" }, options = nil }, s11 = { say = { speaker = "npc", text = "Hey! Danke nochmals, dass du meine Stiefel gefunden hast!", audio = "", actions = nil, nextStage = "" }, options = nil } } }
  21. 1 point
    Ich würde pro Gebiet ein GameObject (Spawner) erstellen und alle Npcs unterordnen (als childs). Dann immer bei Mitternacht (falls du Tag/Nacht Zyklus hast) der Spawnvorgang starten. Du kannst einfach im Spawner mit transform.childCount die aktuell vorhandenen Tiere zählen. //alle 300 sekunden spawnen float spawnTimer = 300; void Update() { if(spawnTimer > 0) { spawnTimer -= Time.deltaTime; if(spawnTimer <= 0) { Spawn(); spawnTimer = 300; } } } int desiredAnimalCount = 20; void Spawn() { int left = desiredAnimalCount-transform.childCount; for(int i=0;i<left;i++) { //Instantiate } } Du könntest auch anstatt tote Tiere zu Destroy'en, sie nur deaktivieren. Und wenn der Spawnvorgang läuft, suchst du für die deaktivierten Tiere ein neuer Spawnpoint und belebst sie wieder.
  22. 1 point
    Ja. Habe nur das Bedürfnis, auf die einzelnen = hinzuweisen... die machen das ganze etwas... sagen wir: mindestens schlecht lesbar.
  23. 1 point
    Ich fange in der Regel immer wieder von vorne an, außer bei meinem momentanen Projekt, bei dem ich Flippertische baue. Da sind ganz viele Dinge einmalig erstellt und können in jedem neuen Tisch wiederverwendet werden. Aber da ist auch ganz viel neu (Texturen, Sounds, Musik und Objekte), da ja immer auch ein anderes Thema entsteht. Somit würde ich sagen, dass ca. 80% der Logik und 40% der Objekte wieder Verwendung finden. Ich fange aber auch aus einem ganz bestimmten Grund immer wieder neu an: Ich gehe nämlich anders an die Sache heran, da ich das Ziel habe ein Spiel fertig zu stellen! Ich arbeite also mit vielen Platzhaltern und nur manche Dinge mache ich schon komplett fertig. Es wird erst ein simples Grundgerüst gebaut, dann wird dieses verbessert und wieder als Grundgerüst genommen ( jetzt ist das zwar schon verbessert, aber immer noch nicht final). Wenn alles so läuft, wie ich es mir vorstelle, dann bildet sich langsam ein richtiges Spiel heraus. Es kann natürlich passieren, dass ich auch mal eine Idee auf Eis lege und was ganz Anderes anfange. Das wird dann aber nicht vom selben Spielprinzip sein und deswegen gehts beim neuen Spiel wieder von vorne los. Das alte Projekt hebe ich mir aber auf, denn wer weiß... irgendwann mache ich vielleicht weiter. Das Einzige was man immer recyclen kann, sind gewisse Klassen die allgemeine Bereiche abdecken, wie z.B. das Laden und Speichern von Daten. Objekte und Grafiken lassen sich meist nicht in neue Spielthemen integrieren. Und das, was nutzbar wäre ist vom Aufwand her so gering, dass ich es einfach nochmal neu erstelle. Ich würde niemals ein aufwendiges Terrain mit Vegetation erstellen, wenn die Spielemechanik nicht komplett wäre. Es würden immer nur die Objekte auf dem Terrain sein, die auch wichtig für die Mechanik sind. Da reicht es aus, einen kleinen Tümpel zu erstellen, um z.B. schwimmen gehen zu können. 3 Unterschiedliche Uferzonen würde der Tümpel bekommen, um gewisse Stelheiten zu haben und die Bewegungsmechanik darauf hin auszulegen. Ob der super realistisch aussieht, wäre mit jetzt noch komplett egal. Aber ich schreibe schon wieder viel zu viel. Du musst deinen eigenen Weg finden und du wirst irgendwann seber erkennen, was du vielleicht einmal als Asset abspeicherst, um es in einem neuen oder veränderten Projekt nutzen zu können. Als ich noch ganz jung war und ich mit meinem VC20 die ersten Spiele gebaut hatte, fing ich immer mit dem Intro und dem Spielmenü an. Leider sind die Spiele fast nie fertig geworden, weil sogut wie ich immer den Speicher gesprengt hatte. Aber ich hatte echt immer tolle Intros und Menüs!
  24. 1 point
    Willkommen! Also wir haben eigentlich keine feste Regel, wie deine Fragen gestellt werden sollten, also ob darin auch mehrere Fragen vorhanden sind. Wenn es so eine allgemeine Sache ist, wie hier in deinem Thema, ist es ganz ok mehrere Sachen zusammen abzuhandeln. Wird es spezifischer, solltest du für jeden Bereich ein neues Thema aufmachen. Denn das Forum lebt ja davon, dass man in den einzelnen Themenbereichen sucht und meist dann schon einmal eine passende Info bekommt. Sind in den Themen mehrere Fragen drin, kann es sein, dass eine wichtige Antwort nicht gefunden wird, weil sich der Titel vielleicht nur auf die andere Frage bezieht. Außerdem sollte jede Frage auch in dem richtigen Unterbereich des Forums gestellt werden. Sind unterschiedliche Bereiche in ein und demselben Thema drin, geht's schon los. Wir Moderatoren und Admins würden uns dann spätestetens Melden. Also: Für jede Frage bitte ein eigenes Thema aufmachen. Zum anderen Thema: Es ist ganz normal, dass man am Anfang einfach nur mit der Engine rum spielt. Dir scheint es zu gefallen, erst mal eine Landschaft zu bauen und da drin umher zu laufen. Ist ok. Wenn du aber immer wieder andere Dinge innerhalb einer Landschaft austesten willst, dann wäre es schon toll, dass du die Landschaft an sich als Asset abspeicherst. Dann kannst du sie immer wieder in einem neuen Projekt einladen und hast deine kleine Basis fertig. Andererseits ist es ja oftmals so, dass man unterschiedliche Genres testet. Da müsstest du natürlich jedes Mal neu anfangen, geht ja nicht anders. Die Frage ist halt: Möchtest du gewisse Mechaniken erlenen oder geht es dir vorallem um das Visuelle? Beim Visuellen ist es halt so, dass man alles baut. Wenn du aber der Meinung bist, dass du gewisse Teile gut wiederverwenden kannst, dann machst du dir als erstes ein Prefab draus um es in anderen Szenen dieses Projektes wider nutzen zu können. Hast du mehrere Dinge fertig, die man vielleicht gut zusammen immer wieder nutzen könnte, dann speichere sie als Asset auf deine Platte. Du hättest dann einen schönen Start für ein neues Projekt. Beim lernen von Mechaniken, würde ich fast gar keine Szenerie bauen, sondern nur mit wenigen Grundkörpern etwas basteln, damit es gerade mal so zum Testen ausreicht. Später, wenn du die Mechaniken gebaut hast und dann meinst dass daraus was werden könnte, solltest du dich um das Beiwerk kümmern. Aber auch jetzt noch nicht zuviel Energie afwenden. Erst wenn du sagen kannst, dass man die Spielerei jetzt zum vollwertigen Spiel machen sollte, solltest du dich um den Feinschliff kümmern. Auch Platzhalterobjekte oder noch unfertige Dinge kann man als Prefab speichern und/oder als Asset für spätere Projekte speichern. Ich empfehle dir außerdem nicht für jede Kleinigkeit ein neues Projekt zu starten, sondern einfach nur ein Spielerei Projekt, wo dann mehrere Szene drin sind, um gewisse Dinge unabhängig voneinander zu testen. Wenn du dir diese Prefabs erzeugt hast, kannst du sie ja auch immer in anderen Szenen nutzen. Und wenn bei deinen Spielereine dann etwas Gutes raus kommt, dann erzeugst du einfach wieder ein Asset, für spätere Projekte.
  25. 1 point
    Hi, ich bin geade bei meinem ersten Spiel (einem Space Shooter) , in dem es aber verschiedene Levels gibt. Ich habe mir für die Steuerung, Grundbeleuchtung und UI ein Standartlevel erstellt. Dieses ergänze ich je nach Anforderung und befülle die Layer mit Gegner, Hintergrund etc. Mal als Gegenfrage: was wird eingendlich der Sinn deines Spiel? Unity ist ja ein Werkzeug, welches benötigt wird, um ein Ziel zu erreichen. Mit einer Säge kann ich auch tagelang Bretter durchtrennen. Aber wenn ich die Bretter für nichts benötige, wird es sicher irgendwann etwas öde. Setzt dir doch ersteinmal ein Ziel - oder überleg, was für ein Spiel zu erstellen. Und dann versuche mit Unity dieses Ziel zu erreichen. Dabei werden Fragen kommen, welche du hier stellen kannst. In der Regel kann dir hier sicher jemand helfen. Ergänzung: Du erstellst dir ja eigene Prefab. Bei mir sind das z.B. die Gegner oder Teile des Hindergrund. Somit hast du ja die von dir genanten perönlichen Standart-Assets.
  26. 1 point
    Aber das ist doch genau das, worum es geht! Du must bei der Queue aber immer darauf achten, dass auch noch ein Objekt zum Aktivieren drin ist. Versuchst du nämlich eins zu aktivieren aber die Queue ist leer, dann haut's dir ne Fehlermeldung raus und im Build würde dir wahrscheinlich das Spiel abschmieren. Also immer auch den Count der Queue abfragen. if (diesUndDas && theCueueObjects.Count>0){ GameObject CueueObject= theCueueObjects.Dequeue(); CueueObject.transform.position = startingPoint.position; CueueObject.transform.rotation = Quaternion.identity; CueueObject.SetActive(true); } else{ // jetzt vielleicht doch ein zusätzliches Objekt instanzieren und der Queue zuweisen. // Oder aber warten, bis wieder was in der Queue drin ist. }
  27. 1 point
    Das geht solange alle Elemente der Liste durch und addiert dabei die jeweilige Spawn-Chance, bis diese Summe größer dem Zufallswert ist. Es könnte helfen, wenn du dir das mit ganzen Zahlen vorstellst. item: 0 | 1 | 2 | 3 | 4 roll: 0 1 2 3 | 4 5 6 7 | 8 | 9 | 10 11 12 Roll 0-3 bedeutet Item 0, 4-7 bedeutet Item 1, usw. Du gehst von links nach rechts durch. Dein Roll ist, sagen wir, 8. currentChanceSum ist 0. Erster Schleifendurchlauf: currentChanceSum (0) >= 8? Nein. Also rechnest du currentChanceSum += 4 (die Chance von Item 0). Zweiter Schleifendurchlauf: currentChanceSum (4) >= 8? Nein. Also rechnest du currentChanceSum += 4 (die Chance von Item 1). Dritter Schleifendurchlauf: currentChanceSum (8) >= 8? Ja. Also bist du bei Item 2 fertig und gibst es zurück.
  28. 1 point
    Der Name sagt schon genau das Gegenteil. Ich sehe auch, warum du das so aus dem Satz rausgelesen hast, aber da steht nur, dass damit Collider ignoriert werden - nicht, dass die Layer in der Layermask die ignorierten sind. Genau umgekehrt. Wenn du dich fragst, warum die das jetzt so in der Dokumentation formuliert haben, dann versuch mal denselben Satz in andersherum zu formulieren
  29. 1 point
    Hi, du brauchst nur die deutsche Version deines Posts. Wenn dir englisch lieber sein sollte, dann auch gerne auf englisch - beides gleichzeitig brauchst du nicht. Und bitte nur einmal posten Zum Thema... Das Tutorial ist ganz gut: https://catlikecoding.com/unity/tutorials/hex-map/part-1/
  30. 1 point
    Also, du hast ein Collider-Array und willst danach filtern, dass sie einer LayerMask entsprechen? colliders.Where(collider => ((1 << collider.gameObject.layer) & mask) != 0) sollte funktionieren. Vorausgesetzt, ich hab mich beim bitshift nicht vertan.
  31. 1 point
    Du kannst mit foreach über ein Transform iterieren, um einmal alle Kinder zu haben: foreach (Transform child in transform)
  32. 1 point
    Eben und mit der Idee kann ich auch das Problem des speicherns von Wetterdaten und Uhrzeit umgehen, wenn er schlafen geht kann sich alles verändern. Uhrzeit und Wetter werden dann beim Spielstart per Zufall generiert. Die Idee is denke ich sehr passend und spart an vielen Punkten sehr viel Arbeit. 😀
  33. 1 point
    Die Idee finde ich gut. Oder dein Charakter geht in eine Höhle, Schlafplatz oder was auch immer. So wie viele andere Spiele das auch machen. Damit verhinderst du auch ohne viel Denken, dass in deinem Charakter irgendwas dummes spawned.
  34. 1 point
    Du kannst Areale für Tiere machen, aus denen diese nicht herausdürfen. Beim "hetzen" laufen sie an der Grenze dann eben wieder zurück oder schon vorher in eine andere Richtung. Und dann kannst du die Entfernung vom Spieler zum Areal-Spawner messen oder so. Wozu ist es denn zwingend nötig, die Tierpositionen zu speichern? Du kannst ja auch einfach sowas wie "Menge an getöteten Tieren" pro Spawner speichern. Ist es für das Gameplay nötig, jedes Tier im Detail persistent zu speichern? Genau. Und da gibt es viele Ansätze. Aber um eine Art level of detail für die Messung wirst du wahrscheinlich nicht herumkommen. Du kannst aber die Abfragen der Messung in eine Queue packen und diese werden dann jeden Frame abwechselnd abgefragt. Also Update Frame 1 = Tier 1 - Tier 10 misst, Update Frame 2 = Tier 11 - 20 misst. Oder so in der Art.
  35. 1 point
    Nur ein paar Anregungen: Tiere kannst du mMn problemlos despawnen, wenn der Spieler z.B. weiter als x Meter entfernt ist und das vielleicht noch über eine Dauer von x Minuten Für das spawnen von Tieren und prüfen, ob diese schon oder noch da sind bzw. leben, brauchst du keinen Collider. Du packst dir einfach Referenzen in eine Liste oder so und kannst jederzeit abfragen, ob dein Tier schon oder noch lebt. Hierfür bekommt jedes Tier eine Eigenschaft Health. Wenn diese 0 ist, ist das Tier tot. Prozentualen Kram kannst du mit https://docs.unity3d.com/ScriptReference/Random.html machen Das mit der Entfernung messen kann komplexer werden. Aber grundsätzlich kannst du das Distanz messen für Spawner auf verschiedenen Frames ausführen und/oder erst pro Areal (1km² z.B.) prüfen, ob der Spieler darin ist und dann nur darin alle Prüfungen pro Spawner machen oder oder oder, nicht ganz trivial.
  36. 1 point
    Moin zusammen! Nach etwa einem Jahr Arbeit (mit Pausen... ) kann ich mein neues Asset Store-Paket vorstellen! Es handelt sich dabei um eine stark weiterentwickelte Implementation der Konzepte, die in diesem Talk vorgestellt werden: Um es kurz zu fassen: Damit könnt ihr extrem saubere Architekturen bauen, doch der Kniff ist: Ihr arbeitet hier mit Unity und nicht dagegen an. Das Paket ersetzt keine von Unitys Funktionalitäten, es gibt kein "das kannst du jetzt so nicht mehr benutzen". Es wird ausschließlich erweitert, was schon da ist. Ich sag mal so... ich arbeite nicht mehr ohne, seit ich das Ding für meine eigenen Projekte gebaut habe. Falls ihr euch jetzt fragt, wie das geht... ich könnte erstmal eine Menge schreiben, aber schaut euch besser den Talk an, der ist hervorragend. Hier geht's zum Paket: https://assetstore.unity.com/packages/tools/integration/soda-scriptableobject-dependency-architecture-137653 Bei Fragen gerne fragen!
  37. 1 point
    So, die erste Testrennstrecke ist fertig und der RaceController funzt auch so weit ganz gut. Endlich wieder racen. 😎
  38. 1 point
    Dein Graph oben zeigt eine einfache Exponentialfunktion. y = x * x. Der Timer zählt einfach die Sekunden seit Scriptstart (x) hoch. y ist dann x * x und wird noch mit einem Wert multipliziert, den du angibst, damit du kontrolle darüber hast, wie stark die Kurve ansteigt. Dann wird y von der Vitalität abgezogen. Wenn's da hakt, mach dir nicht zu sehr einen Kopf darüber, ist sowieso die schlechtere Lösung und eigentlich nur als Beispiel gedacht.
  39. 1 point
    Was du da hast, ist exponentiell (nicht logarithmisch), und das kann man recht einfach bauen. Hier einfach mal zwei Varianten. Variante 1: private float damagePerTick = 0f; private float damageIncreasePerTick = 0.1f; private void FixedUpdate() { damagePerTick += damageIncreasePerTick * Time.deltaTime; ApplyDamage(damagePerTick); } Variante 2: private float vitality = 100f; private float damageTimer = 0f; public float damageTimerMultiplier = 1f; private void Update() { damageTimer += Time.deltaTime; var actualVitality = vitality - damageTimer * damageTimer * damageTimerMultiplier; if (actualVitality <= 0) { Die(); } } Die erste Methode muss in FixedUpdate sein; wie alles, was nicht linear berechnet wird und von der Framerate unabhängig sein soll. In der zweiten Variante wird nur linear der Timer erhöht und dann von vitality abgezogen. Da vitality aber nicht geändert wird, ist das Ganze linear und kann auch in Update passieren, wenn du willst. Nachteil: Das Script braucht Zugriff auf die Vitalität, kennt dann die "richtige" Vitalität (abzüglich des Schadens durch Zeit), und kann deshalb nicht gerade gut lose gekoppelt werden. Ich würde daher zu Variante 1 raten.
  40. 1 point
    Hallo Leute, seit ca. 3 Wochen arbeite ich an einem kleinen Spielchen für Android und iOS und wollte meinen Fortschritt und meine Ideen einfach mal mit euch teilen. Spielmechanik Ganz simpel: Euer Charakter läuft von ganz allein, ihr müsst nur im richtigen Moment, also auf den Pfeilen, auf euren Bildschirm tippen. Tippt ihr zu spät oder zu früh, dann fliegt ihr leider in die Luft. Hier mal ein paar GIFs: MENU KLETTERN ROLLEN SPRINGEN STERBEN Was ist noch zu Tun ? Werbung einbinden Verschiedene Charaktere erstellen Shop implementieren
  41. 1 point
    Gut geschrieben. Ich bastel selbst gerade an einem neuen Projekt(allein). Ob es gut ankommt, oder ob sich jemand dafür interessieren wird, weiss ich nicht. Macht mir auch nix. Ich sehs als mein Hobby an. Ich hab schon mehrfach versucht Personen zu finden die einen helfen. Es gab viele Leute die sich gemeldet haben. Aber dann abgesprungen sind, weil ihnen der Aufwand zu hoch war. Verständlich... Aber ich bedankte mich trotzdem bei ihnen das sie es versucht haben. Ich hab ihnen vorher auch gesagt das es schwierig wird. Mein Standardspruch war immer wenn sie sagten es sei einfach. "Wenn es einfach wäre, gäbe es glaube verdammt viele Spiele von kleinen Machern". Gibt es leider aber nicht. Aber auf jedenfall bin ich äußerst dankbar über die rasche und hilfreiche Hilfe die ich hier im Forum bis jetzt bekommen habe. Warum ich das schreibe? Ich modelliere selbst gern und mir macht es Spaß. Außer beim Unwrappen und Texturieren, da hat sich die Faust schon öfters Richtung Bildschirm bewegt. Hatte mich anfangs auf realistisches Rendern fixiert(Blender, Cinema4D). Durch das Studium und paar Kollegen bin ich dann auf Unity gestoßen. Und hängen geblieben. Ich werde sicherlich probieren ein kleines Spielchen zu veröffentlichen. Aber wie gesagt, ob der Weg das gewünschte Ziel zeigt, weiss ich nicht. Ich interessiere mich halt für ganze Thematik. Und es frisst verdammt viel Zeit. Wenn ich noch ne eigene Familie hätte, würde sich die Zeit die ich dafür aufwenden könnte Richtung 0 bewegen. Und ich glaube auch, wenn die ganzen Leute die hier helfen, oder Hilfe suchen, oder auch die, die halbe Tutorials auf Youtube machen, mal ihre Fähigkeiten in einen Topf werfen würden. Und noch ein Organisator federführend über die Sache schaut. Dann käme glaube für mich das geilste Spiel aller Zeiten raus. :-) So gute Nacht
  42. 1 point
    @malzbi so sieht es aus. Alles jahrelange harte Arbeit, und selbst wenn die Workflows ausgereift sind, es gibt immer wieder was neues zu lernen. Die Technik entwickelt sich weiter, und damit die Anforderungen weil das verlangen nach Next-Gen genauso wächst. Ich würde sagen man sollte vor allem sehr sehr, seeehr klein Anfangen. So lernt man mehr weil man auch dinge zu Ende bringt und nicht dazu neigt bei jedem Problem aufzugeben. Im Grafikdesign (aus der Ecke komme ich Ursprünglich) habe ich gelernt man soll alles auf das Wesentliche Reduzieren. Wenn ich das mit Programmieren vergleiche, zerlege ich Projekte in viele Prototypes, wo man nicht genau weiß wie man das Problem zu lösen hat. Prototypen sollte man beherrschen, dadurch kann man auch realistisch abschätzen wie lange ein Projekt dauert, oder gegeben falls Hilfe benötigt. Vergleiche ich wiederum die Programmierung mit dem Design habe ich gelernt der Grafik eine Funktion zu geben. Der Kreis schließt sich für mich als Allrounder im Interaktiven am stärksten, weil dort eine Symbiose aus allen bereichen verlangt wird.

Announcements

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

Weiterleitung zum Entwickler "daubit"



×
×
  • Create New...