Drakes Legacy - Crysis go Pirates

[Sisko2000]

Danke ich habe nun die Signaturen gefunden

[ODemuth]

[Wedori]

Hey Leute,

kurze Info: Da wir es nicht wirklich schaffen noch alle Threads mit Info zu bedienen, möchte ich nochmal drauf hinweisen, dass es eine zentrale Webside mit allen möglichen Infos und Updates gibt.

Wer es noch nicht so ganz verinnerlicht hat: Das ursprüngliche Projekt "Drakes Legacy" hat sich in das Spiel "Hearts Of Oak" integriert, welches seine Heimat in der Community "Pirates Ahoy" hat. Das Spiel hat neben dem Entwicklerforum dort auch eine eigene Homepage, eine Facebook-Fanpage und einen Tweet. Natürlich auch Moddb und Indiedb Einträge.

Die Hauptseite der Entwickler befindet sich hier: http://www.piratesahoy.net
Die Info-Webside des Spiels mit einem schnellen Gesamtüberblick: http://www.heartsofoakgame.com/

Wir brauchen nach wie vor Hilfe, wer also seine Freizeit mit in dieses tolle Spiel investieren möchte, wir erwarten Euch gern.

Es war und ist ein recht harter Weg, auf dem ja schon viele Projekte gescheitert sind. Am Ende wißt Ihr ja selbst, wie oft wir wegen Features oder dem SDK oder sonstwas von Crytek (meist kaputt reparierte Features) gemeckert haben. Analog dem damaligen Dinoprojekt betrachte ich es nach wie vor als extrem wichtig eine Wissensdatenbank und ein Wiki zu haben. Die Pirates Ahoy Community ist im Genre ja die Quelle schlechthin, also ist an historischen Infos alles vertreten und gesichert. Ein WIKI haben wir ebenfalls, was wir regelmäßig mit den CE Features füllen, die wir für unser Projekt brauchen.
Eine eigene QC-Gruppe handelt die Memberorganisation, eine Werbung und Recruiting und eine Andere die Produktionsgruppen von 3D, Engine und Animation. Der letzte Punkt ist mangels Dokumentation und dem echt nervigen Mannequineditor noch recht schmall besetzt. Wir arbeiten von der Umsetzung der Technologie bis zu den Programmierern, die versuchen alles so gut wie möglich in die Engine zu packen. Rein technisch gesehen ist fast alles realisiert. Was wir noch brauchen, sind folgende BESSERE Workarounds:

1. Die Segel zu realisieren klappt zwar aber das nur mehr oder minder mit Einbußen. Hier mal das Ganze im Detail:
- Die klassische Variante als "Entity - Cloth" ist extrem rechenintensiv, was bei starken PCs nicht am Framecount, sondern am Ruckeln der Physikengine zu merken ist. Obwol CPU und GPU Reserven haben, lässt es sich nicht eindeutig sagen, warum das so ist. Selbst wenn es etwas besser laufen würde, müssten wir auf das reine Entity verzichten, da ein Seegefecht mit 20 Schiffen schlichtweg unberechnenbar wäre.
- Dann gibt es noch die Methode "Cloth Merged Mesh Deform". Das ist eine super Sache, sehr Performance schonend ABER funktioniert nicht an dynamischen Objekten. Kann also nicht bewegt werden.
- Dann haben wir noch die dritte Option: Animation als CHR, Verticeanimation ABER da fehlt mir ein DOC, was den Weg beschreibt eine CHR mit CAF and eine CGA zu binden und nicht über den Mannequineditor zu müssen. Das System wäre auch sehr gut für Kanonen und deren Takelage zu verwenden.
- Eine vierte Möglichkeit wäre die in RYSE verwendete ABER da gibt es null Dokumentation, im Forum (Crydev) antwortet nur selten jemand und in den DOCs steht auch hier: NULL

2. Am Mannequineditor haben 3 Leute separat herum probiert und es nicht geschafft einen Customchar mit custom Waffe auszurüsten und dem ganzen auch noch Sound zu geben. Ein Kanone Sound zu geben wenn diese KEINE Animation hat (verglichen mit dem buggy Tank) ist ebenso unmöglich. Wir reihen uns hier in eine mittlerweile unendlich lange Reihe von anderen Meinungen ein: Der Mannequineditor ist suboptimal und zu kompliziert verkettet angelegt, das kann man mit den ganzen Tag etc. def. einfacher umsetzen, und er hällt als Animations- und Tagverwalter für so ziemlich alles her, mit Ausnahme ganz einfacher Dinge (wie der Kanonensound ohne Animation), was das Ding schlichtweg NICHT kann. Erklärt auch warum der Panzer weder an Rohr noch Coaxial-MG Sound hat.

3. In RYSE, und das wäre für uns recht wichtig zu wissen, sind die Segel scheinbar über rig-rope-chains mit der Takelage verbunden, wo die Seile sogar reißen wenn das Schiff aufschlägt. Leider fehlt jede Dokumentation wie das umgesetzt wurde udn wie gesagt bei Crydev gibt es so gut wie keine Hilfe.

Im Grunde sind das die einzig verbliebenen offenen oder besser gesagt halb offenen Punkte. Die Programmierer haben die Engine stark modifiziert, dass könnt Ihr auch anhand der Videos sehen. Einfache Dinge wie der Kanonensound für See- und Landwaffen wurden von den Animationen und damit auch vom Mannequineditor gelöst. Damit haben die Modder und Mapper mehr Freiheit das alles umzusetzen. Das war auch möglich, da diese Waffen keine Char-bezogenen Werte haben. Alles, womit der Char hantieren kann, das landet natürlich im Mannequineditor, sofern der mal macht was er soll und nicht so extrem umständlich bleibt.

Wenn Crytek die CryEngine dann als "Service" anbietet, muss definitiv das Niveau der Dokumentation an das der Konkurrenz angepasst werden und sollte auch endlich aktuelle Sampleassetts enthalten.

[ODemuth]

Kleines Update der Endeavour:

[ODemuth]

Ich habe bisschen was gebastelt:



Btw nicht böse sein, es ist mein erstes Youtube Video

[General Kaboom]

Ich habe bisschen was gebastelt:



Btw nicht böse sein, es ist mein erstes Youtube Video

Cool, ich habe mich schon immer gefragt, wie so ein Ruder funktioniert

[Wedori]

Ja, unser Oli, der alte Perfektionist, der mit hollywoodreifen Rigs bastelt

[Wedori]

Hallo Leute,

sorry für die schlechten Updates in letzter Zeit

Es gibt mittlerweile regelmäßige NEWS von "Hearts Of Oak", welche auf Twitter, der Facebook Fanpage und über Pirates Ahoy zu erreichen sind.
Ich werde zukünftig den Link hier ebenfalls einpflegen.

Hier der Link zur News vom 9. Mai: http://www.piratesahoy.net/threads/h...ay-2014.22363/
Und hier zur News vom 23. Mai: http://www.piratesahoy.net/threads/h...ay-2014.22425/

Beide sind eine sehr gute Zusammenfassung über die aktuelle Arbeit, wobei durch die neue EaaS CryEngine wieder etwas mehr Wind, gerade in die Programmierung, kommt.

Eine zufriedenstellende Darstellung der Segel und Seile (wie im RYSE Video immer wieder zu sehen ist) sind allerdings noch so eine Sache. Der Code hat sich bei weitem weniger verändert, als wir dachten und der Einsatz von "Ropes" and "Cloth Merged Mesh Deform" and dynamischen Objekten ist nach wie vor nicht möglich. Die Entwickler der zukünftigen CryEngine versprechen viel und durch den Sourcecode Access zu "CryAction" haben wir zudem die Chance hier tiefgreifender zu agieren ABER es ist gerade ein kleiner Spagat vom erneuten Umdenken vom Free SDK zur EaaS denn neben dem Lightning hat sich auch der Sound wieder einmal verändert. Mal schauen wie es sich entwickelt.

Undurchschaubar ist nach wie vor das ganze Mannequinsystem. Beispielsweise: Noch immer müsste ein programmiertechnischer Beipass gefahren werden wenn beispielsweise schlichtweg nur einen Sound zu einer Kanone hinzugefügt werden soll. Zwar hat der Sound mittlerweile eine eigene Datenbank bekommen aber trotz preload und korrektem Soundsetup, spielt die Kanone bei Benutzung keinen Sound "out of box" ab. Die Entscheidung ein eigenes Entity dafür neu zu programmieren war daher für uns von Anfang an richtig. Es ist damit zusätzlich möglich, neben Kanonenladung, auch nach zukünftigen Geschosstypen und Deckneigung die Animation per Code zu generieren.

Ein wenig Bauchschmerzen bereitet noch das Thema "Zerstörbarkeit". Für Kanoneneinschläge würden wir ebenfalls wie in Ryse oft gezeigt, procedural zerstörbare Elemente integrieren ABER das scheitert etwas an mangelndem Support Seitens Crytek und den schlechten DOCs. Nicht alle zerstörbaren Teile können mit Cutshapes generiert werden und vieles in Ryse sieht angesichts dessen was die Engine tatsächlich berechnen kann wie "gekünstelt" aus. Es ist auch nicht möglich an Informationen zu gelangern, wie Rysemodelle im Setup sind.
Bretterwände beispielsweise sind prädestiniert für procedural Boolean Zerstörbarkeit aber wie es so ist, das Setup ist grausam und weit weg von dem was man in Ryse sieht. Also der Werbebasis für die EaaS. Verbindet man mehr als ein Mesh in einer oder mehrere Groups innerhalb einer CryExportNode, arbeitet das System wie soll. Die Bretter gehen kaputt. Da es aber "doof" aussieht wenn eine 3x5m Bretterwand komplett umfällt wenn man drauf schießt, teilt man die Bretter auf. Selbes Setup aber statt einem Mesh, sagen wir mal 20 Bretter-Meshes. Schon funktioniert es nicht mehr. Im Setup RigidBody bleibt es zwar interagierbar, kann nicht mehr zerstört werden. Teilt man die Materialien pro Brett auf (also jedes Brett sein eigenes Material) dann interagieren zwar alle unabhängig voneinander aber keines lässt sich zerstören. In solchen Fällen wünscht man sich einfach mal nur richtig guten Support und der fehlt, trotz "BlingBling Werbung", leider noch immer.

Da kommen auch schon die richtig negativen Dinge, die bis heute echt noch verdammt störend sind:

1. Das Physiksystem steht bei weitem noch hinterm dem von Crysis 1, was die visuelle Rechenpower angeht. Die EaaS bröckelt bereits ab wenn 1000 Goldmünzen aus einer angeschossenen Kiste kullern und das ist schon arg heftig. Die Frames bleiben stabil aber der Physikkern der Engine dümpelt mächtig ab und während im Hintergrund das Meer ordentlich rollt und die Palmen im Wind wehen, da stottern die Münzen aus der Kiste. DAS darf nicht sein! Ob das jetzt mit der "echteren" Berechnung zu tun hat oder nicht wissen wir nicht. Wir wissen nur eines: Hier muss schleunigst Abhilfe her denn die CPU ruht sich deutlich mehr aus, als noch zu Crysis 1 Zeiten (Zumindest bei unseren jeweiligen Testsetups). Wir hoffen zuerst auf Mantle und eine kleine Erleichterung dadurch ABER später eine richtige Änderung im Kern. Die hollywoodreifen Szenen aus Ryse sind teilweise mit nachgesetztem Setup bei weitem nicht realisierbar und das fällt einem immer öfter auf. Riesige einstürzende Mauern, während im Hintergrund zig Geschosse die weitere Szenerie zerstören, sind alles herrlich vorberechnete Skripte oder sonstwas.

2. Das ganze Animationssystem sieht zwar gut angedacht aus, ist aber unpraktikabler als ein Kühlschrank in der Arktis. Das Wegfallen sämmtlicher einfacher "Hand-Funktionen", das nicht-funktionieren des Grab-One-Hand-Helpers und zig Tags und Tod und Teufel, kreieren ein undurchschaubares Labyrinth an Lego-Baustein-ähnlichem Aufbau, die leider nur nicht zusammen passen. Da stimmen einerseits Joint Orients nicht, Waffen hängen an den Armen sonstwo und Custom Rigs müssen von A bis Z ebenfalls neu gesetzt werden. Nicht nur, dass das wie ein Kaugummi zäh vor sich hin arbeitet, ist mangels Dokumentation und stimmigen Sampleassets kein gutes Arbeiten möglich. Da auch an diesem System von Update zu Update mehr und mehr verändert wird, überlegt man sich aktuell dort überhaupt noch dran zu arbeiten und mal abzuwarten bis sich so etwas wie "final" einstellt.

3. Das führt sogleich zu Punkt 3. Eigentlich soll ja alles besser werden, würde man nicht so tun als "sammle man Feedback für die neue Bezahlengine" und ignoriere gleichzeitig viele Crydev-Beiträge und sonstige Supportanfragen. Das Ganze ist teilweise schon so offensichtlich, dass Threads in denen dem Ärger mal Luft gemacht wird "versehentlich" verschwinden.
Weiteres Ärgerniss: Parallel einher geht die sehr deutlich verbreitete Aussage: Die tolle Dokumentation, auf die man zurückgreifen könne. Man kann ja sogar voten für zu überarbeitende DOCs. Die Praxis zeigt zum Großteil noch immer veraltete DOCs, oftmals fehlende Sampleassets, manchmal auch nur die für Maya und teilweise hahnebüchene Lücken. Ich nehme mal als Beispiel "Cloth Merged Mesh Deform". Das ganze DOC wollte ich neu schreiben, da geht bei Crydev KEINER drauf ein. Ich hätte sogar ein Maya - Sampleasset zur Verfügung gestellt. Hier herrscht nach wie vor an den Grundlagen viel bis sehr viel Handlungsbedarf.

Alles in allem sind wir mit der Engine natürlich zufrieden aber man hofft immer, dass die teilweise echt blöden "Ecken und Kanten" mal erkannt und sinnvoll angegangen würden. Oftmals würde nur ein Satz als Antwort oder auch nur ein Sampleasset die Lösung bringen aber das bekommt man leider im Moment noch nicht hin. Der Support der Community untereinander hat aber leider auch sehr stark gelitten. Aus diesem Grund ist das von uns erstelle WIKI bei Pirates Ahoy von Außen für jeden zugänglich. Es ist so aufgebaut, dass man als Neuling von der Installation bis zu speziellen Setup sehr viele Bilder und Erklärungen vorfindet, die zumindest die größten Fragen ausräumen. Was bei Maya beispielsweise immer von Nöten ist, sind die Setups im Outliner und mögliche verwendete UDPs.

In diesem Sinne

viele Grüße!

Wedori
>>>>>>>>>>>>>>>><<<<

[Tibull]

http://www.crydev.net/newspage.php?n...4843a37d247c83

vllt kann man da etwas know how bzgl der segel einholen ...

[Wedori]

Hallo Projekt- und Gamefreunde!

Heute ist die Zeit gekommen über eine tiefgreifende Veränderung zu informieren, sofern sich Interessenten nicht bereits unsere aktuellen Developervideos angesehen haben und es damit bereits wissen.

Wie Ihr wisst, wurde vor einer ganzen Weile die "CryEngine As A Service", kurz "EaaS" (Version 3.6+) veröffentlich. Damit ging einher, dass das CryEngine SDK Free nicht weiter geführt und bei Version 3.5.8 gestoppt wurde. Diese Version wird auch nicht länger supported. Um die Entwicklung unseres Spiels "Hearts Of Oak" (kurz „HoO“) weiter voran zu treiben, haben wir die EaaS abonniert und angefangen den bereits erstellen Gamecode, Bypassed Codes und Assetts zu konvertieren. Leider sind wir dabei bis in die aktuelle Version 3.6.4. nur auf noch weitere Probleme gestoßen, die ich unten stehend kurz zusammenfassen möchte:

Sounds
Durch die Einführung von Wwise und damit dem kompletten Austausch von FMOD, haben wir alle Sounds verloren. Um aber im Sinne unseres Spiels weiter entwickeln zu können und die Beschränkung der 200 freien Sounds zu umschiffen, haben wir versucht für unsere „PiratesAhoy!“ Community eine Non-commercial Lizenz zu erhalten, da schnell klar war, dass 200 Sounds bei Weitem nicht ausreichen.
Wir hatten aktuell ca. 30 Kanonensounds, 15 Geschoss – Schwirr und Windgeräusche, 40 Holz- und Wassersounds. Ein Bruchteil dessen was man final benötigt.
Nach einer Menge Aufwand und vielen Anstrengungen wurde uns diese Lizenz zugestanden.
Was damit nicht gelöst wurde ist, dass um ähnliche Resultate wie unter FMOD zu generieren, die erforderlichen Schritte nun deutlich aufwändiger sind und wir alle Sounds neu aufsetzen mussten.
Ein ungeheurer Aufwand, um wenigstens zurück zu dem Stand zu kommen, wo wir bereits mit dem Free SDK 3.5.8. waren.
Aber es kam noch schlimmer. Wir bekamen unsere Sounds nicht zum funktionieren. Das war bereits in der ersten Version der EaaS der Fall. Wir warteten 1 Monat um an diesem System endlich weiter arbeiten zu können, bekamen aber außer der Crytekmeldung „an einem Fix wird gearbeitet“ keine weitere Information. Das ist für Indie-Entwickler unzumutbar.
Wir haben mit der weiteren Soundentwicklung in der zweiten EaaS-Version erst einmal gestoppt.

Materials/Models/Texture
Mit den Modellen lief zunächst alles augenscheinlich reibungslos. Wir konnten sie importieren, die Kollisionsdaten wurden erkannt und Partikelsysteme arbeiteten.
ABER: Warum auch immer war es nicht mehr möglich Animationen zu verwenden (exportiert aus Maya). Es gab zwar nach wie vor eine CGA und ANM, die auch als Test im Free SDK 3.5.8. funktionierten, aber leider nicht im EaaS. Trotz intensiver Meldung des Fehlers auf Crydev und an unsere Crytek-Kontakte, fehlt bis heute die Information ob es sich um einen Bug oder neuen, noch nicht dokumentierten, Workaround handelt. Auch das ist für Indie-Entwickler eine Zumutung. Nach den schlechten Erfahrungen mit dem Sound wollten wir jetzt nicht noch einen Monat verstreichen lassen.
Das neue PBR System konnte nach erheblichen Anlaufschwierigkeiten und einem Tutorial eines Crydevmembers dann aber gelöst werden. Auch hier war es notwendig ca. 22GB Rohtexturen neu einzustellen und erneut zu kompilieren. Wir haben uns gefragt, ob dieser Aufwand nun bei jedem größeren Update gemacht werden soll und was das für die Entwicklungszeit von HoO bedeutet. Wir haben uns gefragt, ob wir ehrlich weitere 2 Jahre Entwicklungszeit zur Hälfte mit immer neuen Konvertierungen in die neuen Engineversionen verbringen sollen. Ist das Effektiv?

Compiling Custom DLLs
Die letzte böse Überraschung folgte sogleich kurz später. Da Sound und Modell-Setup vorerst nicht bearbeitet werden konnten, konzentrierten sich unsere Entwickler darauf die ganzen programmierten Bestandteile in die neue CryGame.dll zu kompilieren. ABER: Jede Änderung an dieser Datei machte die EaaS instabil und für führte zu wahrlosen und zufälligen Abstürzen. Das, obwohl wir von einer neuen und sauberen Quelle anfingen Code zu kompilieren.
Crytek antwortete uns im Bezug auf diesen Fehler, dass er bekannt sei und auf der „Fixlist“ stehen würde. Leider passierte das bis zur aktuellen Version 3.6.4. nicht.
Die dritte Unzumutbarkeit brachte das Fass bei uns intern zum Überlaufen und es galt für uns zu realisieren was wir überhaupt von der CE erwarten können und was die Engine für die Zukunft unseres Spieles bedeutet. Wir hatten einen absoluten Entwicklungsstillstand erreicht. "Frust" beschreibt unsere Situation nicht annähernd.

Die Zukunft
Nach den ganzen schlechten Erfahrungen mit der CryEngine in der letzten Zeit, dem Support und auch den Leuten bei Crydev, haben wir realisiert, dass da noch weit mehr Dige waren, die für eine Spieleentwicklung wichtig sind. Es sind nicht nur die anderen Communitymember, die sagen „Wir wissen was aber sagen es nicht“ oder „wir sagen gar nichts“ oder Crytek „Steht endlos lange auf der Fixlist und Ihr müsst warten“ oder dem ewigen Schweigen bei Crydev, mit dem Damoklesschwert drohender weiterer Initialupdates der EaaS. Eine tödliche Mischung.
Die konkreten Fakten wiegen weit schwerer wenn man an einem Spiel arbeitet und ein kleines Team hat. Die CryEngine hat seit Version 2 (CE2) bis heute, 3 tiefgreifende Updates erfahren. Das war der Wechsel von der CE2 zur CE3, CE3 Free SDK 3.4.x zur CE3 Free SDK 3.5.x und CE3 Free SDK 3.5.x zur EaaS. Alle Änderungen brachte teils sehr tiefgreifende Veränderungen mit sich, die jeweils einen kompletten Neuanfang in der Entwicklung darstellten und oft von einzugehenden Kompromissen begleitet war. Eines war für uns Entwickler schnell klar: Es wurde nicht einfacher. Im Gegenteil. Es wurde komplizierter und verbuggter denn es war durch den fehlenden Support und ausbleibende Antworten Seitens Crytek und Crydev teils nicht mehr klar, ob es sich bei manchen Situationen nun um einen Bug oder ein neues Feature mit undokumentiertem Setup handelt.
In der weitern Überlegung kamen wir dann zu dem Punkt, der letztlich die finale Abwendung von der CryEngine mit sich brachte: Wir zahlen 10EUR im Monat für eine Engine, mit oben genannten Umständen. Leider Umstände, die die Community bereits teilweise seit Jahren kennt. Waren sie bisher noch zu ertragen oder zu umschiffen, müssen wir für die Zukunft aber eine solide Spielentwicklung beurteilen, daher diese planbar und handelbar gestalten. Mit unserem kleinen Team geht das auch nicht anders.

Updatezwang
Die EaaS wird ausschließlich über Steam vertrieben. Sprich es ist uns zukünftig nicht möglich zu sagen (Beispiel) wir haben jetzt einen Stand „X“ und den nehmen wir. Nein, jedes neue Update der EaaS zwingt uns zum Konvertierungs-Update, welches unter aktueller Masse an Assetts , Sounds und Codes, gut 1 Woche kosten dürfte. Initiale Änderungen, die wieder alles auf den Kopf stellen, weil beispielsweise noch neue PBR-Berechnung, Ressource Compiler, Mannequinsystem usw. usw. kommen, sind dabei gar nicht mit beachtet. Bei zu erwartender Bugliste und erneuten Einschränkungen in der Spieleentwicklung, plus den hanebüchen schlechten Support und Hilfe bei Crytek, bleibt nicht nur die Abwendung von der CryEngine, sondern wir müssen sogar alle anderen ernsthaften kleinen Entwickler in der EaaS warnen sich genau zu überlegen ob sie diesen Strudel weiter mitmachen möchten. So etwas kann sehr schnell die Auflösung ganzer Teams bedeuten. Davon gab es rückwirkend betrachtet in der CE eine ganze Menge! So etwas muss als Warnung verstanden werden! Nicht vor der CE. Die Warnung muss lauten: Seit Ihr groß genug das mit der CE zu bewältigen!? Stellt Euch vor Euer Indiestudio muss ein nahezu komplettes Game Monat für Monat in die neue Engineversion konvertieren, dass ist so gut wie unmöglich und mit "unzumutbar" nicht annähernd zu beschreiben!

Sicher kann man uns dem Vorwurf machen zu lange gewartet zu haben denn die meisten Probleme sind nicht neu aber der endlos lange Kampf eben für die CE und für unser Spiel, hat uns mit aller Kraft weiter kämpfen lassen, bis mit dem EaaS so gut wie alles planiert war, was wir seit Anbeginn mit Drakes Legacy vor gut 3 Jahren begonnen haben. Wir sind irgendwie wach geworden. Eine vernünftige Entwicklung als Indie in unserer Größe, ist mit der CE nicht möglich. Größere Entwicklungen sind logisch gesehen mit dem EaaS generell unmöglich. Entweder man hat als Indie ein ausreichend großes Team, welches über Crowdfunding die Möglichkeiten hat schneller die Update-Konvertierung mit Manpower zu meistern, plus direkte CE-Programmierer mit Vorkenntnissen die schnell initiale Updates verarbeiten können oder man versucht das Geld für eine Vollversion zu bekommen. Letzteres ist oftmals unmöglich, wäre aber für eine Spielentwicklung Idealzustand und im Falle der CE auch notwendig.

Alles in allem darf aus diesem Text nicht der Eindruck entstehen, dass die CE schlecht ist. Im Gegenteil. Die CE ist eine sehr gute Engine, die in verschiedenen Varianten den Entwicklern zur Verfügung steht. Wir habe oft genug darüber gesprochen, dass die EaaS dringend ein dazu buchbares Supportpaket braucht um für kleine Indies wenigstens weiter interessant zu bleiben aber auch dieser Kampf ist verloren. Wir sind mit unserer Teamgröße kein passender Kunde für die aktuelle CE in der EaaS-Version und müssen im Sinne der Absicherung der Zukunft unseres Spiels nun der Realität ins Auge blicken und uns für ein Ende mit Schrecken entscheiden, als Schrecken ohne Ende zu bekommen. So leid es uns tut.

Die Entwicklung wird in Unity 5 weiter geführt und aktuell in Unity 4 als Basis getestet. Unsere Programmierer haben bereits eigenen Gamecode und Shader am Laufen und haben den Funktionsstand des Free SDK 3.5.8. in Unity erreicht. Es geht sehr schnell vorwärts.
Die Grafik wird, wie einige andere Dinge auch, als Kompromiss sicher nie die Qualität der CE erreichen aber es geht am Ende um das Spiel, nicht um uns. Um das Spiel releasen zu können, müssen wir auf eine Engine setzen, die uns Fortschritt und Entwicklung auch als kleine Indieentwickler erlaubt und da scheiden CE und Unreal zum aktuellen Stand leider komplett aus. Auch wenn es Kompromisse abringt, die aktuell einzige Chance für „Hearts Of Oak“.

Wir sind ja nicht weg und niemand weiß, was die Zukunft bringt, von daher gibt es immer ein lachendes und ein weinendes Auge. Ich persönlich werde das Abo der EaaS weiter führen und am Ball bleiben, was mit der Engine noch passiert. HoO wird aber ohne weitreichende Änderungen im Support und Updatezwangmodell keinen Fuß mehr hinein setzen.