RPG Game verschlüsseln

[Rosa Canina]

Wer die Ressourcen will, wird sie meistens auch auf irgendeinem Weg bekommen

...

Das...
Sowohl Molebox als auch die internen Routinen von XP aufwärts sind mit ein wenig Googlesuche knackbar.

Ich würde mir da jedenfalls nicht zu viele Gedanken drüber machen. Hey, ich hab ein riesiges Archiv an Charaktersets für AVoR gepixelt und
bislang ist es... in einem einzigen anderen Spiel im größerem Ausmaß verwendet worden. Und selbst, wenn ich das Spiel nicht wirklich
besonders fand, ist es doch eigentlich für mich ein positives Zeichen, dass jemand meine Arbeit so zu würdigen weiß.

Abgesehen davon... wenn jemand deine Grafiken verwendet und DU es nicht willst, dann sag beim Release des Spiels das einfach einem
Moderator und BAMMM ist das Spiel erstmal wieder weg vom Fenster.

Das vergessen die Leute immer gerne ^^

[sorata08]

Ich mach es bei Grafiken und Musik auch so, dass ich dort überall die Credits und dazugehörigen Lizenzen vermerke.
Wer die dann dennoch entgegen der Lizenz einsetzt, hat halt selber die Probleme im Nacken.
Wenn einer meine eigens angefertigten Ressourcen klaut (und ich das herauskriege), dann wird halt entsprechend der Forenmoderation oder dem Tropf persönlich geschrieben. °^°

Bezüglich meiner Technik und Scripts: Viel Spaß beim Durchwuseln dabei. Übersichtlichkeit ist was anderes.

MfG Sorata

[Rosa Canina]

Bezüglich meiner Technik und Scripts: Viel Spaß beim Durchwuseln dabei. Übersichtlichkeit ist was anderes.

...

Bei Scripten kann man das ja teilweise noch rauskopieren. Aber wenn man dann mit Events das ganze noch zusammenschustert,
dann verdient der "Dieb" eigentlich eine Medallie, wenn er DARAUS dann noch etwas machen kann XD
So etwas zu übernehmen ist IMO sogar schwerer, als etwas eigenes zu bauen.

[WeTa]

Viel Spaß beim Durchwuseln dabei. Übersichtlichkeit ist was anderes.

...

Aber wenn man dann mit Events das ganze noch zusammenschustert,
dann verdient der "Dieb" eigentlich eine Medallie, wenn er DARAUS dann noch etwas machen kann XD
So etwas zu übernehmen ist IMO sogar schwerer, als etwas eigenes zu bauen.

...

If it was hard to write, it should be hard to read in allen Ehren, aber das spricht nicht gerade für euren Code

[Rosa Canina]

If it was hard to write, it should be hard to read in allen Ehren, aber das spricht nicht gerade für euren Code

...

Ganz ehrlich, mein Code ist, wie man im englischen so schön sagt "quite a mess".

Das liegt daran, dass ich anfangs alles gaaaaanz einfach baue und es dann im Laufe der Entwicklung immer aufwendiger mache, immer
weiter ausbaue... hier und da Code raus haue, anderen Code einbaue oder einfach "vorrübergehend ausklammere".
Beispiel: Der Unterschied von AVoR Demo 1 (oder gar Beta) zum momentanen KS ist ein Unterschied, wie Mondschein zu Velsarbor... oder so :'D

Ich meinte mit meinem Statement auch eigentlich, wenn jemand so gut einen Code lesen kann, dass er damit effektiv weiter arbeiten
kann, dann könnte er es auch selbst bauen - und dann klaut man für gewöhnlich eher nicht. Wir reden ja hier nicht von einem Simpel-
Tag und Nacht-System, sondern von aufwendigen Dingen, wie z.B. Menüs oder Kampfsystemen.

[sorata08]

If it was hard to write, it should be hard to read in allen Ehren, aber das spricht nicht gerade für euren Code

...

Was zählt, ist doch das Ergebnis.
Ich setze mal einfach voraus, dass der Code nicht so grottig ist, dass alles laggt wie Hölle o.Ä.
Aber viele Features sind bei mir z.B. über diverse Scripte verteilt, weil ich halt immer kleinere Edits eingebaut habe, anstatt da ganze Scripte zu überschreiben. In der Hinsicht ist es nur unübersichtlich, weil es "überall verstreut" ist. xD

MfG Sorata

[TwoFace]

Was zählt, ist doch das Ergebnis.

...

Jep. Is eh nicht deine Aufgabe als Entwickler, den Code so zu gestalten, dass er möglichst nachvollziehbar für absolut jeden ist.

[WeTa]

Jep. Is eh nicht deine Aufgabe als Entwickler, den Code so zu gestalten, dass er möglichst nachvollziehbar für absolut jeden ist.

...

Sauberer Code ist in erster Linie im Interesse des Entwicklers Der Maker ist eh schon messy genug, wenn man da keine Ordnung hält, findet man sich schnell in der Debughölle wieder.

[Corti]

Mein Code ist (wenn ich ihn mit Sachen vergleiche, die ich in anderer Leute Spielen gesehen habe ) recht sauber und strukturiert. Ich kommentiere recht viel, meine CEs haben oft Header die Funktion, Aufruforte, Parameter und Bedingungen beschreiben. Meine CEs und Variablen sind blockartig statt verteilt in den Datenbanken angeordnet und sind im Regelfall anhand ihres Namens (z.B. <Skills> HeroDataArrayPointer ) gut ihrem System und ihrer Funktion zuzuordnen.

Das ändert nichts an der Tatsache, dass es sinnlos ist von mir Code zu klauen. Der Maker erlaubt keine richtigen Funktionen mit Parametern und lokalen Variablen, wenig was es erleichtert Code wiederzuverwerten, somit sind die meisten Sachen sehr projektspezifisch. Wer es klauen will muss den Code verstehen und wer den Code versteht könnte es auch selbst schreiben. Wer meine Kommentare liest, es dadurch versteht und es dann selbst schreiben/nachbauen kann hat was gelernt,... gern geschehen war mir eine Freude.

Ich werde die Kommentare allesamt da lassen wenn ich mal veröffentliche weil es denke ich auch mal ganz interessant sein kann zu sehen wie Systeme unter der Haube ticken.

Jep. Is eh nicht deine Aufgabe als Entwickler, den Code so zu gestalten, dass er möglichst nachvollziehbar für absolut jeden ist.

...

Code wird vielfach öfter gelesen als geschrieben, am öftesten vom jeweiligen Entwickler. Das Gegenargument lautet "aber ich weiss doch was mein Code tut", das ist okey, wenn man ein Superbrain ist und nach 3 Jahren noch genau weiss was jede der x-tausend Codezeilen in hunderten CEs bedeutet. Ich bin nicht Superbrain, darum arbeite ich so, dass ich es beim nächsten mal möglichst leicht habe, Fehler zu finden, Sachen umzuändern/umzustricken etc.

Oh~ und sauber, strukturiert und nachvollziehbar werkeln ist keine Frage von vergeudeter Zeit oder zusätzlichem Aufwand. Man kann eine Variable "SklHeDAP" nennen oder "<Skills> HeroDataArrayPointer", wieviel Tippzeit ist das verglichen mit der Zeit die ich spare auch nur ein mal zu überlegen, was die Buchstaben in der Abkürzung wohl bedeuten? Natürlich ist auch das nicht schwer und schnell zu dekodieren wenn man sich eine Syntax angewöhnt und etwas Routine entwickelt, aber lesen ohne denken >>>>>>> Denknotwendigkeit. Es gibt genug Sachen an die man denken muss. Dinge klarer und trivialer machen schafft Kapazitäten für die wirklichen Aufgaben die man lösen will.

Kommentare schreiben heisst nicht "// hier wird Variable a + Variable b gerechnet" über die Zeile VarA +=VarB zu schreiben, sondern in kurzen informativen Ausdrücken das zu beschreiben, was nicht sowieso offensichtlich ist. Wenn man sich das erstmal angewöhnt hat ist das eine Sache von Sekunden.
Die Zeit hat man sich wieder eingespart wenn man einmal einen kleinen Fehler sucht oder 'ne Woche später nochmal eine Kleinigkeit ändert.

Wie gesagt, ausser man ist Superbrain, aber Superbraine sind selten und wer sich denkt "brauch ich nicht" und später mit "mein Code tut nicht was ich will, Hilfe!" im Technikforum aufkreutzt, sollte sich Gedanken über die eigene Arbeitsweise machen. Wer sauber strukturiert und dokumentiert was wann passiert wird an den Punkt sehr viel wahrscheinlicher gar nicht erst kommen.

[TwoFace]

Sich bei den Benennungen der Varis Mühe zu geben sollte eig selbstverständlich sein. Hauptsache ist aber, dass du als Entwickler auch später noch was damit anfangen kannst. Nicht Hinz und Kunz. Comments sind ziemlich nützlich. Mach ich auch. Als ich mit meinem Bruder an Colors of Damnation gearbeitet hab, hab ich öfters Comments in die CEs reingeklatscht, damit er Bescheid weiß, was überhaupt Sache ist, wenn ich ihm das Game in die Dropbox reinschmeiße. Genauso hats er gemacht und das Ganze hat super funktioniert.

Wenn ich allein an einem Projekt arbeite mach ich das genauso (Comments als Gedankenstütze), hau sie dann aber wieder raus, wenn ich weiß a) der Event funktioniert und b) ich muss, wenn er nicht funktioniert, nur 1-2 Varis abändern und das Ding tut. Kommt natürlich immer auf den Code an.

[Corti]

Sich bei den Benennungen der Varis Mühe zu geben sollte eig selbstverständlich sein.

...

Es gibt Leute, die hatten schon 10 Jahre Berufserfahrung als Softwareentwickler, als ich damals gelernt hab mir die Schuhe zuzubinden und benennen ihren Variablen heute noch v1, v2, v3 etc. Wenn sowas nicht selbstverständlich ist bei Leuten, die ihre paar tausend € im Monat dafür kriegen bezweifle ich, dass man bei Makerleuten ohne Programmierahnung von "selbstverständlich" reden kann. Benennt den Kram richtig, verdammt. V2 ist 'ne Rakete.

[TwoFace]

Wenn "v1, v2, v3 etc." für diese Leute Bezeichnungen mit genug Wiedererkennungswert sind, sodass sie auch nach 3+ Tagen noch was damit anfangen können, dann ist das doch gut und alles passt. Genauso kenn ich Mathematiker, die im Kopf 6823779498 Rechenschritte überspringen, während sie dir etwas, das für sie selbstverständlich ist, vermeintlich auf dein Niveau runtergebrochen, zu erklären versuchen, und im Endeffekt peilst du gar nix. Kommt also immer auf den Menschen an. Wenn ein Programmierer, der Geld für seinen Job bekommt, seinen eigenen Code nicht mehr blickt, dann ist das in erster Linie peinlich.

[Corti]

Und das meinte ich mit "jetzt kommt Superbrain....", denn mit dem Argument kannst du alles auskontern, prinzipiell kannst du bei jeglicher Form von Tipp oder Ratschlag sagen "es gibt aber Leute, die müssen das nicht" und wenn jetzt jemand seine Variablen v1, Horst und Pimmelnase nennt ist das ganz toll, weil es für genau denjenigen sicherlich perfekt ist, unkritisierbar. Die Annahme, dass jeder von uns ein individuelles schneeflockiges Superbrain sei, ist aber unfug. Es birngt nichts Inkompetenz in Sinne der Hypertoleranz aktzeptabel zu diskutieren.

Es gibt Sachen, die werden aus einem Grund gemacht, z.B. so zu coden, dass es leicht lesbar ist. Und "leicht" nicht im Sinne von "für einen individuellen Grenzfall" wodurch "sh2ngg11" wieder zur perfekten Benennung für eine Variable werden würde, sondern allgemeingültiger. Bei Programmierneulingen ists oft so, dass kein Bock, kein Verständnis dafür da ist warum man nicht "hin••••••••n, hauptsache läuft irgendwie" arbeiten sollte. Jetzt kommt TwoFace, du würdest sagen "hey, wenn das genau für dich richtig ist, dann mach das so", das ist schön. Damit kann jeder für sich sagen "egal welche Eigenart, die von Fachleuten sind 150 Jahren für dumm erklärt wurde ich auch habe, sie ist perfekt, ich sollte genau so bleiben.", Unwissenheit, Faulheit, alles perfekt gerechfertigt durch Hypertoleranz.

Ding ist: v3, blablubb, t4b sind für keinen Menschen auf der Welt bessere Variahblennamen als itemCount, cursorPosition und <Skills>StackPointer. Man kann die schlechteren Namen in Kauf nehmen wenn man der Meinung ist, davon mehr zu haben. Zeitersparnis verglichen mit dem Ausschreiben, oder "och nöö kein Bock die richtig zu benennen", was auch immer. Hier viel Zeit zu sparen ist ein Irrglaube, vielfach erwiesen, allgemein bekannt, einfach weil korrektes Bennenen wirklich minimalst Zeit kostet. Und auch wenn es Leute gibt, die mit "Blablubb, blablub und blubbbla" als Namen arbeiten können, es gibt niemanden(ich lehne mich aus dem Fenster), der damit besser arbeiten kann als mit richtigen Namen, die etwas aussagen.

[Rusk]

Was ich jetzt schon hassen werde: ich komme zu einem neuen Arbeitsplatz und muss an einem Programm weiterschreiben, bei dem der vorheriger Entwickler sich nicht die Mühe gemacht hat, vernünftige Variablennamen zu vergeben (von Kommentaren ganz zu schweigen).
Besser kann es ja nicht beginnen.

[TwoFace]

Ist ja was ich sage. Es muss für denjenigen, der es entwickelt perfekt sein. Ob wer anders durchpeilt ist doch übertrieben egal. Mit "Superbrain" hat das nichts zu tun. Nur damit, dass man das, was man fabriziert, auch im nachhinein noch nachvollziehen können sollte. Und das tut schließlich jeder auf seine Art.

Jetzt gibts ja aber auch Leute, die ihre Varis und Switches extra so benennen, dass der Code an sich für andere schwer nachvollziehbar wird und dann wird auch evtl. der ganze Code entsprechend auf der Basis aufgebaut. "Leicht lesbar"ist für jeden was anderes. Was für dich total simpel ist könnte für mich der komplizierteste Shit ever sein, genauso umgekehrt. Die perfekte Definition für "leicht" gibt es also nicht. Nur eine Annäherung an "leicht verständlich", wobei sich das dann auch wieder von Mensch zu Mensch und von Denkweise zu Denkweise unterscheidet. Dein Hirn ist schließlich nicht genauso vernetzt wie das von jedem anderen, der mit dem Maker arbeitet. Deine Kritik an "Hypertoleranz" ist genau dann berechtigt, dass, wenn jemand seinen Code irgendwie macht, er dann nicht funktioniert und der Entwickler selbst nicht einmal mehr in der Lage ist, nachzuvollziehen, woran das überhaupt liegt.

Beim Maker gibts kein richtig und falsch. Nur ein "funktioniert wie ich will" und ein "funktioniert nicht wie ich will".

[MagicMaker]

Es muss für denjenigen, der es entwickelt perfekt sein.

...

Undzwar auf möglichst langem Zeitraum, ist keine leichte Angelegenheit, wenn die Events auch mal über ein paar
kurze Zeilen oder nur sehr einfache Befehle ohne komplizierten Zusammenhang zueinander hinausgehen.

Also ich hab ja stellenweise selbst mit annährend vorhandener Struktur und vielen Notizen erhebliche Probleme,
nach ein paar Wochen selber noch zu verstehen, was ich da eigentlich zusammengezimmert hab. Das kann sehr
aufhaltend sein, wenn später Bugs auftauchen, von denen man vorher nichts bemerkt hat und partout die Ursache
nicht auftreiben kann, da sitz ich jetzt auch schon lange fest.

[The_Burrito]

Wenn ein Programmierer, der Geld für seinen Job bekommt, seinen eigenen Code nicht mehr blickt, dann ist das in erster Linie peinlich.

...

Das ist manchmal viel schwerer als mein meinen möge. Nur weil du im Moment gerade weißt was dein Code macht, und nur weil du das in 2 Tagen auch noch weißt, heißt das nicht, dass nach 6 Monaten Arbeit an anderen Projekten, es noch immer genau so ist.
Ich wage es einmal zu bezweifeln, dass jemand der nie Kommentare schreibt und seine Variablen komplett Sinnfrei benennt (oder auch einfach nur unsprechend) sich nach einer gewissen Zeit noch daran erinnern wird, was er sich damals Gedacht hat, als er den Code geschrieben hat.

Es ist nicht peinlich seinen Code nicht mehr zu verstehen nachdem man lange Zeit was anderes gemacht hat, egal wie scheisse man ihn geschrieben hat. Es ist einfach nur strunz dumm in seinem Code keine Vorkehrungen zu treffen, sich später leicht wieder einlesen zu können, denn es kostet kaum mehr Mühe es zu tun als zu lassen.

Ist ja auch richtig so. Sagt ja niemand, dass man es sich schwieriger machen muss als nötig. Ich sagte ja auch nur, dass der Code für einen selber möglichst leicht nachvollziehbar sein sollte und nicht allgemein für jeden anderen, der das Spiel im Maker öffnet.

...

Wenn ich meinen Code so schreibe, dass ihn auch ein Fremder nachvollziehen kann, steigen damit die Chancen, dass ich es selber nach einiger Abstinenz von diesem Code auch noch tun kann.