--
--
Geändert von Les (20.10.2018 um 23:49 Uhr)
Deine mentalen Fähigkeiten sind verblüffend, denn genau diese Vorgehensweise habe ich schon seit Wochen im Hinterkopf. Und genau so möchte ich auch mein neues Projekt angehen. Ich will erstmal mit Standardkram bis zu einer ersten Demo, vielleicht sogar Vollversion arbeiten um es dann hinterher erst aufzupolieren. So hat man bereits die komplette Handlung mit allem drum und dran (oder von mir aus auch hier nur eine vorzeitige, abgespecktere Variante, wie von dir vorgeschlagen) fertig. Man kann es von vorne bis hinten durchspielen und wenn man es letztlich aus welchen Gründen auch immer nicht zuende führt, hat man dennoch eine beachtliche Menge an Spiel vorzuweisen. Es ist zwar kein technisches Meisterwerk, das vor Eigeninitiative nur so strotzt, aber man konnte das Wesentliche rüberbringen- die Handlung.Zitat von Les
Ich gehöre auch zu denen, die immer alles mögliche selber machen wollen. Mein allererstes Projekt mit dem Maker hat es immerhin zu einer Demo von etwa 30min geschafft (bedeutend länger, wenn man nicht alle Dialoge wegdrückt xD) und bediente sich ausschliesslich des Standards. Es war grottig umgesetzt, aber ich hatte was vorzeigbares, auf das ich (mehr oder weniger) stolz sein konnte. Später bin ich beim Erstellen anders vorgegangen. Technikkram kam zuerst, danach Ressourcen. Technikkram wurde in der Regel erfolgreich fertiggestellt. Ressourcen meist auch zur Zufriedenheit editiert. (Kam allerdings immer mal wieder vor, dass mir die Tatsache, dass ich alles in einem Batzen erledigen wollte, vorzeitig die Motivation raubt.) Dann sollte eigentlich immer der schönste Teil kommen- die Handlung umsetzen. Bereitet eine Weile Freude bis man sich natürlich das Spiel oder den Rechner zerhaut und von vorne anfangen kann. Wäre nicht weiter schlimm, wenn man nicht wieder den Brocken an trockener Arbeit (=> Technik und Ressourcen) vor sich hätte. Ehrm, ja, nach ein paar mal hatte ich das dann auch mit den Backups (toll ist es auch aktuellen Fortschritt mit Backups zu überschreiben) verstanden...
Bei der Erarbeitung der Story würde mir das aber schon arg den Spaß nehmen. An dieser Stelle wollte ich eigentlich einen Roman verfassen, aber halten wir uns mal kurz. Für mich persönlich fühlt es sich natürlicher an eine Geschichte stückchenweise und eher puzzleartig oder wie einen Flickenteppich zu gestalten. Da gilt es dann also all das möglichst sinnvoll zusammenzusetzen. Vor allem auch äußere Einfluss tragen einen großen Teil zur Gestaltung bei. Das dabei hier und da einiges übersehen wird, halte ich für micht allzu kritisch. Wenn etwas doch total daneben ging, fällt das schon irgendwann auf. Spätestens wenn jemand anders drüberschaut. Aber jede Kleinigkeit muss jetzt nicht von vornherein perfekt durchdacht sein. Das wirkt zu schnell schablonenhaft, unnatürlich und gezwungen. In meinen Augen reicht es, wenn man als Ersteller seine Welt und die Zusammenhänge versteht und im Zweifelsfall auch spontan auf Unklarheiten reagieren kann. Wie man in diversen Spielvorstellungen sieht, gibt es ja häufig ausreichend Feedback dahingehend. Diesen Luxus wird natürlich nicht jeder erleben dürfen, aber im Fall, dass doch, kann man so gut auf Dinge reagieren, die einem selber nicht auffielen.
Interessantes Konzept. Hier mal meine Überlegungen dazu:
Im Prinzip fängt ja jedes Werk so an. Es gibt eine Idee. Diese ist meistens nur ein Aspekt oder eine sehr kurze Handlung.
Dann entsteht daraus eine kleine Welt mit ein paar mehr Zusammenhängen.
Und nach und nach entwickeln sich dann Nebenstorys, Charakterzüge, Handlungen und so weiter. bis eine mehr oder weniger "fertige" Welt vor einem steht.
Das ist meiner Meinung nach aber nur der gedanklich-schriftliche Teil.
Man kann ein Spiel klein anfangen, so dass man quasi die Story als light-Variante hat und sie dann ausbauen.
Das Problem, dass ich hier sehe: Es gibt einen deutlichen Mehraufwand. Denn ich füge ja nicht nur neues hinzu, sondern ändere bestehendes ab, passe es den neuen Ideen und Eingebungen an. Besonders wenn Grafiken und Technik sich über die Zeit ändert muss ich teilweise alles mehrfach wieder komplett neu machen.
Ein weiteres Problem (das quasi zum ersten gehört): Die Story und deren Entwicklung ist praktisch immer organisch, lebendig. Wenn ich mir meine beiden Konzepte anschaue und dann darüber nachdenke, woraus sie sich entwickelt haben, was deren Grundideen waren, dann sehe ich teils deutliche Unterschiede, manchmal kann man den Ursprung nicht einmal mehr erkennen, aus dem sich das aktuell vorliegende Werk entwickelt hat.
Wenn ich also schon eine kleine Version habe und ich füge Elemente hinzu, die die Handlung über den Haufen werfen, sie tiefgreifender oder anders gelagert mache, oder sonst wie gravierende Veränderungen vornehmen möchte, dann kann ich praktisch wieder ganz von vorne anfangen. Und im Schlimmsten Fall kann einem das sogar bremsen, weil man das schon entwickelte unbedingt mit einbinden möchte, selbst wenn es vielleicht nicht mehr rein passt.
Und je nach Genre und Story kann sich solch ein System mehr oder weniger eignen.
Nehmen wir mal ein Detektivspiel und ein RPG mit simpler Handlung. Im Detektivspiel ist die Story von vorne bis hinten wichtig, da überall Indizien, Verwirrungen und Hinweise versteckt sind, die Story ist komplex und kann selten gekürzt werden. Das Simpel-RPG hingegen besteht aus einem Startdorf, einer kleinen Reise und dem Schloss des Bösen Magiers. Man kann also alles (Handlungs-) wichtige in 10 Minuten erzählen und darauf aufbauen und weitere Details und Nebengeschichten hinzufügen. Hier geht das deutlich leichter und effektiver als beim Detektivspiel, die Story bleibt dann aber in seinen Grundzügen auch immer recht simpel - wenn sich der Aufwand nicht wieder deutlich erhöhen soll.
Also kurz gesagt: Um die Story zu entwickeln gibt einem dass eine super Unterstützung und hilft einem den Faden nicht zu verlieren und zu früh zu sehr abzuschweifen. Direkt beim konkreten Erstellen würde ich es in den meisten Fällen eher als Kontraproduktiv empfinden.
Mein Meinung ©
Da ich immer sehr gerne mit dem Kopf durch die Wand bin und neben der (teilweise völlig unausgearbeiteten Story) direkt riesige Menüs samt Alchemie- Rüstungs- und Itemsystem umgesetzt habe, halte ich diesen Ansatz auch für sehr sinnvoll.
Eddy sagte ja bereits, eigentlich fängt jedes Spiel irgendwie so an. Diese Entwicklung aber methodisch und strukturiert zu vollziehen halte ich für durchaus gewinnbringend!
Wenn ihr mit dem Ansatz mal was brauchbares generiert habt, sagt mal bescheid
--
Überlegenswert ist es sicherlich. Ich glaube, gerade der Spielmechanik täte eine konsequente Denkabfolge, die immer erst dann zum Speziellen schielt, wenn sie sich bereits über das Allgemeine vergewissert hat, sehr gut, weil damit eine Prüfmethode existierte, ob sich der neue Einfall überhaupt ins Programmatische einfügte und wert wäre, zu einer Idee ausgearbeitet zu werden.
Soll der Held für jeden gelaufenen Spielweltkilometer einen Extrapunkt auf seinen Konditionswert erhalten? Mit einem bereits formulierten Grundplan ließe sich überschlägig abschätzen, ob sowas passt, indem man vor dem konkreten Kontext des angestrebten Spielzuschnitts die Einwirkung des möglichen Spielbestandteils abgleicht.
Als Erzähltechnik wäre mir persönlich das Schneeflockenprinzip nicht sonderlich willkommen. Ich fange lieber mit einer ausgebauten Situation und bereits definierten Heldenpersönlichkeiten an und fahre von dort aus chronologisch fort. Details stören mich nicht, sind mir vielmehr eine wertvolle Stütze bei der erzählerischen Fortführung.
Heyho,
der Gedanke ist gut - hatte ich witzigerweise auch kürzlich.
Aber es hat seinen Grund, warum diese Methode für Geschichten und nicht für Spiele erfunden wurde *g*
Für die Story kann man das empfehlen, jedoch nicht im Maker, sondern in Word. Das ist ein um einiges flexibleres Tool, wenn ich nebenbei mal auf die Idee komme, den ein oder anderen Plotstrang zu verändern.
Auf grafischer Ebene kann ich es mir auch vorstellen, da es den Workflow teilweise sehr erheblich behindert, wenn man gleichzeitig mappen, scripten und pixeln muss. Nachteil ist, man hat einen Mehraufwand:
Entweder ich bastele Stellvertretergrafiken, die ich im Nachhinein ersetze oder ich muss wirklich später jedes Event durchgehen und Posen, Gesichtsausdrücke etc etc. nachtragen.
Auch ein Problem: Fehlende Abwechslung. Wenn ich alles gleichzeitig mache, dauert es zwar mitunter länger, ich werde ständig unterbrochen, muss schnell was zusammenpixeln, aber es ist eine abwechslungsreiche Tätigkeit. Wenn ich mir vorstelle am Ende des Projekts dann stundenlang NUR zu pixeln ... neee...
Scriptebene schwer vorstellbar, wenn man größere Systeme plant. Beispiel Scripte, die die Interaktion mit NPC's regeln, Diebstahl, Schlösser knacken usw. müsste ich alles dann auf Eventebene pro Map aktualisieren -> Fehlerquelle: Dinge übersehen.
Eine sinnvolle Methode, sodenn man die Muße hat, wäre eine ausführliche Konzeptplanung, die alles beinhaltet: Story, Scripte, Grafik usw. Dann alles an allgemeinen Events, Posen, Faces, Musik etc. vorbereiten und schlussendlich in sehr gutem Tempo all das zusammenfügen.
Ich finde die Methode super und sogar sehr wichtig, auch in der Spieleentwicklung. Man gewinnt schnell einen guten Eindruck davon, ob das Gesamtkonzept noch passt. Man verliert sich nicht ständig in Details, sondern prüft erstmal, ob diese Details überhaupt notwendig sind.
Natürlich sollte man sich auch nicht strikt an das Prinzip halten, wenn man gerade einen Flow hat. dann macht man weiter, bis der Flow abflaut und distanziert sich danach erst wieder vom Projekt, um das Gesamtwerk zu betrachten.
Es ist oft die doppelte Arbeit, ja. Aber dafür ist es nie der falsche Weg, den man dann zu lange beschreitet.
Ich finde die Art zu makern eigentlich wichtig und sinnvoll für die meisten Leute die Probleme haben ein Spiel fertigzustellen. Und das das sind vom Bauchgefühl über 90% der Spielemacher hier. Das Hauptproblem das einem fertigen Spiel im Wege steht ist natürlich die Motivation und begrenzte Zeit. Wir alle haben nur begrenzte Zeit uns unserem Hobbyprojekt zu widmen und wenn man da laufend vor technischen und grafischen Hürden steht und an alles gleichzeitig arbeitet, kann die Motivation sicher irgendwann mal verfliegen. Ich arbeite teilweise selbst nach dem Schneeflockenprinzip, habe aber nicht von Anfang an so angefangen, was ich immer wieder mal bereue.
Ich denke man kann dieses Prinzip in folgende Bereiche aufteilen:
1. Zu allererst wird die Geschichte samt Gameplay vorher ausgearbeitet.Für die Geschichte schreibt man eine Art Drehbuch, für das Gameplay eine Art Blaupause oder Index für Dinge die ein Spieler tun oder bekommen kann.
Nehmen wir z.B. Super Mario um das Beispiel einfach zu halten. Die Geschichte ist einfach gehalten und benötigt eigentlich kein Drehbuch, aber einen roten Faden, in dem man Anfang und Ende der Geschichte, sowie die Etappen dazwischen festhalten sollte. Und natürlich die Umwelt (ein Klempner in einer Welt aus Rohren und Schergen einer Drachenschildkröte). Beim Gameplay wird es schon genauer. Der Spieler hüpft, klettert, rutscht, fliegt durch Levels, sammelt Objekte Pilze, Blumen usw. und erledigt Gegner, zerquetschen oder abschießen usw. Man sollte hier wirklich möglichst alles einbauen und sollte einem später noch etwas einfallen, sollte es kein Problem sein es hinzuzufügen.
2. Nachdem der theoretische Teil abgeschlossen ist, sollte man die Levels gestalten. Und zwar mit einem Dummy-Chipset. Es könnte theoretisch nur aus 3 Bereichen bestehendes Chipset sein. Wand, Boden und Objekte. Im Schnellverfahren kann man so sämtliche Maps fertigstellen. Man muss natürlich so mappen, das sich später das Dummy Chipset einfach mit einem anderen Chipset austauschen lässt und die Map im Grunde optisch schon fertig ist.
3. Events. Alles was irgendwie auf der Map von belang ist. Ein Teleport, NPCs die sich bewegen etc. sollten ebenfalls als Dummys eingefügt werden. Dialoge und co. sollte man eigentlich erstmal nur mit einer Textbox mit dem Inhalt "Text" einbauen. Später kann per Copy&Paste diese aus dem Drehbuch ersetzen. Sinn? Es erleichtert das Testpielen ungemein, wenn man die Dialoge schnell wegklicken kann. In den ersten Phasen testet man ja eher technische Abläufe auf Fehler und nicht ob ein Dialog stimmig ist.
4. Wenn der technische Teil abgeschlossen ist und ihr euer Spiel mit seinen Dummy Chipsets, Dummy Charakteren und Dummy Dialogen durchspielen könnt, erst dann kann man anfangen den optischen Teil aufzupolieren. Sprich Grafiken ersetzen, Sounds und Musik einbauen, Dialoge ersetzen etc. Hier beginnt der Feinschliff der dann auch mehr Spaß macht.
Bei Punkt 1-3 ist es eigentlich nur wichtig, das man seine Motivation aufrecht erhält und dies geschieht meiner Meinung nach in dem man sich nur einer Baustelle widmet und in dieser schnelle Fortschritte erzielt. Ich arbeite wie gesagt selbst teilweise so und es ist einfach viel motivierender, weil man so schneller vorankommt.
--
Es ist ja eigentlich schon fast unausweichlich, dass man die Geschichte auf diese Weise schreibt. Ich mach's so: Schlüsselmomente grob aufschreiben; die Handlung in Stichworten drumherum aufbauen; im Drehbuch ausformulieren; Dialoge implementieren.
Aber beim Rest des Spiels bin ich mir nicht sicher, ob man sich mit diesem "Schneeflockenprinzip" die Arbeit wirklich leichter macht. Vieles arbeite ich lieber sequentiell ab. Beim Dungeon sieht der Idealfall (oft muss man ja nachbessern) so aus: Skizze vom Dungeon auf Papier zeichnen; Grafiken pixeln; Maps ohne Events fertigmachen; Events einbauen.
@Ascare
Machst du dir damit nicht eher zusätzliche Arbeit? Ich müsste schon die fertigen Grafiken vor mir sehen, um einschätzen zu können, ob der Map-Aufbau in Ordnung ist. Später die Dummies einfach gegen die richtigen Grafiken auszutauschen würde bei mir also nicht funktionieren. Welchen Nachteil hätte es denn, die Grafiken schon vorher fertigzumachen?
Das Szenario gibs in unserer Community doch dauernd: Jemand mit viel Spaß am schreiben und/oder der Technik stürzt sich in ein massives Projekt, das supergut werden soll, aber er hat keine Ahnung von Grafiken. Statt erst einen Prototypen zu machen, der Dummygrafiken hat, stürzt er sich in das wilde Abenteuer mit einer Hand voll nichts nach einem Grafiker zu fragen. Die sehen dass er nichts hat und melden sich nicht, weil sie von etwas, das aus zwei Seiten Text und einer Idee beseht, nicht einspannen lassen wollen.
Klappe zu, Projekt tot.
Lange Geschichte kurz erzählt, Dummygrafiken können einem ne Menge Stress sparen. X_x
Hm, suche Grafiker, der Dummy-Grafiken macht, damit ich mit denen noch einen Grafiker anlocken kann. Wer macht mit?
Auch würde ich jetzt nicht unbedingt die Hardcore-Variante "Nur ein Boden, eine Wand und ein Objekt" nutzen sondern vielleicht schon auf das RTP zurückgreifen. Damit kann auch schon oft ein ungefährer Eindruck der Umgebung gegeben werden und man sieht, ob die Maps nach etwas aussehen oder nicht ^^
--
Vielen Dank
@Sabaku
Screens mit Dummy-Grafiken motivieren aber auch nicht zum Mitmachen.Nein, das sind ja zwei unterschiedliche Probleme: auf der einen Seite ist die eigene Motivation (die Ascare meinte, denke ich), auf der anderen ist die der potenziellen Helfer. Wobei ich in Hinblick auf Letzteres glaube, dass egal wie man das Spiel präsentiert, das eigentliche Problem der große Aufwand bleibt.
Nein, aber eine spielbare Demo(!) kann Narrative und Technik beinhalten und wäre für mich, als jemand der sich durchaus freut mal jemandem unter die Arme greifen, mehr ein Symbol dafür, dass dabei auch was herauskommt. Und wer zu faul ist in Paint eine Dummyrafik zu erstellen, zum beispiel ein weißes Quadrat, oder sich eins der tausendundeins fertigen Charsets aus dem Netz zu holen, der wird auch nicht die Kraft aufbringen seine Grafiken selber zu machen, da bin ich mir ziemlich sicher.@Sabaku
Screens mit Dummy-Grafiken motivieren aber auch nicht zum Mitmachen.
Außedem ist es für viele motivierender, eben erstmal diese Ebenen der Funktion abzuarbeiten, um dann quasi den "stupiden Teil" nämlich das "Aufhübschen" des Spiels zu beginnen. Und für einen technisch funktionierenden Protoyp braucht man keine speziellen Grafiken, sondern höchstens ähnliche, wenn man vom Makerstandart spricht, der ja mit Tiles funktioniert, die immer gleich arbeiten.
Und wenn wir vom Mapaufbau sprechen: Wer mit Panoramamapping arbeitet wie ich das häufig mache, der wird seine Map sowieso tausendfünfhundertmal umarrangieren (und kann das auch, wenn er mit Ebenen arbeitet) und wer im Maker mappt, der hat sowieso alles sauber geteilt, das ist gar kein Problem, wenn man dann die finalen Grafiken verwendet, noch etwas zu ändern. Wenn du nicht an einem filigranen Webstuhl deine Maps zusammenfügst, dann seh ich da auch kein Problem, den groben (!) Mapaufbau erst mit Dummygrafiken zu machen.
Geändert von Sabaku (13.08.2016 um 12:31 Uhr)
Das wäre auch für mich das Entscheidende: Eine Demo als Zeichen dafür, dass aus dem Spiel wirklich mal was wird. Auf den Inhalt kommt es gar nicht so sehr an. Aber scheitert es wirklich an den Grafiken? Ich meine, es scheitert eher daran, dass die Anfragen zu früh kommen. Es passiert ja gar nicht so selten, dass die Spielidee den Eindruck macht, gerade mal einen Tag alt zu sein.
Das hängt aber schon zusammen. Die Handlung wird ja nicht nur durch Dialoge vermittelt, sondern auch durch das Bild. Die Szenen entfalten erst dann ihre Wirkung, wenn sie inszeniert und animiert wurden. Vielleicht nimmt das jeder anders wahr, aber eine unfertige Szene würde mir gedanklich so lange auf die Nerven gehen, bis ich sie fertigmache.
Den groben Map-Aufbau gibt es bei mir gar nicht. Wenn ich die Maps direkt im Maker mach, setz ich natürlich auch zuerst die Wände, Böden, größeren Objekte usw. aber nahtlos im Anschluss kommen dann schon die Details. Wenn die Map im Grafikprogramm entsteht, mach ich die Map komplett fertig, bevor ich mit der nächsten anfange.
Ich glaube speziell für dich Kelven macht es vielleicht weniger Sinn mit Dummy Grafiken zu arbeiten, da du sehr vieles (alles?) selber machst und sicherlich schon eine Grafik Bibliothek hast, auf die du zurückgreifen kannst und, wenn nötig, kurzerhand abändern kannst. Da du auch immer im gleichen Still bleibst, egal ob Adventure/Horror, kannst du sogar von einem vorherigen Spiel erstmal die Grafiken wiedergebrauchen um zu sehen ob das Spiel so funktioniert.
Ich denke die Mehrheit der Maker würde schon von einfachen Dummy Grafiken profitieren, weil sie meistens ganz neu anfangen und schnelle Fortschritte brauchen um motiviert zu bleiben.
Und was das RTP als Dummy angeht. Ja, kann man nehmen, allerdings muss es auch thematisch passen. Denn wenn ich ein Horror Game machen will und mit RTP arbeite, dann kann das Ganze später sehr demotivierend sein, weil das Projekt allein schon vom Stil des RTP eine starke Ausrichtung bekommt. Und auch wenn man bewusst weiß, das die Grafiken später ersetzt werden, wird man vielleicht unterbewusst eine Art Unzufriedenheit mit dem Projekt entwickeln und die Überzeugung daran verlieren. Schließlich ist RTP nicht gruselig, atmosphärisch etc Das RTP funktioniert als Dummy vielleicht wenn man sowieso ein sehr allgemeines RPG auf die Beine stellen wollte. Allerdings birgt es auch die Gefahr das man auf dem RTP hängen bleibt und das Projekt ist dann aus Faulheit als RTP Projekt fertiggestellt. Und schon haben wir ein generisches RPG.
--
Das Thema geht jetzt mehr in Richtung: "Wann ist die richtige Zeit, um Unterstützung zu holen." Nichts für ungut
Ich habe für mich eine Methode gefunden, um den Aufwand einschätzen zu können. Ich erstelle Dummies für alle Gameplay Elemente die mein Spiel beinhaltet. In meinem Fall sind es die Elemente
- Story
- Gespräche
- Rätsel
- Kämpfe
- Ausrüsten
- Sammeln
- Fallen
Dann gibt es noch Unterkategorien, die hier erstmal nicht so wichtig sind. Die "Gameplay-Elemente-Dummies" kann ich dann einfach als Module einsetzen und je nach Situation abändern. Voilà. Agile Produktentwicklung
@Ascare
Auf den neuen Makern, also XP aufwärts, nutzen die meisten Spiele sogar das RTP bzw. den RTP-Stil, auch Horrorspiele (es gibt moderne Sets für die neuen Maker), wobei die ja sowieso unabhängig vom Maker eher eine Nische sind. Viele Entwickler können also eigentlich sofort loslegen.
Fortschritte womit denn?
Ich blende jetzt mal die Werbung für Helfer komplett aus, es geht nur um die Motiviation des Entwicklers. Nehmen wir als Beispiel mal ein Horrorspiel und der Entwickler hat am Anfang gar keine Grafiken.
Er könnte nun, Möglichkeit 1, erst die Grafiken zusammensuchen und dann mit dem Spiel anfangen. Er braucht natürlich nicht gleich alle Grafiken, aber genug, um die ersten Abschnitte zu machen.
Er könnte aber auch, Möglichkeit 2, erst mit Dummy-Grafiken loslegen. Aber was hätte er davon? Die Maps in Horrorspielen sind oft sehr individuell, halb im Grafikprogramm entstanden und mit Licht- und Schattenfiltern, und relativ wenige an der Zahl, zumindest im Vergleich zu Rollenspielen. Sobald der Entwickler später die Grafiken hat, muss er die Maps wohl alle neu machen. Einfach nur die Tilesets austauschen klappt eher nicht.
Viel zu testen gäbe es in der Dummy-Welt nicht. Für ein AKS in einem Horrorspiel würde ich auch eine Dummy-Map anlegen, aber da reicht ja eine, und der Rest vom Gameplay ist meistens das, was der Maker von Haus aus unterstützt (etwas anklicken, Gegenstände benutzen).
Zu guter Letzt ist in der deutschen Community die Grafik von Horrorspielen für die Entwickler sehr wichtig, deswegen werden die meisten vermutlich auch motiviert an sie herangehen.
Anstelle von Dummy-Grafiken würde ich schon eher bevorzugen einfach einen Bleistift zu nehmen und es grob auf ein Blatt Papier zu zeichnen (alternativ auch Paint, aber ich mach sowas lieber analog). Für den groben Überblick für einen selber reicht das völlig aus. Und es ist bei Bedarf immer detaillierter als eine Map mit Dummy-Grafiken. Man kann schnell was dazu zeichnen oder auch einfach ne Notiz einfügen, was beim Maker alles garnicht geht oder eben mit mehr Aufwand.
Um Technisches auszuprobieren erstell ich mir immer Testmaps, in denen ich dann bestimmte Situationen am besten nachstellen kann und erst dann kommt das in's fertige Spiel.
Ich fänd es jetzt auch eher unmotivierend alles quasi doppelt zu machen.
Wenn ich schon anfange zu Mappen, dann soll das direkt schon das fertige sein ("feritg" im Sinne von "wird eh noch zich mal umgeändert" ^^ Also eher "fertig nach aktuellem Stand").
@Kelven
Ich finde das die Punkte "Sets zusammensuchen" und "gleich loslegen" nicht zusammenpassen. Ich denke das jeder bei der Planung des Spiels schon vorher weiß, was für Gebiete er braucht und in welchem Stil sie sein sollen. Aber die passenden Ressourcen zu finden dauert ewig und es gibt meiner Meinung nach immer noch wenige "komplette" Ressourcen die man durchweg für ein Spiel nutzen kann. Das ist auch der Grund warum viele selbst Hand anlegen müssen, weil sie dadurch schneller voran kommen und motiviert bleiben. Das war zumindest bei mir so und ich denke, da du deine Sets selber machst, bei dir auch. Wenn du z.B. ein Bücherregal im düsteren Look einbauen willst, dann zeichnest du wahrscheinlich selber eins oder bedienst dich an deinen eigenen bereits vorhandenen Ressourcen (du hast über die Jahre sicherlich schon so viele Dinge kreiert, das man daraus ein eigenes Kelven RTP machen könnte
Ich weiß ich brauch ein düsteren, kargen, blattlosen großen Baum. Diesen im Internet zu finden oder selbst zu zeichnen dauert lang und ist auf die Dauer demotivierend. Sets zu zeichnen macht Spaß ist aber auch zeitaufwendig. Um schnelle Ergebnisse zu erreichen nehmen wir also erst einmal das hier:
Einfache geometrische Figuren kann jeder schnell erstellen.
Irgendwann wenn es nun Zeit wird den richtigen Baum an die Stelle zu platzieren, dann können wir uns auf die Suche begeben oder einfach selbst Hand anlegen und den den Dummy Baum mit diesem Baum ersetzen:
Die Dummy-Idee ist übrigens nicht neu. Bei 3D Spielen ist es Gang und Gäbe zunächst mit Dummys (am Anfang sogar meist nur mit Drahtgittermodellen) zu arbeiten und diese später auszutauschen.
Ach ja und Sets einfach austauschen funktioniert sogar erstaunlich gut, natürlich muss die Anordnung der Objekte genau gleich sein.
@Eddy131
Das was du ansprichst sind aber zwei verschiedene Entwicklungsphasen. Auf Papier Skizzen anzufertigen gehört in den Planungsbereich, während ein Dummy ja tatsächlich im Spiel eingebaut wird und dazu dient ein Prototypen herzustellen. Ein Dummy für z.B. oben genannten Baum machst du in 5 Minuten fertig, während du für den endgültigen Baum Stunden brauchst, wenn nicht noch länger so einen im Internet zu finden.
Ich glaube der Faktor Zeit, welcher ein entscheidender Motivationsträger ist, wird von den meisten unterschätzt.
--
@Ascare
Ich sprach ja vom RTP, als ich "gleich loslegen" schrieb. Die meisten Entwickler (vor allem die Anfänger) benutzen heute das RTP oder eines der Pakete, die man auf rpgmakerweb kaufen kann. Sie kommen also gar nicht in die Situation, dass sie loslegen wollen, aber keine Grafiken haben.
Und das ist sie in den meisten Fällen ja nicht. Es ist ziemlich wahrscheinlich, dass man einen großen Teil der Map wieder über Bord schmeißt, weil man erst mit den echten Grafiken sagen kann, ob die Map den ästhetischen Ansprüchen gerecht wird. Für mich sieht das daher nach zusätzlicher Arbeit aus: Dummy-Grafiken zeichnen, Dummy-Maps anlegen, Grafiken besorgen, Maps neu machen. Ich glaube nicht, dass jemand mit Dummies schon die "endgültige" Map (bis ins Detail) anfertigen kann.
Und wie gesagt, welchen Nutzen hätte das Dummy-Spiel für den Entwickler selbst? Über den Prototypen als Werbung für potenzielle Grafiker haben wir ja schon gesprochen. Ich denke aber, dass es sehr schwierig ist, jemanden zu finden, der unentgeltlich die ganzen Grafiken für ein größeres Spiel macht.
Gibt es heute nicht schon größere Asset-Sammlungen? Einen toten Pixelbaum hab ich z. B. auf opengameart.org gefunden. Aber ja, es wäre suboptimal, die ganzen Sprites einzeln zusammenzusuchen, deswegen würde ich jedem, der die Grafiken nicht selbstmachen kann, auch raten, zum RTP oder einen der oben angesprochenen Pakete zu greifen.
Berechtigungen
Zitieren
"Wolfenhain" fertig. "Endzeit": fertig. Neues Projekt: "Nachbarlicht" 
