Mein MapSystem ist komplett offen Es funktioniert weil ich raw bytes schreibe und lese und das ganze dynamische laden kann.
...
Offen ist zwar gut, aber für mich sind deine Map-Dateien dennoch Bit-Müll, weil ich nichts mit anfangen kann.
Ich kann deine Map-Dateien nicht einfach Notepad++ öffnen und bearbeiten, weil sie nicht menschenlesbar sind.
Worauf ist hinaus will ist eine öffentliche Minimal-Spezifikation für rpg_rt-ähnliche Engines, angefangen wie das Map-Format aufgebaut ist.
Es spart erstens viel Zeit sich ein eigenes Format auszudenken und zweitens wer will schon für sagen wir mal 10 Engines mit je unterschiedlichem Map-Format 10 Konvertierungsalgorithmen in das eigene Map-Format schreiben.
Was sparst du dir denn für Zeit ein Format auszudenken? So wie ich das sehe tun das viele Entwickler ohne groß drüber nachzudenken. Sie schreiben einfach die Daten sie brauchen und mehr tue ich in dem "Map-Format" ja auch nicht. Das es für dich nach müll aussieht liegt wahrscheinlich daran das es mittels ZLib komprimiert wurde. Ich will halt kein XML oder Json dafür haben. Das ist mir zu bloated und naja wie gesagt, schau in die MapIO Klasse, da kannst du sehen wie man es lesen kann. Es sind nur ein paar primitives und Strings die ich schreibe. Keine Magie
Das Ganze ist auch eher ein Feature in der Engine. Ich werde es sehr wahrscheinlich entfernen und als Extension wieder ermöglichen. Ich will eben nur aktuell alles in einem Projekt haben
Es ist auch meines Wissens nach nur in meiner Engine so. Die meisten nutzen halt Tiled. Aber ich mag Tiled nicht. Total nutzlos das Tool wenn man mehr als "darstellen" will. Aktuell ist das ja nicht in meinem Map-Format drin aber es wird noch ein Event-System eingefügt das dem von Rpg Maker sehr ähnlich ist (Die Idee ist allein von Lachsen).
Und das ist oftmals das Problem in größeren Projekten.
Man denkt nicht nach. Man tut einfach irgendwas.
In so einer Situation befinde ich mich auch grad auf der Arbeit. Für ein und das selbe Problem gibt es tausend unterschiedliche Implementierungen und ich darf ein Feature bauen, womit alle Implementierungen zurechtkommen können. Am liebsten würde ich sagen: "Gebt mir ein halbes Jahr Zeit und ich mache alles neu!", nur welche Firma investiert 180 PT für ein einzelnes Feature, welches die meisten Kunden eh nicht benutzen, bzw welcher Kunde würde 180 PT für ein Feature bezahlen wollen?
@Whiz: PT? Das einzige, wozu ich das auflösen könnte, wären "Punkte" wie in "Prozentpunkte", aber ich bezwifle, daß deine Firma Verträge macht, in denen sie 180% ihres Einkommens weggeben...
Insgesamt aber ja. "Ich schreibe mal Kram in eine Datei, ohne drüber nachzudenken" funktioniert so lange, wie man davon ausgeht, daß niemals jemand mit einem kompatibel sein will.
Beispiel: Es gibt für DSA3 und DSA4 einen Charaktereditor namens "DSAWiege". Für DSA3 war das Ding echt heißer Scheiß; für DSA4 wurde es von einem OSS-Projekt überholt. Wir haben zu DSA3-Zeiten ewig den Entwickler angehauen, daß er uns doch mal die Sourcen gibt; unter Anderem deshalb, weil sämtliche Datenformate aus "ich schreibe einfach Strings in einer Textdatei und die Reihenfolge bestimmt, was was ist" bestanden. Richtig geil, wenn man den Kram verwerten möchte, weil das ewig langes Reverse Engineering bedeutet.
Die Sourcen hätten da auch nicht furchtbar viel Zeitersparnis gebracht.
Beispiel: Magic Workstation. Ein Programm, mit dem man online MtG spielen kann. Ganz nett und hat in der Regel recht aktuelle Kartenlisten komplett mit eingebackenen Errata. Sehr geil, wenn man eine Kartendatenbank bauen möchte... Bis auf ein Problem: Das Datenformat für die Kartenlisten ist "ich nehme dieses Delphi-Objekt und schreibe es auf die Festplatte". Damit sind die Listen exakt dann lesbar, wenn man Delphi benutzt und alle verwendeten Klassen hat. Magic Workstation ist nicht OSS.
Ich habe meine Karten exportiert gekriegt, aber es involvierte eine recht zerbrechliche Toolchain aus mehreren Konvertierungsprogrammen.
Wenn du ein Datenformat entwickelst, mach' es selbsterklärend (denke "XML") und/oder dokumentiere es vernünftig. Es sei denn, Inkompatibilität mit dem Rest der Welt ist ein Designziel.
@Whiz: PT? Das einzige, wozu ich das auflösen könnte, wären "Punkte" wie in "Prozentpunkte", aber ich bezwifle, daß deine Firma Verträge macht, in denen sie 180% ihres Einkommens weggeben...
In so einer Situation befinde ich mich auch grad auf der Arbeit. Für ein und das selbe Problem gibt es tausend unterschiedliche Implementierungen und ich darf ein Feature bauen, womit alle Implementierungen zurechtkommen können. Am liebsten würde ich sagen: "Gebt mir ein halbes Jahr Zeit und ich mache alles neu!", nur welche Firma investiert 180 PT für ein einzelnes Feature, welches die meisten Kunden eh nicht benutzen, bzw welcher Kunde würde 180 PT für ein Feature bezahlen wollen?
...
Du bist nicht allein! (=
Es gibt nichts ätzenderes als historisch gewachsene Projekte, an die zig Entwickler unzählige Änderungen rangeflanscht haben.
Die Auswirkung von tieferen Modifikationen ist quasi "untestbar", weil man mit an Sicherheit grenzender Wahrscheinlichkeit doch einen der hundert Sonderfälle vergisst und spätestens beim Going-Live knallts dann an allen Ecken und Enden.
Weil das ein verdammt teurer Spaß würde, bleibt einem also nichts übrig, als seinen eigenen Kram auch irgendwie ranzuflanschen.
@Whiz
Ich meinte ehr direkt Spiele usw und weniger Engine aber egal, wie gesagt sehe ich das eh eher als Extension Man sollte dazu vllt auch Wissen das die Engine mehr oder weniger aus einem Spiel entsteht. ich enkopple nur Sachen die ich eh wiederverwenden werde. Wenn ich damit Leuten noch helfen kann, schneller ihre Ideen auf den Bildschirm zu kommen mach es umso mehr Spaß.
Ich sehe nichts Verwerfliches in einem Binärformat, d.h. solange es gut durchdacht und dukumentiert ist. Erweiterbarkeit lässt sich auch in Binärformaten realisieren, z.B. ähnlich wie es RIFF macht. XML finde ich persönlich zu aufgebläht und würde JSON vorziehen, falls Menschenlesbarkeit erforderlich ist und Binärdaten nicht gespeichert werden sollen.
Hallo,
ich habe da eine kleine C++ Frage.
Mein Compiler weigert sich den Typ int64_t in time_t ohne expliziten Cast umzuwandeln.
Dieser Code ergibt als Ausgabe:
Meine Frage ist, woran liegt das? An einer zu alten Compiler-Version? (Bei mir läuft 4.2.1) Und nein, einfach explizit zu casten ist keine brauchbare Lösung für mich.
Beschreibende Methodennamen sind da in meinen Augen am besten. Sind zwar mehr zu tippen, aber wozu gibt es heutzutage die Auto-Vervollständigung.
Damals war es ja mehr der gute Ton alles kurz zu machen, als es leicht lesbar zu machen.
atoi ist aber beschreibend (und in meinen Augen auch leicht lesbar). Der einzige Unterschied zwischen atoi und AsciiToInt ist doch der, dass in atoi "Ascii" und "Int" abgekürzt sind. Das Problem mit atoi ist wohl eher, dass heute nicht jedem sofort klar ist, wofür das "a" steht (mir war es anfangs auch nicht klar). Ich schätze, dass der Term "ASCII" zur Blütezeit von C sehr viel präsenter war und es machte Sinn ihn durch "a" abzukürzen. Heute sieht es allerdings nicht sehr viel anders aus: Wenn der Name einer Funktion sinnvoll abgekürzt werden kann und es bei der abgekürzten Version immernoch klar ist, was die Funktion macht, wird der Name abgekürzt. Und das ist absolut in Ordnung. Selbst eine derart ausführliche Sprache wie Java hat in ihrem Repertoire Funktionen mit abgekürzten Namen, wie etwa die mathematischen Funktionen, weil es erstens Sinn macht solch elementaren Funktionen kurze Namen zu geben und zweitens, weil die Abkürzung immernoch Sinn ergibt und es klar ist, was die Funktion macht. Krampfhafte Ausführlichkeit ist meiner Meinung nach genauso schädlich (selbst heute, mit automatischer Vervollständigung), wie kryptische Abkürzungen. Es muss abgewogen werden und abgewogen hast du ja auch, oder weshalb ist deine Wahl auf "AsciiToInt" und nicht etwa auf "ConvertAsciiEncodedCStringToIntegerAndReturnTheResult" gefallen?
Weil es einen Unterschied gibt zwischen "verbose" Namen und einfach beschreibenden Namen. Aber nein, schon klar darauf willst du nicht hinaus.
Wie du selbst sagst muss man wissen was das "a" und das "i" zu bedeuten hat. Dann erst mach auch das "to" im Methodennamen Sinn.
Das Ganze mit den Methoden von java.lang.Math zu vergleichen finde ich nicht ganz so passend.
Immerhin hast du hier mathematische Ausdrücke die damit quasi von der fachlichen Seite vorgegeben sind.
Meine Wahl ist von daher eher auf asciiToInt gefallen.
Ich finde hier sieht man von vornherein was die Methode tun wird. Hierfür ist auch kein Wissen nötig was irgendein Abkürzung nun genau bedeutet.
Sicherlich gäbe es hier noch passendere Name.
Man könnte sich z.B. sparen was überhaupt zurück gegeben wird, da man dies idR auch anderweitig sehen kann.
Das Ganze mit den Methoden von java.lang.Math zu vergleichen finde ich nicht ganz so passend.
Immerhin hast du hier mathematische Ausdrücke die damit quasi von der fachlichen Seite vorgegeben sind.
...
Gutes Argument, daran habe ich nicht gedacht. Ich habe zu wenig Erfahrung mit Javas Bibliotheken um passendere Beispiele nennen zu können (falls es welche gibt) und Lust darauf noch weniger.
Zitat von makenshi
Meine Wahl ist von daher eher auf asciiToInt gefallen.
Ich finde hier sieht man von vornherein was die Methode tun wird. Hierfür ist auch kein Wissen nötig was irgendein Abkürzung nun genau bedeutet.
...
"ascii" und "Int" sind aber auch Abkürzungen. Aber ich schätze, dir geht es mehr darum, dass das "to" hervorgehoben ist.
"all to int" macht - zumindest für mich - keinen Sinn, vor allem weil es itoa gibt. Mir fällt jetzt auf Anhieb auch nichts ein, was sonst (außer "ASCII") für das "a" in atoi stehen könnte und Sinn machen würde. Hand aufs Herz, es ist doch nicht so, dass man die benötigte Information alleine aus dem Funktionsnamen entschlüsseln muss. In der Praxis schaut man sich doch immer die Dokumentation, oder zumindest die Deklaration an. Selbst bei AsciiToInt ist nicht alles sofort klar und man muss die Deklaration heranziehen. Darüber hinaus handelt es sich nicht um irgendeine Funktion aus der Bibliothek eines Drittanbieters, sondern um eine Funktion aus der Standardbibliothek von C, die im Header stdlib.h definiert und unter "String conversion" aufgelistet ist (zumindest auf cplusplus.com).
Zugegeben, das "a" in atoi könnte für jemanden, der den Funktionsnamen zum ersten mal liest, schwierig zu entziffern sein (wie gesagt, ich wusste anfangs auch nicht, dass es für ASCII steht). Aber das alleine reicht für mich nicht aus um den Funktionsnamen als "ein Beispiel wie man Funktionen nicht benennen sollte" zu betiteln, in Anbetracht dessen, dass - wie ich meine - der Term ASCII früher deutlich präsenter war und damit auch klar war, was mit dem "a" gemeint ist, sowie in Anbetracht der Punkte, die ich oben genannt habe und vielleicht noch aus Respekt gegenüber den Autoren der C-Standardbibliothek.
Das "a" könnte aber auch Array heißen, da hier ein Char-Array in die Funktion reingereicht wird. Ein String ist ja in C nichts weiter, als ein Char-Array.