Anmelden
Registrieren
Freitag, 13. Juli 2007, 13:03
SDK - Fluch oder Segen?
Sollen meine Scripte das SDK benötigen?
Insgesamt 49 Stimmen
18%
Ja, immer doch (9)
82%
Nein, lieber nicht (40)
Hallo ihr lieben,
ich plane demnächst einige Scripte von mir zuveröffentlichen, nun würde ich gerne wissen, ob die das SDK 2.2 unterstützen sollen oder nicht.
Außerdem würde mich mal eure Meinung zum SDK allgemein interessieren.
Was haltet ihr vom SDK allgemein?
Was ist das SDK - Standard Development Kit?
-> http://www.rmxp.org/forums/showthread.php?t=1802
Gruß Sven
ich plane demnächst einige Scripte von mir zuveröffentlichen, nun würde ich gerne wissen, ob die das SDK 2.2 unterstützen sollen oder nicht.
Außerdem würde mich mal eure Meinung zum SDK allgemein interessieren.
Was haltet ihr vom SDK allgemein?
Was ist das SDK - Standard Development Kit?
Zitat
The Standard Development Kit (SDK) aims to increase compatibility between
RGSS scripts by:
a) defining a set of scripting standards (see section 3)
b) restructuring often-used default classes and methods (see section 4)
c) providing a scripting tools module (see section 5)
-> http://www.rmxp.org/forums/showthread.php?t=1802
Gruß Sven
 YAams |
 Random Signatur |
|---|---|
 |
|
Freitag, 13. Juli 2007, 15:57
Jedoch ein Fluch für diejnigen die kein RGSS können, weil viele Scripte dann inkompatibel sind und von einien Scripter erst mühselig angepasst werden müssen.
Und genau das ist durch das SDK nicht der Fall. Man kann nicht mehrere Scripte gleichzeitig laufen lassen, wenn diese sich gegenseitig überschreiben. Inkompatibilität tritt nicht erst durch das SDK auf, sondern ist praktisch immer gegeben. Meistens sogar recht subtil, was ich für ziemlich gefährlich halte. Ich erinnere mich da z.B. an irgendein Zelda-Projekt bei dem am Ende ein Haufen Bugs an völligen unerklärlichen Stellen auftreten. Bei genauerer Betrachtung stellte sich heraus, dass die Scripte sich gegenseitig an eher unauffälligen Stellen überschrieben haben, so dass es zwar nicht zu einem Absturz, dafür aber zu haufenweise Bugs kam.
Das SDK ermöglicht durch das Aufsplitten der Methoden, dass man eigene Inhalte in ein Script pluginmäßig einfügen kann, ohne bestehende Inhalte zu überschreiben. Wer sich nicht mit RGSS auskennt und nur auf eine möglichst große Auswahl an Scripten aus ist, hat es leicht das SDK als größten Schrott zu bezeichnen. Aber ich denke jeder Scripter ist dankbar für diese Arbeitserleichterung. Auch die Programmierkonventionen, die im SDK festgelegt sind, sind sehr angenehm. Tatsächlich haben viele Programmierer einen wirklich schrecklichen Stil, so dass ein Außenstehender kaum noch im Code durchblickt. Da sind klare Regelungen für Kommentare etc. durchaus positiv.
Sicherlich lässt sich das SDK noch etwas optimieren, aber man will natürlich auch die Kompatibilität zu den bereits bestehenden SDK-Scripten beibehalten. Damit befindet man sich nun mal in einer Zwickmühle, in der das SDK sich kaum noch weiterentwickeln darf.
Freitag, 13. Juli 2007, 16:11
Verdammt dumme frage 
Was genau ist SDK ? oO
Habs schon oft gelesen hab hat mich nie gefreut zu fragen
bin auch noch nie dagegen gestosse XD
so long
Vincent
Was genau ist SDK ? oO
Habs schon oft gelesen hab hat mich nie gefreut zu fragen
bin auch noch nie dagegen gestosse XD
so long
Vincent
Spoiler: Gezocke
CONSOL:
SERIEN:
Final Fantasy:
Final Fantasy IX
Final Fantasy X
Final Fantasy X-2
Final Fantasy XII
Final Fantasy CC
Final Fantasy Tactics
Final Fantasy Dirge of Cerberus
The Legend of Zelda:
The Legend of Zelda
The Legend of Zelda A Link to the Past + Four Swords
The Legend of Zelda DX
The Legend of Zelda Ocarina of Time
The Legend of Zelda Majoras Mask
The Legend of Zelda Wind Walker
The Legend of Zelda Twilight Princess
The Legend of Zelda Oracle of Ages
The Legend of Zelda Oracle of Seasons
The Legend of Zelda Four Swords Adventures
Hack. :
Hack. Infection
Hack. Mutation
Hack. Outbreak
Hack. Qurantine
EINZEL GAMES:
Dragon Quest - Suche nach dem verwunschenen König
Devil May Cry 3
PC:
Warcraft 3
World of Warcraft
Guildwars
zum Lesen den Text mit der Maus markieren
Freitag, 13. Juli 2007, 16:34
Spoiler: Gezocke
CONSOL:
SERIEN:
Final Fantasy:
Final Fantasy IX
Final Fantasy X
Final Fantasy X-2
Final Fantasy XII
Final Fantasy CC
Final Fantasy Tactics
Final Fantasy Dirge of Cerberus
The Legend of Zelda:
The Legend of Zelda
The Legend of Zelda A Link to the Past + Four Swords
The Legend of Zelda DX
The Legend of Zelda Ocarina of Time
The Legend of Zelda Majoras Mask
The Legend of Zelda Wind Walker
The Legend of Zelda Twilight Princess
The Legend of Zelda Oracle of Ages
The Legend of Zelda Oracle of Seasons
The Legend of Zelda Four Swords Adventures
Hack. :
Hack. Infection
Hack. Mutation
Hack. Outbreak
Hack. Qurantine
EINZEL GAMES:
Dragon Quest - Suche nach dem verwunschenen König
Devil May Cry 3
PC:
Warcraft 3
World of Warcraft
Guildwars
zum Lesen den Text mit der Maus markieren
Freitag, 13. Juli 2007, 16:48
@=Kai=
Ich hoffe jetzt nicht, dass du meine Scripte meinst :whistling:
Aber recht haste schon, mit komischen Programmierstyle, dass habe ich gerade beim HUD gemerkt > http://www.rmxp.org/forums/showthread.php?t=4247 Wenn man es sich so anschaut, sieht es auch wie 4 normale Windowfenster -> http://img490.imageshack.us/img490/8831/hud7dw.png . Aber denkste da liegt ein großes Window drüber, was den Text zeichnet und 4 kleine Windows die den Rahmen bilden. >.> Im Endeffekt durfte ich das ganze Script umschreiben.
Aber das große Problem beim SDK ist, dass es ziemlich spät kam, und alle alten Scripte nicht damit laufen :/
@Rabu
Gibt doch nicht allzuviele Versionen, bloß 1.5 und 2.2
@allgemein
Aber wirklich schlauer bin ich nun auch nicht, die Umfrage ist 50:50, vieles spricht für die SDK unterstützung, vieles dagegen. Wobei ich denke, dass meine Scripte eh nicht alles umschreiben. Bzw. immer nur das umschreiben, was kein anderes Script umschreibt, weil dann hätte ich ja das Script nutzen können
Gruß Sven
Ich hoffe jetzt nicht, dass du meine Scripte meinst :whistling:
Aber recht haste schon, mit komischen Programmierstyle, dass habe ich gerade beim HUD gemerkt > http://www.rmxp.org/forums/showthread.php?t=4247 Wenn man es sich so anschaut, sieht es auch wie 4 normale Windowfenster -> http://img490.imageshack.us/img490/8831/hud7dw.png . Aber denkste da liegt ein großes Window drüber, was den Text zeichnet und 4 kleine Windows die den Rahmen bilden. >.> Im Endeffekt durfte ich das ganze Script umschreiben.
Aber das große Problem beim SDK ist, dass es ziemlich spät kam, und alle alten Scripte nicht damit laufen :/
@Rabu
Gibt doch nicht allzuviele Versionen, bloß 1.5 und 2.2
@allgemein
Aber wirklich schlauer bin ich nun auch nicht, die Umfrage ist 50:50, vieles spricht für die SDK unterstützung, vieles dagegen. Wobei ich denke, dass meine Scripte eh nicht alles umschreiben. Bzw. immer nur das umschreiben, was kein anderes Script umschreibt, weil dann hätte ich ja das Script nutzen können
Gruß Sven
|
YAams |
Random Signatur |
|---|---|
|
|
|
Freitag, 13. Juli 2007, 17:07
@Abt
dann hab ich das wohl fehlinterpretiert, nichtsdestotrotz (saublödes Wort) gibt's Versionsprobleme zwischen 1.5. und 2.2 trotz Patch-Script.
Was den Ungang mit SDK auch schwierig macht, dass es halt nur die endlische Doku gibt, und man letztlich nicht wirklich weiss, welche Parts man nun wirklich braucht und welche man weglassen kann.
Ehrlich gesagt, ich bin aus der Doku nicht richtig schlau geworden, obwohl ich imho ganz gut Englisch kann.
dann hab ich das wohl fehlinterpretiert, nichtsdestotrotz (saublödes Wort) gibt's Versionsprobleme zwischen 1.5. und 2.2 trotz Patch-Script.
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#============================================================================== # ** RMXP Standard Development Kit (SDK) - Part I #------------------------------------------------------------------------------ # Build Date - 2005-11-22 # Version 1.0 - Near Fantastica - 2005-11-22 # Version 1.1 - SephirothSpawn - 2005-12-18 - (Near Fantastica) # Version 1.2 - Near Fantastica - 2005-12-18 - (Wachunga) # Version 1.3 - Wachunga - 2005-12-19 - (Near Fantastica) # Version 1.4 - Prexus - 2006-03-02 - (SephirothSpawn) # Version 1.5 - Jimme Reashu - 2006-03-25 - (Near Fantastica) # Version 2.0 - SephirothSpawn / Trickster / # Der Drake / Sandgolem - 2007-02-22 - (SDK Team) # Version 2.1 - tibuda /alexanderpas / Mr. Mo - 2007-02-25 - (SephirothSpawn) # Version 2.2 - SephirothSpawn / Trickster / # tibuda - 2007-04-04 - (SDK Team) #============================================================================== |
Was den Ungang mit SDK auch schwierig macht, dass es halt nur die endlische Doku gibt, und man letztlich nicht wirklich weiss, welche Parts man nun wirklich braucht und welche man weglassen kann.
Ehrlich gesagt, ich bin aus der Doku nicht richtig schlau geworden, obwohl ich imho ganz gut Englisch kann.
Rabu
Freitag, 13. Juli 2007, 17:16
Ich benutze das SDK nicht...
Der Ansatz vom SDK ist ja eigentlich wirklich gut, aber ich konnte mich bis heute noch nicht aufraffen mich mal damit auseinanderzusetzen.
Sprich, ich war bis jetzt einfach zu Faul
Ein weiterer Grund ist denke ich, dass wie man an diesem Thread hier sieht, viele User doch stark abgeneigt gegen das SDK sind. Wieso sollte ich für eine Unterzahl an Benutzern programmieren? ^^
Ne Scherz. Also mir fehlte bisher einfach die Zeit und die Lust mich durch das 15.000 Zeilige Script zu forsten, damit ich weiss, wie die entsprechenden Standardmethoden denn jetzt heißen, die ich verändern möchte. Aber ich mache ja meistens sowieso eher Miniskripte die am Standard nicht allzuviel verändern.
Aber bei größeren Skripten wär mir der Aufwand viel zu groß es noch mal umzuschreiben, da die Anzahl der SDK User ja eher beschränkt ist.
Naja, also bei mir ist das wie gesagt sone Geschmackssache ^^
Wenn du dein Skript schon in der Finalen Fassung hast, könntest du ja eine Non-SDK und eine SDK Version posten. Das ist natürlich nicht so Sinnvoll wenn das Skript noch in der Entwicklung ist ;-)
Also ich bin normalerweise erst mal dagegen ^^
Mfg Monsta
Der Ansatz vom SDK ist ja eigentlich wirklich gut, aber ich konnte mich bis heute noch nicht aufraffen mich mal damit auseinanderzusetzen.
Sprich, ich war bis jetzt einfach zu Faul
Ein weiterer Grund ist denke ich, dass wie man an diesem Thread hier sieht, viele User doch stark abgeneigt gegen das SDK sind. Wieso sollte ich für eine Unterzahl an Benutzern programmieren? ^^
Ne Scherz. Also mir fehlte bisher einfach die Zeit und die Lust mich durch das 15.000 Zeilige Script zu forsten, damit ich weiss, wie die entsprechenden Standardmethoden denn jetzt heißen, die ich verändern möchte. Aber ich mache ja meistens sowieso eher Miniskripte die am Standard nicht allzuviel verändern.
Aber bei größeren Skripten wär mir der Aufwand viel zu groß es noch mal umzuschreiben, da die Anzahl der SDK User ja eher beschränkt ist.
Naja, also bei mir ist das wie gesagt sone Geschmackssache ^^
Wenn du dein Skript schon in der Finalen Fassung hast, könntest du ja eine Non-SDK und eine SDK Version posten. Das ist natürlich nicht so Sinnvoll wenn das Skript noch in der Entwicklung ist ;-)
Also ich bin normalerweise erst mal dagegen ^^
Mfg Monsta
Spoiler: Bissi Zeusch
Skripte:
Animations "Entruckler"
Console
Drunken Mode
Eventskript Debugger
Flat-Events
Impassable Script
Item Shortcut
MSS: Monsta's Shoot System (Neu)
Radius Skript
Random Event Teleport
RMXP Leistungstest
Single Rotate
Split Screen (Beta)
Tutorials:
'alias' Bug beheben
Eigenes RTP
Standard KS komplett Übersetzen
RGSS: Eigener HUD
Programme:
Maker Exchange [ MEX ]
RMXP Skript Explorer
RPGXP Code Converter
Spiele:
[Minispiel] Stampfi V1.5 (Gold)
[Minispiel] Mastermind XP
[Humor] Verfressene Klone
______________________________
[Zukunft] Evil Science
zum Lesen den Text mit der Maus markieren
Freitag, 13. Juli 2007, 17:35
Ich weiß gar nicht was hier alle gegen das SDK haben XD Letztlich hilft das SDK vor allem dem BENUTZER. Durch das SDK kann man Scripte einfach in den Scripteditor reinkopieren. Non-SDK Scripte müssen manchmal doch auf spezielle Weise eingefügt werden ("geh in Zeile xyz und kopier dort die Zeile abc rein"). Außerdem ist es eine Sache von wenigen Minuten ein Script SDK-lauffähig zu machen.
lol, außer meinem "eval = evil" Vorurteil hab ich wirklich nix gegen deine Scripte - ganz im Gegenteil ^^
rofl. Und das große Window sicherlich mit opacity=0 XD Und wenn sich solche Sachen im Code häufen, muss man sich nicht aufregen, wenn das Spiel später ruckelt oO
Ich persönlich halte allerdings auch nicht viel von diesen selbstzeichnenden Balken (von Seph afair). Die sehen zwar ziemlich cool aus und scheinen auch toll geproggt zu sein (nur warum als Window-Methode -_-?), aber kosten einfach zu viel rechenzeit. Würde man einen vorgezeichneten Balken nehmen, würde man den Rechner extrem entlasten und hätte weniger mit der Performance zu kämpfen =/
Ich hoffe jetzt nicht, dass du meine Scripte meinst :whistling:
lol, außer meinem "eval = evil" Vorurteil hab ich wirklich nix gegen deine Scripte - ganz im Gegenteil ^^
sieht es auch wie 4 normale Windowfenster. Aber denkste da liegt ein großes Window drüber, was den Text zeichnet und 4 kleine Windows die den Rahmen bilden.
rofl. Und das große Window sicherlich mit opacity=0 XD Und wenn sich solche Sachen im Code häufen, muss man sich nicht aufregen, wenn das Spiel später ruckelt oO
Ich persönlich halte allerdings auch nicht viel von diesen selbstzeichnenden Balken (von Seph afair). Die sehen zwar ziemlich cool aus und scheinen auch toll geproggt zu sein (nur warum als Window-Methode -_-?), aber kosten einfach zu viel rechenzeit. Würde man einen vorgezeichneten Balken nehmen, würde man den Rechner extrem entlasten und hätte weniger mit der Performance zu kämpfen =/
Freitag, 13. Juli 2007, 22:44
Segen für Scripter, wegen den Funktionen und Hilfen...
Jedoch ein Fluch für diejnigen die kein RGSS können, weil viele Scripte dann inkompatibel sind und von einien Scripter erst mühselig angepasst werden müssen.
Lass am besten weg
Ich finde auf 1-Linie Methoden und Funktionen kann ich locker verzichten. Ganz besonders wenn die eine Linie "super" sagt. Das einzige, was ich noch als mühseliger empfinde ist SephirothSpawn, wenn er mal wieder nicht über seinen Schatten springen kann.
Jedoch ein Fluch für diejnigen die kein RGSS können, weil viele Scripte dann inkompatibel sind und von einien Scripter erst mühselig angepasst werden müssen.
Und genau das ist durch das SDK nicht der Fall. Man kann nicht mehrere Scripte gleichzeitig laufen lassen, wenn diese sich gegenseitig überschreiben. Inkompatibilität tritt nicht erst durch das SDK auf, sondern ist praktisch immer gegeben. Meistens sogar recht subtil, was ich für ziemlich gefährlich halte. Ich erinnere mich da z.B. an irgendein Zelda-Projekt bei dem am Ende ein Haufen Bugs an völligen unerklärlichen Stellen auftreten. Bei genauerer Betrachtung stellte sich heraus, dass die Scripte sich gegenseitig an eher unauffälligen Stellen überschrieben haben, so dass es zwar nicht zu einem Absturz, dafür aber zu haufenweise Bugs kam.
Das SDK ermöglicht durch das Aufsplitten der Methoden, dass man eigene Inhalte in ein Script pluginmäßig einfügen kann, ohne bestehende Inhalte zu überschreiben. Wer sich nicht mit RGSS auskennt und nur auf eine möglichst große Auswahl an Scripten aus ist, hat es leicht das SDK als größten Schrott zu bezeichnen. Aber ich denke jeder Scripter ist dankbar für diese Arbeitserleichterung. Auch die Programmierkonventionen, die im SDK festgelegt sind, sind sehr angenehm. Tatsächlich haben viele Programmierer einen wirklich schrecklichen Stil, so dass ein Außenstehender kaum noch im Code durchblickt. Da sind klare Regelungen für Kommentare etc. durchaus positiv.
Sicherlich lässt sich das SDK noch etwas optimieren, aber man will natürlich auch die Kompatibilität zu den bereits bestehenden SDK-Scripten beibehalten. Damit befindet man sich nun mal in einer Zwickmühle, in der das SDK sich kaum noch weiterentwickeln darf.
Das grösste Problem bei diesen "Plugin" Skripten ist, dass sie von SDK abhängen. Bei Definition ist ein Standard nicht wovon etwas "abhängen" sollte. Der Name Standard Development Kit ist damit eigentlich bloss eine Farse.
Ich finde auch, dass sich SDK noch optimieren lässt. Hoppla, es gibt doch bereits eine Optimisation: RTP Skripts. Hat jemand eigentlich mal sich das SDK v2.2 angesehen?! Dort gibt es tolle Methoden wie
|
|
Quellcode |
1 2 3 |
def method(arg) super(arg) end |
Tschuldigung, aber ein weitere Programfluss Adresse und Argumentkopien sehen für mich nicht gerade nach Optimisation aus. RGSS ist mit keinem Optimisator ausgestattet (zumindest nicht, dass ich wüsste) und solche Linien werden direkt ausgeführt und nicht zufälligerweise einfach übersprungen, weil sie ja sowieso bloss die Superklassenmethod rufen. =/
Ich benutze das SDK nicht...
Der Ansatz vom SDK ist ja eigentlich wirklich gut
Genau. Die Ausführung ist bloss mies. >.< Kein normaler Skripter den ich kenne, mag es. Alles was das SDK hingekriegt hat sind noch weitaus grössere Kompatibilitätsprobleme (seit v2.2 sogar mit SDK Skripten -_- ).
Ich weiß gar nicht was hier alle gegen das SDK haben XD Letztlich hilft das SDK vor allem dem BENUTZER. Durch das SDK kann man Scripte einfach in den Scripteditor reinkopieren. Non-SDK Scripte müssen manchmal doch auf spezielle Weise eingefügt werden ("geh in Zeile xyz und kopier dort die Zeile abc rein"). Außerdem ist es eine Sache von wenigen Minuten ein Script SDK-lauffähig zu machen.
Ich hoffe jetzt nicht, dass du meine Scripte meinst :whistling:
lol, außer meinem "eval = evil" Vorurteil hab ich wirklich nix gegen deine Scripte - ganz im Gegenteil ^^
sieht es auch wie 4 normale Windowfenster. Aber denkste da liegt ein großes Window drüber, was den Text zeichnet und 4 kleine Windows die den Rahmen bilden.
rofl. Und das große Window sicherlich mit opacity=0 XD Und wenn sich solche Sachen im Code häufen, muss man sich nicht aufregen, wenn das Spiel später ruckelt oO
Ich persönlich halte allerdings auch nicht viel von diesen selbstzeichnenden Balken (von Seph afair). Die sehen zwar ziemlich cool aus und scheinen auch toll geproggt zu sein (nur warum als Window-Methode -_-?), aber kosten einfach zu viel rechenzeit. Würde man einen vorgezeichneten Balken nehmen, würde man den Rechner extrem entlasten und hätte weniger mit der Performance zu kämpfen =/
Dass all meine Skripten überwiegend mit dem SDK v1.5 funktionierten ohne jeglichen Eingriff lässt den Anfang deines Posts aber ziemlich müde aussehen. >.< Und das mit den 4 Windows: Typisch SDK, lol! Wenn ich opacity = 0 als standard hab, versuch ich einfach Sprites zu benutzen. xD Seph's Balkencode hat eine Komplexität von n^2, darin liegt das Problem. Meiner hat bloss n seit v4.0 (ausser in dieser einen kleine Ecke, wo's net anders geht... >_> ).
Ehrlich gesagt hat mir Minkoff's RTAB weitaus mehr Probleme bereitet. Ach ne, wartet... das ist ja auch SDK... >.<
Sex is not the answer. Sex is the question. Yes is the answer.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Blizzard« (13. Juli 2007, 22:51)
Freitag, 13. Juli 2007, 23:07
Typisch SDK, lol! Wenn ich opacity = 0 als standard hab, versuch ich einfach Sprites zu benutzen. xD
Das hat aber nichts mit SDK zu tun oO
Ich sehe das Problem eher darin, dass gerade die populärsten Scripter wie die von dir genannten oder wie Dubealex einen teilweise recht miesen Scriptingstil drauf haben (Parameter sinnloserweise in Arrays speichern, statt Sprites Windows benutzen). Das typischste Problem an diesen Fix&Fertig-Scripten ist meiner Meinung aber, dass sie völlig statisch sind. Das ist auch der Grund weshalb ich selbst kein SDK benutze. Ich persönlich achte darauf, dass meine Scripte möglichst dynamisch sind. Das ein anderer Scripter also meine Scripte nach Belieben anpassen kann. SDK-Scripte sind darauf ausgelegt, so wie sie sind in das Spiel eingebaut zu werden. Aus diesem Grund ist es da nicht "erforderlich" dynamisch zu arbeiten. Versuch mal das Ringmenü von Dubealex (ist sowieso ziemlich spaßig geschrieben... Parameter werden in einen Array gepackt um Instanzvariablen zu sparen lol) zu erweitern. Du musst praktisch alles umcoden XD Es ist darauf ausgelegt genau so und so viele Elemente zu haben. Will man mehr oder weniger - Pech! Das ist aber nicht die Schuld des SDK, sondern ein prinzipielles Problem in der RGSS-Community. Die meisten haben keinerlei Erfahrungen mit objektorientierten Sprachen und versuchen ihr Makerwissen (oder ihr Wissen aus anderen statischen Sprachen) auf Ruby zu übertragen. Die eleganten Fähigkeiten von Ruby werden da größtenteils missachtet. Beispielsweise meine gehassten For-Schleifen ^^ Warum solche Konstrukte wie for 0..array.size benutzen wenn es den Iterator each_index gibt? (Iteratoren werden sowieso zu meinem Ärger nie genutzt. Meistens wird lieber eine komplexe For-Schleife geschrieben, statt die vorprogrammierten Iteratoren zu nutzen). Oder eval, statt die effizienteren Procs zu benutzen. Auch von Vererbung etc. wird selten Gebrauch gemacht. Die meisten schreiben rein funktional. Und so sind auch viele Tutorials aufgebaut, was wiederum zur Folge hat, dass die neue Rubygeneration diese Fehler der älteren nachmacht.
Das hat also imo nichts mit dem SDK zu tun. Ich weiß ehrlich gesagt auch nicht, was das SDK sonst für Methoden anbietet. Mir gehts allein darum, dass die Standardscripte aufgesplittet werden. Und das ist imo eine ziemlich sinnvolle und nützliche Idee. Ich selbst habe das SDK aber nie benutzt, weil ich keine Fix&Fertig-Skripte schreibe.
Edit: So, ich habe jetzt doch mal einen kurzen Blick ins neue SDK geworfen. Was du mit den einzeiligen Super-Methoden meinst, ist mir unklar. Das endlich eine Superklasse von Scene geschaffen wurde, war mehr als nötig (ich selbst arbeite in meinen Projekten auch immer mit einer Scene-Superklasse). Dass demnach die meisten Methoden der Scene-Klassen nur aus einer Zeile und dem Aufruf super() bestehen ist meines Erachtens auch nicht bedenklich. Im Gegenteil, es ist sogar genau richtig. OOP-Sprachen sollen so aufgebaut sein. Das der Rubyinterpreter jetzt ins Stocken geraten soll, weil die Anzahl der Methoden zugenommen hat, finde ich auch schwachsinnig. Ich werd gerne mal einen Benchmark Test machen, wie viel der Aufruf einer Zwischenmethode an Zeit frisst. Aber eigentlich sind es die Grafikprozesse, die im Maker viel Rechenzeit nehmen. Und solche unsinnigen Sachen wie das Verwenden tausender Sprites, statt des Blocktransfers, das Verwenden unsichtbarer Windows statt Sprites, das Zeichnen komplexer Strukturen, statt fertig gezeichnete Bilder zu laden, sowie das sparsame Verwenden des Cache-Moduls für selbstgeschriebene Grafikprozesse.
Edit²: Wow, die haben sogar endlich ein Vokabular eingerichtet. Ehrlich, ich bin momentan von der neuen SDK-Version positiv beeindruckt.
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »=Kai=« (13. Juli 2007, 23:17)
Samstag, 14. Juli 2007, 12:26
Ehrlich gesagt, ich bin aus der Doku nicht richtig schlau geworden, obwohl ich imho ganz gut Englisch kann.
Das haben die mit Absicht so gemacht
Ich benutze das SDK nicht...
Der Ansatz vom SDK ist ja eigentlich wirklich gut, aber ich konnte mich bis heute noch nicht aufraffen mich mal damit auseinanderzusetzen.
Sprich, ich war bis jetzt einfach zu Faul
Dito, aber wenn ich für ne breite Masse ne Menge Scripte anbieten will, sollte man sich damit mal auseinander setzen.
Wenn du dein Skript schon in der Finalen Fassung hast, könntest du ja eine Non-SDK und eine SDK Version posten. Das ist natürlich nicht so Sinnvoll wenn das Skript noch in der Entwicklung ist ;-)
Soviel Langeweile habe ich dann doch nicht, entweder SDK oder garkein SDK und nicht 2312 Versionen des Scriptes.
Ich weiß gar nicht was hier alle gegen das SDK haben XD Letztlich hilft das SDK vor allem dem BENUTZER. Durch das SDK kann man Scripte einfach in den Scripteditor reinkopieren. Non-SDK Scripte müssen manchmal doch auf spezielle Weise eingefügt werden ("geh in Zeile xyz und kopier dort die Zeile abc rein"). Außerdem ist es eine Sache von wenigen Minuten ein Script SDK-lauffähig zu machen.
Wenn ein ein normaler BENUTZER bist, ist das bloß keine Zeit von Minuten
Ich hoffe jetzt nicht, dass du meine Scripte meinst :whistling:
lol, außer meinem "eval = evil" Vorurteil hab ich wirklich nix gegen deine Scripte - ganz im Gegenteil ^^
Dann erkläre doch mal für ganz doofe, wie dieses Procs funktionieren soll und das Fehlerlogscript nimmt die evalsachen auch schon gut auf
sieht es auch wie 4 normale Windowfenster. Aber denkste da liegt ein großes Window drüber, was den Text zeichnet und 4 kleine Windows die den Rahmen bilden.
rofl. Und das große Window sicherlich mit opacity=0 XD Und wenn sich solche Sachen im Code häufen, muss man sich nicht aufregen, wenn das Spiel später ruckelt oO
Am besten finde ich die Überprüfung ob sich ein Wert geändert hat (Stichwort Arrays.)
Spoiler
|
|
Quellcode |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
class Window_HUD < Window_Base
#...
def update
super
for i in 0...$game_party.actors.size
actor = $game_party.actors[i]
if (eval("@old_hp#{i+1}") != actor.hp or eval("@old_sp#{i+1}") != actor.sp or
eval("@old_exp#{i+1}") != actor.now_exp)
refresh
eval("@old_hp#{i+1} = actor.hp; @old_sp#{i+1} = actor.sp; @old_exp#{i+1} = actor.now_exp")
end
end
end
end |
zum Lesen den Text mit der Maus markieren
Gut gelöst finde ich auch den Fall wenn sich die Werte von allen 4 Helden geändert haben.
Dass all meine Skripten überwiegend mit dem SDK v1.5 funktionierten ohne jeglichen Eingriff lässt den Anfang deines Posts aber ziemlich müde aussehen. >.< Und das mit den 4 Windows: Typisch SDK, lol! Wenn ich opacity = 0 als standard hab, versuch ich einfach Sprites zu benutzen. xD
Wobei das nix mit dem SDk zu tun hat, dem SDK ist es ziemlich egal ob du nun 20 Window mit 0 opacity einbindest oder ob normale Windowse nimmst.
Meiner hat bloss n seit v4.0 (ausser in dieser einen kleine Ecke, wo's net anders geht... >_> ).
Würdest du dann die Güe besitzen, mir mal dein Balken(code) zu zeigen? Danke (verwende ja Sephs auch -> http://www.rmxp.de/bilder/pictures/chesu…u/opt_sound.jpg )
Ehrlich gesagt hat mir Minkoff's RTAB weitaus mehr Probleme bereitet. Ach ne, wartet... das ist ja auch SDK... >.<
Technik die begeistert
Versuch mal das Ringmenü von Dubealex (ist sowieso ziemlich spaßig geschrieben... Parameter werden in einen Array gepackt um Instanzvariablen zu sparen lol) zu erweitern. Du musst praktisch alles umcoden XD Es ist darauf ausgelegt genau so und so viele Elemente zu haben. Will man mehr oder weniger - Pech!
Ich hatte mal ein Ringmenü eines Japaners, das teil war toll. Hat sogar den Radius in Abhängigkeit der Elemente berechnet.
(Nur das Ringmenü ging mir nachher auf dem Keks, weil das so ewig brauchte, deswegen ist es rausgeflogen. Lustig war da bloß, dass da alles über ein Window [opacity=0] lief, wo alle Elemente drauf gemalt wurden.)Das ist aber nicht die Schuld des SDK, sondern ein prinzipielles Problem in der RGSS-Community. Die meisten haben keinerlei Erfahrungen mit objektorientierten Sprachen und versuchen ihr Makerwissen (oder ihr Wissen aus anderen statischen Sprachen) auf Ruby zu übertragen. Die eleganten Fähigkeiten von Ruby werden da größtenteils missachtet. Beispielsweise meine gehassten For-Schleifen ^^ Warum solche Konstrukte wie for 0..array.size benutzen wenn es den Iterator each_index gibt? (Iteratoren werden sowieso zu meinem Ärger nie genutzt. Meistens wird lieber eine komplexe For-Schleife geschrieben, statt die vorprogrammierten Iteratoren zu nutzen). Oder eval, statt die effizienteren Procs zu benutzen. Auch von Vererbung etc. wird selten Gebrauch gemacht. Die meisten schreiben rein funktional. Und so sind auch viele Tutorials aufgebaut, was wiederum zur Folge hat, dass die neue Rubygeneration diese Fehler der älteren nachmacht.
Das hat also imo nichts mit dem SDK zu tun. Ich weiß ehrlich gesagt auch nicht, was das SDK sonst für Methoden anbietet. Mir gehts allein darum, dass die Standardscripte aufgesplittet werden. Und das ist imo eine ziemlich sinnvolle und nützliche Idee. Ich selbst habe das SDK aber nie benutzt, weil ich keine Fix&Fertig-Skripte schreibe.
Man macht es so, wie man es lernt. Kannst ja missionieren gehen. Weil wenn man bestimmte Methoden nicht kennt, kann man sie auch net benutzen.
Edit²: Wow, die haben sogar endlich ein Vokabular eingerichtet. Ehrlich, ich bin momentan von der neuen SDK-Version positiv beeindruckt.
Was für ein Vokabular meinst du?
@allgemein
Wenn ihr ne Diskusion über schlechten Programmierstil aufmachen wollt, nimmmt doch einen eigenen Theard (oder die Todsünden einiges Programmiers)
@fazit
ich denke ich werde versuchen ohne das SDK auszukommen, hier scheint es wohl viele Leute zugeben, die was dagegen haben und die Umfrage spricht ja auch für sich.
Na mal schauen, vielleicht werde ich auch SDK 2.2 Part I benutzen, das scheint ja noch ziemlich kompatibel zu sein.
Gruß Sven
|
YAams |
Random Signatur |
|---|---|
|
|
|
