Sammlung von Tipps rund ums Spieldesign

Defmaster · 30. Mai 2009, 17:31

Neues (altes) Forum und dann werd ich mal den Anfang machen
und als Startpost eine Reihe von Tipps geben die man bei dem Erstellen von
Spielen beherzigen sollte.
Die Tipps stammen aus eigener Erfahrung und auch aus anderen Artikeln die
sich mit dme thema auseinander setzen.

Ich hoffe natürlich, dass hier noch mehr Tipps besteuert.
Ich habe bisher die Tipps aufgeschrieben die mir am wichtigsten erschienen und auch eingefallen sind ;p

Bugs – diese widerwärtigen Käfer...
Fehler sollten gleich beim Finden berichtigt werden
und nicht erst am Schluss, da man viele vergessen wird und einige
euch eventuell am späteren Arbeiten hindern werden.

Kommentare, dein Freund und Helfer!
Nicht jede Zeile muss kommentiert werden, aber man sollte seinen Code so dokumentieren,
dass ein anderer ihn ohne viel Nachdenken weiterführen kann.
Man sollte die Kommentare also sozusagen so schreiben, als
wenn man die Dokumentation für jemand anderen erstellen würde.
So könnt ihr euch auch nach längeren Pausen einem angefangenem
Projekt widmen, ohne zu viel Zeit mit dem Einarbeiten zu verbringen.

Leveldesign
Details! Details sind in Maps sehr wichtig, auch wenn sie kaum auffallen,
so machen sie einen nicht unerheblichen Teil der Atmosphäre aus.
Hier und dort ein paar Kleinigkeiten lassen eine sonst kahle Map
schöner aussehen, jedoch nicht übertreiben!

Optimierungen – Renn' geschwind
Diese sollten man am Schluss durchführen, wenn das Projekt soweit steht.
Wer sich gleich zu Anfang den Kopf damit belastet wie man welche Routine
am Performancetesten schreibt, wird kaum das Projekt an sich schaffen.
Erst schreiben, dann optimieren. Oftmals brauch man auch keine
Optimierung vornehmen, wenn das Spiel auch ohne flüssig läuft und
die Optimierung nur unnötig Zeit verschlingt und der nutzen gering ist.

Das Konzept steht geschrieben...
Ein gute ausgearbeitet Konzept zum Anfang eines Projektes ist Gold wert.
Ihr braucht dann nur noch eurem roten Faden folgen und braucht nicht ewig überlegen,
was für Features denn noch rein sollen.
Auch nach längerer Pause könnt ihr so an einem Projekt weiter arbeiten, da ihr
alle Details zum Projekt schriftlich niedergelegt habt.
Auch bei kleineren Projekten hilft es sich die Features aufzuschreiben, denn
auch wenn man voll im Thema drin ist wird man schnell die ein oder andere Kleinigkeit vergessen.

Übermut tut selten gut
Es bringt nichts, sich eine ewig lange Liste von Ideen für ein Spiel aufzuschreiben,
wenn man eh nur ein Bruchteil davon umsetzen kann. Man sollte sich seiner Fähigkeiten
bewusst sein und auch dessen, wie viel Zeit solche Projekte verschlingen.
Je kleiner ihr euch eure Ziele setzt, desto eher könnt ihr sie umsetzen und
das gibt Anreiz weiter zu machen und sich ein etwas höheres Ziel zu stecken.
Das scheitern solcher 'Riesen'-Projekte kostet unnötig Kraft und Aufwand und
senkt die Motivation und schließlich soll es Spaß machen und nicht in einem
Debakel enden.

Klein, aber oho!
Als Erweiterung zum vorherigen Punkt. Macht die Spiele lieber klein,
aber dafür mit Liebe zum Detail.
Große Spiele mit wenig Gefühl bleiben kaum in den Gedächtnissen der Spieler hängen.

TEAM - Toll ein anderer macht's
Viele wollen immer in Teams arbeiten und dann am besten für jeden Bereich einen
eigenen Verantwortlichen. Das wird in den meisten Fällen in die Hose gehen.
Man sollte seine Fähigkeiten so gut es geht erst einmal alleine erweitern.
Denn es bringt nichts wenn man ein Team von Anfängern hat die sich nur gegenseitig
auf die Füße treten, der nutzen tendiert gegen 0.
Auch muss es eine treibende Führungskraft geben, denn ohne gute Leitung wird
das Projekt schnell untergehen, die Motivation ist dahin, das Interesse verfliegt.
Der Leiter muss das Team zusammenhalten.
Ein Team nur über Internet ist den meisten Fällen nicht optimal.
Viel mehr sollte man sich Leute suchen mit denen man sich des Öfteren treffen kann,
das sorgt für gute Stimmung und der Anreiz weiter zu arbeiten steigt.

Abstand nehmen
Falls einem mal die Motivation an einem Projekt schwindet oder einem nicht die richtigen Ideen
einfallen wollen, so macht etwas anderes! Dadurch kommt ihr auf anderen Gedanken, bekommt
neue Motivation, sammelt Ideen. Nach einer gewissen Auszeit hat man dann wieder genug Anreiz
weiter zu arbeiten.

Präsentation
Die Präsentation eines Projektes ist etwas ganz entscheidendes über das man sich am
ENDE Gedanken macht. Es bringt nichts ein Forum, Webseite und pipapo zu einem Projekt
zu erstellen das noch in den Kinderschuhen steckt.
Eine kleine Webseite oder Blog reicht vollkommen aus, um ab und zu den Entwicklungsstand
kund zu tun, dazu muss es erstmal keine groß angelegte Webseite sein.
Auch entscheidet eine gute Präsentation wie erfolgreich euer Projekt wird.
Eine einfach lieblos dahin geworfene Beschreibung und ein Downloadlink sind nicht ausreichend.
Viel mehr sollte man sich mühe geben z.B. hier im Forum eine ordentliche Einleitung machen
zum Beispiel in Form eines Banners fürs Spiel, richtige Formatierung der Schrift (und dessen Inhalt),
Screenshots, eventuell Trailer (meist nur bei größeren Projekten sinnvoll) und einen
oder besser mehrere Downloadlinks.
Es kann immer sein, dass mal einer ausfällt oder besonders lahmt.

Testen! Testen! Testen!
Man sollte sein Spiel bis zum Erbrechen testen bevor man es auf die Öffentlichkeit loslässt.
Nichts nervt mehr als ein Spiel umsonst geladen zu haben, weil am Ende von Level 1 etwas vergessen worden ist raus zu nehmen und man so eine neue Version laden muss, weil man nicht weiter kommt.
Das macht einen ganz schlechten Eindruck.
Auch sollten andere euer Spiel vor der Veröffentlichung testen, damit ihr gegebenfalls auf
Vorschläge reagieren könnt um das Spiel spielenswerter zu machen.
Man hat als Entwickler eine etwas andere Sicht auf die Dinge als ein außen stehender.
Viele Bugs fallen einem auch gar nicht auf beim Spielen, also immer auch
Meinung anderer einbeziehen und es von mehreren Leuten testen lassen.

Toshiro · 30. Mai 2009, 17:48

Schöner Post insgesammt!

Einen Einwand hab ich allerdings:

Defmaster schrieb:

...Optimierungen – Renn' geschwind
Diese sollten man am Schluss durchführen, wenn das Projekt soweit steht.
Wer sich gleich zu Anfang den Kopf damit belastet wie man welche Routine
am Performancetesten schreibt, wird kaum das Projekt an sich schaffen.
Erst schreiben, dann optimieren. Oftmals brauch man auch keine
Optimierung vornehmen, wenn das Spiel auch ohne flüssig läuft und
die Optimierung nur unnötig Zeit verschlingt und der nutzen gering ist...

Ich hab öfter das Problem, dass wenn ich mich nach einer längeren Pause wieder mal an ein Spiel setze, kaum noch weis, welche Variable wofür genau zuständig ist. Oft stellt man während der Entwicklung fest, dass man bestimmte Variablen gar nicht mehr benötigt, vergisst aber an manchen Stellen, sie aus dem Code zu entfernen. Wer erst am Ende der Entwicklung optimiert und alle Codes nach unnötigen Leistungfressern durchschaut, denkt sich vlt: "Naja, für irgendetwas wird die Variable schon zuständig sein, ich weis nur nicht für was. Besser ich lass' den Code so wie er ist."
Ich finde also, man sollte auch immer mal wieder optimieren, wenn man die Zusammenhänge zwischen den Programm-Schnipseln noch in Erinnerung hat. Das ist aber nur meine Meinung.

Defmaster · 30. Mai 2009, 18:45

Es geht darum viel mehr um Optimierungen die bestimmte Routinen verschnellern soll,
weil sie besonders Rechenintensiv sind.

Dafür sind Kommentare da, dass man nicht gebrauchte Variablen entfernt.
Wenn du selber nicht mehr weißt wo für eine Variable steht hast du entweder:
a) den Variablen schlechte Namne gegeben
b) oder nicht gut genug dokumentiert
Was du beschreibst Zähl ich nicht als Optimierung, das ist selbstverständlich.

Und der Punkt das man guckt ob man hier oder da ne Varaible sparen kann,
ist genau der Punkt, was dir kaum nennenswerten Vorteil bringt aber eben unnötigt Zeit kostet
bei der Entwicklung.

Der Punkt ist der, dass man sich nicht mit kinkerlitzchen befassen sollte, sondern
sich auf das wesentliche konzentrieren sollte.

Thodd · 30. Mai 2009, 20:51

Zum Thema Optimierung würde Donald Knuth jetzt sagen:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

Der Mann ist ein Guru, der hat das Programmieren quasi erfunden und wenn der sagt ich soll nicht frühzeitig optimieren dann tut ich das auch nicht.

Schattenphoenix · 8. Juni 2009, 02:32

Und wenn du eine Variable aus unbekanntem Grund nichtmehr zuordnen kannst, kommentier sie aus, teste jedes Level etc. und du siehst was passiert

Ich finds immer schlimm, wenn Leute ihren Variablen undeutliche Namen geben. Schlimm z.B. find ich xx,xxx,xxxxxxxxx, und das selbe mit y... wozu das ganze? Wenn ihr eure Variablen kurz halten wollt, dann nehmt andere Buchstaben und verdoppelt nicht nur, was ihr eh schon habt.

CAS · 8. Juni 2009, 08:58

Schattenphoenix schrieb:

Ich finds immer schlimm, wenn Leute ihren Variablen undeutliche Namen geben. Schlimm z.B. find ich xx,xxx,xxxxxxxxx, und das selbe mit y... wozu das ganze? Wenn ihr eure Variablen kurz halten wollt, dann nehmt andere Buchstaben und verdoppelt nicht nur, was ihr eh schon habt.

Schlimmer soll sein, wenn du - wie hieß das - emotionale Variablennamen vergibst, d.h. wenn du sie "Hund", "Wind", "Liebe", etc. nennst. Wenn du mit jedem Variablennamen irgendwas assoziieren kannst, soll das Debuggen die Hölle sein (vor allem, wenn die Variablennamen nichts mit dem zu tun haben, was sie im Programm bewirken). Hab jemanden gehört, der meinte, er sei mal fast wahnsinnig geworden, weil er sowas debuggen musste.

GML-Quellcode

baum := stamm + ast;

JOhannski · 8. Juni 2009, 12:25

Gefällt mir.

hier noch ein paar ideen, anregungen und meinungen von mir:

Grundengine

Beginne mit der grundengine und kleinen lustigen sprites die noch nicht
final sind. Wenn du mal was spielbares hast mach dir erst Gedanken über
Story, Grafik genauere bewegungsabläufe usw. Ich wollt mal ein ganz
großes spiel machen mit toll story und effekten bis zum umfallen. Ich
hab alles was mir eingefallen is zusammen geschrieben und hatte dann
einfach einen haufen an ideen vor mir die aber komplett durcheinander
waren und ich einfach keinen roten faden hatte. Als nächstes hab ich
mich dann an das von mir so toll geplante intro gemacht.....es hat auch
nicht so schlecht ausgeschaut. Als ich dann die aufwändig gemachten
grafiken in mein kurz programmiertes spiel eingesetzt hab und sich der
spieler nicht bewegt hat weil er noch keine laufanimation hatte, war
ich ziemlich deprimiert weils einfach scheiße ausgeaschaut hat. Sowas
is eine Erfahren die zwar gut is zu machen, einen aber viel zeit und
nerven kostet...

Leveldesign

Hier muss ich noch etwas anmerken

Optimierungen – Renn' geschwind

Diese sollten man am Schluss durchführen, wenn das Projekt soweit steht.
Wer sich gleich zu Anfang den Kopf damit belastet wie man welche Routine
am Performancetesten schreibt, wird kaum das Projekt an sich schaffen.
Erst schreiben, dann optimieren. Oftmals brauch man auch keine
Optimierung vornehmen, wenn das Spiel auch ohne flüssig läuft und
die Optimierung nur unnötig Zeit verschlingt und der nutzen gering ist.

bitte
nicht ganz am schluss...optimiert die renngeschwindigkeit bevor ihr das
leveldesign macht! Klingt dumm sollte man aber auf alle fälle bedenken
*auseigenererfahrungred*

Man wächst mit seinen Aufgaben

mfg johannski

Schattenphoenix · 11. Juni 2009, 13:21

Ich denke, man sollte schon eine Story in etwa haben, damit man sich überhaupt für eine Art entscheiden kann...
Sicher, es gibt viele die sich denken "Hach ich mach jetzt ein JnR" aber eigentlich ist die Story der Kern.

Wenn man ne Story hat, dann sollt man sich überlegen, was dazu passt, wie es am besten rüber kommt.
Eine ausgefeilte Fantasy Story z.B. passt natürlich klassisch zum RPG, allerdings kann sie auch zum JnR passen. Bei einem Strategiespiel ist sie (meinermeinung nach) weniger am richtigen Ort.

Wenn man sich entschieden hat, sollte man sich aufs funktionelle beschränken.
Wichtig finde ich, dass man schaut, was man brauch. Welche Features kommen.
Es ist oft schwerer Features einzubauen, wenn die Engine steht und es einfach nicht mehr reinpasst, weil die Engine nicht flexibel genug ist.

Hiermit zum nächsten Punkt.
Ich denke, man sollte bei seiner Engine ein bisschen ein Auge drauf werfen, dass sie ein gewisses Maß an flexibilität bietet, um hinterher noch erweitert werden zu können.
Bewegungsabläufe nicht zu strikt ablaufen lassen und ähnliches.

Sicher, wenn ich mit meinem JnR Schleim an der Wand kleben kann, dann ist das was feines, aber wenn ich hinterher auch davon abspringen will, aber es nicht eingeplant hatte, dann hab ich vielleicht ein Problem.
Wenn man Gravitation in seinem Spiel hat, aber irgendwann eine Szene hat, wo sie stört und man es nichtmehr hinkriegt, sie abzuschalten, ists auch Mist.

Wenn das Funktionelle steht, finde ich sollte man sich Gedanken machen, was nicht nur man selber können soll, sondern auch, was Gegner können sollen.
Die grundlegene Engine sollte das normale Bewegungsverhalten von Gegnern abdecken, aber hinterher sollte man sich auch um etwas speziellere Sachen gedanken machen.

Hierzu gehören z.B. fliegende Gegner etc.

Wenn alles steht, dann vielleicht mit der Grafik des Spielers anfangen. Im Normalfall ist der Spielercharakter ja der vielseitigste im Spiel, da er einen das ganze Abenteuer durch begleitet.
Also hierfür die Grafiken zuerst.
Hierbei finde ich es wichtig, vorher zu wissen, ob man AlphaKanäle braucht oder nicht.
In pixeligen Spielen à la SNES ist es nicht umbedingt nötig, bei anderen Sachen kann es angebracht sein.
Dementsprechend ist relativ klar, ob man seine Grafiken in der exe lagert oder nicht. Ich bin normalerweise dagegen, es sei denn, es handelt sich um Kleinkram (wie ein Cursor z.B.)

Es gibt nix nervigeres, als einen Charakter zu malen und hinterher zu sehen, dass es grundsätzlich scheisse aussieht, weil die Kanten so eckig sind.
Hinterher ein Antialaising drauf, geht nicht so einfach, wenn ich mich nich grad täusche.

Wenn man die Grafiken des Spielers hat, denke ich kann man mit den Grafiken der ersten Handlungsorte beginnen.
Hierzu gehören z.B. Tilesets für die Welt.
Man sollte sich klare Gedanken machen, was man wirklich will, grade wenn man es nicht selber malen kann und auf Hilfe angewiesen ist.
Es wird sich keiner hinsetzen und 30 Tilesets malen nur weil du dich nicht klar ausdrücken kannst und dir selber nicht sicher bist.

Gegner etc. finde ich sollte man paralell zu den Tilesets machen.
Welt fertig -> Gegner passend machen.

Was ich auch wichtig finde... LEUTE bitte nicht ZU bunte Farben benutzen. Ich hab schon einige Threads gesehen, wo das angesprochen wurde und ich kann dem nur Beipflichten.
In den meisten Fällen ist das nicht angebracht. Ein neongrüner Rasen sieht nicht natürlich und nicht schön aus... besonders dann nicht, wenn er das ganze Bild verdeckt und sich langsam in die Netzhaut brennt.

Soviel von mir, meine 2 cent sind hiermit beigetragen und ich hoffe, ihr könnt was damit anfangen.
Wenn ich absulut falsch denke, belehrt mich =P
Ich hab auch noch kein Spiel fertig gebracht, was daran scheitert, dass ich ein miserabler Grafiker bin. Wenn ichs könnte, würd ich bestimmt auch mal was zaubern um es hier zu Präsentieren.

CAS schrieb:

Schattenphoenix schrieb:

Ich finds immer schlimm, wenn Leute ihren Variablen undeutliche Namen geben. Schlimm z.B. find ich xx,xxx,xxxxxxxxx, und das selbe mit y... wozu das ganze? Wenn ihr eure Variablen kurz halten wollt, dann nehmt andere Buchstaben und verdoppelt nicht nur, was ihr eh schon habt.

Schlimmer soll sein, wenn du - wie hieß das - emotionale Variablennamen vergibst, d.h. wenn du sie "Hund", "Wind", "Liebe", etc. nennst. Wenn du mit jedem Variablennamen irgendwas assoziieren kannst, soll das Debuggen die Hölle sein (vor allem, wenn die Variablennamen nichts mit dem zu tun haben, was sie im Programm bewirken). Hab jemanden gehört, der meinte, er sei mal fast wahnsinnig geworden, weil er sowas debuggen musste.

GML-Quellcode

baum := stamm + ast;

Oh man...
Gut, da sollte man schon schauen, was man tut.
Ich muss nur sagen, dass es einfach verwirrend ist, wenn man 3 Variablen hat, die jeweils aus den identischen Zeichen bestehen und nur die Anzahl anders ist.
x versteh ich... xx kenn ich mitlerweile auch als alternative zu x, z.B. wenn man einen x-Zwischenwert hat. Aber xxx? einmal gesehen und fast verzweifelt beim rausfinden, was es bedeutet.

Dann würde ich zumindest beim ersten Aufkommen einen Kommentar dazu schreiben.