Daten exportieren und Text Displayauflösung

  • Tach! :)

    Ich hoffe, dass ich hier nicht falsch poste, falls ja bitte verschieben :)


    Also: In meinem Spiel kann man sowohl die „Story“ spielen, als auch eigene Lvls zusammenstellen. Diese kann man dann natürlich auch bespielen und auch an Freunde weitersenden.


    Die Frage ist nun, wie ich die Lvls versenden sollte.


    Momentan ist es so, dass aus dem fertigen Lvl ein Code zusammengestellt wird und dieser dann als Text an andere Apps wie Whatsapp, Sms, mail, usw. geschickt werden kann. Dieser sieht in etwa wie folgt aus:


    "Hi! Probiere mein neues Lvl und füge den folgenden Code mit diesem Text in deine ABC App ein! (1,0,0)(1,0,16)(1,1,0)(1,1,16)(1,2,0)(1,2,16)(1,3,0)(1,3,16)(1,4,0)(1,4,16)(1,5,0)(1,5,16)(1,6,0)(1,6,16)(1,7,0)(1,7,16)(1,8,0)(1,8,16)(1,9,0)(1,9,16)(1,10,0)(1,10,16)(1,0,1)(1,10,1)(1,0,2)(1,10,2)(1,0,3)(1,10,3)(1,0,4)(1,10,4)(1,0,5)(1,10,5)(1,0,6)(1,10,6)(1,0,7)(1,10,7)(1,0,8)(1,10,8)(1,0,9)(1,10,9)(1,0,10)(1,10,10)(1,0,11)(1,10,11)(1,0,12)(1,10,12)(1,0,1)
    "


    Die alternative dazu wäre, dass ich nicht den Code, sondern eine ganze Datei versenden lassen würde. Der Vorteil hierbei wäre, dass ich die Dateien durch anklicken öffnen könnte. Nur hierbei kann man das wohl nur mit Mail und ähnlichem versenden.


    Also, würde euch der Code stören? Er kann unter Umständen auch deutlich länger sein, je nachdem wie viel Objekte der Lvlersteller platziert.


    ------


    Ein weiteres Thema hab ich (leider) noch:
    Wie sollte ich die Anpassung der Grafik, der Texte usw. für andere Display Auflösungen machen? Momentan hab ich von jeder Grafik nur ein Bild (im HDPI Ordner) platziert und lasse dann im Spiel die Größe prozentuell anpassen. Es kann zwar zu Stauchungen kommen, wenn ich jedoch später für die 4 Ordner eine Grafik anlege, dürfte sich das doch reduzieren, oder?


    Mit den Grafiken bin ich momentan eigentlich soweit zufrieden, was mir jedoch Sorgen bereitet sind die Texte. Diese lasse ich meistens im Spiel mit canvas.drawText zeichnen. Die Größe passe ich zwar mit paint.setTextSize((int)(height/100f*PROZENTSATZ)) an, es ist dennoch auf schwächeren Displayauflösungen verpixelt. Habe es jetzt auch versucht, Werte in die dimens.xml Datei zu schreiben (bsp: „25dp“) und danach zu verwenden, wesentlich besser sieht es trotzdem nicht aus.


    Auf meinem SGS2 sehen alle Texte jedoch ganz gut aus... liegt es also generell an der Auflösung, oder gibt es hierfür eine elegantere und bessere Methode?


    Vielen Dank für eure Antworten :)

  • ok ich hab zur zweiten (unangenehmen) Frage nun endlich eine wirklich tolle Lösung gefunden. Einfach paint.setAntiAlias(true); setzen und voilà :)) Auch Kreise und andere Formen sehen dadurch viel besser aus. Was bleibt ist die Frage, wie ich das exportieren lösen sollte :P

  • Die Frage ist natürlich, was du mit der Levelweitergabe bezweckst bzw. welche Informationen sie enthalten.
    Diese Art der Weitergabe ist natürlich simpelst manipulierbar. ;)
    Ich persönlich würde nichts davon halten, den Kram via Copy'n'Paste übergeben zu müssen, zumal man sich einfach nicht darauf verlassen kann, dass Copy'n'Paste wirklich immer und überall funktioniert.
    Da ich total auf Bitfelder und Ähnliches stehe würde ich eher für ein binäres Austauschformat plädieren. :)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Zitat

    Da ich total auf Bitfelder und Ähnliches stehe würde ich eher für ein binäres Austauschformat plädieren. :)


    ... mit anderen Worten? Mit einer Datei?^^



    Dass der Code leicht manipulierbar ist, ist mir natürlich bewusst, hier geht es auch nicht darum, dass dieser gut geschützt ist. Von mir aus kann man - sollte einem tatsächlich so langweilig sein - das Lvl so zusammenbasteln, dass man es eben mit dem Code schreibt, statt es via Drag und drop im Spiel platziert.


    Um es nochmal zu verdeutlichen: Man kann selbst ein Lvl erstellen und dieses dann an seine Freunde weitergeben (ober im Internet veröffentlichen,...) und dann kann jeder andere mit dieser App den Code einfügen und das Lvl spielen bzw. bearbeiten, welches der andere zusammengebaut hat.
    Der eigene Lvl Bereich ist komplett von der Story und anderen Fortschritten abgeschnitten und kann von daher gerne Manipuliert werden.


    Informationen sind in diesem code enthalten: Bsp: (1, 5, 5) <-- Objekt mit id 1 (spezielle Grafik), auf der x feld Koordinate 5 und y feld koordinate ebenfalls 5


    In welchen Fällen funktioniert copy & paste denn nicht? :-/
    Das Copy aus meiner App hinaus wäre in diesem Fall sowieso egal, da man mittels Klick auf das Lvl mithilfe eines Intents exportieren kann.


    MfG

  • Ja, eine Datei.
    Allerdings kann ja auch eine Textdatei mit deinem Inhalt eine Datei sein. ^^


    Die Idee, das Ganze als Text einzubinden, halte ich irgendwie für befremdlich.
    Deshalb wäre ich einfach für eine Datei. :)


    Ich hatte es ein paar Mal bei einigen Anwendungen, dass in dem Textfeld entweder das Kopieren oder das Einfügen deaktiviert war.
    Fand ich da ziemlich nervig, wird aber mit Sicherheit an den Anwendungen gelegen haben.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Ih stimme auch für "Datei" zum Datenaustausch.


    Nur beim Format würde ich noch mehr investieren, wenn du den Nutzern das Ändern per Hand etwas erleichtern möchtest. Formate wie JSON oder XML sind besser lesbar und auch in der Verarbeitung etwas sicherer.


    Denn wenn jemand was ändert oder mit Copy/Paste arbeitet, könnte mal etwas zu viel oder zu wenig mitkommen und dir deine internen Daten zerbröseln. Dann schon lieber eine Exception vom Parser abfangen und einen Fehler-Toast anzeigen.

  • Nur beim Format würde ich noch mehr investieren, wenn du den Nutzern das Ändern per Hand etwas erleichtern möchtest.


    In dem Punkt wäre ich zwiegespalten. Mit Messengern wie WhatsApp oder auch via MMS kann man ja Dateien anfügen.
    Da wäre es meiner Meinung nach sinnvoller, wenn die Dateien möglichst klein sind, zumal der Editor ja dem Game beiliegt.


    Sollte das Spielfeld also maximal 16x16 Felder haben und maximal 16 Bilder beinhalten, ließe sich das Ganze schön binär abspeichern.

    C
    100 10F 110 11F 120 12F 130 13F 140 14F


    Wird das Ganze auf 256 ausgeweitet, sieht das natürlich etwas gröber aus:

    C
    010000 0100FF 010100 0101FF 010200 0102FF 010300 0103FF 010400 0104FF


    Dann noch ein paar Infoflags dazu und gut.

    C
    1 3 0A 100 10F 110 11F 120 12F 130 13F 140 14F


    C
    02 06 0A 010000 0100FF 010100 0101FF 010200 0102FF 010300 0103FF 010400 0104FF


    Das ganze noch zusammengekürzt (Darstellung in Bit-Blöcken von 8 Bit, also 0 bis 255 [entspricht dem Datentyp unsigned char]) und die Datei ist um Längen kleiner als JSON oder XML.

    C
    00000001 00001000 00001010 00000000  00000001 00000000 00000000 00000001 00000000 00001111 00000001 00000001 00000000 00000001 00000001 00001111 00000001 00000010 00000000 00000001 00000010 00001111 00000001 00000011 00000000 00000001 00000011 00001111 00000001 00000100 00000000 00000001 00000100 00001111


    Parsen muss man den Kram so oder so, also empfiehlt es sich doch, einen Binärparser zu erstellen.
    1. Byte: Version der Datei/des Programms (falls in Version 1 Bild 5 ein anderes ist als in Version 2 oder 3...)
    2. Byte: In der Ursprungsplanung als Bitlänge je Eintrag gedacht, um möglichst viel Platz zu sparen. Sprich: wenn maximal 15 Elemente vergeben werden, reichen 4 Bit pro Ziffer, bei 8 Elementen reichen 3 Bit pro Ziffer, bei 32 Elementen wären es 5 Bit pro Ziffer und so weiter. Hab ich in meinem Beispiel der Einfachheit halber mal nicht weiter berücksichtigt und auf 8 gesetzt.
    3. Byte: Anzahl der Elemente (hier: 10)


    Man kann also an Hand des ersten Bytes irgend ein Flag setzen, an Hand des zweiten Bytes sehen, wie viele Bits für ein Element verarbeitet werden müssen und an Hand des dritten Bytes wie viele Elemente es gibt.
    Nun schleift man also 3.Byte male 3*2.Byte Bits um daraus die Ziffern der drei Objekte Bild, xPosition und yPosition zu generieren.
    Vorher lässt sich natürlich ausrechnen, ob die Dateigröße gleich (3*3.Byte*2.Byte/8)+3Byte entspricht, um inhaltliche Fehler zu vermeiden.


    Oh, wie ich LowLevel liebe. ^^
    Natürlich kann es durchaus passieren, dass man mal mit unterschiedlichen ByteOrders arbeitet, dürfte allerdings mittlerweile echt sehr selten sein.
    Wichtig ist dabei nur, dass das verdammt gut dokumentiert ist. Sonst sieht da ja keine Sau mehr durch. ^^


    Zum Schluss zum Vergleich Binary vs. JSON vs. XML:

    C
    <nicht darstellbarer Steuerzeichensalat>


    (33 Byte für 10 Elemente zuzüglich Overhead)

    C
    [{I:1,X:0,Y:0}{I:1,X:0,Y:15}{I:1,X:1,Y:0}{I:1,X:1,Y:15}{I:1,X:2,Y:0}{I:1,X:2,Y:15}{I:1,X:3,Y:0}{I:1,X:3,Y:15}{I:1,X:4,Y:0}{I:1,X:4,Y:15}]


    (138 Byte für 10 Elemente zuzüglich Overhead)


    (598 Byte für 10 Elemente zuzüglich Overhead)


    Zitat

    iMac-LDV:~ ldv$ ls -lsah *tst
    8 -rwxr--r-- 1 ldv staff 33B 20 Mär 11:17 bintst
    8 -rw-r--r-- 1 ldv staff 138B 20 Mär 11:16 jsontst
    8 -rw-r--r-- 1 ldv staff 598B 20 Mär 11:18 xmltst

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Erstmal danke für eure ausführliche Antworten ^^



    In dem Punkt wäre ich zwiegespalten. Mit Messengern wie WhatsApp oder auch via MMS kann man ja Dateien anfügen.


    Tjaja, wäre das der Fall, hätte ich mich auch ohne zu Fragen für die Datei-Option entschieden.
    Leider ist das versenden von Dateien bei Whatsapp nur dann möglich, wenn es eine Bild- oder Videodatei ist.
    Ebenso ist es auch nicht möglich, diese z.B. per Facebook Messenger oder ähnlichem zu verschicken.


    Daraus folgt, würde ich das Ganze als Datei versenden, wäre die Publizierung der selbsterstellten Lvls deutlich eingeschränkt.



    Und Uwe, so war es nicht gemeint, dass der Code per Hand geschrieben werden soll, ich wollte damit nur verdeutlichen, dass es möglich wäre und dass vom User eingebaute Fehler einfach ignoriert werden und somit auch nicht schädlich sind.


    Ich persönlich würd's ja auch eigentlich bevorzugen, eine ganze Datei zu versenden, aber aus oben genannten Gründen wär ich eher für einen Code...


  • Tjaja, wäre das der Fall, hätte ich mich auch ohne zu Fragen für die Datei-Option entschieden.
    Leider ist das versenden von Dateien bei Whatsapp nur dann möglich, wenn es eine Bild- oder Videodatei ist.
    Ebenso ist es auch nicht möglich, diese z.B. per Facebook Messenger oder ähnlichem zu verschicken.


    Na super, das Problem mit dem Sicherheitsaspekt. Warum sollte man nur Bilder und Videos verschicken können? Dafür nehmen die dann auch noch Geld?
    (man merkt: ich nutze WhatsApp nicht.)


    Prüft WhatsApp eigentlich den Datenheader? Falls nicht, nenn die Dinger doch einfach ‚Peters New Gamelevel': .png ^^
    (Deine App sollte dann aber tunlichst prüfen, ob da nicht irgend ein Scherzkeks wirklich eine Portable Network Graphic laden möchte.)


    Ansonsten halte ich aus Nutzersicht die manuelle Art des Levelcodes für zu kompliziert.


    Wobei es natürlich egal sein sollte, ob du das Ganze jetzt als Text oder Datei weiter gibst.
    In dem Fall böte sich vermutlich der JSON Ansatz an. Ist immerhin standardisiert, zuverlässig und recht erfolgreich getestet und produziert auch nicht nennenswert mehr Overhead als dein Ansatz.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«


  • Na super, das Problem mit dem Sicherheitsaspekt. Warum sollte man nur Bilder und Videos verschicken können? Dafür nehmen die dann auch noch Geld?
    (man merkt: ich nutze WhatsApp nicht.)


    Diese würden selbstverständlich auch noch mehr Geld damit einnehmen, wären die nicht so tolerant bei einem nicht kauf (Es erscheint zwar, dass die Gültigkeit abgelaufen ist, man kann es dennoch ruhig weiterverwenden :P)




    Prüft WhatsApp eigentlich den Datenheader? Falls nicht, nenn die Dinger doch einfach ‚Peters New Gamelevel': .png ^^
    (Deine App sollte dann aber tunlichst prüfen, ob da nicht irgend ein Scherzkeks wirklich eine Portable Network Graphic laden möchte.)


    Ansonsten halte ich aus Nutzersicht die manuelle Art des Levelcodes für zu kompliziert.


    Wobei es natürlich egal sein sollte, ob du das Ganze jetzt als Text oder Datei weiter gibst.
    In dem Fall böte sich vermutlich der JSON Ansatz an. Ist immerhin standardisiert, zuverlässig und recht erfolgreich getestet und produziert auch nicht nennenswert mehr Overhead als dein Ansatz.


    Wie das bei Whatsapp genau aussieht weiß ich leider nicht, aber da ja die gesamten Bilddateien in einer Galerie dargestellt werden und diese "nicht Bilder" ja keinen Sinn ergeben, wird das bestimmt auch kein schönes "Bild" ( :P ) machen.
    Auch über Benutzerfreundlichkeit würde ich in diesen Fall keinen großen Vorteil sehen. Entweder muss man immerhin die Endung umschreiben, damit die Datei als eine von meiner App erkannt wird, oder wenn man das aus dem Spiel heraus importieren möchte muss man sich durch einen Bilderdschungel schlängeln, was, wenn man dann doch ein paar Bilder mehr hat, ziemlich aufwendig sein kann^^


    Mit dem JSON komm ich jetzt leider nicht zurecht, was du damit meinst...
    Aus deinem vorherigen Beitrag entnehme ich das:


    [{I:1,X:0,Y:0}{I:1,X:0,Y:15}{I:1,X:1,Y:0}{I:1,X:1,Y:15}{I:1,X:2,Y:0}{I:1,X:2,Y:15}{I:1,X:3,Y:0}{I:1,X:3,Y:15}{I:1,X:4,Y:0}{I:1,X:4,Y:15}]


    Damit ist ja eigentlich nur das "Format" gemeint, wie ich das also verschicke, nicht jedoch, mit was ich das verschicken soll. Würde es weniger schlimm sein, es mit diesem "Format" als Code weiterzuverschicken, oder ist das anders gemeint?


    Sollte es so gemeint sein, dass ich den Code wie in der bisherigen Umsetzung verschicken soll (einfach Text an app wie Whatsapp usw schicken), da hab ich überhaupt kein Problem das Format "schöner" zu gestalten. Das momentane Formate (1,10,10) ist nur ein Entwurf :P

  • Hoi ,


    ich würde JSON benutzen, da es einfach zu handhaben ist und die Klassen JSONArray und JSONObject echt schnuffig gelungen sind. Benutzen kannst du das ganze sowohl mit einer Datei als auch mit einem String.


    Ich persönlich würde folgende Funktionen anbieten:
    - Versenden der Datei via E-Mail
    - Falls es unbedingt WhatsApp und co sein muss:
    - Informieren, ob Cloud Storage wie Google Drive oder Dropbox anzapfbar sind, so dass man die Datei dort hoch lädt und in WhatsApp und co nur den Link versendet.


    JSON als Klartext via WhatsApp versenden würde mich als Benutzer schon etwas arg verwundern ...



    Gruß,
    matze

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!