Jump to content
Unity Insider Forum

Zer0Cool

Members
  • Content Count

    1,962
  • Joined

  • Last visited

  • Days Won

    138

Zer0Cool last won the day on July 1

Zer0Cool had the most liked content!

Community Reputation

402 Excellent

8 Followers

About Zer0Cool

  • Rank
    Advanced Member
  • Birthday 01/04/1974

Profile Information

  • Gender
    Male
  • Location
    Germany

Contact Methods

  • Skype
    zer0f0rce

Recent Profile Visitors

7,901 profile views
  1. Ja, du musst auch nicht den ganzen Server "neu" entwickeln. Man nimmt beispielsweise einen Tomcat-Server (ist derzeit recht verbreitet), dieser läuft sowohl auf Windows als auch auf Linux problemlos. Im nächsten Schritt entwickelt man dafür beispielsweise ein Servlet (in Java) welches die Kommunikation mit den Clients implementiert. Das fertig programmierte Servlet wird dann auf den bereits laufenden Tomcat unter Linux deployed. Während der Entwicklung lässt man den Server dann lokal unter Windows laufen. Ein Servlet ist zumindest für kleinere Games völlig ausreichend, aber selbst größere Games könnte ich mir damit gut vorstellen, wenn man entsprechend die Skalierbarkeit mit einplant. Die Verwendung eines Tomcat hat auch den Vorteil das einige "sicherheitsrelevante" Mechanismen bereits implementiert sind und man sich darum nicht mehr im Detail kümmern muss. Zudem kann man in der Entwicklung ein "Hot-Deploy" einrichten wobei der Server nicht neu gestartet werden muss, wenn man Änderungen am Servlet deployen möchte.
  2. Ich kann dir nur berichten, dass es mit Java kein Problem darstellt. Mit C# unter Linux habe ich keine Erfahrung, lese aber gerade Mono und .Net Core wird unter Linux unterstützt. Nach meiner Erfahrung lässt man C# dann aber eher auf Windows-Servern laufen und die meisten Cloud-Anbieter bieten beide Servertypen an. Da jetzt Java und C# sich doch ziemlich ähnlich sind würde ich in deinem Fall dann eher in Java entwickeln.
  3. Ich vermute mal du hast die Bäume auf das Terrain gemalt... Ab einem bestimmten Abstand rendert Unity dabei nicht mehr die Bäume, sondern ersetzt diese durch einfache Billboards (die sind einfache 2D-Grafiken die sich immer zu der Kamera drehen) die das Terrainsystem automatisch erzeugt. Die Bäume werden dann über einen Billboard-Renderer gerendert. Du kannst einmal Testen, ob die grauen Bäume tatsächlich Billboards sind, indem du die Distanz ab dem die Billboards angezeigt werden verschiebst. Dabei müsst du den "Billboard Start" verändern: https://docs.unity3d.com/Manual/terrain-OtherSettings.html Leider kenne ich das Problem mit den grauen Billboards. Das Problem kann dabei folgende (mir bekannte) Ursachen haben: Deine Light-Settings in der Scene sind noch nicht korrekt eingestellt. Hier kann man beispielsweise die Lightmap für die Scene erzeugen (siehe "Generate Lightning"): https://docs.unity3d.com/Manual/Lightmapping.html Damit bekommen auch die Billboards eine andere "Beleuchtung": Eine andere Ursache war einmal die Fog-Einstellungen in Unity. War der Fog aktiviert, dann führte dies dazu das die Billboards quasi als im Nebel dargestellt wurden und damit grau wurden. Die Einstellung für Fog ist ebenfalls im Lightning-Fenster im Szene-Tab (oder bei HDRP im Post-Processing Profil). Du kannst ja mal schauen, ob hier ein Haken gesetzt ist. Sollte man hier die Einstellung verändert haben, dann kann es sein, dass man noch einmal all Texturen der Bäume bzw. das Asset neu importieren muss, damit Unity die Billboard-Texturen neu berechnet. Eine weitere Ursache (und auf diese Ursache würde ich tippen) kann das verwendete Baum-Asset sein, es gibt leider Assets bei denen die Erzeugung der Billboards über Unity nicht richtig funktionert, hier hilft es meist nur das Asset auszutauschen. Dabei kann das Problem die verwendeten Shader dieses Assets sein, das verwendete Baummodel oder allgemein ein "falsch" eingestelltes Asset. Es gibt auch "Lösungen" die dann den Billboard-Renderer manipulieren, aber meist erzeugt man dann damit nur andere Probleme (wie glänzende oder weiße Bäume in der Nacht etc.) Bezüglich der Shader, du kannst auch einmal prüfen, ob dein Baum-Asset einen der folgenden Shader in seinen Materials verwendet, wenn nicht, dann könnten die verwendeten Shader "inkompatibel" mit dem Unity-Terrain sein und so das Problem verursacht werden:
  4. Schwer zu erkennen, da ich den Inhalt einiger Variablen nicht kenne, normal sollten Input-Eingaben immer in der Update-Methode gemacht werden. Ansonsten bau doch mal ein Debug.Log ein und schau was bei dem Mausklick herauskommt: (siehe Scene-View) Vector2 moveToPos = playerPosition - direction * distance Debug.Log("Wir bewegen uns zu: " + moveToPos); Debug.DrawLine(new Vector3(playerPosition.x,playerPosition.y,transform.position.z) , new Vector3(moveToPos.x,moveToPos.y,transform.position.z), Color.red, 2.5f); rb2d.MovePosition(moveToPos);
  5. Habe es mal ausprobiert. Wenn du eine Texture mit 128x128 Pixel hast musst du die PPU auch auf 64 stellen. Damit erstreckt sich dieses Sprite nun über 128x128 Pixel im Game. Das Ganze klappt auch bei Texturen wie beispielsweise 512 x 64 (also wie bei deiner Healthbar). Dabei muss man bei der Healthbar ja nicht alle 64 Pixel "ausfüllen", da man die anderen Pixel ja über den Alphachannel ausblenden kann.
  6. zu 2) Der Gedanke dahinter ist denke ich, dass der Pixel eines Sprites exakt einem Pixel der horizontalen Bildschirmaufösung entsprechen sollen und damit auch die PPU ein ganzzahliger Teiler der horizontalen Bildschirmauflösung in Pixel sein sollten. Beispiel: Bildschirmauflösung: 1024x768 (ratio = 1.33) PPU = 64 = 64 Pixel pro Unity-Einheit damit 1024 Pixel / 64 Pixel = 16 Units (ein Unity-Würfel mit Scale 16) => Wir wollen also das 16 Einheiten auf den Bildschirm passen, damit 16 Sprites nebeneinander die volle Breite des Bildschirms in Pixel ausfüllen => damit die Ränder der 16 Unity-Einheiten links und rechts mit dem Bildschirmrand abschließen muss die Orthographic -Kamerasize wie folgt berechnet werden: (16 / 2) * 768/1024 = 6 (Camera ortographic size) Nimmt man nun beide Formeln und vermischt diese, dann kann man die Formel entsprechend kürzen: Number Units = W / PPU = 1024 Pixel / 64 Pixel = 16 Camera ortographic size = (16 / 2) * 768/1024 = ((W / PPU) / 2) * 768/1024 = (W / PPU / 2) * H/W = W / (PPU * 2) * H/W = W *H / (PPU * 2) * W = H / (PPU * 2) = H / PPU / 2 Damit ist das Spielfeld bestehend aus 16 Unity-Einheiten voll in der Kamerasicht (Viewport) und die 16 Sprites (64x64) in horizontaler Reihe sollten den Screen füllen So sieht dann das Ergebnis in Unity aus (16 Figuren-Sprites a 64 Pixel in einer Reihe nebeneinander = 64 * 16 = 1024 Pixel):
  7. Markier mal Vector3 und drück RMB und geh auf "Go to Definition" dann sollte er eigentlich in den struct Vector3 im Namespace "UnityEngine" springen. Theoretisch als test kannst du auch mal schreiben: public UnityEngine.Vector3 pos; dann sollte UnityEngine grau angezeigt werden und Vector3 diese blau-ähnliche Farbe. (wobei er bei dir oben die Namespaces auch nicht eingefärbt hat, hat er bei mir aber bei UnityEngine auch nicht gemacht)
  8. siehe auch https://docs.unity3d.com/ScriptReference/Physics.Raycast.html oder https://docs.unity3d.com/ScriptReference/Physics2D.Raycast.html
  9. Schau mal ob du hier: https://docs.unity3d.com/2017.3/Documentation/Manual/FBXImporter-Rig.html Animationtype auf "Humaniod" gestellt hast, wenn es dann immer noch nicht klappt nimm ein anderes Model.
  10. Wenn dein Hund-Png da mit einem non-kinematic Rigidbody2d verbunden ist müsste man sogar die FixedUpdate()-Methode verwenden.
  11. Ich geh mal davon aus, das die Distanz-Berechnungen und der Direction-Vector stimmt. Das solltest du mal mit Debug.Line prüfen. Ansonsten sehe ich du übergibst hier eine Mask (playerMask) und dann auch noch falsch, weil an der 3. Position die Distanz übergeben wird. RaycastHit2D hit2D = Physics2D.Raycast(transform.position,direction*distance, playerMask); Probier es mal so: Debug.DrawRay(transform.position, direction*distance, Color.green, 2f); RaycastHit2D hit2D = Physics2D.Raycast(transform.position, direction*distance);
  12. Ja was ich vorgeschlagen hatte funktioniert nur für ein Child des gleichen Typs, bei mehreren ist dann deine Methode gut.
  13. _slotImages.Add(GameObject.Find("ItemIcon").GetComponent<Image>()); _slotAmounts.Add(GameObject.Find("Amount").GetComponent<TextMeshProUGUI>()); Hab mir nicht alles im Detail angeschaut, aber hier durchsuchst du alle GOs nach dieser Komponente (und damit findet er vermutlich immer nur den 1. Button), was falsch ist, du willst ja nur das aktuelle GO durchsuchen. Hier gibt es diese Methode die ich verwenden würde: GameObject button = Instantiate(_slotButtonPrefab, _slotButtonCanvas.transform, true) as GameObject; _buttons.Add(button.GetComponent<Button>()); _slotImages.Add(button.GetComponentInChildren<Image>()); _slotAmounts.Add(button.GetComponentInChildren<TextMeshProUGUI>());
  14. GPU-Instancing muss man in Unity über eine Klasse (Script) ansteuern und spezielle Methode aufrufen, wenn du das mit diesem Shader nicht geplant hast, dann kannst du den ganzen Block aus dem Shader rauswerfen, da es nie benutzt wird. HDRP und LWRP haben bereits ihren eigenen visuellen Shader-Editor (Shader Graph) integriert, hab ich aber auch noch nicht benutzt, ist aber für 3D Artists ein wichtiges Tool was schon eine Weile überfällig war. Für das "normale" Unity (nennt sich glaub Built-In Unity Renderer) gab es aber auch schon visuelle Editoren, aber nicht von Unity selbst. Ich würde um einen performanten Shader zu schreiben auch einen Shader verwenden mit Fragment und Vertex Funktion, weil nur hier siehst du was der Shader intern so treibt. Bei der "fancy" Shaderlab-Syntax oder der Syntax von Surface-Shadern treibt er ggf. einige Sachen im Hintergrund was wieder ungewollt Performance kosten kann.
  15. Ja, es darf nur eine Start-Methode geben und dann quasi so void Start() { currentLevel = SceneManager.GetActiveScene().buildIndex; rb = GetComponent<Rigidbody>(); count = 0; SetCountText(); winText.text = ""; }
×
×
  • Create New...