lytron hat geschrieben:
Oh, bist du wirklich so konstant daran am Arbeiten? So wie ich es verstanden hatte, war das Projekt für eine lange Weile dadurch ausgebremst, dass kein Grafiker da war.
Wenn ich mal so neugierig sein darf: Womit hast du die meiste Zeit verbracht? Soweit ich weiß hast du dir eine grundsätzliche Engine gebastelt, mit der du dir den üblichen Blödsinn ersparst, immer wieder zu schreiben (DMA-Helferlein, um mal das Banalste zu nennen).
Hast du die meiste Zeit diese Engine weiter ausgebaut, um es den geplanten Features anzupassen, oder ging die meiste Zeit wirklich für das Implementieren der Spieleinhalte drauf?
Bei so einem Projekt fällt mehr Arbeit an, als du dir vielleicht vorstellen kannst.
Nicht nur Engine und das Spiel selbst, sondern auch eine große Menge an Tools wollen geschrieben werden:
Grafikkonverter (Generierung von optimierten Spritelisten usw.), Supportskripte für Übersetzung, Tools zum Generieren von HDMA-Listen für Effekte, Werkzeuge zur Datenkomprimierung etc. etc.
Selbst Compiler (Bugfixes, erweiterte Debug-Ausgabe) und Emulator (Emulation von Spezialhardware im Modul) musste ich schon anfassen.
lytron hat geschrieben:Nächste Frage: Musstest du viel "zurückbauen", oder ist es selten/nie vorgekommen, dass irgendwas komplett rausreißen und von vorne machen musstest?
Kaum bis gar nicht.
Getreu dem Motto
"Vielleicht" lässt sich nur schwer programmieren implementiere ich das, was konkret besprochen, definiert und durchdacht ist.
Ein Spiel zu entwickeln ist aber letztlich in vielen Fällen auch ein iterativer Prozess, bei dem fortlaufend Dinge ausprobiert, verändert und ggf. auch verworfen werden müssen, falls sie keinen Spass machen.
Hier hilft es, das System zuerst auf eine solide Basis zu stellen und dann die Kommunikations/Interaktionsmöglichkeiten zwischen den Objekten im System generisch genug zu halten, sodass man sich möglichst wenig verbaut, andererseits das Ding aber auch schnell genug hält und nicht durch unnötige Abstraktionsebenen verlangsamt.
Das ist insbesondere auf der ziemlich langsamen SNES-CPU ne Gratwanderung, die man mit Erfahrung am besten hinbekommt.
Ein großer Vorteil ist natürlich, dass wir gameplaytechnisch das Rad nicht neu erfinden müssen, sondern auf Jahrzehnte von Videospielen zurückblicken können und somit eine ziemlich genaue Vorstellung davon haben, wie sich unser Spiel anfühlen muss.
lytron hat geschrieben:
Nächste Frage: Ist es regelmäßig vorgekommen, dass deine Tage an dem Projekt vor einem blanken Collegeblock mit einem "wie verschachtel ich das bloß am Sinnhaftesten?" verliefen? Eine Frage, die ich aus persönlicher Erfahrung stelle.

Vielleicht am Anfang und bei der Performance-Optimierung, aber der Großteil der Arbeit am Spiel selbst hat eher was von "Teile aus einem Baukasten zusammenstecken".
Ich habe eine monströse, nach Priorität geordnete Todo-Liste (allerdings digital) und die arbeite ich Schritt für Schritt ab.
Das hilft mir, fokussiert zu bleiben und nicht den Überblick zu verlieren.
lytron hat geschrieben:
Letzte Frage: Gibt es bei dem Feintuning auch einige Sachen, wo du sagen musst: "Das geht jetzt nicht mehr." Ich weiß ja selbst, dass eine an sich kleine Änderung technisch gigantische Änderungen im Code erfordern kann, und dass das Feintuning demnach unerträglich lästig sein kann. Oder konntet ihr alles soweit im Voraus planen, dass es nicht zu solchen unangenehmen Vorfällen kam?
Ich erinnere mich nicht daran, wann ich das letzte mal "geht nicht" zu einem Feature gesagt habe.
Sehr oft habe ich aber Änderungsvorschläge gemacht, um Features mit dem geringstmöglichen Aufwand einbauen zu können.
Wie oben geschildert habe ich das System so aufgesetzt, dass ich mir möglichst wenig verbaue.
Da hilft Planung und Erfahrung. Von Details abgesehen ist das Konzept unverändert geblieben.
lytron hat geschrieben:
d4s hat geschrieben:Grundsätzlich ist alles da, aber bei den Grafiken muss noch an einigen Stellen nachgearbeitet werden.
So im Stile von "Die Palette für das Tileset passt zu dem Zeitpunkt nicht in den CGRAM, pass das mal an." und "Diese Grafik braucht ein paar zu viele Tiles, mach es etwas kleiner!"?
Es geht hauptsächlich um Ästhetisches.
Welche Elemente welche Paletten verwenden und wieviele Tiles Hintergründe haben können haben wir bereits in der Planungsphase festgehalten, sodass es dort keine unangenehmen Überraschungen gab.
Grundsätzlich ist das System hier aber auch in gewissen Grenzen tolerant.
Objekte mit identischer Palette auf dem Screen teilen sich diese logischerweise, nicht essentielle Dinge (Effekt-Sprites, kleine Cannon-Fodder-Gegner) werden nicht erzeugt/geladen/animiert, falls Videospeicher, Farbspeicher oder die Transferbandbreite momentan nicht ausreichen.
Optimierung der Anzahl der Tiles für Sprites und Hintergründe wird auch automatisch von den Konvertierungstools erledigt.