Das könnte ich so nicht unterstreichen.Zitat von The_Burrito
Man muss bedenken das einen der Maker stark einschränkt.
Es bleibt die Frage ob man mit einer anständigen Programmiersprache und einer bereits vorgefertigten Grafikengine nicht schneller gewesen wäre.
Bzw. ob es nicht schneller geht eine Sprache zu nehmen die auf Hobbyspieleentwickler ausgelegt ist. Wie z.B. BlitzBasic.
--
Kann beiden nur zustimmen.
Technik ist aber auch ein Begriff für Kampfsport(bestimmte Moves oder so) Arten oder andere sachen, muss nicht unbedingt mit Elektronik zusammen hängen. Von daher ist es nicht falsch, dieses Wort zu nutzen. So sehe ich das auf jeden fall. Das Wort Technik ist eigentlich mehr ein Begriff ,dass man etwas auf bestimmte Art und Weise umsetzt.
Leute die aber erst Makern und dann das Proggen lernen, bekommen das schneller hin, als Leute die vorher nicht gemakert haben und direkt Proggen lernen. Da sie mit logischen abläufen besser klar kommen!
Aber wieder zum Thema!
Ich finde Mapping wichtig, egal wie gut auch die Geschichte in einem Spiel ist oder die Grafik, es kommt auch auf das Mapping an.
Oder würde es euch gefallen wenn man für ein Haus ein Wasser Tile nehmen würde, um es mal ganz derbe aus zu drücken.
Die Gegenstände die überall herum liegen, können zum beispiel auch zur Atmo beitragen, wenn in einer Stadt alles Arme Leute Wohnen, aber überall ein Porsche und Goldene Wasserspeier vor stehen, würde wohl nicht wirklich passen oder?
Oder weil man sich eher für das Designen eines Spieles interessiert und nicht für das Programmieren.
@Er Te Pe
Das ist für mich eigentlich genauso unverständlich wie die Sache mit der Technik. UiD hat ein sehr abwechslungsreiches und intelligentes Gameplay (bei kaum einen anderen Makerspiel kann man so viel entdecken und so viel interagieren), es gibt Minispiele wie dieses Schildkrötenrennen oder den Boxkampf und das Standard-KS wurde gehörig aufgebessert. Grandy zeigt ja gerade, dass man auch ohne Monster-Scripte und Effektgewitter ein spielerisch hervorragendes Spiel machen kann.
@makenshi
Also Lightmap würde ich bei Makerspielen niemals in den Mund nehmen. Nur weil viele Unsinn reden, muss man das selber ja noch lange nicht. Bei deinem Beispiel mit dem laggenden KS würde ich denken: "Der kann nicht scripten". Obwohl solche lahmen Kampfsystem gar nicht mal nur durch schlechten Code entstehen, sondern auch weil die Leute nicht wissen, wie man Kämpfe rasant inszeniert. Wenn man wie bei Aldaran zu viele Animationsframes benutzt, dann ist es kein Wunder, dass manche Leute beim Kämpfen an Altersschwäche sterben. Der Begriff Technik ist hier jedenfalls irreführend, weil nicht klar ist, ob das Gameplay-Design oder die handwerklichen Fähigkeiten beim Scripten gemeint sind.
Kann ich mir nicht vorstellen. Alleine schon weil man beim Maker (zumindest bei den alten) nur Design-Bugs und keine Programmier-Bugs einbauen kann.
Ich habe nie behauptet, dass das meine Meinung ist, sondern habe einfach mal dein Beispiel aufgegriffen.
@ Fansoftware:
Das was du als schlechtes Mapping bezeichnest, empfinde ich eher als Fehlen von logischem Verständnis.
Dass ich das Armenviertel meines Spieles mit abgehalfterten Hütten anstatt mit Palästen vollstelle, ist klar, aber das bedeutet doch noch lange nicht, dass diese Hütten gut gemappt sind.
Kommt meiner Meinung nach auf den Anwender an.
@Kelven
Also ich denke der Begriff "Technik" ist nicht mit dem Gameplay zu verbinden. Technik deutet im Makerbereich immer auf die Skripttätigkeit hin.
Das ist als eigentlich eher klar definiert als irreführend.
Und das man beim Maker nur Designbugs hat, ist ebenfalls nicht als Allgemeinaussage zulässig. Ab dem Zeitpunkt ab dem du praktisch jedes makereigene System durch ein eigenes ersetzt, weil es deinen Anforderungen nicht entspricht, hast du ein durchaus immer komplexer werdendes System was genau die gleichen "Krankheiten" wie ein rein programmiertes System bekommen kann. Das simpelste Beispiel wären Pointerfehler die durch dynamisch generierte Daten entstehen. Genau den gleichen Spaß kannst du auch in einer C++ Anwendung haben. Nur rechnest du da halt mit Speicheradressen anstand der Nummeriung des Variablen im Maker. Was im Prinzip aber dasselbe ist.
Nebenbei sei noch zu fragen warum du so krampfhaft daran festhälst das ein Begriff nur einen gültige Bedeutung haben darf. Warum darf sich das nicht durch den Context ergeben? Solange es sinnig zu der neuen Bedeutung passt, ist es doch in Ordnung?
--
Geändert von makenshi (02.09.2008 um 15:55 Uhr)
@makenshi
Ich hab aber schon öfters gelesen, dass der Begriff auch für das Gameplay allgemein benutzt wurde (bzw. die Leute nicht wissen wovon sie reden) und sicherlich bewertet niemand den Code eines Spieles, sondern nur dessen Auswirkungen. Es kann aber durchaus sein, dass jemand schrecklich gescripted hat, das Spiel aber trotzdem vernünftig läuft.
Die Bugs, die im Maker entstehen können, entdeckt man aber einfacher und schneller als bei höheren Programmiersprachen. Natürlich ist es etwas anderes ein Autostart-Event nicht abzuschalten, als in irgendeinem CBS eine Variable zu vertauschen, trotzdem ist der Arbeitsaufwand diese Fehler zu entdecken mMn viel geringer als bei einem von Grund auf selber programmierten System. Der Maker ist da halt doch deterministischer.
Warum ich was gegen "Technik" habe? Ach, mich nervt nur der Maker-Elitarismus. xD Hier wird eine Selbstverständlichkeit - nämlich vernünftig laufender Code - zu mehr gemacht als es ist, was, wie ich oben ja am Beispiel von UiD verdeutlicht habe, zu sehr seltsamen Aussagen führt. Technik ist nichts was das eine Spiel besitzt und das andere nicht; es gibt nur "Spiel läuft gut" oder "Spiel läuft nicht gut" (das Mittelfeld hab ich jetzt mal absichtlich ignoriert). Außerdem geht's ja nicht nur darum, dass ein KS gut läuft, es muss sich auch gut spielen lassen.
Wahrscheinlich weil du selbst so gut wie keine Erfahrung mit Programmierung hast (?).
In der Regel, wenn man sich mit dem gewählten Werkzeug auskennt, behaupte ich, dass keine Programmier-Bugs (z.B. Syntaxfehler) entstehen können, gerade dann, wenn eine simple Skriptsprache implementiert ist, denn in dem Fall unterscheiden sich die Klick-Skriptsprache des Makers und eine echte Skriptsprache in ihrer Einfachheit kaum, in ihrer Flexibilität und ihren Möglichkeiten aber enorm.
Wir können ja mal einen Versuch machen: Makerhalbgott Lachsen mit dem Maker und jahrelanger Erfahrung damit und ich (der bisher nichtmal etwas auf dem Maker zusammengebracht hat) mit einer Engine meiner Wahl. Wer wird wohl schneller zu einer besseren "Technik" kommen?
Gibt es überhaupt "Technik", die keinen Einfluss auf das Gameplay hat? Ich meine, man skriptet doch erst aus dem Grund um besseres Gameplay zu bieten.
Du unterschlägst dabei aber die Zeit, die diese Leute zum Erlernen des Makers brauchen.
Wenn jemand die logischen Vorgänge im Maker nachvollziehen kann, behaupte ich kann er das auch in einer echten Programmiersprache in der selben Zeit, ohne davor mit dem Maker irgendwas zu tun gehabt zu haben.
Ich empfehle jedem, der vor hat, eine echte Programmiersprache zu erlernen, nicht die Zeit mit dem Maker zu verschwenden.
Geändert von Kyuu (02.09.2008 um 16:32 Uhr)
Nun ja, eigentlich habe ich das Makern aufgegeben, zu Wort melde ich mich hier aber trotzdem mal.
Gutes Mapping muss in meinen Augen der Kompromiss zischen Eyecandy und Spielbarkeit sein. Ich hasse es, wenn Ersteller die Maps so voll stopfen, dass man sich nicht mehr ordentlich bewegen kann und dann ist das spiel recht schnell im Papierkorb. Aber im Gegenzug sollte die Map auch nicht mehr so leer sein, dass es unrealistisch wirkt (wenn man denn beim Maker von Realität sprdchen kann, aber ich denke ihr wisst was ich meine.)
Was isch allerdings krankhaft finde, ist es, wenn solche Kritiken wie "Die Bäume, Büsche, Steine ( whatever) sind auf der selben Höhe". Wir sprechen hier von einem Tool mit Raster, da ist das okay.
Genauso finde ich es dumm wenn etwas von "Zu wenig Bodentexturen" geredet wird. Wenn da eine wiese ist, dann ist da eine wiese und dann ist es doch egal, ob ich dafür einen oder fünf verschiedene Graßtextren verwende.
Soviel zu meiner Meinung.
@Kelven
Also das das Spiel noch anständig läuft wenn jemand schreckliche Skripte schreibt wage ich zu bezweifeln. ^^"
Und auch bei der Aussage das man Bugs im Maker "schneller" findet ist etwas wo ich dir leider wiedersprechen muss. Ja nochmals. Auch hier kommt es wieder auf den Ausmaß an. Wenn wir mal wieder von dem KS Beispiel ausgehen, dann kann man das mit dem schnellen finden vergessen. Wenn du wirklich ein umfangreiches KS hast wo wirklich große Skripte am werkeln sind, dann ist es nicht so einfach "mal eben" den Fehler zu finden. Wobei man auch hier wieder unterscheiden muss wie groß der Fehler ist. Klar gibt es diese Fehler wo man lediglich was vergessen oder vertauscht hat. Nur wenn da mehre Module miteinander arbeiten und du die Auswirkung von einem auf das andere so nicht erahnen konntest, dann wirst du einen Spaß haben "mal eben" den Fehler zu finden.
Bei einer Programmiersprache hast du in meinsten Fällen meist noch so etwas wie einen Debugger der dir die Arbeit erheblich vereinfachen kann. Das kannst du beim Maker vergessen. Mehr als die lustige Konsole hast du nicht. Da ist "Debugging" mit "Messagebreakpoints" angesagt. x)
Auch denke ich nicht das vernünftig laufender Code eine Selbstverständlichkeit ist. Es ist eine Arbeit genau so wie das mappen oder das pixeln an sich. Es erfordert je nach Größe der Arbeit genau wie bei den angeführten Bereichen recht viel Zeit. Da kann man der ganze Sache durchaus einen eigenen Überbegriff geben denke ich. Das muss dann nicht unbedingt sofort was mit Elitarismus zutun haben.
Recht hast du. Ich habe mich da undeutlich ausgedrückt. Es geht mir eher darum zu sagen das Technik in dem Fall wirklich "nur" auf die Skriptarbeit referenzieren soll. Nicht auf den Bereich des Gameplays der für mich völlig andere Dinge bezeichnet als halt die Arbeit um ein Skript zu schreiben.
--
@Kyuu
Jaein, mir fehlt die ganze Routine, aber im Prinzip kann ich schon programmieren (um Programmiersprachen kommt man bei einem Informatikstudium nicht herum), nur eben nicht wirklich gut, weil mein Interesse daran eher gering ist und ich alles so schnell wieder vergesse.Mag sein, dass man mit der nötigen Routine viele Fehler nicht mehr macht. Ich kenne beim Makern eigentlich nur Flüchtigkeitsfehler (vor lauter Copy&Paste vergisst man mal eine Variable zu ändern) oder dass ein Konzept sich im Nachhinein als schlecht erweist.
@makenshi
Solche Fehler mache ich gar nicht, kein Wunder, dass wir aneinander vorbeireden. *höhöhö*
Ich meinte, dass es selbstverständlich ist, dass das Spiel vernünftig läuft. Wenn jemand ein verbuggtes Spiel veröffentlicht, muss derjenige sich nicht wundern, dass er mit harter Kritik überhäuft wird. Also liegt es nahe, dass jeder versucht ein lauffähiges Spiel zu entwickeln (in der Theorie, ich weiß). Außerdem gibt es doch genug passendere Begriffe wie Scripter oder Gameplay-Implementierer, falls es ganz gehoben klingen soll. Ich bin jedenfalls immer noch der Meinung, dass um diese "Makerdisziplinen" einfach zu viel Wind gemacht wird. Das ist alles nichts besonders, sicherlich etwas das man würdigen sollte, aber nicht feiern.
Ich möchte nochmal auf diese tolle Bemerkung aufmerksam machen. Das wäre tatsächlich eine tolle Idee imo, nur bin ich nicht der Contest-Organisier-Mensch.
@Topic2: Wenn man makert, programmiert man nicht. Man skriptet - und das auch über Umwege. Aber es können beim Skripten immer Fehler entstehen, und zwar - relativ betrachtet - genauso leicht wie bei einer "echten" Skriptsprache. Sind bei einer solchen Funktionen wie file.open vorgefertigt, ist es hier die RPG Engine. Der einzige gravierende Unterschied ist die Eingabe. Beim Maker skriptet man mittels Dialogfeldern, wodurch keine Syntax-Fehler entstehen können, und - aufgrund der fehlenden Komplexität (keine Evaluierung von komplexen Ausdrücken mit Klammern, etc.) und der leichten Erkennbarkeit der Befehle auch andere Fehler vermieden werden, die im Skript-Alltag öfters passieren. Das liegt aber nicht am RPG Maker-System selbst, sondern an der Eingabemethode. Für mich ist makern mit skripten durchaus zu vergleichen.
@Topic1: Wieso sollte Mappen Zeitverschwendung sein? Ein Spiel mit schlechten Maps macht keinen Spaß. Mir zumindest.
--
Mir war nichtmal bewusst dass ich nominiert wurde, aber: Cool! Hälfte des Lobes muss aber unbedingt an Archeia!Now all new and shiny:CherryShare | Patches und Tools | Programmwunschthread | www.cherrytree.at | Cherry = CherryDT
Geändert von Cherry (02.09.2008 um 17:59 Uhr)
Beim Ersteren gebe ich dir vollkommen recht. Ich habe selbst vor meiner Makerzeit schon programmiert.
Beim Letzteren kann ich dir aber nicht ganz zustimmen. Wieso sollte es Zeitverschwendung sein mit dem Maker zu skripten, wenn man noch eine richtige Programmiersprache lernen möchte? Makern ist doch letzlich nur Fun, weiter nichts, zumindest für mich. Sicher kann man mit C++ und anderen Sprachen wesentlich mehr erzielen und weitaus schönere "Dinge" anstellen, dafür ist der Maker aber auch nicht gedacht. Sonst hätten die Entwickler deutlich umfangreichere Funktionen eingebaut, dann wäre er aber für viele mit Wahrscheinlichkeit nicht mehr so verständlich (was er aber teils trotz relativ leichtem Click- Skript- System für viele nicht ist, imo).
Nein, ich meinte dass es Zeitverschwendung ist, wenn jemand nur aus dem Grund den Maker benutzt um es später bei einer echten Programmiersprache leichter zu haben bzw. ihre Logik schneller aufzufassen (siehe Aussage von Fansoftware).
Mir hat die Makererfahrung auch beim Einstieg in die Programmierung einiges erleichtert. Allerdings muss ich Kyuu recht geben, denn die grundlegegenden Sachen hat
man auch ohne Maker bald verstanden.
Und ja, debugging im Maker ist imo viel unschöner als bei Programmiersprachen(einen ordentlichen Debugger vorausgesetzt).
@Topic:
Wie schon erwähnt, der eine macht lieber schöne Maps der andere
haut lieber ein paar Gameplay Features rein, wobei ich letzteres schon für
wichtiger erachte. MMn sollten Maps ihren Zweck erfüllen und damit meine
ich nicht nur das Ermöglichen des Durchlaufens sondern auch ein Gefühl
geben wo sich der Spieler gerade befindet usw.
Die meisten Aussagen zum Fehler finden sind sehr stark davon abhängig wie jemand programmiert. Gerade wenn man etwas Ahnung hat und C++ nicht als Aufsatz zu C betrachtet, kann man doch sehr gut wartbaren Code schreiben, in dem man oftmals recht leicht fehler findet. Genauso auch in anderen Sprachen. Dazu kommen viele Hilfsmittel wie das Anzeigen von Fehlern während man Code schreibt, der Debugger, Unit-Tests und co.
Da kann der Maker nicht gerade mithalten. Auch schreibt man Script oft sehr umständlich. Also Dinge die in einer Programmiersprache oft in einer Zeile erledigt werden, benötigen mit dem Bastelsystem gerne mal 20-30 und mehr.
Ob man schneller zum Ziel kommt mit dem Maker ist auch relativ. Es kommt immer darauf an was man entwickeln will. Gerade bei so Sachen wie Wegfindung hat der Maker doch starke Probleme. Auch in Sachen Performance ist er nicht unbedingt eine Glanzleistung.
Auch gibt es für viele Sprachen schon einiges an vorgefertigten Sachen. Somit kann man sich oft einfach nur die interessanten Libs zusammen suchen und zusammen setzen und man hat schon fast ein (kleines) Spiel.(Mapsystem,GUI-System,Wegfindung,Physik,...)
Auch gibt es schon einige Spiele auf die man aufbauen kann und somit hat man die Freiheit und man kommt schnell voran.(Also alles ist relativ)
Das ist ja genau das, was ich meine. Du tust dir vll mit C++ oder Java leichter, Lachsen jedoch mit dem Maker. Deshalb kann man das nicht pauschalisieren und behaupten: "Ordentliche Grafikengine und eine nette Programmiersprache schlagen den RM"
Aber wir weichen hier einfach zu weit vom Thema ab^^
@ Cherry:
Wenn ich als Forums-Neuling zu dem Contest aufrufen würde, wären die Teilnehmer wohl eher rar. Aber vll will ja jemand anders den Denkanstoss aufnehmen^^
Natürlich schränkt einen der RPG Maker (je nach Version mehr oder weniger) ein. Wenn du dein Spiel an der Dragon Quest Reihe(Rm2k) oder Final Fantasy Reihe(Rm2k3) orientierst, wirst du (derzeit) sicherlich kein Framework oder Tool finden, welches dich schneller ans Ziel bringt. Der Preis dafür ist halt, das je weiter du dich von diesem Vorbild entfernst, desto aufwendiger und mühsamer wird es das ganze mit den genannten Tools umzusetzen.
Ich bin ziemlich sicher, dass für die meisten 2D japano Style RPGs kein Framework oder Tool gibt, welches dich schneller zu spielbaren Resultaten führen wird, als die RPG Maker Reihe. Du darfst nicht vergessen, dass das Kampfsystem und das Menü nicht zwingend der größte Aufwand bei diesen Spielen ist.
Die meisten (mir bekannten) Frameworks zur Spielentwicklung verstehen von Haus aus einmal nur Bitmaps und relativ "dumme" Sprites, sowie Sounds. Dies sind einfach die Grundlegenden Elemente die allen Spielen gleich sind, und dementsprechend kann man nur sehr über sie hinaus gehen, ohne das Framework gleich in eine bestimmte Richtung zu spezialisieren.
Dies beinhaltet noch keinerlei Dinge wie Tilesets, Maps, Battle Animations, etc. Das sind dann die ersten Dinge die man implementiert, wenn man mit so einem Framework startet. Alles Dinge die man beim RPG Maker bereits fertig vorhanden sind, nachdem ich auf "New Project" geklickt habe. Nachdem man dann mal erste Spielszenen wie "Titlescreen" oder "Map" implementiert hat, fällt einem auf, dass das Framework noch absolut Null Plan von so Dingen wie "Gegenständen", "Waffen", "Monstern", "Helden", etc hat. Das heißt nun geht es daran, das in das Spiel einzubauen, was uns beim RPG Maker allgemein als "Database" bekannt ist. Am besten auch gleich mitsamt einem Editor für das ganze, denn alles händisch in Textdateien zu schreiben ist auf dauer äußerst mühsam...
Irgendwann bist du dann soweit und bist dort angelangt, und kannst dann vermutlich relativ reibungslos das einbauen was vielen Benutzern der RPG Maker Reihe schlaflose Nächte und einiges an Kopferzerbrechen bereitet. Ein eigenes Kampfsystem und ein eigenes Menü.
Für mich persönlich würde es einfach zu lange dauern, bis ich überhaupt anfangen kann erste Spielabschnitte/Spielszenen entwerfen könnte, sprich bis ich etwas wirklich Spielbares vor mir habe, um so weit von vorne mit einem Projekt zu beginnen.
--
Aus eben diesem Grunde schrieb ich, dass Makern ja nur Fun ist. Vorm eigentlichen Proggen den Maker am besten auswendig kennen zu wollen ist de facto recht unsinnig. Die Syntax ist im Gegensatz zu den Programmiersprachen teils recht aufwendig. Man täte schon besser daran wirklich zu programmieren, anstatt den Maker als "Vorabhilfe" zu nutzen, da kann ich dir aus der Sichtweise nur recht geben.
Ja, du weichst ziemlich von dem ab, was du gequotet hast. :P
In dem von dir gequoteten Satz von makenshi ging es darum, dass man mit einer Programmiersprache und einer Grafikengine, was die Technik angeht, schneller ist, als mit dem RPG Maker.
Du sagst nun, dass es auf den Anwender ankommt. Ich sage, dass es eben nicht auf den Anwender ankommt (wir gehen davon aus, dass der Engine-Nutzer weiß, was er tut) und selbst Lachsen, mit seiner jahrelangen Erfahrung könnte nicht das selbe und in der selben Zeit mit dem RPG Maker 2k/3 erreichen, was jemand mit weitaus weniger Erfahrung mit einer Programmiersprache und einer Grafikengine erreichen könnte. Wir reden immernoch von der Technik, da der Maker in anderen Bereichen wie Mapping und vorgefertigten Strukturen sehr hoch punktet.
Wenn wir allerdings von Extremen ausgehen, wie z.B. wenn der Engine-Nutzer ein blutiger Anfänger ist und nicht weiß, womit er anfangen soll, dann gebe ich dir Recht, in dem Fall könnte Lachsen durchaus zu besseren Ergebnissen in kürzerer Zeit kommen.
------------------------------------------------------------------------------
BTW: Ich weiß ehrlich gesagt gar nicht, wieso immer wieder von C++ die Rede ist. Es gibt weitaus benutzerfreundlichere High-Level-Sprachen wie Python, die in Verbindung mit Spielbibliotheken wie beispielsweise PyGame schon fast mit einem RPG Maker XP gleichzusetzen sind (wenn man die vorgefertigten Skripte weglässt).
Geändert von Kyuu (02.09.2008 um 21:09 Uhr)
Je mehr Freiraum einem die Game Engine gibt, desto mehr ist man dazu verleitet seinen Ideen und seinen Perfektionismus freien Lauf zu lassen, desto mehr Zeit verbringt man mit dem Grundgerüst (bzw. der Technik) des Spiels, desto höher die Wahrscheinlichkeit, dass man übertreibt und das Projekt deshalb nicht fertig wird.
Darüber hinaus hab ich persönlich die Erfahrung gemacht, dass eine schöne, objekt-orientierte Programmiersprache einen dazu verleitet sehr viel Gehirnschmalz in ein tolles Design zu stecken - d.h. man hat eine ganze neue Ecke, in die man viel Zeit investieren kann. Das schlimme daran ist, dass es eine Ecke ist, die auf das Spiel selber aus der Sicht des Spielers eigentlich keinen Einfluss hat.
Das sind genau die beiden Argumente die gegen eine tolle flexible Engine mit einer anständigen Programmier/Skriptsprache sprechen, aus meiner Sicht.
Meiner Ansicht nach ist nämlich Flexibilität für diese Community eine zweischneidige Klinge
Ich habe sehr viel mit dem RPG-Maker gearbeitet, aber auch viel programmiert und andere Game Engines wie Sphere ausprobiert.
Es ist klar, dass viele Sachen mit dem RPG-Maker sehr, sehr umständlich sind. Aber genau das ist oft ein Argument, wieso man es einfach sein lässt. D.h. man muss Grenzen setzen.
Darüber hinaus kann man mit dem RPG-Maker nur sehr schwer wirklich guten Code produzieren (meistens ist es unmöglich), also coded man einfach schnell etwas dahin. Ja, dadurch hat man ein schlechtes Design, alles wird chaotisch, aber ich persönlich bin damit immer recht weit gekommen (siehe TA und Velsarbor). Wenn ich in Vergleich dazu mit Sphere gearbeitet habe, habe ich sehr viel Zeit darin investiert einfach den Code optimal zu strukturieren, die richtigen Design Patterns zu finden etc. etc. Dummerweise bin ich bisher nie darüber hinaus gekommen - aber das liegt hauptsächlich an den Zeitmangel, den ich im Moment habe...
Aber genau das ist der Grund, wieso man mit richtigen Programmiersprachen oft nicht so schnell tolle Ergebnisse bekommt, wie man denken würde - finde ich. Man hält sich mit dem Design auf.
Gut, das kann jetzt einfach daran liegen, das ich schlecht darin bin, mit gutem Design zu programmieren oder sonst was. Ich kenne jedenfalls mindestens ein Projekt, das mehr oder weniger nur wegen der Suche nach dem perfektem Design seit mehreren Jahren auf Eis liegt.
(Anmerkung: In diesem Text meine ich mit Design jetzt die Umsetzung der Technik)
Blah Blah Blah.
Mein Schlusswort dazu:
Was wirklich vielen in der Community, inklusive mir, einfach fehlt, ist die Fähigkeit, Grenzen zu setzen. Und genau deshalb ist es ganz gut, dass die RPG Maker so ihre Grenzen mit sich bringen.
Aber mal zum Thema:
Ja - gutes Mapping ist DEFINITIV überbewertet!
C ya
Lachsen
PS: Haltet mich mal aus diesen ganzen Vergleichen hier raus XO
Gibt auch genug andere gute Techniker in dieser Community. Nehmt doch makenshi oder sowas.
Geändert von Lachsen (02.09.2008 um 21:20 Uhr)
Berechtigungen
Zitieren
