lithander

Freut mich, dass der Thread auf euer Interesse stößt! Automatisierte Tests verwenden wir gar nicht. *Schock* Test-Cases für Spiele sind einfach schwer zu schreiben. Wir testen in dem wir das Spiel spielen. Da haben wir dann oft Systeme die das reporten von Bugs erleichtern. Z.B: F12 drücken und Beschreibung eintippen und das System legt einen Jira Bug komplett mit Screenshot und Savegame an. Wir hatten auch schon mal unseren Buildserver Jenkins so konfiguriert das er alle Szenen in allen Qualitätsstufen einmal startet und einen Screenshot macht und die Performance-Eckdaten speichert. Ansonsten arbeite wir, wenn das Spiel auf die Fertigstellung zugeht oft mit externen Dienstleistern wie Quanticlab zusammen. Kann ich gut verstehen. Aber mit physikalischen Versionen ist der logistische Aufwand natürlich höher und die Kostenkalkulation komplizierter. Wir konnten sie deshalb zum jetzigen frühen Entwicklungszeitpunkt nicht als Backer-Rewards anbieten. Wir arbeiten schon seit Bout1 mit Benny Oschmann für den Soundtrack zusammen. Und auch die Soundeffekte kommen meistens von einem Externen dessen Namen ich gerade nicht parat hab. Beides wäre ein Pluspunkt. Je nachdem ob du dich für ein Praktikum oder ne Festanstellung bewirbst sind die Hürden natürlich unterschiedlich. (Eine Festanstellung ohne Praktikum haben wir bisher so gut wie nie vergeben, aber bei anderen mag das anders sein.) Ich denke, der beste Weg als Student einen Fuß in die Tür zu bekommen ist das Praxissemester denn da kostest du die Firma wenig und kannst sie von deinen Fähigkeiten überzeugen. Danach kann man auf eine Übernahme hoffen. Mit abgeschlossenem Studium will man ja auch "richtig" bezahlt werden, aber wenn du 5x so viel kostest wie ein Praktikant muss dein Lebenslauf eigentlich schon Berufserfahrung in der Branche aufweisen, damit man das "Risiko" eingeht. Ein Personaler hätte das bestimmt netter formuliert aber bei uns ist es in der Praxis ungefähr so. Last but not least darf man den Glücksfaktor nicht unterschätzen. Ob eine Initiativbewerbung mit akutem Bedarf zusammenfällt ist ein sehr wichtiger, schwer zu steuernder Faktor. Wie auch dieser Thread beweist experimentieren wir gerade mit solchen Ideen. Der angesprochene Haufen Arbeit lohnt sich eigentlich nur bei entsprechender Sichtbarkeit. Making Games plant so ein Devlog-Feature und möglicherweise ist das der richtige Ort für Einblicke die sich in erster Linie an die Zielgruppe der Entwickler richten. Wir haben eigentlich immer einen Partner für's Publishing und mit denen stimmen wir das Marketing ab. Aber ein wirklich großes Budget haben wir trotzdem nicht. Natürlich kann man selber z.B. auf Facebook Werbung schalten oder Anzeigen in den Zeitschriften aber letztlich ist man auf die Berichterstattung der Presse, Sichtbarkeit in den Shops und Mund-zu-Mund-Propaganda angewiesen. Bei uns fällt auf, dass wir in Deutschland in der Spielerschaft & Presse einigermaßen bekannt sind und es international viel schwieriger ist mit unseren Spielen (die ja immer auch auf Englisch rauskommen und aufwendig lokalisiert sind) ein Echo zu erzeugen. Aber das ist ein Thema mit dem ich mich nicht besonders auskenne.

Vielen Dank für die vielen klugen Fragen! So gut wie gar nicht. Er findet das alles selbst ziemlich spannend und steht auch für gelegentliche Fragen und gemeinsame PR zur Verfügung aber inhaltlich lässt er uns weitestgehend freie Hand. Bei Zwerge machen wir es das erste mal so das ich (bzw wir Coder) möglichst keine Custom-Shader schreibe. Wir benutzen diesmal sehr viel den Assetstore und jeder 3D Artists hat da relativ viel Freiraum z.b. auch Shaderforge zu verwenden. Nur wenn dann die Eckdaten einer Szene nicht mehr passen (zu groß, zu langsam) gucken die Programmierer sich das genauer an. Man kann Spiele entwickeln, ohne das zum Beruf zu machen. Daraus folgt für uns, dass jemand der sich auf einen Job in der Branche bewirbt, weil das "schon immer mein Traum war" dieses auch mit kleinen Arbeitsproben, wie bei Gamejams oder in der Freizeit entstandenen Spielen oder Mods oder ähnlichen Experimenten belegen können sollte. Also macht einfach Spiele egal ob ihr damit (schon) Geld verdienen könnt oder nicht! Informatik kann man studieren aber Programmieren ist ein Handwerk und das lernt man wie jedes Handwerk nur durch viel Übung. Die 10.000 Stunden Regel gilt auch hier! Ja, ich denke darüber werde ich noch mal ausführlich schreiben! Die HORDE Bibliothek hat keine Abhängigkeiten auf Unity und könnte sicher auch für ein anderes Spiel als die Zwerge als Basis dienen sofern es prinzipiell vergleichbare Mechanismen hat. Ansonsten ist es aber gerade der Vorteil von Horde, dass wir dabei genau auf unsere spezifischen Anforderungen eingehen können. Es ist ganz lustig wenn ein Zwerg den anderen umrennt obwohl das nie so programmiert wurde. Aber noch stecken viele Systeme in den Kinderschuhen und das emergente Verhalten wird eher noch zunehmen. Was dich interessiert. Meine eigenen Hobbyprojekte werden immer exotischer. Ich finde es persönlich spannender und lehrreicher möglichst wenige Abstraktionsebenen unter meinem Code zu haben. Unity ist toll und nimmt einem viel Arbeit ab wenn du ein Spiel machen willst aber wenn ich z.B. an der Hochschule Spieleprogrammierung unterrichte dann setzen wir bewusst keine Engine ein. (Sondern C# und SFML) Was man auf diesem Wege lernt ist universal und hilft so auch Unity besser zu verstehen und zu verwenden. Wie ich in meinem ersten Post schon sagte benutzen wir schon seit über 4 Jahren Unity. Davor hatten wir unsere eigene Adventure-Engine auf Basis von Ogre und der Grund auf Unity zu wechseln war ganz klar, dass Unity viel mehr Platformen unterstützt als wir das sonst gekonnt hätten. Unreal stand damals noch gar nicht zur Debatte und heute ist es einfach so, dass wir als Firma sehr eingespielt sind im Umgang mit Unity und auch wenn Unreal theoretisch intressant ist (und wir das vielleicht mal für ein kleineres Projekt evaluieren) ist der Produktivitätsverlust eines Umstiegs nicht gerechtfertigt. Wir entwickeln auf dem PC und deployen regelmäßig auch auf die Konsolen. Wir haben einen Mitarbeiter der für alle Konsolenports seit Raben die Verantwortung trägt und der passt auf, dass wir bei den Zwergen nichts machen, was später zu Probleme führen könnte. Das ist schwierig. Im Moment würden wir uns am meisten über Backer der Kickstarter-Kampagne freuen. Wenn das Spiel rauskommt dann wollen wir möglichst ein Kaufverhalten dass uns in den Verkaufscharts weit oben auftauchen lässt. Auch Nutzerbewertungen sind dann wirchtig. Möglichst lange in den Läden stehen ist natürlich auch super denn der Online-Vertrieb neigt dazu sehr schnell nachzulassen, während Präsenz in den Läden wie Saturn auch über Monate für Verkäufe sorgt. Alles in allem geht es nicht nur um die Marge sondern vorallem darum viele Spieler zu erreichen! Es ist heutzutage nicht selbstsverständlich, dass man mit seinem Spiel nicht in der Masse untergeht.

Ich freu mich über die vielen Fragen! Alles was man mit höherer Intelligenz assoziieren würde (Strategie&Taktik) ist eher gescripted. Das Script legt sowas fest wie: "Jetzt kommt eine Welle von Gegnern durch das Tor und versucht den König zu erreichen" oder "Die Orks bauen Katapulte auf um damit die Mauern einzureißen." Die Orks kommen nicht selber auf den Gedanken das zu tun, denn es ist Teil der Handlung und sozusagen fester Bestandteil des jeweiligen Encounters. Es wird aber nicht jeder Ork einzeln gescripted sondern eher gesagt: Hier ist euer Primärziel, das müsst ihr töten. Das da hinten ist die Gegend die ihr erreichen solltet." Das Verhalten der Horde ist dann ein Zusammenspiel von Systemen und Agenten-Verhalten. Das Physiksystem verhindert Durchdringungen und hilft Kollisionen aufzulösen. Dann gibt es das Pathfinding, das Pfade und Vektorfelder ausspuckt um die Ziele auch erreichen zu können. Da gibt es das Aggro-System das eine rudimentäre Kommunikation unter benachbarten Orcs erlaubt. Dann kann jeder Agent (wir nennen sie Grunts) in verschiedenen States sein, die sein Verhalten festlegen. Wer zum Beispiel über eine Brüstung geschubst wird fällt (FallState) liegt dann auf dem Boden (KnockedDownState) und muss erstmal wieder aufstehen bevor er im DefaultState wieder sein gewohntes Verhalten nachgeht. Aus dem Zusammenspiel dieser Systeme ergibt sich ein ganz plausibles Crowdverhalten. In der aktuellen Version bedeutete der Umstieg auf Physical Based Rendering für viele (vorallem auch Artists) eine Umstellung. Das hat sich auch auf die Buildzeiten negativ ausgewirkt. (Baking...) Mitlerweile läuft Unity aber sehr rund. Bei unseren vorherigen Spielen hatten wir viel mehr mit Bugs und Crashes (besonders bei den Konsolen und bei Mecanim) zu kämpfen. Hürden ergaben sich eigentlich auch immer wenn man versucht etwas anders zu machen als es Unity als Standard vorgibt. Bei Battleworlds war das der Versuch das Terrain komplett prozedural zu generieren - das war machbar, aber mühsam und besonders im OpenGL Renderer sehr langsam weil sich die Drawcalls nicht so weit reduzieren ließen wie man das eigentlich könnte, wenn man den Scene-Renderer kontrollieren würde. Das 2,5D Rendering in Bout2 wo wir subtraktive Schatten haben war auch unnötig schwer zu implementieren. Ich finde auch das Surface-Shader System ziemlich grausam weil so viel "Magic" dabei im Spiel ist. Die Lösung dafür ist natürlich einfach nicht so viel eigene Ideen umsetzen zu wollen sondern sich mehr an den vorhandenen Möglichkeiten zu orientieren und das machen wir jetzt auch. Ich persönlich traure aber den Zeiten nach, als die Fragen lauteten "wie geht das?" und nicht "das geht, aber wie geht es in unity?" Ich fände es schön, wenn man Mecanim-Statemachines komplett scripten könnte. Das ist im Moment viel zu eingeschränkt möglich. Ich verstehe auch nicht warum es die Beschränkung auf eine Szene zur Zeit gibt. Hierarchische Prefabs wären auch schön. Und natürlich Source-Code Access und sei es nur zu Dokumentationszwecken. Das konsequente Entity/Component Modell ist eine von Unitys Stärken. Aber wir benutzen eher keine Co-Routinen und das SendMessage-System gar nicht. Außerdem haben wir eben auch immer noch zusätzlich Systeme die durch eine Bootstrap-Component angetriggert werden und dann ganz klassisch System- und Managerfunktionen bereitstellen. Bei Bout2 hatten wir auch Components verwendet um zum Beispiel einzelne Bones zu taggen und das machen wir jetzt wieder über Naming-Conventions. Technisch wäre das möglich! Aber bis jetzt hat noch niemand verlangt, dass ich das einbaue.

Premature Optimization is the Root of all Evil! Vermutlich werden wir vor Release in irgend einer Form auf Multithreading setzen. Aber sowas gehört zu den Optimierungen die das Spiel schneller aber die Entwicklung nicht leichter machen. z.B. macht es das Debuggen deulich komplizierter und man muss sich um die Synchronisation kümmern. Sowas schiebe ich gern nach hinen! Es gibt auch noch ein paar Bottlenecks, die sich durch bessere Algorithmen und Datenstrukturen lösen lassen. Sowas hat für mich Priorität. Ich bin z.B gerade dabei die Shapes nicht mehr in schnöden Listen sondern in einer Baumstruktur zu erfassen um schnellere (sprich nicht O(n^2)) Querys machen zu können. So lässt sich ausloten wieviel Spielraum man wirklich hat - Multithreading verteilt die Arbeit ja nur aber reduziert sie nicht.

Hallo allerseits! Da ist mein erster Post hier gleich eine Projektvorstellung? Schoen08 hat mich auf eure Community verwiesen, und mich gefragt ob ich nicht mal Lust hätte hier über unser aktuelles Spiel zu schreiben. Einem technisch interessierten Publikum gegenüber könnte das in der Tat Spaß machen und vielleicht auch dem ein oder anderen nützliche Einblicke in unsere Arbeit geben. Also warum nicht? Ich bin Technical Director bei King Art und seit 4 Jahren setzen alle unsere Neuentwicklungen auf Unity. Das wären also das Adventure The Raven (zu dem Zeitpunkt war meine Beziehung zu Unity bestenfalls eien Hassliebe) danach Battle Worls: Kronos ein Rundenstrategiespiel dann das 2,5D Adventure Book of Unwritten Tales und jetzt gerade in der Entwicklung: Die Zwerge. Ich möchte nicht zu viele Worte über das Spiel selbst verlieren, denn im Moment läuft ein Kickstarter dazu und andere haben sich dort bereits große Mühe gegeben das Spiel so gut wie möglich vorzustellen. Also einfach mal dem Link folgen: Ich kann ohne Übertreibung sagen, dass Die Zwerge für mich das spannendste Projekt meiner bisherigen Karriere darstellt. Als Anfang der Nullerjahre der Herr der Ringe in die Kinos kam, haben mich vorallem die Massenschlachten beeindruckt. Dahinter stand ein System mit dem Namen "Massive" zu dem es leider nie allzuviele öffentliche Informationen gab. Aber trotzdem hat mich das Thema sehr fasziniert auch wenn es natürlich nicht real-time war. Ich weiß noch, dass ich damals dachte, dass die Computer vielleicht in 10-15 Jahren so leistungsfähig sind, dass man sowas auch in Echtzeit versuchen kann. Und nun bin ich in der glücklichen Situation mich bei den Zwergen dieser Vision zumindest annähern zu können. Viele Computerspiele besonders im Genre der RPGs modellieren den Kampf nicht viel anders als Pen&Paper-RPGs oder Brettspiele. Da wird viel gewürfelt, es gibt zalreiche Attribute und Formalismen für Rüstung, Kritische Treffer, Ausweichwürfe und so weiter... am Ende läuft alles darauf hinaus die Lebenspunkte der Gegner auf Null zu senken und selbiges für die eigenen Figuren zu verhindern. Für die Zwerge setzen wir dagegen auf eine physikalische Simulation der Dynamik von Massenschlachten. Natürlich ist auch das nur ein krudes Modell der Wirklichkeit aber eben doch ein fundamental anderer Ansatz als wir ihn zum Beispiel noch bei Battle Worlds gegangen sind, wo Zeit (turnbased) und Raum (feldbasiert) disktretisiert waren und das Spiel fast einer Brettspielumsetzung gleichkam. In Die Zwerge simulieren wir stattdessen das Verhalten und Zusammenspiel einzelner Agenten ohne zeitliche und räumliche Diskretisierung auf Basis einer physikalischen Simulation mit einfachen Shapes wie Kreiseln und Kapseln, die anders als in fast allen 3rd Party Lösungen allerdings keine Rigid-Bodies sind. Diese Basis wird ergänzt um weitere Systeme wie ein relativ komplexes Pathfinding oder eine flexible Schnittstelle um Kräfte in die Simulation zu induzieren und damit z.B. Schläge, Explosionen oder ganz allgemein Spezialattacken zu simulieren. Das Framework, das all diese Berechnungen durchführt und das wir HORDE (Horde Onslaught Realtime Dynamcs Engine) genannt haben ist von Unity weitestgehend entkoppelt. Unity hostet diesen Prozess nur - Es ruft irgendwo im Update-Schritt einer Component eine unverdächtig klingende Battle.Update() Methode auf die dann mehrere Millisekunden braucht um zu terminieren. Performance ist durchaus eine knappe Resource da man sich mit dem gesammten Rest des Spiels um die knappen Cycles des Unity Mainthreads streiten muss. Nach dem erfolgreichen Update ist die Simulation um die aktuelle Deltatime fortgeschritten und wieder synchron zur Spielzeit. Für jeden Orc oder Zwerg gibt es auch ein "normales" Gameobjekt in der Unity-Szene dessen Aufgabe aber lediglich darin besteht die Vorgaben seines Gegenparts der Simulation (Grunt genannt) visuell umzusetzen. Die beiden Fragen, "wie berechne ich eine Massenschlacht zwischen Orcs und Zwergen so, dass realistisch aber auch spaßig zu spielen ist" und "wie visualisiere ich diese Daten so, dass man den Ansprüchen an moderne Spiele genügt" stehen im Mittelpunkt meiner bisherigen Arbeit. Und ich freue mich darauf meine Antworten und Ansätze hier mit euch zu teilen. Für's erste ist der Post aber schon lang genug geworden. Lasst mich hören, was euch besonders interessiert, es muss auch nicht unbedingt mit den Zwergen zu tun haben. ~Thomas