Gutes Mapping = reine Zeitverschwendung

[Er Te Pe]

Hm, mein Post bezieht sich natürlich auf Alone - Eternal Nightmare, ich hoffe doch, von Cold Winter positiv überrascht zu werden.
Dass Stimmung nicht fehlen sollte ist klar, aber ich behaupte nur, dass bei Alone (Eternal Nightmare) aufgrund des hohen Mappingaufwands Bugfixing und Story zu kurz kamen.
Dass ein gewisses Umfeld bei Horrorspielen nicht fehlen sollte ist klar, aber nicht zwingend nötig. Wie Kelven erwähnt hat, kann Horror auf verschiedenen Ebenen spielen. Entweder man spricht wie Bio die optische und akustische Wahrnehmung an, oder man gibt dem Spieler eine solch glaubwürdige und grauenhafte Geschichte, dass der Horror einzig und allein in seinem Kopf stattfindet.
Egal wie man sich entscheidet, das Gameplay sollte jedenfalls nicht darunter leiden. Was es bei Eternel Nightmare leider tat...

[Captain Smoker]

Wobei ich es doch stark bezweifle, dass durch eine Geschichte, sei sie auch noch so gut erzählt und beängstigend, ein Horrorgefühl in meinem Kopf entsteht.... zumal dann auch noch an einem Makerspiel. Oo Da wage ich es doch sehr stark zu bezweifeln, dass, wenn man sogar weitesgehend auf die optische und akustische Veriante der Atmo-erzeugung verzichtet, etwas erreicht. Um ein Horrorspiel am Maker wenigstens ein bisschen düster darzustellen, sollte man wirklich die Grafik und die Gestaltung der Umgebung sehr sehr ernst nehmen....
Einzige Variante die man ohne Effekte sonst nämlich nehmen könnte um Grusel zu erzeugen wäre wohl sonst die sogenannt Schock-Blitz-Screens.... auf gerade Strecke kommt urplötzlich ein Ekel-picture mit lautem Scrawl-sound. Ansonsten kann man Horror-atmo imo nur mit sehr gutem Effekt-und Areamaking erreichen. Die Story ist wie gesagt wichtig, aber Horror allein erzeugt man damit noch lange nicht.

[Kelven]

Auf dem Maker kann man mMn gar keine Horrorstimmung erschaffen, aber das Thema hatten wir ja schon mal.

... dass man grade bei einem Spiel wie Alone, vor allem auf die Atmo, die Effekte, insbesondere Lichtspielereien, und die Grafik sein Augenmerk legen sollte.

...

Das widerspricht aber doch irgendwie der Idee eines Spieles. Außerdem steht eine schwache Geschichte der Stimmung im Weg, denn wenn man die Dialoge und Storywendungen unfreiwillig komisch findet, dann kann man das Spiel gar nicht mehr ernst genug nehmen, um eine Atmosphäre zu spüren. Von daher ist es auch bei Horrorspielen wichtig, sich einen guten Plot auszudenken (und erst recht gut umzusetzen). Im Grunde ist das aber genau das, worüber wir hier diskutieren, dass nämlich Grafik schnell als Entschuldigung für das Fehlen von Gameplay und Handlung genutzt wird.

[Captain Smoker]

So wieder daheim... ^^

Auf dem Maker kann man mMn gar keine Horrorstimmung erschaffen, aber das Thema hatten wir ja schon mal.
...
Das widerspricht aber doch irgendwie der Idee eines Spieles. Außerdem steht eine schwache Geschichte der Stimmung im Weg, denn wenn man die Dialoge und Storywendungen unfreiwillig komisch findet, dann kann man das Spiel gar nicht mehr ernst genug nehmen, um eine Atmosphäre zu spüren. Von daher ist es auch bei Horrorspielen wichtig, sich einen guten Plot auszudenken (und erst recht gut umzusetzen). Im Grunde ist das aber genau das, worüber wir hier diskutieren, dass nämlich Grafik schnell als Entschuldigung für das Fehlen von Gameplay und Handlung genutzt wird.

...

Das Thema gabs wirklich letztens schon in einem andren Thread und hier hege ich dieselbe Meinung. Horror am Maker geht nicht... generell geht meiner Meinung nach Horror nicht im medialen Format... weder Filme, Spiele, noch gute Bücher können wirkliches Horrorfeeling überbringen. Ist zumindest meine Ansicht der Dinge. Es ist Fiktion und Entertainment und wird so auch im Gehirn aufgenommen.
Und das eine gute Story Horror im Kopf entstehen lässt.... Oo Das hat denke ich nichts mit längerer Lebenserfahrung zu tun, MA-Simon. Naja aber wir schweifen vom Thema ab...

Grafik wird zum Teil als Ausrede für fehlende Können in den anderen Bereichen des Makers genutzt, aber macht das nicht jeder? Ein Technik macht ein bombiges KS und versucht dadurch sein Spiel besser anzupreisen, weil er vielleicht in Sachen Grafik kein Plan hat. Jeder muss sich halt auf seine Stärken konzentrieren, um sein Game außergewöhnlich zu machen und von der breiten Masse abzuheben. Bio kann nun mal tolle LEs und Grafik machen.... logischer das er sein Spiel nunmal damit voll ausrüstet. Oo Und was die Story angeht... naja die Idee war damals schon gut, nur die Umsetzung hat er nicht so gebacken bekomm. Mal sehen wie Cold Winter wird... aber da er z.B. beimk Intro Unterstützung von Veyrne hat, denk ich mal wirds storytechnisch prickelnd. xD
Klar braucht ein Horrorgame eine gute Story, aber die Werteverteilung ist dabei denk ich mal anders, als bei einem klassischen RPG. Wenn mir da schon das Intro und die Story missfällt, wars das eigentlich schon, denn Fantasy lebt von der Geschichte, der Welt, dem Hintergrund etc. Bei einem Horrorgame spielen hingegen noch andere Sachen stark mit rein. Dunkle Grafik, gute LEs, schöne Animationen und actionreiche Momente sollten dort imo nicht fehlen. Es lebt halt nicht zu 100% von der Story so wie die Fantasy... sondern diese wird vielleicht nur zu 80% ins Gesamtwerk merkbare benötigt.

Wie gesagt, das ist alles nur sehr subjektiv und spiegelt lediglich meine Ansicht im Bezug der beiden genannten Genres am Maker wieder. Mag sein, dass jemand anderer Meinung ist. Damit kann ich leben, aber ich seh es halt so. ^^

[Fleischmann1]

Und das eine gute Story Horror im Kopf entstehen lässt.... Oo Das hat denke ich nichts mit längerer Lebenserfahrung zu tun, MA-Simon.

...

Naja ich denk mal er hat damit eher die Vorstellungskraft und die Einstellung gemeint. Wenn jemand ein Horror-Game spielt und dann schon von vornerein in einer eher genervten Stimmung ist, wird er auch nicht so beeinflussbar sein als jemand, der sich auf das Spiel "einlässt".
Das ist dasselbe wie mit Horrorfilmen. Wer seinen Film in hellem Zimmer sieht und sich nebenbei vll noch mit etwas anderem beschäftigt, wird sich da wohl eher nicht gruseln.

btw, würde denn jemand von euch noch ein Spiel (das jetzt mal kein Trash/Fun ist) ohne LEs spielen?

[Kelven]

btw, würde denn jemand von euch noch ein Spiel (das jetzt mal kein Trash/Fun ist) ohne LEs spielen?

...

Ich bemerke bei Spielen mit Lichteffekten und bei Spielen ohne kaum einen Unterschied, außer dass ich bei den Spielen ohne Lichteffekte meistens mehr auf dem Bildschirm erkenne. \o

[makenshi]

@Kelven

Auf Seite 1 meinst du das das Mapping beim Makern genau so eine "Pseudokunst" sei wie die Technik. Beschreibe mir bitte mal anhand eines
komplexen Kampfsystems warum die Technik eine "Pseudokunst" ist.

[Kelven]

Weil du mißverstanden hast was ich meinte. Natürlich steckt ein hoher Sciptaufwand hinter solchen selbstgemachten Kampfsystemen, aber wieso nennt man das Technik? Technik ist das was in meinem DVD-Player steckt. Diese Zutaten eines Spieles nennt man für gewöhnlich Gameplay oder Spielmechanik. Der Spieler kann ein selbstgemachtes Kampfsystem dafür loben, dass es sich gut spielt oder es dafür kritisieren, dass es sich schlecht spielt, aber die Qualität eines Spieles bzw. der Spielmechanik lässt sich kaum an der Menge der Codezeilen messen. Wenn ich solche Sprüche höre wie "UiD besitzt keine Technik", dann runzelt sich meine Stirn. Das meine ich mit Pseudokunst.

[Er Te Pe]

@ Fleischmann:
Das ist genau der falsche Ansatz.
Wenn du bei Spielen schon mal Lichteffekte vorraussetzt, bevor du es überhaupt mal anspielst, entgeht dir eine Menge.
LEs sind kein Standard, sonder lediglich Zierde, und haben mit dem Spiel dahinter gar nichts zu tun. (Insofern man die Lichteffekte nicht mit dem Gameplay verbindet, nur fällt mir kein Spiel ein, wo das der Fall ist.)

@ Kelven:
Du bist doch kleinlich^^
Der Begriff Technik hat sich eingebürgert, ob er jetzt richtig verwendet wird, spielt keine Rolle, solange man weiß, was man meint.
Dann behaupten wir halt mal: "UiD hat keine spielmechanischen Beeinflussungskonzepte."
Obwohl du in dem Punkt Recht hast:

die Qualität eines Spieles bzw. der Spielmechanik lässt sich kaum an der Menge der Codezeilen messen.

...

Jeder arbeitet anders mit dem Maker, so kommen viele auch mit unterschiedlichen Codes zum selben Ergebnis. Solange das Spiel packend ist, juckt es mich nicht, ob der Ersteller 4 Jahre oder 4 Wochen dran gewerkelt hat.
(So überlegt, wäre das mal ein netter Wettbewerb: Man gibt diverse Kampfsystemgrafiken sowie eine Aufgabenstellung, was das System können soll vor und wer das am Ende mit den wenigsten Variablen, Switches, Codezeilen, Events etc. erfüllt, hat gewonnen^^)

[makenshi]

@Kelven
Eben deswegen habe ich ja gefragt Kelven.
Ich denke der Begriff "Technik" hat sich simpel eingebürgert.
Das ist denke ich in jeder "Szene" so das diverse Begriffe genommen
werden und diese entzweckfremdet werden. Den gleichen Vorgang
kannst du bei den "Lightmaps" beobachten. Eigentlich ein Begriff
aus der 3D-Grafik, bezeichnet es hier ein Bild das über eine 2D Map
gelegt wird. Trotzdem benutzt du es afaik auch als normales Wort.
Ergo sehe ich nicht den Sinn darin das du dich über das Wort "Technik"
irgendwo beschwerst.

Ein Wort hat in meinen Augen nicht nur eine Definition. Es kann durchaus
mehrere haben die sich aus dem Context erschließen. In diesem Sinne vergisst du übrigens einen Punkt bei deiner Bewertung der Technik. Klar, es sieht keine wie effizient ich den Makercode aneinandereihe. Allerdings merkst du das beim spielen sehr wohl. Ein KS das schlecht zusammengestöpselt wurde hat Defizite in Sachen Geschwindigkeit. Und das nicht zu knapp. Die Steuerung und das allgemeine Spielgeschehen könnte anfangen zu "laggen". Gute Technik ist also imo keine "Pseudokunst". Ich denke eher das ist der Witz warum Leute mit einer Informatikausbildung an einem Spielebaukasten rumwerkeln. Mit primitiven Mitteln ein lauffähiges und effizientes System aufbauen.

Edit:
Im Quote gesehene Typos

[The_Burrito]

Ich denke eher das ist der Witz warum Leute mit einer Informatikausbildung an einem Spielebaukasten rumwerklen. Mit privimiten Mitteln ein lauffähiges und effizientes System aufbauen.

...

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

[makenshi]

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

...

Das könnte ich so nicht unterstreichen.
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.

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

[Cherry]

(So überlegt, wäre das mal ein netter Wettbewerb: Man gibt diverse Kampfsystemgrafiken sowie eine Aufgabenstellung, was das System können soll vor und wer das am Ende mit den wenigsten Variablen, Switches, Codezeilen, Events etc. erfüllt, hat gewonnen^^)

...

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.

[cilence]

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.

...

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

[Kyuu]

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.

...

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

[Hisoka]

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)

[Er Te Pe]

Wenn ich solche Sprüche höre wie "UiD besitzt keine Technik"

...

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.

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

...

Kommt meiner Meinung nach auf den Anwender an.

[makenshi]

@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?

[Kelven]

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