Gibt es eine Möglichkeit sein Spiel zu verschlüsseln, sprich, dass man mein Game nicht per Maker aufknacken
kann oder gar die Ressourcen aufmachen kann?
Druckbare Version
Gibt es eine Möglichkeit sein Spiel zu verschlüsseln, sprich, dass man mein Game nicht per Maker aufknacken
kann oder gar die Ressourcen aufmachen kann?
Molebox bietet Möglichkeiten seine Ordner zu verschlüsseln aber die Perfomance leidet furchtbar darunter daher finde ich es sinnlos ...
XP, VX, Ace verwenden. Da hast du das von Grund auf mit drin.
Für den 2k oder 2k3 gibts die Molebox. Die macht allerdings die Performance schlechter und Probleme bei dem einen oder anderen.
Lohnt sich Verschlüsselung? Nein. Ripps und Edits zu verschlüsseln ist lächerlich und bei Ressourcenklau sorgt die Community selbst für die Ächtung jener, die sich zu dreist bei anderen bedienen.
Was die Performance angeht würd ich bei viel eigener Technik und Actionkampfsystemen schonmal grundleegend davon absehen.
Was Ressourcenklau angeht sollte man imo keine überzogene Paranoia haben. Versicherungen definieren "Schaden" als "Eintrittswahrscheinlichkeit * Ausmaß" oder so. Wie wahrscheinlich ist, dass man dich ausplündert? Gering. Was kann schlimmstens passieren? Irgendwer benutzt ein paar Sprites. Chance, dass derjenige wirklich ein Spiel rausbringt ist wiederum gering, Chance dass jemand, der Ressourcen zusammenklaut ein Spiel macht, dass wirklich bombe ankommt und dann mit einen Ressoucen beliebt wird...auch gering.
Auf eigene Sachen,also komplett eigene hast du ausserdem Copyright.
Wenn du dir nicht sicher bist, ob du dein Game wegen den Ressourcen (egal ob selbsterstellt oder Auftragsarbeiten) zum Download freigeben willst, dann lass es einfach.
Im ersten Moment scheint das ärgerlich zu sein, wenn jemand deine Ressourcen ungefragt verwendet.
Aber bedenke:
Personen die Ressourcen klauen sind meist nicht in der Lage diese auch in gute Spiele einzubauen.
Da kommen meist Trash-Games oder Parodien heraus, die sich aber positiv auf Bekanntheit des Original-Spiel auswirken.
Folglich machen die sogar unfreiwillig Werbung für dein Spiel. Das ist für dich eine Win-Win-Situation, die du dir mit einer Verschlüsselung verbaust oder erschwerst.
Deswegen solltest du dir nochmal genau überlegen, ob du erstens dein Game überhaupt zum Download freigeben willst und zweitens ob du dies auch verschlüsselst.
PS: Molebox lässt sich schnell knacken.
Ist wie mit Kopierschutz. Wer dran vorbei will, hat leichtes Spiel und wer das Game geniessen will,Zitat:
PS: Molebox lässt sich schnell knacken.
bekommt eine müllige Vercrypterei vorgesetzt, die das Erlebnis beeinträchtigt, insofern:
...ausser dir ist alles und jeder egal und willst nur die Leute mit einem Haufen Scheisse belästigen.Zitat:
[...] lass es einfach.
Ich gehe mal davon aus, dass das nicht so ist.
Aber liebevoll erstellte, fremde Ressourcen haben nichts in Trashspielen zu suchen. :/Zitat:
Zitat von niR-kun
Bei guten Spielen wäre ich, bezüglich auf meine Ressourcen, irgendwie schon nachsichtiger.
Wer die Ressourcen will, wird sie meistens auch auf irgendeinem Weg bekommen. Aber ich kann jeden verstehen, der das diesen Leuten etwas schwieriger machen will, um damit vllt einen Großteil der 0815-Scriptkiddies abzuwehren.
Ich persönlich würde es auch nicht toll finden, wenn Arbeiten, in die ich viel Mühe gesteckt habe dann ohne zu fragen geklaut und einfach so in anderen Spielen weiterverwendet werden. Ich finde allerdings auch, dass man da einen Mittelweg finden muss, damit das Spielerlebnis nicht negativ beeinflusst wird.
Das...Zitat:
Wer die Ressourcen will, wird sie meistens auch auf irgendeinem Weg bekommen
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 ^^
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
Bei Scripten kann man das ja teilweise noch rauskopieren. Aber wenn man dann mit Events das ganze noch zusammenschustert,Zitat:
Bezüglich meiner Technik und Scripts: Viel Spaß beim Durchwuseln dabei. Übersichtlichkeit ist was anderes.
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.
Zitat:
Zitat von 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 :pZitat:
Zitat von Rosa Canina
Ganz ehrlich, mein Code ist, wie man im englischen so schön sagt "quite a mess".Zitat:
If it was hard to write, it should be hard to read in allen Ehren, aber das spricht nicht gerade für euren Code
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.
Was zählt, ist doch das Ergebnis. ;)Zitat:
Zitat von Tako
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
Jep. Is eh nicht deine Aufgabe als Entwickler, den Code so zu gestalten, dass er möglichst nachvollziehbar für absolut jeden ist.Zitat:
Was zählt, ist doch das Ergebnis.
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.Zitat:
Zitat von TwoFace
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.
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.Zitat:
Zitat von TwoFace
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.
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.
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.Zitat:
Zitat von 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.
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.
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. ;)
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".
Undzwar auf möglichst langem Zeitraum, ist keine leichte Angelegenheit, wenn die Events auch mal über ein paarZitat:
Es muss für denjenigen, der es entwickelt perfekt sein.
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.
Und das ist nichts was einem peinlich sein sollte. Es sich selbst einfacher machen in der Zukunft wieder durchzusteigen heisst nicht "omg, das hieße ja ich bin unfähig, coole Progranmmierer brauchen das nicht", stattdessen zeugt es von Verstand sich Notizen zurückzulassen.Zitat:
Zitat von MagicMaker
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. ^^
http://i.imgur.com/LtxFRNu.gifZitat:
Zitat von TwoFace
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.Zitat:
Zitat von TwoFace
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.
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.Zitat:
Zitat von Thuin8
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.Zitat:
Zitat von TwoFace
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.
Ihr vergleicht Programmieren mit Makern.
@Deamonic: Anwendungsentwicklung funktioniert immer nach denselben Prinzipien.
Maker ist wie Assembler zum Klicken ;-)
Und dann haben die neuen Maker RGSS, was schließlich ebenfalls programmieren ist.
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
Wobei die Kommentare ein gutes Beispiel dafür sind, wie man es eigentlich nicht machen sollte, weil sie in der Regel so aussehen:Zitat:
Zitat von Morden
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
@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
Guck dir das obligatorisch-typische Spiel auf einer Makerengine an:Zitat:
Und bei komplexeren Dingen, bei denen man sich eine Erklärung wünschen würde, steht dann hingegen meist garnichts
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.
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.Zitat:
Zitat von TwoFace
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.
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.Zitat:
Zitat von TwoFace
Für simple Funktionen ist es simpel einen Kommentar zu schreiben.Zitat:
Zitat von MagicMaker
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.
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. ;)Zitat:
Zitat von Corti
Ablaufdiagramme sind überbewertet. Aber ich hab schon mindestens eine Doku für meine Eventscripts geschrieben.Zitat:
Zitat von Deamonic
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. ^^Zitat:
Zitat von Nemica
Ach lass mir meinen Spaß. xDZitat:
Zitat von Deamonic
Und Kommentare haben auch den Vorteil, dass man sie vorm Release rauslöschen kann.
Kommentare vor dem Release zu löschen verfehlen meiner Meinung nach ihren Sinn und Zweck. Außer du meintest in Form von persönlichen Notizen, was aber dann keine richtigen Kommentare wären (zumindest nicht in richtigen Programmen und im Makerspielen ist es ja eh egal, was drinsteht. Das liest sich kein Mensch durch ^^).
PAP, Nassi-Shneiderman und wie sie nicht alle heißen - ich bin auch kein großer Freund davon. Ich persönlich denke aber, dass sie bei komplexen Projekten durchaus Sinn machen. Ein paar kleinere Notizen oder MindMaps mache ich doch durchaus manchmal - wenn auch sehr selten xD
Und naja, Kommentare vor Release zu löschen wäre in meinen Augen - gerade bei einem Makerspiel - mehr Aufwand als Nutzen. Immerhin muss man sich dann durch jedes einzelne EventScript quälen und die Kommentare suchen und herauslöschen.
PeAcE
MorDen
Wenn dein Code gut ist, dann hast du da nicht so viel, wo du durchscrollen musst.
Ich glaub so einfach hätten wirs alle gerne, aber darüber reden wir am besten nochmal, wenn du dein erstes, eigenes Action-KS skriptest, das vom Umfang und der Komplexität über auf-Gegner-zurennen-und-Enter-drücken hinausgeht. ;)Zitat:
Zitat von Nemica
Wenn man sich vorher Gedanken über sowas macht, ist das auch übersichtlich machbar.
edit: aber wir schweifen hier gerade ziemlich hart ab. Mein Punkt nochmal in kurz: Verständliche und übersichtliche Events die am besten noch gut kommentiert sind, sind in erster Linie nützlich für den Entwickler, weil man dadurch gerade beim Debugging und wenn man nach längerer Pause wieder ins Spiel steigt um einiges leichter klarkommt. Wer was anderes sagt geht auch zur Domina.