Gutes Mapping = reine Zeitverschwendung

[Inius]

Oder aber weil es der schnellste Weg ist zu einem spielbaren Ergebnis zu kommen.

...

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?

[Kelven]

Oder aber weil es der schnellste Weg ist zu einem spielbaren Ergebnis zu kommen.

...

Oder weil man sich eher für das Designen eines Spieles interessiert und nicht für das Programmieren.

@Er Te Pe

"UiD hat keine spielmechanischen Beeinflussungskonzepte."

...

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.

Es bleibt die Frage ob man mit einer anständigen Programmiersprache und einer bereits vorgefertigten Grafikengine nicht schneller gewesen wäre.

...

Kann ich mir nicht vorstellen. Alleine schon weil man beim Maker (zumindest bei den alten) nur Design-Bugs und keine Programmier-Bugs einbauen kann.

[Kyuu]

Kann ich mir nicht vorstellen. Alleine schon weil man beim Maker (zumindest bei den alten) nur Design-Bugs und keine Programmier-Bugs einbauen kann.

...

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.

Kommt meiner Meinung nach auf den Anwender an.

...

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?

@Kelven
Also ich denke der Begriff "Technik" ist nicht mit dem Gameplay zu verbinden. Technik deutet im Makerbereich immer auf die Skripttätigkeit hin.

...

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.

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!

...

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.

[Satyras]

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.

[Er Te Pe]

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?

...

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^^

[Kyuu]

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^^

...

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

[Er Te Pe]

@ Kyuu:
Das ist ja das, was ich meinte.
Lachsen kommt vll mit deiner Programmiersprache nicht zurecht, und du nicht mit dem RPG-Maker. Deshalb ist es sehr wohl nutzerbedingt, wie schnell man voranschreitet.

Und ich habe mich persönlich noch nicht mit Spieleprogrammiersprachen auseinandergesetzt, aber die paar Programmiersprachen die ich beherrsche, sind alle C-basierend, weshalb ich C (oder C++) meistens als Beispiel verwende.

Außerdem kannst du den RM sowieso nicht mit Programmiersprachen gleichsetzen, da die Bandbreite an Befehlen mit einer Sprache einfach größer ist, weshalb du natürlich mehr technische (Sry, Kelven^^) Optionen hast.

Und um noch mal meine two Cents aufs Topic zu werfen:
Mir kommt es langsam so vor, als ob Vertreter der Mappingverschnörkselung von der konservativen "Weniger ist mehr"-Front weggejagt werden.
Das eigentliche Problem ist doch eher, dass jetzt von jedem Billiggame erwartet wird, dass die Umgebung Schatten wirft (Die Charaktere natürlich nicht, das wäre zu aufwendig und wird deswegen nicht gemacht ), die Wasserfälle plätschern und der Hero sich in allem spiegelt, was glänzt.
Das führt in die völlig falsche Richtung, früher galten Lichteffekte und Mappinghöhepunkte wie eigene Grafiken, Wettereffekte und weiterer Blödsinn als Innovation.
Darum mein Appell:
Back to the roots, weniger ist mehr!

[Kyuu]

@ Kyuu:
Das ist ja das, was ich meinte.
Lachsen kommt vll mit deiner Programmiersprache nicht zurecht, und du nicht mit dem RPG-Maker. Deshalb ist es sehr wohl nutzerbedingt, wie schnell man voranschreitet.

Und ich habe mich persönlich noch nicht mit Spieleprogrammiersprachen auseinandergesetzt, aber die paar Programmiersprachen die ich beherrsche, sind alle C-basierend, weshalb ich C (oder C++) meistens als Beispiel verwende.

Außerdem kannst du den RM sowieso nicht mit Programmiersprachen gleichsetzen, da die Bandbreite an Befehlen mit einer Sprache einfach größer ist, weshalb du natürlich mehr technische (Sry, Kelven^^) Optionen hast.

...

Entschuldige, aber du scheinst teilweise nicht wirklich Ahnung davon zu haben, was du hier schreibst. Ich verkneife es mir mal detailliert darauf einzugehen.

@Lachsen:

Das was du ansprichst kommt denke ich eher davon, dass du von den neuen Möglichkeiten einfach überwältigt warst, so dass du alles ausprobieren und implementieren wolltest, als dass du ein schlechter Programmierer bist, oder sonst was. Mir erging es vor einem Jahr auch nicht anders. Ich konnte nichts Vernünftiges anfangen, weil ich immer neue Dinge kennenlernte und immer am Verbessern des bestehenden Codes war.
Diese Euphorie legt sich aber mit der Zeit, spätestens wenn man an die Grenzen der neuen Entwicklungsumgebung kommt (die gibt es immer, egal wie flexibel die Anwendung ist) und man beginnt mit Überblick und Struktur vorzugehen. Beim RPG Maker war es doch auch nicht anders, wenn du mal zurückblickst. Es dauert erst eine Zeit lang, bis man die Umgebung und ihre Grenzen kennengelernt hat und erst dann kann man mit Priorität vorgehen.

Eine andere Sache, die du nicht angesprochen hast, die aber ähnlich ist, wäre Mikrooptimierung, mit der jeder anfänglich zu kämpfen hat, weil jede kleine Optimierung des Codes berechtigt scheint (besonders bei interpretierten Sprachen, die bekanntlich sehr langsam sind), im Endeffekt aber so gering ist, dass eine Veränderung nicht bemerkbar ist (vor allem dann, wenn die Optimierung nicht im kritischen Teil der Anwendung durchgeführt wird) und frisst wertvolle Zeit. Naja, aber auch das legt sich mit der Routine.

Aber davon mal abgesehen, würde ich dir Sphere sowieso nicht mehr empfehlen können. :)

[Kelven]

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.

...

Ich denke auch, dass das einer der Hauptgründe für's Canceln ist und die Problematik lässt sich wunderbar auf das Mapping übertragen. Am Anfang gehen die Mappingwunder locker von der Hand, aber je länger das Spiel wird, desto mehr realisiert man, dass man diesen Stil nicht das ganze Spiel über durchhalten kann oder man damit rechnen muss erst fertig zu werden, wenn schon die Enkel an die Tür klopfen. Deswegen besitzen so gut wie alle Vollversionen kein screenthread-reifes Mapping. Diese Leute konnten Grenzen setzen.

[Er Te Pe]

Entschuldige, aber du scheinst teilweise nicht wirklich Ahnung davon zu haben, was du hier schreibst.

...

Und ich habe mich persönlich noch nicht mit Spieleprogrammiersprachen auseinandergesetzt

...

Sry, dass ich einfach bisher keinen Bock hatte, mich mit Spieleerstellung zu beschäftigen (Den RM ausgenommen), aber ich habe doch ein bisschen Ahnung von Programmierung. Will hier aber gar nicht auf ein "Wer hat den Längeren?" eingehen.

Wie gesagt ist das nur meine Ansicht der Dinge. Oo Ich find Technik am Maker sinnlos und leg stattdessen doch mehr Wert auf Story, Mapping und Grafik... denn davon lebt ein Makergame, in meinen Augen zumindest, in Wirklichkeit.

...

Dass Technik sinnlos ist, würde ich nicht sagen. Wenn jemand originelle Ideen ins Spiel einbringt, und dafür ordentlich scripten muss, stört es doch nicht.
Aber gegen die Verwendung des Standard-KS oder -Menü wird sich sicher nicht negativ auf Games auswirken. Ganz im Gegenteil: Lieber das vom Maker gegebene, als ein total mieses (und dafür selbstgemachtes) KS oder Menü.

Die Kunst dabei ist die Prioritätensetzung, die Kelven und Lachsen ansprechen. Das Mapping sollte nicht perfekt sein, da es so schwer wird, diese Qualität ein ganzes Spiel über zu halten, aber sich auch sehen lassen können. Aber genau das muss man auch auf das Gameplay und die Story anwenden, ein Übermaß an Features oder eine zu komplexe Story können, genauso wie ein Mangel an technischer Innovation oder eine seichte Geschichte, zu Spasskillern werden.

[Fenrir]

Wenn Story, Techik, Mapping sowie alles andere sich ausgleichen, ist das Spiel gelungen und führt zu einem Ergebnis. Spielspaß.

Da kann jetzt auch das Mapping aussehen wie es will. Aber wenn es zum Spiel passt oder durch andere Dinge ausgeglichen wird und der Spieler aus lauter Spaß so abgelenkt wird, dass er die Grafik schon nicht mehr beachtet, ist es doch gut.

Allerdings sollte man schon Wert auf schöne Optik legen, wenn auch nicht viel.

[lucien3]

Dass super Mapping nötig ist, um Spielspass zu erzeugen, stimmt nicht, dafür gibt es viele Beispiele.
Allerdings: Nehmen wir mal ein Spiel X als Beispiel. Wir bringen das Spiel in zwei Versionen raus. Diese unterscheiden sich nur im Mapping, sind sonst aber identisch.
Hier denke ich ist klar, dass die Version mit besserem Mapping eindeutig die bessere ist.
Von da her lohnt sich Mapping. Gutes Mapping macht kein Spiel automatisch gut, aber wenn man den Faktor berücksichtigt wird das Spiel sicher besser als wenn man es nicht tut.

[Kelven]

Allerdings sollte man schon Wert auf schöne Optik legen, wenn auch nicht viel.

...

Nur was ist schöne Optik auf dem Maker? Eigentlich ist das ja nicht mit gutem Mapping gleichzusetzen und selbst bei dem haben wir noch nicht wirklich geklärt, was es ist. Heißt schöne Optik "Hauptsache Lichteffekt drauf", "Ein Stil den keiner kennt" oder "möglichst voll"?

@lucien3
Meistens muss man seine Arbeit aber aufteilen. Wenn man zu viel in das eine investiert, kommt das andere zu kurz und genau das hat Mario Ana ursprünglich angesprochen. Man muss ja fast sagen, dass je mehr Arbeit die Leute in die Grafik stecken, desto unwahrscheinlicher eine Veröffentlichung des Spieles ist. Hier in Deutschland kenne ich wie gesagt nur ein Spiel, das trotz herausragender Grafik fertig geworden ist (und dort zeigen sich die angesprochenen Mängel in den anderen Bereichen).

[Fenrir]

Heißt schöne Optik "Hauptsache Lichteffekt drauf", "Ein Stil den keiner kennt" oder "möglichst voll"?

...

Die Optik setzt sich aus verschiedenen Teilen zusammen, um im Endeffekt ein anblickvolles Bild zu schaffen. Hierbei kann es nun das Mapping oder irgendwelche Effekte sein, die aber auch als Faktoren eine Rolle spielen können, die nur was zum Gesamtbild beitragen. Auch Tiere oder Sounds ergänzen die Atmosphäre um ein vielfaches. Beim Spielen taucht so ein inneres Wohlgefühl auf, welches den Spaßfaktor um ein hohes Maß steigern kann. Vorausgesetzt, die Kombination und die Balance stimmt, wobei man nicht immer haargenau darauf achten muss (da es eine Gefühlssache und kein Zwang ist bzw. sein sollte).^^

Letztendlich würde ich sagen, ist da die eigene Fantasie des Entwicklers gefragt.

[Kyuu]

Sry, dass ich einfach bisher keinen Bock hatte, mich mit Spieleerstellung zu beschäftigen (Den RM ausgenommen), aber ich habe doch ein bisschen Ahnung von Programmierung. Will hier aber gar nicht auf ein "Wer hat den Längeren?" eingehen.

...

Es war nie die Rede von "Spieleprogrammiersprachen". Was soll das überhaupt sein, Blitz Basic?
Es war nie die Rede von einem Vergleich des RPG Makers mit einer Programmiersprache.
Habe auch nie behauptet, dass du grundsätzlich keine Ahnung von Programmierung hast, lediglich festgestellt, dass du keine Erfahrung mit Entwicklungstools außerhalb des RPG Makers hast und dir damit die Basis für die vorherige Diskussion gefehlt hat. (Die Sache mit C++ war übrigens nichtmal generell an dich gerichtet, war doch extra eine Trennlinie dazwischen.)

PS: Versuch bitte das nächste mal einem nicht die Worte im Mund umzudrehen und keine herablassenden Smilies zu benutzen, das ist eher kontraproduktiv für jede Diskussion. ;/

Meistens muss man seine Arbeit aber aufteilen. Wenn man zu viel in das eine investiert, kommt das andere zu kurz und genau das hat Mario Ana ursprünglich angesprochen. Man muss ja fast sagen, dass je mehr Arbeit die Leute in die Grafik stecken, desto unwahrscheinlicher eine Veröffentlichung des Spieles ist.

...

So sehe ich das auch.

Wenn man in einem Team arbeitet und das Team dabei für jeden Bereich eines Spieles mindestens einen Entwickler einteilt, können diese ihre gesamte Zeit natürlich dem jeweiligen Bereich widmen und sich darauf verlassen, dass die anderen Bereiche nicht vernachlässigt bleiben. So funktioniert es bei professionellen Entwicklern. In der Freeware-Szene sind Teams aber sehr selten, so dass die gesamte Arbeit auf einen einzigen Entwickler fällt und dieser seine Zeit gut einteilen sollte.

Optimal wäre es immer in kleinen Schritten zu arbeiten und keine großen Ziele zu setzen. Wenn man sich ein kleines Ziel gesetzt hat und es erreicht, wirkt es motivierend und gibt einen Ausblick auf das, was man schon fertig gebracht hat. Wenn man sich große Ziele setzt, schleift man diese immer mit sich und sieht keinen wirklichen Fortschritt, was demotivierend wirkt.
Auch eine gute Regel ist immer von klein zu groß zu arbeiten, d.h. sich erst nur um das kümmern, was nötig ist, und erst wenn alles davon fertig ist, sich um die Verschönerung/Erweiterung/bla kümmern.