RPG Game verschlüsseln

[Thuin8]

Bugs kann man aber locker eingrenzen. Testplay: Was passiert / was läuft falsch? Woran könnts demzufolge liegen? Keine Ahnung? Mal auf F9 draufklatschen, schaun was für Werte die Varis haben und welche Switches ON / OFF sind. Rückschlüsse ziehen. Immer noch keine Ahnung? Eventcode durchchecken von vorne bis hinten. Ablauf wiederholen.

Klappt bei mir immer relativ gut. Auch wenn ich denk, dass ich den Fehler eh nicht find, irgendwann find ich ihn dann schon. ^^

...

Auch wenn das beim Maker vielleicht unwahrscheinlicher ist als bei größeren Applikationen, die nicht auf dem Maker entwickelt werden: es kann auch mal sein, dass man einen Bug erst spät entdeckt, weil er vielleicht von komplett anderen Switches und Variablen hervorgerufen wird, als man anfangs meinen mag. Und da ist es dann auch schön, wenn man den Code noch Monate später ideal lesen kann und nicht mehr überlegen muss welche Variabel was bedeutet.

Ich persönlich finde es zum Beispiel schon sehr ärgerlich, dass Variablennamen in der Länge sehr stark begrenzt sind. Ich muss da oft deutlich mehr kürzen als ich eigentlich gerne würde. Eventuell könnte man dadurch entgegenwirken, wenn man bestimmte Gruppierungen in den Variablen benennen könnte, aber auch das ist ja leider nicht möglich.

Ich bin da also insgesamt sehr nah bei Cortis Meinung: Code sollte möglichst gut strukturiert sein, möglich gut kommentiert werden und die oberste Devise ist, dass der Code auch gut zu lesen ist. Ansonsten wird man irgendwann Probleme bekommen, wenn man mal eine Programmierpause einlegt und dann erst nach Wochen oder gar Monaten wieder vor diesen Codezeilen sitzt und nicht mehr weiß, warum man jetzt genau diesen einen Befehl mit eingebaut hat, der möglicherweise in der Form irgendein bis dahin unbekanntes Problem verursacht.

[TwoFace]

Und da ist es dann auch schön, wenn man den Code noch Monate später ideal lesen kann und nicht mehr überlegen muss welche Variabel was bedeutet

...

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.

[Thuin8]

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.

...

Die Aussage mag für Projekte, die man allein entwickelt noch halbwegs zutreffen. Auch auch da wären wir dann beim Superbrain. Du kannst mir nicht wirklich weißmachen, dass der "normale" Programmierer sich mehrere hundert kryptische Variablennamen, die keine eindeutige und sofort erfassbare Bezeichnung haben, über Monate hinweg merken kann.

[Corti]

Er hat schon nicht ganz Unrecht was das Individuelle angeht. Kryptisch ist für niemandem einfacher. Aber es gibt andere Sachen wie zB m_ für Member, g_ für Global, eigene Sachen, die einige Leute geil und andere scheisse finden. Man kann zB jeder Variable [0234] HeroCursorSlot die Nummer des CEs vorschreiben in der sie verwendet wird. Einige findens praktisch, andere findens nervig weil da dann so viel Zeugs im Namen steht. Ich z.B. setze als Prefix immer "< Systemname > Variablenname", zB "< Talente > Ausgewählter Held" weils eine für mich angenehme Mischung aus Datentrennung durch Syntax und lockere Lesbarkeit darstellt, aber das ist eben Geschmackssache.

Trotzdem, wenn auch nicht für jeden optimal, ist meine Syntax imo für jedermann gut lesbar. Ich finde auch nicht, dass da so ein gravierender Unterschied ist zwischen "für mich perfekt" und "für alle gut" wenn man sich nicht grade selbst anlügt. Wenn die Namen unkryptische Informationen enthalten ist das schonmal gut. Gleiche Bennenungsstruktur überall ist auch gut, für wen solls gut und besser sein wenn sich das Benennungsmuster stetig ändert?

Blablubb ist nur behindert.

[Rusk]

Ihr vergleicht Programmieren mit Makern.

[Owly]

@Deamonic: Anwendungsentwicklung funktioniert immer nach denselben Prinzipien.

[Corti]

Maker ist wie Assembler zum Klicken ;-)

[MajinSonic]

Und dann haben die neuen Maker RGSS, was schließlich ebenfalls programmieren ist.

[Morden]

Egal wo in der Anwendungsentwicklung: Kommentare und Dokumentation sind wichtiger, als man denken mag!

Und es ist nicht egal, ob man das irgendwie hinklatscht oder sich eine saubere Struktur überlegt! Sowohl für denjenigen, der es erstellt, als auch für etwaige andere Personen!
Man sollte zumindest darauf achten eine gewisse Konsistenz in sein Skript/seinen Quelltext zu bringen. Damit meine ich, dass man bestimmte immer wiederkehrende Probleme auch möglichst auf die gleiche Art und Weise löst (von der Schreibweise und Logik her) - so ist es im Nachhinein viel einfacher auf einen Blick zu erkennen »Was geht dort ab und wann bin ich wo im Quelltext/Skript angelangt?«
Klar ist für jeden "klar verständlich" anders zu definieren, aber dennoch kann mir keiner erzählen, dass er einfacher durch seine Sachen blickt, wenn er keine Kommentare oder Dokumentation hinterlässt und nicht konsistent arbeitet. Auch sollte man für wiederkehrende Aufgaben - auch im Maker - eine Art Funktion schreiben/skripten. So garantiert man a) dass es auf die gleiche Art und Weise funktioniert - an jeder Stelle, an der es eingesetzt wird, und b) ist die Wartung viel einfacher, denn eine Funktion abzuändern ist einfacher, als an tausend Stellen im Quelltext/Skript nach dieser Funktion zu suchen und sie anzupassen bzw. zu copy/pasten.

Und apropos RGSS - schaut euch den originalen RGSS-Quelltext an, der ist auch komplett kommentiert und dokumentiert…

PeAcE
MorDen

[Cepanks]

Und apropos RGSS - schaut euch den originalen RGSS-Quelltext an, der ist auch komplett kommentiert und dokumentiert…

...

Wobei die Kommentare ein gutes Beispiel dafür sind, wie man es eigentlich nicht machen sollte, weil sie in der Regel so aussehen:

Code:

#--------------------------------------------------------------------------
# * Remove Actor
#     actor_id : actor ID
#--------------------------------------------------------------------------
def remove_actor(actor_id)
  # Delete actor
  @actors.delete($game_actors[actor_id])
  # Refresh player
  $game_player.refresh
end

Das fällt genau in die Kategorie von unnötigem Kommentar, die Corti irgendwo weiter oben angesprochen hat. Es sollte z. B. eigentlich offensichtlich sein, dass $game_player.refresh höchstwahrscheinlich genau das tut: Das Spieler-Objekt refreshen. Andernfalls hat man bei der Methoden-Bennenung was falschgemacht.

Und bei komplexeren Dingen, bei denen man sich eine Erklärung wünschen würde, steht dann hingegen meist garnichts o_o

[Morden]

@Cepanks

Da muss ich dir dann durchaus Recht geben. Ich meinte damit ja auch nicht, dass die Kommentare und Dokumentation der RGSS-Parts jetzt sonderlich gut ist - ich weiß, dass sie das im Gegenteil eher nicht ist. Ich wollte damit nur sagen, dass diese halt auch kommentiert sind.

Im Allgemeinen sollte man natürlich versuchen seine Variablen, Funktionen, Klassen und Methoden einfach nachvollziehbar benennen - davon kann man nur profitieren! Sollte ein Funktionsaufruf o.Ä. natürlich selbsterklärend sein - wenn man denn die Sprache in der sie geschrieben ist, lesen kann - ist ein Kommentar natürlich einfach nur unnötig und verwirrt eher, als dass er unterstützt. Man sollte im Allgemeinen nicht jede einzelne Zeile kommentieren, nützlicher ist es eher einen kompakten Kommentar vor eine Verzweigung oder Schleife zu packen, der beschreibt was sie macht - sollte das nicht schon von vornherein ersichtlich sein. Ist zumindest meine Meinung, die natürlich nicht jeder teilen muss^^

PeAcE
MorDen

[MagicMaker]

Und bei komplexeren Dingen, bei denen man sich eine Erklärung wünschen würde, steht dann hingegen meist garnichts

...

Guck dir das obligatorisch-typische Spiel auf einer Makerengine an:
Erklären den einfachsten Doofmist und tun's genau dann nicht, wenn's mal von Nöten wäre.

Es überträgt sich sozusagen von hinter auf vor die Kulissen.