AW: Neuer Simulator "neXt" für Mac und PC
Ich schaue mir das neXt Projekt schon einige Zeit still an und habe sehr lange überlegt, ob ich dazu etwas schreiben soll.
Vorweg: Ich finde es toll, dass jemand sich mal an so etwas heransetzt und würdige auch das bisher auf die Beine gestellte
Auch dass der Entwickler den Feedback der Benutzer einholt, ist eine schöne Sache. Und die Simulation funktioniert auf den ersten Blick auch relativ problemlos und halbwegs überzeugend.
Ich bin seit über 20 Jahren in der Softwarentwicklung tätig, keine kleinen Geschichten sondern zum großen Teil bei - wie sagt man so schön - "Global Players" und bin in eher überschaubaren Projekten, wie den hier schon erwähnten ca. 5000 Zeilen code aber auch in sehr komplexen Geschichten mit weit über 10 Millionen Zeilen Code unterwegs gewesen. Zum Teil auch in der Programmierung und Konzeption von physikalischen Echtzeitsimulationen, die weitaus komplexer sind, als eine Helisimulation.
Ich kann mit der Erfahrung da schon einige Rückschlüsse auf die Architektur und die technische Umsetzung ziehen, auch ohne Reverse Engineering zu betrieben, alleine in dem ich mir mal anschaue was denn meine CPU und Grafikkarte denn gerade so treiben, das ist ein mehr oder weniger gut erkennbarer Fingerabdruck der zugrunde liegenden Architektur.
Wenn das, was ich da sehe jetzt alles nur toll wäre, würde ich wahrscheinlich nichts schreiben sondern nur von mir geben.
Ich hätte da dann natürlich doch einige Dinge zu meckern und hoffe mal, dass das bei den Entwicklern als konstruktive Kritik ankommt
Beim Physikmodell hakt es definitiv noch, so sollte man eine Simulation nicht aufsetzen. Der Geschichte fehlt ein für eine Simulation wichtiges Kriterium: Reproduzierbarkeit. Gleiche Eingaben erzeugen mit dieser Engine keine reproduzierbar gleiche Ausgaben, noch nicht einmal auf dem selben Rechner mit dem gleichen Setup.
Der Rechner, den ich hier stehen habe, gehört schon mit zum Schnellsten was z.Z. im Desktopmarkt käuflich zu erwerben ist, der langweilt sich bei der Simulation nur. Trotzdem verhält die Simulation sich anders, wenn ich etwas CPU-Last im Hintergrund erzeuge.
Das wird spätestens dann, wenn mal so eine Funktion wie Flight-Recording ins Spiel kommt, zum Problem werden.
Bei der grafischen Umsetzung hakt es auch an ein paar Dingen, die rote Wand steht da offensichtlich nicht ganz umsonst, ohne die wird es nämlich ziemlich komisch.
Die größten Defizite sind im Moment aber im Bereich des Userinterfaces. Einen Dialog aufzusetzen, in dem die entsprechenden Parameter eingetragen werden können ist in der Tat relativ schnell gemacht. Wenn es aber darüber hinausgehen soll unterschätzen die meisten Entwickler den dafür nötigen Aufwand. Nicht nur was das Design und die Usability angeht, sondern die Eingabemenge vom Interface Mensch erzeugt eine oftmals größere Varianz als man sich das als Entwickler vorstellt. Während z.B. die Eingangswerte einer Physiksimulatuion immer in einem Plausibilitätsfenster liegen, ist das beim Menschen nicht so, da muß man vom DAU (dümmster anzunehmender User) ausgehen.
Wenn ich mir den jetzigen Stand des Programms anschaue, dann würde man das nach herkömmlichere Definition noch nicht einmal als Beta-Status einstufen. Eine Beta kommt schon mit einem zum größten Teil abgeschlossenen Featureset daher. Der neXt ist z.Z. irgendwo zwischen Alpha und Beta, von einem Release-Candidate aber nocht weit entfernt.
Das wäre aber weiter gar nicht tragisch, fände ich vollkommen OK, wenn denn absehbar wäre, wo die Reise hingeht.
Mit dem Satz
habe ich schon eine gewisse Erwartungshaltung.
Wenn das, was man jetzt sehen kann ungefähr 1 Jahr mit 3 Entwicklern gedauert hat, dann wird es nicht 1-2 Monate dauern, bis daraus ein wirklich brauchbares Produkt geworden ist. 1-2 Jahre wären da realistischer.
Was hier vor etlichen Seiten mal jemand geschrieben hat, dass man sowas mit der UNITY Engine mal eben schnell nachbauen kann, ist natürlich Unsinn. Aber umgekehrt ist es eben auch Unsinn zu glauben, dass ein Produkt was vielleicht zu 80% fertig aussieht, nur noch weitere 20% Entwicklungsaufwand bedarf. Mein Lieblingsstichwort: Pareto-Prinzip
5000 Zeilen Code ist noch recht übersichtlich. Der Aufwand füre neue Features und jede weitere Zeile Code wächst exponential, das ist eine allgemein anerkannte Erkenntnis in der Softwareentwicklung.
Genug gemeckert, der Entwickler kann sich gerne mal bei mir per PN melden, dann kann ich da auch mal etwas detailierter etwas zu sagen, das wäre hier OT.
Was mich selbst bislang aber noch davon abgehalten hat für 44€ die Lizenz zu erwerben, ist aber das etwas merkwürdige Demo-Modell. 20 Sekunden war natürlich ein Witz, 60 Sekunden ist auch nicht viel besser um als potentieller Kunde mal ein bißchen rumzuprobieren. Bei 5 Minuten hätten die Entwickler selbstverständlich Sorgen, dass der Kunde mit der Demo seine 5 Minuten Flüge absolviert und mehr nicht braucht.
Aber die 60 Sekunden sind trotzdem nix. Da gibt es doch nun andere bessere Möglichkeiten. Für eine quasi Beta wäre ein fixes Verfallsdatum ganz angemessen.
Einen Timelock zu implementieren, der aber z.B. ab Erstinstalltion abläuft, bietet dem Demo-User ausreichend Zeit das Produkt zu testen und trotzdem muß er sich irgendwann die Vollversion zulegen. Sowas geht auch, wenn man fortlaufend neue Updates nachschiebt. Und man kann auch verhindern, dass der Benutzer, die Demozeit mittels der Verwendung mehrerer im Haushalt verfügbarer Rechner zu weit streckt.
Also liebe Entwickler, das ist zwar ein bißchen eine Marketing-Geschichte, aber da gibt es bessere Lösungen, die u.U. auch den einen oder anderen zahlenden Kunden mehr bringen.
Ich schaue mir das neXt Projekt schon einige Zeit still an und habe sehr lange überlegt, ob ich dazu etwas schreiben soll.
Vorweg: Ich finde es toll, dass jemand sich mal an so etwas heransetzt und würdige auch das bisher auf die Beine gestellte
Auch dass der Entwickler den Feedback der Benutzer einholt, ist eine schöne Sache. Und die Simulation funktioniert auf den ersten Blick auch relativ problemlos und halbwegs überzeugend.
Ich bin seit über 20 Jahren in der Softwarentwicklung tätig, keine kleinen Geschichten sondern zum großen Teil bei - wie sagt man so schön - "Global Players" und bin in eher überschaubaren Projekten, wie den hier schon erwähnten ca. 5000 Zeilen code aber auch in sehr komplexen Geschichten mit weit über 10 Millionen Zeilen Code unterwegs gewesen. Zum Teil auch in der Programmierung und Konzeption von physikalischen Echtzeitsimulationen, die weitaus komplexer sind, als eine Helisimulation.
Ich kann mit der Erfahrung da schon einige Rückschlüsse auf die Architektur und die technische Umsetzung ziehen, auch ohne Reverse Engineering zu betrieben, alleine in dem ich mir mal anschaue was denn meine CPU und Grafikkarte denn gerade so treiben, das ist ein mehr oder weniger gut erkennbarer Fingerabdruck der zugrunde liegenden Architektur.
Wenn das, was ich da sehe jetzt alles nur toll wäre, würde ich wahrscheinlich nichts schreiben sondern nur
von mir geben.Ich hätte da dann natürlich doch einige Dinge zu meckern und hoffe mal, dass das bei den Entwicklern als konstruktive Kritik ankommt
Beim Physikmodell hakt es definitiv noch, so sollte man eine Simulation nicht aufsetzen. Der Geschichte fehlt ein für eine Simulation wichtiges Kriterium: Reproduzierbarkeit. Gleiche Eingaben erzeugen mit dieser Engine keine reproduzierbar gleiche Ausgaben, noch nicht einmal auf dem selben Rechner mit dem gleichen Setup.
Der Rechner, den ich hier stehen habe, gehört schon mit zum Schnellsten was z.Z. im Desktopmarkt käuflich zu erwerben ist, der langweilt sich bei der Simulation nur. Trotzdem verhält die Simulation sich anders, wenn ich etwas CPU-Last im Hintergrund erzeuge.
Das wird spätestens dann, wenn mal so eine Funktion wie Flight-Recording ins Spiel kommt, zum Problem werden.
Bei der grafischen Umsetzung hakt es auch an ein paar Dingen, die rote Wand steht da offensichtlich nicht ganz umsonst, ohne die wird es nämlich ziemlich komisch.
Die größten Defizite sind im Moment aber im Bereich des Userinterfaces. Einen Dialog aufzusetzen, in dem die entsprechenden Parameter eingetragen werden können ist in der Tat relativ schnell gemacht. Wenn es aber darüber hinausgehen soll unterschätzen die meisten Entwickler den dafür nötigen Aufwand. Nicht nur was das Design und die Usability angeht, sondern die Eingabemenge vom Interface Mensch erzeugt eine oftmals größere Varianz als man sich das als Entwickler vorstellt. Während z.B. die Eingangswerte einer Physiksimulatuion immer in einem Plausibilitätsfenster liegen, ist das beim Menschen nicht so, da muß man vom DAU (dümmster anzunehmender User) ausgehen.
Wenn ich mir den jetzigen Stand des Programms anschaue, dann würde man das nach herkömmlichere Definition noch nicht einmal als Beta-Status einstufen. Eine Beta kommt schon mit einem zum größten Teil abgeschlossenen Featureset daher. Der neXt ist z.Z. irgendwo zwischen Alpha und Beta, von einem Release-Candidate aber nocht weit entfernt.
Das wäre aber weiter gar nicht tragisch, fände ich vollkommen OK, wenn denn absehbar wäre, wo die Reise hingeht.
Mit dem Satz
"Unseren rc Heli Flugsimulator haben wir auf den Namen neXt getauft, da er die nächste Evolutionsstufe in der Modellflugsimulatorbranche einläutet."
Wenn das, was man jetzt sehen kann ungefähr 1 Jahr mit 3 Entwicklern gedauert hat, dann wird es nicht 1-2 Monate dauern, bis daraus ein wirklich brauchbares Produkt geworden ist. 1-2 Jahre wären da realistischer.
Was hier vor etlichen Seiten mal jemand geschrieben hat, dass man sowas mit der UNITY Engine mal eben schnell nachbauen kann, ist natürlich Unsinn. Aber umgekehrt ist es eben auch Unsinn zu glauben, dass ein Produkt was vielleicht zu 80% fertig aussieht, nur noch weitere 20% Entwicklungsaufwand bedarf. Mein Lieblingsstichwort: Pareto-Prinzip
5000 Zeilen Code ist noch recht übersichtlich. Der Aufwand füre neue Features und jede weitere Zeile Code wächst exponential, das ist eine allgemein anerkannte Erkenntnis in der Softwareentwicklung.
Genug gemeckert, der Entwickler kann sich gerne mal bei mir per PN melden, dann kann ich da auch mal etwas detailierter etwas zu sagen, das wäre hier OT.
Was mich selbst bislang aber noch davon abgehalten hat für 44€ die Lizenz zu erwerben, ist aber das etwas merkwürdige Demo-Modell. 20 Sekunden war natürlich ein Witz, 60 Sekunden ist auch nicht viel besser um als potentieller Kunde mal ein bißchen rumzuprobieren. Bei 5 Minuten hätten die Entwickler selbstverständlich Sorgen, dass der Kunde mit der Demo seine 5 Minuten Flüge absolviert und mehr nicht braucht.
Aber die 60 Sekunden sind trotzdem nix. Da gibt es doch nun andere bessere Möglichkeiten. Für eine quasi Beta wäre ein fixes Verfallsdatum ganz angemessen.
Einen Timelock zu implementieren, der aber z.B. ab Erstinstalltion abläuft, bietet dem Demo-User ausreichend Zeit das Produkt zu testen und trotzdem muß er sich irgendwann die Vollversion zulegen. Sowas geht auch, wenn man fortlaufend neue Updates nachschiebt. Und man kann auch verhindern, dass der Benutzer, die Demozeit mittels der Verwendung mehrerer im Haushalt verfügbarer Rechner zu weit streckt.
Also liebe Entwickler, das ist zwar ein bißchen eine Marketing-Geschichte, aber da gibt es bessere Lösungen, die u.U. auch den einen oder anderen zahlenden Kunden mehr bringen.
.
Kommentar