• Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011

Garzec

Members
  • Content count

    167
  • Joined

  • Last visited

  • Days Won

    1

Garzec last won the day on February 2

Garzec had the most liked content!

Community Reputation

4 Neutral

About Garzec

  • Rank
    Advanced Member

Recent Profile Visitors

704 profile views
  1. Naja mein Basiscontroller erbt ja von EnvironmentCommonController und irgendwann erbt der oberste Controller von Monob. Ich wollte nur fragen, ob dort Probleme auftauchen könnten, bzw. Dinge erst im Nachhinein kaputt gehen könnten. Aber sehr cool, danke
  2. Hi, ich habe ein Portal, das beim Betreten eine Szene lädt. Nun gibt es ja im Spiel mehrere Portale und doppelter Code ist bekanntlich doof. Mein Ziel ist also möglichst elegant eine Basis zu schaffen, um hinterher neue Portale " am Fließband zu erzeugen". Also habe ich folgende Struktur gebastelt, // Basis Controller public abstract class PortalCommonController : EnvironmentCommonController { protected PortalData data; protected PortalView view; protected void OnTriggerEnter(Collider col) { if (CheckCollision(col, data.PlayerObject)) LoadScene(data.SceneToLoad); } } // die Daten public class PortalData : EnvironmentCommonData { public PortalData(string sceneToLoad) { SceneToLoad = sceneToLoad; } public string SceneToLoad { get; set; } } // die View mit Animationen etc. public class PortalView : EnvironmentCommonView { } // das eigentliche Portal public class PortalHubWorld : PortalCommonController { private void Start() { data = new PortalData("Ingame"); view = new PortalView(); } } Da ich noch kein wirklich "erfahrener" Programmierer bin, möchte ich mal fragen, ob man tatsächlich OnTriggerEnter vererben kann. Ich habe es getestet, es funktioniert. Ebenfalls mit mehreren Portalen, zu unterschiedlichen Szenen. Es traten keine Fehler auf. Aber OnTriggerEnter ist ja ein Event, ist es wirklich so klug, es zu vererben? Der Code an und für sich ist ja für weitere Portale sehr überschaubar.
  3. Ja cool, direkt mal ausgelagert
  4. Ich vertraue darauf, dass es sich um Nanosekunden handelt und man niemals die Chance bekommen könnte, ingame einen Unterschied zu merken.
  5. Und wo wir grade schon dabei sind, kennt jemand die Methode ReferenceEquals? Ich hatte die grade in der C# Doku gefunden, die müsste doch eigentlich das gleiche machen. protected bool CheckCollision(Collision col, GameObject go) { return ReferenceEquals(col.gameObject, go); } protected bool CheckCollision(Collider col, GameObject go) { return ReferenceEquals(col, go); }
  6. @Sascha jap, hatte es schon oben aktualisiert Ich finde nämlich protected bool CheckCollision(Collision col, GameObject go) { return col.gameObject == go; } protected bool CheckCollision(Collider col, GameObject go) { return col == go; } in einer abstrakten Basis sieht eigentlich ganz überschaubar aus.
  7. Die Kollisionsabfragen von OnTrigger und OnCollision schreibe ich logischerweise mehrfach. private void OnTriggerEnter(Collider col) { if (col.tag == "Player") // irgendwas } private void OnCollisionEnter(Collision col) { if (col.gameObject.tag == "Player") // irgendwas } Diesen Code könnte ich ja auslagern. Was macht denn mehr Sinn, die Tags abzugleichen oder vielleicht sogar direkt if(col.gameObject == dasZuPruefendeGameObject) schreiben? Die Prüfung in eine abstrakte Basis auszulagern wirft aber das Problem auf, dass die Basis das zu prüfende GO nicht kennt. Aus diesem Grunde müsste ich also noch das GO als zweiten Parameter mitgeben. Beispiel: protected bool CheckCollision(Collider col, GameObject go) { return col == go; } Also nochmal die Frage, die Tags abgleichen mit nur einem Parameter oder direkt die GOs abgleichen aber dafür noch einen Parameter mitgeben müssen? Also klar, ich spare dadurch keinen Schreibaufwand ein, weil es ja schon ein Einzeiler ist, ich würde halt nur Codewiederholungen vermeiden.
  8. @GoldBaercheN exakt, den radialen Kreis kann ich mir schon dynamisch füllen Es geht nur noch um das grafische Zeug. @Sascha Ja, hätte ich wie bei Mario eine feste Anzahl von Lebenspunkten, würde ich eine Grafik drüberlegen. Da die maximale Anzahl an Lebenspunkten aber erstmal offen bleiben soll, wäre es perfekt, wenn man das im Script lösen könnte. Also pro "Abschnitt" ein übergeordnetes Image einzufügen, welches dann ein Tortenstück repräsentiert, wäre das eine Möglichkeit?
  9. Hi, ich habe eine radiale Healthbar, die sich aktualisiert, sobald sich das aktuelle Leben oder das maximale Leben verändert. healthBar.fillAmount = currentHealth / maxHealth; Soweit so gut. Nun sieht ein dynamisch gefüllter Kreis ja recht trist aus. Ich möchte den Kreis selbst zeichnen. Quasi eine eigene Painter-Klasse schreiben. Es soll kein Klon sein, aber ich glaube die Super Mario 64 Healthbar trifft meine Vorstellungen sehr gut. Wichtig wäre mir z.B., kleine schwarze Striche einzuzeichnen, um jedes "Stück" Leben abzugrenzen. Ebenso würde ich die Farben anhand des aktuellen Lebens anpassen. Bevor ich mit dieser Painter-Klasse anfange, ist sowas prinzipiell möglich? Eine genaue Idee zur Umsetzung habe ich nämlich noch nicht. Ich glaube mein Ziel wäre auch schon erreicht, sobald ich die schwarzen Abgrenzungen dort reinbekomme.
  10. So ich glaube die Bugs sind alle raus, außer dem "Kleben bleiben". Hängt die Platform in der Luft und ich springe dran, kann ich dort entlang rutschen. Aber danke für den Tipp mit dem Physik Material. Und ansonsten danke für den Rest, irgendwann muss ich auch mal den GroundCheck machen
  11. Äh ja mein ich doch Hatte mich grad selbst verwirrt, weil ich isJumping = false; an den Anfang von FixedUpdate schrieb, aber das hatte ja logischerweise wenig Sinn gemacht.
  12. @Sascha Ich hoffe du hattest dir solch ein Gebilde vorgestellt if (data.IsGrounded && data.JumpPressed) data.PlayerRigid.velocity = new Vector3(data.PlayerRigid.velocity.x, data.JumpPower, data.PlayerRigid.velocity.z); else data.JumpPressed = false; @Helishcoffe Wie kann ich denn dem Rigidbody ein Physikmaterial zuweisen Ich glaube du meinst dem Capsule Collider oder? Der hat aktuell noch gar keins. Und wegen dem Eiern, ich habe mal die Rotation auf der Y-Achse eingefroren.
  13. Ich kann ja mal den Code zeigen (Groundcheck habe ich nochmal rausgenommen, da dieser noch nicht ganz passte) private float turnSmoothVelocity; private float speedSmoothVelocity; private void Start() { data = new PlayerMovementData(); view = new PlayerMovementView(); } private void Update() { if (Input.GetButtonDown("Jump")) data.JumpPressed = true; } private void FixedUpdate() { data.IsGrounded = GroundCheck(); Vector2 inputDirection = (new Vector2(data.InputHorizontal, data.InputVertical)).normalized; if (data.IsGrounded && data.JumpPressed) { data.PlayerRigid.velocity = new Vector3(data.PlayerRigid.velocity.x, data.JumpPower, data.PlayerRigid.velocity.z); data.JumpPressed = false; } if (inputDirection != Vector2.zero) transform.eulerAngles = Vector3.up * Mathf.SmoothDampAngle(transform.eulerAngles.y, Mathf.Atan2(inputDirection.x, inputDirection.y) * Mathf.Rad2Deg + data.CameraTransform.eulerAngles.y, ref turnSmoothVelocity, GetModifiedSmoothTime(data.TurnSmoothTime)); data.CurrentMovementSpeed = Mathf.SmoothDamp(data.CurrentMovementSpeed, data.MovementSpeed * inputDirection.magnitude, ref speedSmoothVelocity, GetModifiedSmoothTime(data.SpeedSmoothTime)); data.PlayerRigid.velocity = transform.forward * data.CurrentMovementSpeed + Vector3.up * data.PlayerRigid.velocity.y; data.CurrentMovementSpeed = (new Vector2(data.PlayerRigid.velocity.x, data.PlayerRigid.velocity.z)).magnitude; } private float GetModifiedSmoothTime(float smoothTime) { if (data.IsGrounded) return smoothTime; if (data.AirControlPercentage == 0) return float.MaxValue; return smoothTime / data.AirControlPercentage; } private bool GroundCheck() { if(true) return true; return false; } GetModifiedSmoothTime ist zusätzlich für die Einschränkung in der Luft zuständig, damit man in der Luft nicht so große Bewegungsfreiheit hat, wie am Boden. Ich weiß jetzt nicht, wie wichtig das dazugehörige Kamerascript ist, da sich der Spieler relativ zu dieser bewegt Vector3 rotationSmoothVelocity; private void Start() { data = new CameraMovementData(); view = new CameraMovementView(); } private void LateUpdate() { data.HorizontalRotation += data.InputHorizontal * data.SensitivityX; data.VerticalRotation -= data.InputVertical * data.SensitivityY; data.VerticalRotation = Mathf.Clamp(data.VerticalRotation, data.YMin, data.YMax); data.CurrentRotation = Vector3.SmoothDamp(data.CurrentRotation, new Vector3(data.VerticalRotation, data.HorizontalRotation), ref rotationSmoothVelocity, data.RotationSmoothTime); transform.eulerAngles = data.CurrentRotation; transform.position = data.CameraFollowTargetTransform.position - transform.forward * data.DistanceFromTarget; }
  14. Hi, Ziel ist es, einen 3D Platformer / Jump n Run á la Mario 64 etc. zu entwickeln. Nun gibt es die Wahl zwischen CharacterController oder Collder mit Rigidbody. Ich hatte das Thema schonmal hier angeschnitten Nun ist es ja bei diesem Genre besonders wichtig, viele Kollisionsabfragen sehr genau durchzuführen. Plattformen, Klettern, Walljumps, Knockbacks, etc. .. Aktuell nutze ich den Collider mit Rigidbody, habe einen eigenen Groundcheck etc, dabei ist mir aufgefallen - Läuft man gegen eine Wand, kann es passieren, dass der Spieler dort hängen bleibt und man sich nur noch an der Wand entlang bewegen kann - Es kann passieren, dass er nach einer Kollision von selbst auf der y-Achse rotiert / eiert - Drücke ich kurz vor der Landung nach einem Sprung die Sprungtaste, springt er nach der Landung direkt wieder von alleine Ich habe aber immer noch die Hoffnung, dass mein Script einfach noch nicht optimal ist und all diese Punkte meine eigene Schuld sind. Der CC hat ja einen internen Groundcheck, da hat man manche Probleme schon automatisch gelöst. Ich überlege auf den CC zu wechseln, da dieser ja für "humanoide Charaktere" passend ist. Mein einziger Punkt, der mich davon abhält ist die Kollisionsabfrage. Wenn ich ein Jumppad mit einem Trigger habe, möchte ich, dass das Jumppad prüft, wer den Trigger betritt und falls dies der Spieler sein sollte, den Spieler beeinflusst. private void OnTriggerEnter(Collider col) { if (col.CompareTag("Player")) // mach irgendwas } So habe ich dann mit einem 2 Zeiler die Technik der Jumppads abgedeckt. Es geht dabei nicht um die Größe des Codes, nur darum welches Objekt welche Arbeit durchführt. Hat der Spieler den CC funktionieren die Trigger nicht, der Spieler wird durch den CC nicht erkannt. Dafür gibt es ja die Methode OnControllerColliderHit(ControllerColliderHit hit) aber die hängt ja am Spieler selbst. Natürlich kann ich sagen, ich habe dann Pech gehabt und die ganze Logik am Spieler. Aber nehmen wir mal an es gibt 10 Welten. dort gibt es Gegner, Geschosse, Jumppads, Powerups, Leitern etc. Vielleicht nicht viele, aber immer mal ein paar. Dann müsste ich ja über die als Parameter übergebene Variable "hit" prüfen, was genau ich da jetzt getroffen habe. Bleibe ich stehen und mich trifft etwas, wird zudem gar nichts ausgelöst. Und Trigger sind dann ja auch so ne Sache. Es gibt ja die Möglichkeit den Spieler extra dafür noch mit Collidern an den Beinen zu bestücken, aber ich bezweifle, dass dies Sinn der Sache wäre. Weil der CC ist ja schon ein Collider für sich. Es wäre sehr cool, wenn hier mal erfahrene Leute, neben @Sascha, ihren Senf dazugeben würden Ich bin nämlich grade echt am grübeln, was die Kollisionsabfragen dann angehen wird.
  15. So wie @Life Is Good das Codebeispiel gebracht hat, so bau ichs immer, nur halt mit Collider und Rigidbody und der Logik an den Objekten. Ich persönlich fühle mich damit wohler, einfach weil ich denke, die Platform muss wissen, welche Sachen sie zu transportieren hat (alle Dinge, die im Trigger stehen) und nicht jede Sache selbst Ebenfalls vielen Dank für den Hinweis mit Time.deltaTime @Life Is Good Da wäre ich wohl nicht drauf gekommen. Und @Sascha um die Performance mache ich mir auch keine Gedanken. Ich hatte nur gedacht in eine Methode einen string zu legen ist ja nicht so cool, falls man mal den Methodennamen ändert. Danke euch beiden