Beiträge von TBn

    Hallo zusammen.


    Ich bastel immernoch an meinem Waffen Viewkick-System, das einen visuellen Recoil vermitteln soll. Es ist jetzt fast fertig, allerdings konnte ich das aktuelle Problem noch nicht knacken.
    Ziel ist das Viewkick-System (Video unten) so zu lassen wie es ist und sozusagen die FirstPersonCamera je nach Zahl der abgegebenen Schüsse zu rotieren, aber den Viewport ständig wagerecht zu halten. Das soll einen Viewkick zu Seite vortäuschen und mir komplizierte Berechnungen bei der Verwendung von AddControllerPitch/YawInput-Node ersparen.


    Ich hatte gehofft, dass ich eine Art Gelenk-Component zwischen CapsuleComponent und FirstPersonCamera einbauen und den Controller auf dieses Gelenk legen kann. Dann könnte ich das Gelenk rotieren wie ich es brauche, die Camera bewegt sich entlang der gewünschten Achse bei einem PitchInput und ich könnte die FirstPersonCamera entgegenrotieren, damit der Viewport immer waagerecht bleibt. Trotz intensiver Suche ist mir derzeit aber noch nicht einmal klar, ob das überhaupt so geht.
    Die Frage ist also ob das so möglich ist und wenn ja wie. Falls das nicht möglich ist, was muss ich machen, damit das Ergebnis wie beschrieben ist?



    Der aktuelle Stand ist folgender:


    https://youtu.be/n52cRtlrPaw


    Je nach Schussnummer wird ein Vektor-Variablensatz gewählt und dann der Linetrace gemacht. Gleichzeitig passiert eine Berechnung für Wert des Viewkick nach oben und dann eben der AddControllerPitchInput. Der Blaue Linetrace ist die gedachte Basis für beide Systeme, also einmal Ausgangspunkt für das Schussbild und Viewkick. Letzterer läuft wieder auf diese Basis zurück, wenn man aufhört zu schießen. Bis auf die gemeinsame Basis haben Schussbild und Viewkick nicht smiteinander zu tun, man könnte eines abschalten und das andere funktioniert noch wie gehabt.



    Gruß Tornado

    Dein Problem ist als "gelöst" markiert. Ist das der Fall?


    Falls nein hätte ich da ein paar Fragen:


    1. Bild:
    Was hat der erste LineTrace für eine Aufgabe?
    Ist das so gewollt, dass der Endpunkt dieses LineTraces nur ein Richtungsvektor mit Länge 100k Einheiten ist?
    Wenn ja, funktioniert das wie gewünscht?
    Gibt der "ForEachLoopWithBreak" nach diesem LineTrace am Ausgang "Array Element" etwas aus, auch wenn die "ForEachLoopWithBreak"-Node nicht angesteuert wird?


    Zum "Mirror Vector" Problem: Ich vermute, dass der Impact Vector der Gegenvektor zum Forward Vector des Charakters ist. Das könnte der Grund sein, weshalb es Deinen Charakter in die Richtung zurückwirft, aus der er gekommen ist. Du müsstest mit dem Pin darüber arbeiten und dann eine Rechnung aufstellen, die den Impact Vector entsprechend dem "Einfallswinkel" rotiert und Dein Charakter dann in die neue Richtung gelauncht wird. Du kannst da entweder mit gleichschenkligen Dreiecken oder mit Vektorrotation rechnen.


    2. Bild:
    Soweit ich das feststellen kann, willst Du einen 2. LineTrace von der Wand aus in die Richtung gezeichnet haben, in die der Charakter zuerst gedreht und dann gelauncht werden soll. Funktioniert der LineTrace wie gewünscht?

    Fall es jemanden interessiert hier mal mein Lösungsweg für den damaligen Stand zum Zeitpunkt der Frage.


    Ich habe 3 Floats erstellt, die folgendes speichern:
    - Rotation der First Person Camera insgesamt(aufwärts)
    - Rücklauf der Rotation (abwärts) pro Tick (Defaultwert)
    - Rücklauf der Rotation (abwärts) pro Tick (variierbar)
    Letzterer kommt zum Einsatz, wenn der Restrücklauf < Defaultwert.



    Das ganze läuft dann folgendermaßen ab:


    Bei einem einzelnen Schuss rotiert die First Person Camera je nach eingegebenem Wert bei AddControllerPitchInput entsprechend nach oben. Der gleiche Wert wird in meinem Fall negiert und zu RotationInsgesamt addiert. Sobald RotationInsgesamt >0 setzt der Rücklauf ein, der so lange ausgeführt wird, bis RotationInsgesamt wieder 0 ist. Der Rücklauf selbst und die Rechenlogik hängen beide am Tick-Event und werden immer vor dem nächsten Rücklauf-Schritt gecheckt.
    Wenn man jetzt aber Dauerfeuer schießt, wird der nächste Schuss ausgelöst, bevor der Rücklauf des vorigen Schusses fertig war. Es wird also wieder der bei der AddControllerPitchInput-Node eingestellte Wert zu RotationInsgesamt (negiert) draufgerechnet und der Rücklauf setzt sich danach fort. Da der Spieler die Schussrate händisch (Mausklick für jeden Schuss) reduzieren kann, habe ich noch ein Compare eingebaut um zu überprüfen, ob RotationInsgesamt kleiner als der Default-Rücklauf, aber größer als 0 ist. In dem Fall wird nicht der Default-Rücklauf verwendet, sondern der Rest von RotationInsgesamt. Das dient dazu, dass die Abwärtsbewegung genauso groß ist wie die Aufwärtsbewegung.

    Soweit ich das jetzt verstanden habe bekommt man von ConvertMouseLocationToWorldSpace eine Positionskoordinate, die auf dem Nullpunkt der FirstPersonCamera liegt und einen normalisierten Richtungsvektor, den Ihr sicherlich verlängert habt. Damit habt Ihr dann einen Endpunkt, auf den Ihr Euer Kanonenrohr ausrichten könntet.
    Kontrolliert am besten mal sämtliche Skalierungen diesen Bereich betreffend, nicht dass die Ausrichtung der Kanone eigentlich stimmt, aber durch die Skalierung verzerrt wird.


    Vielleicht kannst Du da noch ne brauchbare Info rausziehen:

    Ich wollte schon sagen es sähe so aus, als würde der Curser auf der Winkelhalbierenden zwischen Kanonenrohr und dem roten Pfeil liegen, aber das trifft nicht immer zu. Gerade beim Runterfliegen scheint es anders zu sein.


    Ihr habt doch per ConvertMousePosition-dingens Koordinaten zum darauf zufliegen geholt und den Punkt nach vorne verlegt. Versucht doch mal diese Linie und den Endpunkt sichtbar zu machen, vielleicht hilft Euch das weiter. Es kann ja sein, dass die Kanone tatsächlich auf diesen Punkt zeigt, der aber aus welchen Gründen auch immer weit vom Curser weg liegt.
    Ich weiss ja nicht, was diese ConvertMousePosition...-Funktion für Daten ausgibt und was passiert, wenn man die mit einem Skalar multipliziert. Es wird wohl ein Richtungsvektor sein, aber von wo aus und vor allem in welche Richtung wird der verlängert?


    Aktuell bewegt sich der Turret mit dem Schiff so wie es sein soll, jedoch dreht er sich nicht richtig, je nachdem wie das Schiff ausgerichtet hat dreht er sich in komplett falsche Richtungen sofern das Schiff nicht nach vorne zeigt.
    Wenn es gerade ausgerichtet hat scheint es zu funktionieren.


    Das lustige ist auch das der Turret nach hinten zeigt wenn ich zu weit mit der Camera hinten bin, dachte zunächst das es beim rauszoomen dazu führt das der Vorhaltepunkt von 5000 Meter nicht mehr stimmt aber lustiger Weise bewegt sich der Turm kaum noch wenn ich den Wert 5000 erhöhe...rätselhaftes Verhalten.

    Das erste hört sich an, als würde das Turret versuchen IMMER auf der XY-Ebene zu drehen, die das Schiff beim Spielstart hat. Wenn das Schiff auf dem Kopf steht, müsste sich das Turret in die entgegengesetzte Richtung drehen und wenn es genau auf der Seite liegt, gar nicht? Kann das sein?


    Beim 2. Problem vermute ich, dass das Turret nach hinten zeigt, weil der Punkt der Lookat Funktion komplett herausgezoomt hinter dem Turret liegt und dann erst in diese Richtung um 5000m verlängert wird.

    Vielleicht nochmal anders:


    Ich möchte nach einem Schuss wie gesagt ein Viewkick haben (First Person Camera bewegen), der 2° instant nach oben geht und dann nach 0.07 Sekunden wieder unten ankommt. Ich habe das Problem, dass ich es bisher nur per SetControlRotation hinbekommen habe, dass Anfangs - und Endpunkt des Viewkick genau gleich sind. Leider sind während dem Rücklauf keine Mauseingaben möglich.


    Wenn ich die Aufwärtsbewegung per SetControlRotation und die Abwärtsbewegung per AddControllerPitchInput ausführe, komme ich trotz Korrekturwerte nur annähernd auf den Gleichen Punkt. Mal passt es wunderbar, mal zu hoch, mal zu tief. An was könnte das liegen? Ungenauigkeit durch Runden von Zahlen?


    Wenn ich beide Bewegungen über AddControllerPitchInput versuche, liegen Anfangs - und Endunkt weit auseinander. Ich habe versucht das mit Korrekturwerten auszugleichen, aber es haut nicht hin. AddControllerPitchInput hat wohl auch ein Problem mit sehr kurzen Timelines, da bewegt sich dann auch mal gar nichts.
    Die ursprüngliche Idee war, dass ich die First Person Camera über eine Timeline und RInterpToConst in 0.01 Sekunde um 2° hochschwenke und danach über eine 2. Timeline und die gleiche Funktion in 0.07 Sekunden wieder um genau 2° herunterschwenke. Funktioniert hats nicht. Entweder waren die Bewegungen instant oder wurden nur teilweise ausgeführt. Brauchbare Informationen zu dem Bereich habe ich bisher nicht gefunden.


    Es ist auch ein Unterschied, ob ich mit SetControlRotation Pitch um 2° ändere oder mit AddControllerPitchInput. Bei AddControllerPitchInput ist die Bewegung nur doppelt so weit. Weiss jemand warum?



    Muss man eine Pause zwischen zwei Controller Inputs machen, damit die sich nicht teilweise oder auch ganz aufheben? Kann da jemand eine Lektüre empfehlen?

    Servus.


    Mal eine blöde Frage zu Bild3 in Deinem Beitrag #4:


    Für mich sieht das so aus (ohne verstanden zu haben, was im Kommentierten Bereich "Turret Sockel" genau passiert), als würdest Du vom 0-Punkt des "Arrow Sockel" zum "Turret Sockel" einen Linetrace zeichnen wollen, allerdings holst Du Dir dann vom Turret Sockel die Rotation und davon dann den Vorward Vektor und addierst den warum auch immer mit 500. Mich würde an der Stelle interessieren, was mit der Addition bezweckt werden soll.


    Grundsätzlich kannst Du einen Linetrace zwischen 2 Punkten zeichnen lassen, das ist kein Problem.
    Du hast in Beitrag #6 geschrieben, dass Du einen Linetrace von 1000 Einheiten Länge nach vorne aus Deiner Kanone haben willst. Kriegen wir hin.


    Als erstes brauchen wir den Anfangspunkt für den Linetrace. Das ist z.B. der Nullpunkt des Koordinatensystems Deines Kanonenrohrs.
    Dann brauchen wir entweder den Endpunkt, den wir entweder direkt oder über einen Richtungsvektor (z.B. Forward Vektor) mit bestimmter Länge angeben. Da Du überall hinschießen willst nehmen wir letzteres.
    Das bedeutet wir definieren den Endpunkt des Linetrace über den Anfangspunkt (den wir kennen) und die Richtung samt Entfernung (die wir auch kennen bzw. festlegen).


    Das sieht dann so aus (Statt Capsule Component muss bei Dir dann das Kanonenrohr rein):






    Zu Deinen anderen Problemen kann ich Dir leider nichts sagen, ich habe sie nicht wirklich erstanden.

    Hallo zusammen,



    ich beiße mir derzeit die Zähne am Recoil aus. Ich habe einige Videos gesehen, wo mit Zufallswerten und Add Controller Input gearbeitet wird, aber das will ich nicht. Ich will auch keinen völlig randomized Recoil und die Recoil-Animation der Waffe kommt erst viel später.



    - UE 4.18.3
    - Windows OS, First Person Shooter Template,
    - Bei der Standardwaffe habe ich das Projektil entfernt, LineTrace wird verwendet


    Angedacht ist eine Aufwärts - und Abwärtsbewegung des Bildschirmes (View Kick / Aim Punch), der einen Recoil vermittelt. Ich denke der Einfachheit halber reicht es, wenn ich es für Pitch verstanden habe.


    1.) Es soll allerdings so sein, dass die Aufwärtsbewegung instant ist (wovon man bei ca. 0.01 Sekunden max. Zeit dafür wohl sprechen kann), für die Abwärtsbewegung ist mehr Zeit (ca. 0.07 Sekunden). Der Knackpunkt ist, dass beide Bewegungen die gleiche Strecke (oder gleicher Winkel, Rotation, ...) haben sollen, damit ich nach dem Schuss wieder genau auf dem Ausgangpunkt bin. Die Bewegungen sind also unterschiedlich schnell.


    2.) Als Zusatz wäre es gut, wenn die Abwärtsbewegung des vorigen Schusses gestopt werden kann und die Aufwärtsbewegung für den nächsten Schuss an dieser Stelle losgeht (und damit sozusagen stacked). Nach dem letzten Schuss solls dann zum Anfangspunkt des allerersten Schusses zurücklaufen. Ich vermute mal, dass ich das auch selbst ausknobeln kann, wenn ich den ersten Teil verstanden habe, aber wenn zufällig gerade jemand weiss wie das geht hilft mir das sehr.


    Ich habe bisher mit Add Controller Input, Set Control Rotation, Lerp, Timelines und RInterp herumgespielt, bin aber immer mit unterschiedlichen Bewegungslängen herausgekommen. Ich habe einige Stunden gesucht und Videos angeschaut, aber geholfen hat es nicht. Falls jemand ein Buch / Tutorial / Quelle für diesen Bereich kennt, wäre ich da auch dankbar.


    Gibt es Mindestlängen für eine Timeline oder sowas?
    Was muss man auf jeden Fall beachten, wenn man gegenläufige Controller Inputs in so kurzer Zeit macht?



    Ich danke schonmal für die geopferte Zeit.

    So, hab's hinbekommen und glücklicherweise ohne herumgefrickel mit Korrekturwerten. Es hat eine Weile gedauert, bis ich das nötige Wissen aus Analytischer Geometrie und UE4 gefunden und verstanden habe.
    Die beiden Multiplikator-Nodes nach Vertical - und HorizontalBulletClimb dienen mir aktuell zum Skalieren des Schussbildes. Ich werde die später entfernen und gegen entsprechend hohe Werte in den Settern der beiden BulletClimb-Variablen ersetzen.


    Problem gelöst.


    Gruß und schönes Restwochenende.

    Ich werde da bestimmte Werte gegenrechnen müssen, damit das Schussbild nicht mehr verzerrt wird. Am Wochenende geht's da weiter. Unter der Woche kann ich abends nur noch im Schrittempo denken :D.


    WarsheepGER: Du hast sicherlich recht, dass das auch ein Vorzeichenfehler ist, gerade wenn man nach hinten schaut und das Schussbild auf dem Kopf steht. Ursprünglich dachte ich es wäre horizontal UND vertikal gespiegelt, es stellte sich aber heraus, dass es nur hoizontal gespiegelt war.
    Es spielt aber auch noch etwas anderes mit hinein, denn wenn ich nach rechts & unten schaue und schieße, steht das Schussbild in Richtung X+ (WorldRotation) schief.


    Die Tage hatte ich nochmal ein paar Stunden nach Lösungen gesucht, aber selbst im englischspracheigen Bereich war da nichts zu finden. Scheinbar bin ich der einzige Assi, der das unbedingt so haben will.
    Egal wird schon :).


    Schönen Abend

    Soweit ich weiss feuert der ForLoop nach einem Eingangsimpuls so oft einen Ausgangsimpuls wie man es eingestellt hat und das so schnell wie möglich.


    Ich verstehe nicht ganz wie ich den ForLoop einsetzen soll. Der ForLoop soll sicherlich vor den Linetrace, aber da würde er den einzelnen Impuls ja nur vervielfältigen. Für Schrotflinten leuchtet mir das ein und wird sicherlich auch so eingebaut wenn die dran sind, aber für ein Sturmgewehr mit einer bestimmten Feuerrate?

    Hallo Annubis.


    Es soll ein erlernbares (festes) Schussbild für ein Sturmgewehr werden. Das Bild "Schussbild Worldrotation X+" zeigt das entstandene Schussbild nach 30 Schuss Dauerfeuer ohne händische Kompensation durch eine Mausbewegung.
    Bezogen auf das Schussbild sind Random-Werte absolut unerwünscht und das Schussbild soll aus dem Crosshair hinauslaufen (können).


    Ich habe vor das so zu basteln, dass das Crosshair die ersten 2 oder 3 Schüsse mit nach oben wandert. Vermutlich lasse ich diese ersten Schüsse jeweils mitten ins Crosshair gehen und nicht nur den ersten. Der Viewkick simuliert dann (nach diese 3 Schuss) weiter den Rückstoß, bleibt aber auf seiner aktuellen Höhe, während die Schüsse immer weiter nach oben gehen (ähnlich cstrike, aber halt gänzlich ohne jede Randomness).
    Ich hatte dieses Schussbild schonmal mit der AddControllerPitch / Yaw gebastelt was auch funktioniert hat, aber ich will nicht, dass der Viewport so weit nach oben getrieben wird.


    Ja, ich will den Endpunkt der LineTraces versetzen und das wenn möglich (beim jeweiligen LineTrace) absolut zum aktuellen Bildschirmmittelpunkt (wo das Crosshair sitzt). Absolut soll die Trefferpunktlage deshalb sein, damit ich einen bestimmten Schuss (z.B. Schuss Nr. 20) einfach an die gewünschte Stelle schieben kann, ohne die nachfolgenden Schüsse zu beeinflussen.


    Gruß

    Guten Abend Warsheep,


    erstmal danke für die Antwort.


    Ich habe den Output-Value von GetForwardVector gesplitet und jeweils ein "Absolute" drangehängt. Wenn ich Dich richtig verstanden habe sollen an dieser Stelle alle negativen Werte (immer) in positive geändert werden.
    Weiter bin ich noch nicht und das Schussbild geht momentan nur noch in +X-Richtung und +Y-Richtung. In Y-Richtung ist es noch so verkorkst wie anfangs, da wurde ja noch nichts geändert (kein Anstieg des Schussbildes in Z-Richtung, X+Y funktioniert).



    Meine Fragen:


    Wenn ich die WorldLocation oder den ForwardVector prüfen soll, sind damit jeweils die einzelnen Floats gemeint?
    --> Falls ja sollen dann nur die Values mit den entsprechenden Vorzeichen geändert werden oder alle?


    Diese Values zu prüfen und ggf. zu negieren ist kein Problem, aber was hat es mit dem Rotate und Vector (groß & gelb in Deiner Antwort) auf sich?



    Ich wäre Dir sehr dankbar, wenn Du da nochmal ins Detail gehen könntest.

    Hallo kyodai und danke für Deine Antwort.


    Die Werte für beide Bullet-Climb Variablen sind für jeden Schuss festgelegt und werden per Multigate & Set-Funktion für den nächsten Schuss entsprechend gesetzt.
    Die aktuelle Blickrichtung der Camera wird nicht geprüft, sondern nur für Anfangs - und Endpunkt des Linetrace verwendet (siehe "graph1").
    Sie (Bullet-Climb) verändern
    lediglich den Vektor für den LineTrace absolut (nicht inkremental) zur
    Bildschirmmitte, indem sie zum aktuellen Vektor addiert werden. Das
    betrifft aber nur die Y und Z-Achse, es wird nichts um die X-Achse
    rotiert.




    Vermultich multiplizierst du irgendwo mit X oder Y und wenn dann X oder y einen negativen wert haben kommt was anderes raus als positiv, also offensichtlich das exakte Gegenteil. Sowas in der Richtung...

    Ja, wenn ich mir den Forwardvektor anzeigen lasse und nach hinten schaue sind X und Y vertauscht, deshalb ist sicherlich das Schussbild auf beiden Achsen gespiegelt. Die Frage ist wie ich das umgehe.
    In dem Bereich bin ich noch nicht durchgestiegen und ich habe auch noch keine wirklich brauchbare Quelle gefunden, die das gut erklärt und in die Tiefe geht. Die UE4 Doku ist da leider auch recht oberflächlich.

    Hallo zusammen,


    als allererstes muss ich mal sagen, dass ich sehr froh über dieses Forum bin. Mein Englisch ist nicht das schlechteste, aber wenn es dann so in's technische geht komme ich an meine Grenzen.



    - UE 4.18.2
    - Windows OS, First Person Shooter Template,
    - Bei der Standardwaffe habe ich das Projektil entfernt, LineTrace wird verwendet
    - Es gibt noch keinen Waffenrückstoß und dieser wird später auch keinen Einfluss auf das Schussbild haben. -> Beim Schießen zuckt derzeit nix und das soll auch so sein.



    Ich habe vor wenigen Wochen angefangen mich mit der UE4 zu beschäftigen, weil ich meinem Entwickler soweit mir das möglich ist helfen will. Bisher habe ich nur als Betatester fungiert und bin was das Entwickeln selbst angeht ziemlich unbelastet. C++ Kenntnisse habe ich absolut keine, dafür weiss ich ziemlich genau, wie das Ergebnis später mal sein soll und welche Features ich brauche.
    Da ich in der Unreal Engine Logikschaltungen ohne C++-Kenntnisse zusammensetzen kann konzentriere ich mich darauf, optischen Kontent werde ich wohl nicht herstellen.


    Ziel ist es eine Waffenlogik (und ein festes Schussbild) zu erstellen, die ich umfangreich einstellen kann. Momentan hänge ich an dem Problem, dass ich den Linetrace zwar nach jedem Schuss an die vorgesehene Stelle bekomme, das aber nur in Worldrotation X-Richtung richtig funktioniert. Drehe ich den Player um 180°(also nach hinten), ist das Schussbild auf den Kopf gestellt.


    Das Bild "graph1" zeigt den Teil der Waffenlogik, der Start - und Endpunkt des LineTrace festlegt, sowie je eine Wert für den vertikalen und den horizontalen Versatz (absolut zur Bildschirmmitte) einfließen lässt.
    Nach dem Linetrace kommt ein Multigate, wo nach jedem Schuss der Wert der Variablen (vertical & horizontal bullet climb) neu gesetzt werden ("graph2" übersichtshalber).
    Davor kommt die derzeit vorhandene Waffenlogik, die funktioniert wie sie soll und erst nach der Lösung des aktuellen Problems erweitert wird.



    Meine Frage ist wie bekomme ich das hin, dass das Schussbild immer wie in X+ Richtung aussieht, egal wohin ich schaue und schieße?



    Ich danke schonmal für die geopferte Zeit und wünsche einen schönen Abend.

    Hallo zusammen,


    ich bin kein Entwickler, aber ich habe eine Weile lang ein Entwicklerteam als (hobbymäßiger) Betatester unterstützt und hier und da die Community betreut. Ich musste im Prinzip dabei zusehen, wie sich die Truppe verrannt hat. Schön war das nicht, denn es hatte was von einem verendenden Reh, das man mit dem Auto angefahren hat. Das Spiel wurde übrigens auf der Source Engine gebaut.


    Die größten Fehler waren m.E. die mangelhafte Kommunikation, das "machen lassen" von einzelnen Entwicklern und die Unklarheit unter den Entwicklern wie das finale Produkt in etwa aussehen soll, was in der Vermischung von grundverschiedenen Konzepten resultierte.


    Die mangelhafte Kommunikation hatte in erster Linie zur Folge, dass nicht alle an einem Strang zogen, weil jeder im Prinzip seine eigene Version des Spiels vor Augen hatte. Der Eine wollte es langsam und anspruchsvoll, der andere schnell und mit vielen tollen Effekten und der Nächste hatte wieder etwas ganz anderes im Sinn. Im Endeffekt wurden so mehrere Konzepte miteinander vermischt, bis dann überhaupt nichts mehr funktionierte. Es ist wie wenn man in einem Kreis steht, jeder ein Seil in der Hand hat und die in der Mitte verknotet sind. Jeder zieht an seinem Seil, der Knoten wandert hierhin und dorthin, aber er bleibt im Grunde wo er ist. Es geht einfach nicht weiter und man hat dann oft vorhandenen Content mit hübscherem Content ersetzt obwohl sich kein Spieler entsprechend beschwert hatte.


    Ebenfalls schlecht war der allgemeine Informationsfluss von oben nach unten. Man (Tester und Moderatoren) wusste nie so genau, wie eigentlich gerade der Stand war und wie es weitergeht. So lief man immer mal wieder beim Versuch die Community bei der Stange zu halten in eine Wand. Das sieht erstens saumäßig dumm aus und es verärgert auch die Mods, weil es einfach nicht sein müsste. Auch kam es immer wieder vor, dass verschiedenste Dinge auf den allerletzten Drücker gemacht werden mussten (obwohl man sie ordentlich hätte vorbereiten können), weil ein Entwickler es nicht für nötig hielt die Supportebene rechtzeitig oder überhaupt zu informieren. Tester hatten wir einige, die waren aber über den ganzen Globus verstreut und da braucht es nunmal einige Tage Vorbereitungszeit, wenn man da vernünftig testen will. Falls ihr Tester um euch scharen könnt, bindet die gut ein, damit die wissen was gerade läuft und wie der Zeitplan ist. Die sollen auch nicht die Lust verlieren, denn es dauert auch immer eine Weile, bis die wissen wie was gemacht wird und wie sie das Feedback aufbereiten müssen, damit es für einen Entwickler wirklich brauchbar ist.


    Ein weiterer großer Punkt war das "machen lassen" eines neuen, fleißigen Entwicklers in dem kleinen Team. Nachdem dieser sich eingearbeitet hatte, sollte er eigentlich erst einmal die eine oder andere Map Clippen. Damit hat er auch angefangen, aber plötzlich hat er die halbe Map umgebaut. Er wurde zwar angehalten so etwas nicht zu machen, die Änderungen blieben jedoch. Das Resultat war aus Sicht der Tester (waren alles Spieler!), dass die Änderungen keinen Mehrwert für den Spielspass und die taktischen Möglichkeiten bedeuteten. Im Endeffekt hat der Entwickler viele Stunden seiner Zeit und der Tester verballert. Das hat erhebliche Spannungen gegeben, denn die (unbezahlten) Tester sind Spieler. Die laufen genau einmal über die Map und wissen sofort, dass die Umbauten völlig unnötig waren. Dass man etwas umsonst macht kann schon mal vorkommen, aber das muss die Ausnahme sein! Die Devise der Tester ist: "Wir sind Spieler, wir wissen was uns Spass macht, wir sind erreichbar und ihr hättet einfach mal fragen können, dann hätten wir euch gleich gesagt, dass dieser Umbau Quark ist."


    Es ist halt die Frage für wen man das Spiel baut. Wenn man das für sich selbst baut braucht man kein Feedback von außen. Baut man es aber um es z.B. zu verkaufen, sollte man schon ein offenes Ohr für die haben, die es mal kaufen sollen.