Wann ist die BETA-Version von Freewar weg?

[Blizz]

mH Sotrax die alten Portalmaschinen gehen doch noch immer nicht so wie sie sein sollten oder?

[sgr011566]

Hm, ich hab ihm geschrieben, er soll sein Maul noch mal aufmachen, um mal bei der Formulierung zu bleiben, wenn er dir das für die Karte schickt. Aber, wie ich euch beiden schon schrieb, ich kann nicht ständig Postvogel spielen, wenn der eine immer nur in seinen Zwergenbart murmelt und ab und zu laut flucht und der andere keine Zeit hat, mal nachzuhaken und kein Interesse, ihn als Admin aufzunehmen - was, wie ich immer noch denke, allen zum Vorteil gereichen würde.


Wie dem auch sei, ich weiß halt, Stoa hat sehr viele konkrete Konzepte, die man umsetzen sollte - beispielsweise hatte er schon einen Tag, nachdem ich ihm mein Modulsystem erklärte, ein konkretes Rohkonzept, sowohl theoretisch zur Integration als auch praktisch, bei den Bausteinen (wenigstens hab ich ihn so verstanden, korrigiere mich bitte, Zwerg, wenn ich falsch liege). Er hat auch schon klar erläutert, wie man ohne grobe Probleme parallel entwickeln könnte, damit das Ding umgesetzt würde.

Vorteile hast du selbst per PM schon genannt, wäre unter anderem die Geschwindigkeit des Spiels. Aber auch anderes, Uniqueitems zB könnte man in Zukunft immer problemlos überarbeiten, ohne dass Versionen veralten: man schafft einen Funktions-Teil mit allen Bausteinen für die Itemfunktionen sowie einen Textteil, da wird an der richtigen Stelle der neue Baustein eingefügt. IAs können den dann problemlos überarbeiten. Ein weiterer Vorteil wäre auch, dass C&P-Fehler weitgehend der Vergangenheit angehören würden. Zahlen würden fast ausschließlich in einem übersichtlichen Formular verändert, wo man sie nicht minutenlang im Code suchen muss und dann doch wieder die Hälfte übersieht.

Derzeit bist du eingeschränkt, was Items angeht, weil Uniques Probleme bereiten würden. Das wäre später nicht mehr der Fall, du könntest jede beliebige Änderung vornehmen, da der Funktionsteil fest wäre. Das ist ein Punkt, wo derzeit die Entwicklung und der Fortschritt leiden. Genauso kosten C&P-Fehler unnötig Zeit und Nerven, wenn sie ständig wieder auftreten. Vielleicht geht es nicht schneller, neue Sachen zu entwerfen - aber du hättest sicher Dutzende Minibugs weniger.

Außerdem wäre die RP-Engine dann weit weniger buganfällig, da die Komponenten leichter zusammenarbeiten könnten.


Vielleicht habe ich Unrecht, was das angeht, dass du Dinge oft nur umsetzt, wenn sie auch anerkannt werden - unsere häufigen Diskussionen bezüglich Bugabarbeitung lassen mich da aber anders denken - und von vnv hab ich in vielen Gruppengesprächen eben ähnliches gehört.

[Vidar]

Da ich nicht weiß, wie die Kommunikation zwischen dir und in dem Fall vnv aussieht, kann ich dazu nichts groß sagen, vermutlich fehlte ihm einfach eine Resonanz, dass du darüber bescheid weißt und dich damit beschäftigen wirst.

Von den Updates her, hast du eine sehr hohe Frequenz derzeit und mich freut es, dass es Dinge wie das flammlose Kleisterschild gibt, die nicht angekündigt werden. Auch die Itembeschreibungen sind wieder auf dem Weg zur alten Klasse und dem Humor, der FW so unverwechselbar macht. (Ist es hier Absicht, dass die Waffe die gleichen Anforderungen besitzt wie die Stachelrüstung oder ist es ein Copy&Paste-Fehler?)

Persönlich würde ich mich freuen, wenn du auch mal hin und wieder an die Mods denkst, immerhin gibt es dort auch einige Dinge, die man in Zukunft lösen sollte, gerade bei den Usernachrichten.

[Sotrax]

@sgr: Wie gesagt, die Sache mit dem Modulsystem überzeugt mich einfach noch nicht, ich denke nicht, dass ich mit sowas schneller oder besser neue Sachen implementieren kann. Und an sich ist es mir da derzeit zu aufwändig alles umzustellen, da müsste ich mir erstmal genauer anschauen wie es am Ende wirklich funktioniert.

Wir haben da mal ein halbes Modulsystem versucht, was noch von ganymede kam, aber dann doch irgendwie zu unflexibel war.

Aber ganz ehrlich, ich will eigentlich keine extra neue Modulsystemsprache lernen sondern mag es die Items und Feldfunktionen bequem in PHP programmieren zu können ^^.

Im Endeffekt ist es halt auch Geschmackssache, da gibts kein richtig oder falsch. Vielleicht lasse ich mich da durchaus noch überzeugen, derzeit kann ichs mir jedoch einfach nicht vorstellen, wie sowas überhaupt aussehen soll und dabei so flexibel wie das bisherige sein. Evt. bräuchte ich da konkretere Beispiele. Dazu kommt, ich habe nur wenig Erfahrung in der Programmierung von Parsern und ich will nachher nicht etwas machen, wo ich selbst nicht mehr durchblicke

Daher wäre mein Vorschlag eben ein Modulsystem in DF zu testen, und wenn ich dort sehe, dass es wirklich richtig gut ist und sich lohnt, sehe ich kein Problem das auch in FW zu integrieren. Für diese Methode wäre ich durchaus offen.

@vidar: Ja, habe da schon mit damh geredet, gerade die Mods dürfen sich wohl auch bald auf die ein oder andere neue Sache freuen

[sgr011566]

mH Sotrax die alten Portalmaschinen gehen doch noch immer nicht so wie sie sein sollten oder?

Doch, passen ebenfalls.

Mir ist es relativ egal, ich habe nicht die nötigen Kenntnisse, um dich vollständig dafür zu begeistern. Bei Stoa habe ich das geschafft, was etwas heißen will, denke ich ...

Ich werde dich eben weiterhin mit Minibugs nerven, die man mit einem Modulsystem ganz einfach hätte verhinderen können.

[Andi90]

Aber ganz ehrlich, ich will eigentlich keine extra neue Modulsystemsprache lernen sondern mag es die Items und Feldfunktionen bequem in PHP programmieren zu können ^^.

Ich will ja jetzt nicht sagen, dass es hier offenbar Leute gibt, die das genügend beherrschen, um dir dabei zu helfen... *seufz*

Das neu organisieren der Engine wär doch auf diese Weise viel einfacher zu bewerkstelligen. Stell einfach jemanden ein, der das macht (/machen will, zB vnv, wie ich das verstanden hab) und du kannst dich nebenher um neue Spielelemente kümmern... Oder, wie in dem Thread vorgeschlagen, auf den ich dich auch schon aufmerksam gemacht habe, du suchst dir jemanden, dem du die vielen kleinen Arbeiten abgeben kannst und kümmerst dich dann selbst um die Engine.

Je nach dem, wie weit du mit FW noch gehen willst und wie lange du das Spiel noch laufen lassen willst (und ich denke, das sind noch einige Jahre, da du ja eigentlich immer mit Freude an der Arbeit bist^^) würde sich so eine Sache bestimmt lohnen..!

[Sotrax]

Wie gesagt, schon jetzt verwenden wir ein Modulsystem, nur ist die Sprache dafür eben PHP. Klar könnten evt. manche Bugs verhindert werden, dafür tauchen dann aber neue auf. Also eine andere Sprache macht sowas sicher noch nicht bugfrei.

Wie auch immer, es gibt durchaus Punkte, wo ein System welches abstrakter abläuft per Modulen sehr viel Sinn bringen würde, nämlich z.B. bei Uniques und Item-Admins. Genau dort wollen wir sowas eigentlich auch in Zukunft testen

Ansonsten habe ich mich bereits in mehrere typische Modulsystemsprachen wie LUA etc eingearbeitet, allerdings sind diese jetzt nicht unbedingt sehr viel leichter als PHP zu erlernen.

Man darf eben nicht vergessen, dass das jetzige System ebenfalls auf Modulen basiert, die sogar recht viel können wie Funktionen ableiten etc und dazu extrem flexibel sind. (so muss das auftragshaus z.B. nicht 4 mal in der DB abgelegt werden sondern nur einmal und die anderen Orte leiten diese Funktion ab).

Letztendlich muss man eins sagen: So schlecht wie manch einer glaubt ist der Freewar-Code nicht, denn immerhin konnte er seid 5 Jahren mit Dingen erweitert werden, die damals nie geplant waren, ohne dass er uns um die Ohren fliegt. In Sachen erweiterbarkeit hat er sich also bisher als extrem gut herausgestellt

@sgr: Wie gesagt, ich verstehe nicht ganz, wie ein Modulsystem Fehler verhindert. Wenn man damit alles machen kann, was man in PHP realisieren kann, kann man auch die gleichen Logikfehler erzeugen. Und ich gehe hier mal von einem Turing mächtigen Modulsystem aus.

@Andi: So einfach gehts leider nicht, dass ich jemand sage er soll das alles machen und es am Ende nur nutze. Denn wenn ich nicht zu 100% verstehe, wie es funktioniert, kann ich später darin keine Bugs fixen und ich kann nicht davon ausgehen, dass derjenige immer Zeit dafür hat, solange FW existiert.

[mopf]

@Andi: So einfach gehts leider nicht, dass ich jemand sage er soll das alles machen und es am Ende nur nutze. Denn wenn ich nicht zu 100% verstehe, wie es funktioniert, kann ich später darin keine Bugs fixen und ich kann nicht davon ausgehen, dass derjenige immer Zeit dafür hat, solange FW existiert.

dazu möchte ich übrigends noch anmerken, dass das forum ebenfalls aus sehr vielen unterschiedlichen modulen besteht, hauptsächlich php verwendet und eigentlich sehr leicht verstädnlich ist, wenn man sich die zeit nimmt die kommentare zu lesen.

der nachteil ist, dass es relativ aufwändig ist modifikationen zu entwerfen, da man wirklich alle modulabhängigkeiten berücksichtigen muss.


aber sotrax, ich denke vnv und sgr meinen eher eine objektbasierte modulbasis als eine eigene modulsprache o.ä.


z.b.
du baust dir dein item grundgerüst und an den jeweiligen stellen wird halt extern der funktionscode oder der beschreibungstext abgefragt.

wenn du dann items veränderst, gehst du nur kurz zu dem funktionsteil und bearbeitest den und alle items, fragen diese nachher geänderte stelle ab.

ähnlich arbeiten wir ja auch im wiki. wenn einer die vorlage für ein itemlayout ändert, werden alle itemseiten automatich angepasst.

mfg

p.s.
ich teste das mal, von wegen pn schreiben und aktiv mitarbeiten

edit:
weil wir uns eben darüber unterhalten haben:
mit einem modularen system könntest du z.b. die shops so bearbeiten, dass du ein standartshop modul hast und nur noch die anzahl und art der der items, die verkauft werden einstellst.
dann würde endlich jeder shop mehrfachkauf unterstützen

wenn du magst, kann ich dir gerne weitere beispiele nennen ^^

[sgr011566]

aber sotrax, ich denke vnv und sgr meinen eher eine objektbasierte modulbasis als eine eigene modulsprache o.ä.

z.b.
du baust dir dein item grundgerüst und an den jeweiligen stellen wird halt extern der funktionscode oder der beschreibungstext abgefragt.

wenn du dann items veränderst, gehst du nur kurz zu dem funktionsteil und bearbeitest den und alle items, fragen diese nachher geänderte stelle ab.

Genau sowas meine ich - einfach nur, dass der Code nicht immer wieder neu getippt bzw dorthinkopiert, sondern in Module verwandelt wird, die am Einsatzort mit variablen Werten belegt werden (können).

Ein weiterer Vorteil wäre, man könnte mit einem minimalen Aufwand eine Singular-/Pluralunterscheidung einführen könnte, derzeit merkt man an vielen Stellen einfach, dass das Standardtexte sind. Standardtexte wären ja weiterhin möglich, aber man könnte sie weit authentischer gestalten, sodass sie eben nicht so wirken. Gut, das macht auch (zB) Nintendo nicht, aber warum sollte das KEIN wünschenswertes Ziel sein? Und ja, es steht auf der Liste der Bugs

[vnv_nation]

vereinfachte Definitionsbasis.

z.b.: attack(x,y,z) wird zu

Code: Alles auswählen

if (x > y) {
       $newLife = $actLife - z;
}

Diese Translationenvorschriften liegen in einer separaten Modultabelle. In der ItemDB werden beide Varianten, also die modellhafte Beschreibung des Items und der generierte Source mitgeführt. Editiert wird eben jene Beschreibung, der Source generiert. Wichtig hierbei ist, dass der auszuführende Code bei Änderung einmalig neu erstellt wird und nicht bei jeder Ausführung (deshalb ist ja beides drin und es die Performanz bleibt erhalten).

Was die Fehleranfälligkeit betrifft, so ist als bewiesen zu betrachten, dass nach spätestens nach n- Korrekturzyklen banaler Code (Translationsvorschrift eines Modulssegments oder eine "Methode") fehlerfrei ist. Wenn also gilt, dass banaler Code fehlerfrei ist, kann angenommen werden, dass aus banalem, fehlerfreiem Code ein weit weniger fehlerbehafteter, komplexer Source gebildet werden kann.

Das komplexe Software immer Fehler haben wird, die eben noch unentdeckt sind, und z.B. durch das Zusammenspiel der banalen Komponenten eingetragen werden, ist klar. Das sollte jeder Entwickler wissen und weiß jeder Tester (denen es nicht darum geht dem Entwickler seine Fehler vorzuhalten, sondern mit diesem das Produkt für den Endkunden zu verbessern).

Weiterhin ist es zwingend notwendig die Lesbarkeit und Dokumentation der Bestandteile Freewars zu erhöhen. Denn damit ist die Wiederverwertbarkeit wesentlich zu steigern. Eine Vereinfachung, Straffung, aber auch klare Definition formaler Strukturen, die obendrein in sich auf Fehlerrobustheit geprüft werden kann, empfiehlt sich und sollte bei Anwendungen dieser Größenordnung genutzt werden. FW ist eben schon längst nicht mehr die Seifenkiste in der Ecke.

Darüberhinaus dient eine Variablendefinition zum Eintritt wesentlich der Erleichterung der Bearbeitbarkeit und erhöht die Möglichkeit der Feineinstellung.

[damh]

hmm, das könnte ja dann auch ein php nach php Compiler sein.

So wie Du es beschreibst, meinst Du ja nichts anderes als Inlinefunktionen und klar verbessert das den Code und es hilft noch mehr:
Man kann z.B. schnell herausfinden, welche Items heilen, starren, verletzen, ...

heilen(person, lp) returns diff_LP; [ja, ich weiß, dass es kein PHP ist; ist Absicht ]:
Vorbedingung: aktuelle LP(act_LP), maximale LP(max_LP) bestimmen
Funktion:

Code: Alles auswählen

new_LP := min(max_LP, act_LP+lp);
if (new_LP <= act_LP) diff_LP := 0;
else {
    if (new_LP < max_LP) diff_LP := lp;
    else diff_LP := new_LP-act_LP;
    act_LP := new_LP;
    setWriteBackFor(act_LP);
}

Aufräumarbeit: LP-Wert zurückschreiben, falls nötig

Aus den Vorbedingungen kann man die SQL-Abfragen erzeugen, welche tatsächlich benötigt werden für das entsprechende Item.
Aus der Aufräumarbeit weiß man ebenfalls, was noch gespeichert werden muss und kann sich in beiden Teilen unnötige Abfragen und entsprechende Zeit sparen.

Außerdem ermöglicht das u.a. auch Zauber, die man selbst zusammenbauen könnte:
Ich mixe zwei Starren und erhalten eine andere Starre, die nun 20 Minuten wirkt.

Hmm, ich hatte vor 1.5 Jahren mal mit jemandem über soetwas ähnliches gesprochen. Ein PHP nach PHP Compiler, der den kompletten statischen Anteil aus dem PHP wegoptimiert. Dies hätte bei einigen Items den Vorteil, dass diese wirklich deutlich schneller laufen dürften. Das machen zwar die JIT teilweise, aber eben nicht optimal, da sie eben nicht beurteilen können, was schwachsinnig ist und was tatsächlich gewollt ist. Macht man allerdings diese kleinen Funktionsteile extrem ordentlich, sollten eigentlich kaum noch unnötige Dinge übrigbleiben, mal ganz von den Bugs abgesehen

Gruß damh

[vnv_nation]

zum Teil korrekt. Es geht hier nicht nur um einfach Definition von Funktionen, sondern tatsächlich um die Möglichkeit zu beschreiben. Anhand einer konkreten Semantik (zu definieren) kann dann ein NPC / Item / Feld wesentlich schneller, wesentlich flexibler erstellt werden. JSON ist hier ein sehr gutes Beispiel, wie es exakt gemeint ist.

Aber warum sollten wir weiter über Dinge reden, die hier sowieso nie eine Chance haben werden?

[-=Baphomet=-]

Ich brauch keine Ahnung, ich spiele einfach ein kostenloses Browsergame was FUNKTIONIERT. Dabei ist es mir total egal, ob der Admin sich das Leben selbst schwer macht oder ob ein pfiffiger RP-Wächter-Dingsi-Bumsi, da nen Masterplan hat, wie man Items, NPC, what ever in nur der halben Zeit entwickelt.

[Geist von Fool]

Naja, es könnte ja sein, dass durch die Umsetzung des Masterplanes irgendeines RP-Wächter-Dingsi-Bumsis ja durchaus auch Vorteile für die Spieler entstehen könnten. Nicht nur so offensichtliche Dinge, wie dass ein Admin der sich das Leben mit dem Einbau von Dingen nur halb so schwer macht, mehr Zeit und Lust für andere Dinge hat die sonst manchmal auf der Strecke bleiben (ja, die gibt es, was kein Vorwurf sein soll, es ist einfach ein Haufen Arbeit), sondern eben auch schnellere, bessere und sicherere Uniquesierbarkeit, weniger Bugs (ja, es gibt Bugs die so richtig weh tun wenn man betroffen ist) usw...

Auch Dinge die eigentlich bereits funktionieren kann man oft noch besser machen - und danach fragt man sich dann immer, wie man den Vorzustand je ertragen konnte .

*steigt wieder von der Seifenkiste herunter*

Aber ich weiß ja tatsächlich nichts...

[sgr011566]

Dabei ist es mir total egal, ob der Admin sich das Leben selbst schwer macht oder ob ein pfiffiger RP-Wächter-Dingsi-Bumsi, da nen Masterplan hat, wie man Items, NPC, what ever in nur der halben Zeit entwickelt.

Ich mag auch keine Masterpläne, die da mehr Interaktion zwischen Items, Wetter, Aufträgen, NPCs und Spieler bringen würden, sondern lieber den aktuellen Zustand, wo jede kleinste Idee dieser Art wochenlange Programmierarbeit bedeutet und vielleicht einmal in sechs Monaten eine reinkommt. Bloß nichts verändern, es könnte ja besser sein.