• 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

Sneyke

Members
  • Content count

    16
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Sneyke

  • Rank
    Member
  1. Ich glaube dass das nicht so gut ist. Mal angenommen jemand verkauft sein device. Der Käufer will sich zufälligerweise auch bei dir Registrieren. Das kann er dann aber nicht weil die deviceID schon mal genutzt wurde. Ich würde eher den klassischen weg gehen. Du kannst eventuell ein Snippet abspeichern in dem die Accountdaten verschlüsselt hinterlegt sind. Und im falle dass dieses existiert, darf kein weiterer Account erstellt werden. Falls jemand einen neuen Account möchte (der Käufer des gebraucht-Geräts), kann man auf "Account auf diesem Gerät freigeben" klicken. Dann werden alle Daten des Altaccounts vom Gerät entfernt und nur der neue Account kann genutzt werden. Klar könnte man immer wieder den Account freigeben und immer hin und her wechseln. Man kann es aber unendlich nervig machen zu wechseln. Am besten mit email und Verifizierung. Eventuell kann man auch ein kleines tool basteln dass auf "Mehrfach-Accountnutzung" prüft auf serverseite. Um dies endgültig zu vermeiden könnte man das gerät nach dem Freigeben für Account XY sperren.
  2. Ich würde dir nahe Legen erstmal ein paar Grundlagen zu lernen. Erstelle einfach mal ein C# Projekt in Visual Studio und such auf youtube mal ein Anfängertutorial. Meiner erfahrung nach geht Copy-Paste-Nix-Verstehen nämlich nur solange gut wie man mit dem zufrieden ist, was das Kopierte hergibt. Sobald "Änderungen" geplant und umgesetzt werden, geht nichts mehr weil man es schlicht und ergreifend nicht kann. Du musst kein C#-Guru werden. Aber mal ein, zwei Wochen intensiv mit der Syntax befassen wird dir schon sehr viel helfen.
  3. Das finde ich als Java-Entwickler echt interessant. Wenn man in Java eine Integer variable in eine Funktion übergibt, wird der Wert kopiert. In C# bekommt man anscheinend den Pointer. Oder ist das nur in diesem Spezialfall so? Auf jeden Fall wird die Lösung von Mr 3d funktionieren. Aber mal eine andere Frage: Wieso willst du da was mit Threads machen? Das sieht für mich aus als würdest du mit Parallelität nur Probleme an dieser Stelle bekommen. Ich würde das eher ganz einfach alles nacheinander machen. Gerade wenn du noch Turn und Level verwendest (ich vermute mal das sind globale Variablen), und du dort irgendwas änderst, gibt es Überschneidungen im Zugriff bei den Threads.
  4. Ich hab mir mal den Thread komplett durchgelesen. Richtig cool. Gibts eigentlich mal wieder was neues? Das letzte Update ist schon ein Monat her.
  5. Für C# generell habe ich mir mal das hier besorgt: https://www.amazon.de/Visual-Studio-2015-Objektorientierung-Programmiertechniken/dp/3836237148/ref=sr_1_1?ie=UTF8&qid=1500966151&sr=8-1&keywords=c%23+buch Ich finde es gut beschrieben und ist auch für Anfänger geeignet, da sehr viel erklärt wird. Auch geht es später mehr auf Professionelle Sachen ein. Mit diesem Buch hier habe ich mich in Java eingebarbeitet (Das wurde uns in der Ausbildung gestellt): https://www.amazon.de/Java-von-Kopf-bis-Fuß/dp/3897214482/ref=sr_1_1?s=books&ie=UTF8&qid=1500966231&sr=1-1&keywords=java+von+kopf+bis+fuß Wobei ich hier aber sagen muss dass mir es nicht tief genug ging. Es ist daher wirklich nur für Anfänger. Aber um die wIchtigsten Sachen mal angekratzt zu haben, gibts von mir ne klare Empfehlung. Falls du gleich ein wenig Professioneller gehen willst: https://www.amazon.de/Java-auch-eine-Insel-Java-Entwickler/dp/3836241196/ref=sr_1_2?s=books&ie=UTF8&qid=1500966492&sr=1-2&keywords=Java+buch+rheinwerk Ich habe das Buch aber nicht gelesen. Da ich aber davon ausgehe, dass das Niveau ähnlich dem C# Buch sein wird, habe ich es hier mal aufgelistet. Für Unity wird/wurde hier im Forum dieses hier empfohlen: https://www.amazon.de/Spiele-entwickeln-mit-Unity-3D-Games/dp/3446451978/ref=sr_1_1?s=books&ie=UTF8&qid=1500966267&sr=1-1&keywords=Unity+5.6 Wobei ich hier aber keine Erfahrung habe, da ich Unity über Google lerne.
  6. Du kannst andere Skripte ansteuern indem du dir eine Referenz (ein Objekt) holst. Hat ein GameObject, das in unserem beispiel "Court" heißt, ein Script das "Ball.cs" heißt, kann du dir dieses z.B. folgend holen: public GameObject court; // im Inspector zu befüllen private void doSomething(){ Ball ball = (Ball) court.getComponent<Ball>(); // Jetzt habe ich meine referenz ball.roll(); // Meine referenz macht irgendwas } Außerdem hier nachzulesen: https://docs.unity3d.com/ScriptReference/GameObject.GetComponent.html Als ich mich vor meiner Programierzeit mal mit Unity beschäftigt habe, hatte ich ein komplett falsches Bild vom Skriptsystem in Unity. Eventuell gehts dir ja ähnlich. Darum würde ich dir raten erstmal noch ein bissl Java zu lernen, wenn du sowieso schon dabei bist. 4-6 Wochen werden da schon Wunder wirken (meine Erfahrung).
  7. Ich kenne mich mit den Unity Netzwerksachen nicht aus. Aber ich könnte mir vorstellen dass hier ein simplerer Ansatz eventuell "smoother" wäre. Korrigiert mich wenn ich mit meiner Einschätzung falsch liege: Ich glaube die Netzwerk Bibliothek ist zu groß/schwerfällig/langsam für einen einfachen Ball, der in eine Richtung rollt, und dass möglichst in Echtzeit. Ich würde versuchen den Ball (also wirklich nur den Ball) in eine andere, schnellere Ebene zu holen. Am schnellsten wäre es natürlich einfach Peer to Peer über Sockets. Da würde es ja einfach reichen wenn du Startposition des Balls, Richtung (Vector) und eventuell noch die Geschwindigkeit versendest. Einfach die 5 floats in den Stream packen und flushen.
  8. Also wie es in C# geht weis ich nicht aus dem Stand. In Java startet man einen neuen Prozess ( new ProcessBuilder(bla.exe); ) und dann kann mit einem Inpustreamreader den Output von bla.exe auslesen. wenn du nach "c# run process and read output" googlest, kommen viele seiten wo sowas erklärt wird. Andere möglichkeit wäre "Shared memory". Damit hatte ich einer Firma zu tun die IBM Mainframes benutzt (und sich auf Bankensoftware spezialisiert hat). Da konnte man in COBOL auf geteilten Speicher zugreifen. War ne coole Sache.
  9. Eine Möglichkeit wäre den Schuss lokal durchzuführen und dann Server-seitig zu prüfen. Also erstmal abfeuern und etwas treffen. Wenn etwas relevantes getroffen wurde, überprüft der Server ob alles seine Richtigkeit hat, also ob es auch für den Server und für den/die getroffenen Spieler plausibel ist (Prüfen ob der getroffene Spiele nicht schon 10 Meter weiter gerannt ist, und der Schütze nur aufgrund eines Lags getroffen hat). In der Zwischenzeit kannst du ja lokal den Dingen soweit ihren Lauf lassen (Getroffener Spieler bekommt schaden, Animation, usw.). Falls der Server dann der Meinung ist, dass alles fair und richtig ist, kann er dann die restlichen Clients benachrichtigen. Falls nicht (sei es wegen Lags oder Hacks), wird der Ausgangs-Client kurz "zurückgespult". Also im Prinzip spielt dann jeder sein eigenes Spiel in Echtzeit abgekoppelt vom Rest. Falls ich aber lokal vorbeiballer, und das Projektil aufgrund der Verzögerung dann aber "in Wirklichkeit" doch etwas trifft, wird das einfach ignoriert. Weil das ja nichts mit meinem selbst gezielten Schuss zu tun hat. Das wäre auch generell nicht richtig nachvollziehbar. Es zählt nur das was der Server als Fair und Richtig deklariert. So ein ähnliches Verhalten kann man ja bei Netzwerkshootern beobachten.
  10. Ich werf für den TO einfach mal ein paar Begriffe/Sätze in den Raum: Server hostet meist der, der das Spiel betreibt vserver (virtual server) Wissen was Netzwerkprotokolle sind (TCP, UDP, ...) Sockets in Verbindung mit C# Das Standardbeispiel zum lernen was Netzwerkprogrammierung ist: Einfacher Chat-/Server/Client Jaja, Protokolle muss nur der kennen, der den Server selbst Programmiert, was pauschal 100 Jahre dauert . Schaden kanns aber trotzdem nicht. Dann weis man zumindest in etwa wie sowas funktioniert. Ich habe mir die "Fertig-Server" bis jetzt noch nicht angeguckt, bzw in Unity noch nichts mit Netzwerk gemacht. Werd ich aber bald mal nachholen.
  11. Coole Sache. Was vielleicht interessant wäre, wäre noch der vergleich zu z.B. einfach 1000000 Additionen auf deinem System. Weil ich weis jetzt nicht ob 150ms für Normalize viel sind oder nicht. Ist ja eigentlich ein nur durch seine länge teilen.
  12. Du setzt als allerletzten Befehl charakterTeleportieren auf true. Ich denke da wird zuerst dein Code ausgelöst, und hinterher dann der onTriggerEnter. Dieser setzt es dann wieder auf true, da du teleporterSperre in deiner if-abfrage am ende immer auf false setzt (womit die Bedingung in onTriggerEnter immer erfüllt sein wird). Am besten wie schon gesagt wurder einen Timer einbauen. Alles nach besten Wissen und Gewissen. Falls ich falsch bin, einfach widerlegen.
  13. Bei mir hat es mit circa 10 Jahren (~ 2000/2001) angefangen. Da habe ich zumindest angefangen mich ein wenig mit Modding von Games zu beschäftigen, da mein älterer Bruder das auch gemacht hat. Das war damals noch so zeug wie "Quake 3" und "Star Wars Jedi Knight 2". Danach kamen so mit 12-13 erste Minigames aus dem RPG-Maker. Doch wirklich etwas brauchbares kam da nie zustande. So zwischen 12 und 15 kam dann auch erste Programmiererfahrung in C++ dazu. Leider bin ich über Konsolen-Programme nie hinaus gekommen. Am Programmieren sollte ich zunächst das ernsthafte Interesse verlieren. Immer mal wieder habe ich es dennoch Versucht von vorne anzufangen, mit meinem C++ Buch von 2002. Erst nachdem ich (nach 3 Wochen) meine Kaufmännische Ausbildung beendet hatte (absolut nichts für mich), habe ich beschlossen wieder zu Programmieren und auch beruflich in diese Richtung zu gehen. Hierbei haben mir die, wenn auch wenigen, Erfahrungen aus meiner C++-Zeit sehr geholfen. Daran habe ich solch einen Gefallen gefunden, dass ich heute behaupten kann ein Passabler Java-Entwickler zu sein. Nach mehrfachen Anläufen in diversen Engines, habe ich es dann auch endlich geschafft mich ein wenig in Unity einzuarbeiten, dass ich nun meine Freizeit mit Basteleien füllen kann
  14. Danke fürs Feedback. Ja... die Groß- und Kleinschreibung... Da tu ich mir noch schwer, weil ich eigentlich aus der Java-Ecke komm. Daher kommt glaub ich auch mein double-Wahn (in Java sind floats irgendwie verpönt. Zumindest in den Firmen in denen ich bis jetzt war). Aber ich will mich nicht rausreden Ich wusste gar nicht dass Unity schon so viel von Haus aus mitbringt. Bezüglich der Fraktion stimme ich dir natürlich uneingeschränkt zu. Ich würde selbst sogar behaupten, String für sowas zu benutzen fällt unter "Bad Practice". Da Stringvergleiche (zumindest in Java) echt teuer sind, sollte man immer Enums benutzen. Aber für das Beispiel habe ich es bei einem String belassen. Ohne Worte... Sehr Peinlich Cool dass du dir die Mühe gemacht hast. Ich werde die Sachen übernehmen und dann das Tut nochmal überarbeiten.
  15. Danke für die Antwort. Hab mir auch Mühe gegeben . Eventuell habe ich ein bisschen wirr geschrieben am Anfang. Zu dem angesprochenen Problem: Genau das soll vermieden werden. Der Raycast wird in jedem Frame, von der aktuellen Position des Projektils, nur so weit nach vorne durchgeführt wie er innerhalb der Zeit von Time.deltaTime zurücklegen konnte (also ~ 0.001LE). Wenn es dabei etwas trifft, wird es in die Hitliste gelegt, wenn nicht, dann wird die Position aktualisiert. In der if-Abfrage sieht man ja wie "kurz" der Ray ist: if (Physics.Raycast(shot.Postion, shot.Direction, out hit, shot.Speed * Time.deltaTime)) Wenn man die Projektilgeschwindigkeit in meinem Code z.B. auf 1 setzt, dann sieht man einen kurzen, langsamen grünen Strahl, der so lange gerade aus fliegt, bis er was trifft oder Zerstört wird. Der Strahl an sich ist immer nur ein paar Zentimeter lang. Dafür muss man die Debug.DrawRay()-Zeile entkommentieren. Wenn ich daheim bin mach ich mal einen Screenshot dass man sich das besser vorstellen kann. Dieses Problem das du angesprochen hast, wäre aufgetreten wenn ich die "einzig halbwegs gute Idee" aus dem Internet übernommen hätte. Die hätten es nach genau dem Schema durchgeführt wie von dir beschrieben. Da ich mir sofort die gleichen Fehlerquellen eingefallen sind, habe ich mir dieses System ausgedacht. Nur komisch dass soweit bis jetzt noch niemand gedacht hat. Oder ich war nur unfähig zu suchen.