RPG Game verschlüsseln

[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.

[Cornix]

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.

...

Für simple Funktionen ist es simpel einen Kommentar zu schreiben.
Eine komplizierte Funktion welche man mit nur viel Denkarbeit und Trial&Error schreiben konnte ist hingegen schwer zu kommentieren, vor allem wenn man nicht sofort kommentiert nachdem man die Funktion geschrieben hat sondern erst im Nachhinein.

Generell bevorzuge ich sehr einfach verständliche und konsequente Namensgebung für Variablen und Methoden beizubehalten, sodass man die meisten Methoden nicht kommentieren muss.
Was man kommentieren sollte sind Ausnahmefälle, Vorbedingungen für die Ausführung einer Funktion, Schleifeninvarianten (bei komplexen Schleifen), oder wenn man gewisse Schritte zur besseren Effizienz "weniger" übersichtlich schreibt weil es sich um eine kritische Funktion handelt.
Außerdem, wenn die Bibliothek veröffentlicht werden soll, liebe ich es immer wenn in die Kommentare auch geschrieben wird, ob es sich um eine heavy- oder lightweight Methode handelt.

[Corti]

Eine Kommentarmethode , die sich bei mir im Job und im Maker bewährt hat:
Ich beschreibe als Text vollständig was die Funktion machen soll. Bevor ich auch nur eine Zeile Code tippe. Wenn die Funktion fertig ist muss ich nur noch den Text zerstückeln und verteilen ;-)

[Rusk]

Eine Kommentarmethode , die sich bei mir im Job und im Maker bewährt hat:
Ich beschreibe als Text vollständig was die Funktion machen soll. Bevor ich auch nur eine Zeile Code tippe. Wenn die Funktion fertig ist muss ich nur noch den Text zerstückeln und verteilen ;-)

...

Und vor der Kommentarmethode wird es, wie es sich gehört brav ein Ablaufdiagramm erstellt.

[Nemica]

Und vor der Kommentarmethode wird es, wie es sich gehört brav ein Ablaufdiagramm erstellt.

...

Ablaufdiagramme sind überbewertet. Aber ich hab schon mindestens eine Doku für meine Eventscripts geschrieben.

[Rusk]

Ablaufdiagramme sind überbewertet. Aber ich hab schon mindestens eine Doku für meine Eventscripts geschrieben.

...

Ich meinte das auch sarkastisch ... ich kann mich nie wirklich mit diesen Dingern anfreunden. Ich mach sie sowieso nie, einfache Notizen sind da schon das Maximum. ^^