lytrons Fragerunde - Spezialchips, Homebrews und mehr :P

[lytron]

Da das hier ja eh meine Plunderecke ist...


Spielidee! Spielidee! Spielidee!

Ich habe gerade überlegt, wie man für das SNES ein gutes 2-Player-Game machen kann.

Eins, das richtig Spaß macht.

Wo man co-open muss.

Wo man ohne Miteinander-Reden nicht weiterkommt.

Und dann fiel mir Recoil ein. Kennt ihr Recoil?

versteckter Inhalt:

61IZfBhuyUL__AA300_.jpg (21.91 KiB) 6005 mal betrachtet

recoil1.jpg (58.98 KiB) 6004 mal betrachtet

Das war ein Game für den PC, irgendwann im vergangenen Jahrtausend. Man steuerte einen SciFi-Panzer durch ein SciFi-Battlefield. Alle gegen einen. Solches Zeuch.

Bei dem Spiel (von dem ich damals nur die Demo mittels PC-Games spielen konnte, und die ich (12) und mein Bruder (16) damals als Bockschwer empfanden) steuerte man mit der Tastatur den Panzer ansich, während man mit der Maus den Geschützturm steuerte. Da ich normalerweise kein Freund von Action-Games bin (ich habe keine Neigung zu Krieg und Geschicklichkeit), war das das einzige Mal, dass mir bisher eine solche Steuerung begegnet ist, und so sehr es auch gedauert hat, bis ich mit selbiger umgehen konnte, so einnehmend war auch das Feeling, wenn man endlich damit klarkam.

Kam mir jetzt die Idee:
Selbiges auf dem SNES. Spieler eins bekommt einen Controller und steuert den Panzer, Spieler zwei hat die Maus und steuert den Geschützturm. Alles mit chicem Mode 7/SFX-Grafik und Metal-Slug-Ästhetik.

Warum ich das nicht umsetzen werde:
Weil: Mode 7. Oder SFX. Beides gleich schlimm. Außerdem habe ich keine Ahnung, wie ich es halbwegs Prozessor-erträglich programmieren soll, ob ein Gegnersprite jetzt auf dem Bildschirm sichtbar sein sollte oder nicht.

Aber die Idee bleibt. <3

[lytron]

Spielidee! Spielidee! Spielidee!

firefighter.png (7.8 KiB) 5997 mal betrachtet

Fire Fighters
Noch ein 2-Player-Game.
Feuer ist da, Feuer muss gelöscht werden, Feuer breitet sich aus.
Zwei Feuerwehrleute müssen löschen.
Ein "Kessel" mit Löschwasser steht bereit.
Die Herausforderung besteht darin, dass genug Druck auf dem "Kessel" sein muss, damit gelöscht werden kann. Folglich muss unten einer stehen und pumpen. Wenn man zu viel pumpt, explodiert der Kessel. Der Druck baut sich auch langsam von selbst ab. Es kann nicht immer nur einer unten stehen und pumpen, da beide Feuerwehrmänner (in den späteren Leveln?) zu unterschiedlichen Teilen der Stage gelangen können und somit beide aktiv werden müssen, um den Brand in den Griff zu bekommen.

Weil: Hätte man ein Zwei-Spieler-Spiel, bei dem einer nur Trac&Field-mäßig Button Mashing machen muss, während der andere den ganzen Spaß hat, wäre es besser, ein Ein-Spieler-Spiel draus zu machen.

Werde ich nicht umsetzen, weil: Keine Lust.

[lytron]

Spielidee! Spielidee! Spielidee!

Zwei-Spieler-Spiel.
Rechts, ein Spieler, eine Variante von Tetris.
Links, ein Spieler, bekommt einen "in etwa" Tetris-Stein, der aus 2 oder 3 statt 4 Klötzchen besteht. Er muss den Stein von oben nach unten steuern. Unten ist die "Warp-Zone". Der Stein, der die Warpzone erreicht, wird dem Spieler rechts zur Verfügung gestellt.

Der linke Spieler muss auf seinem Weg von oben nach unten mehreren Bällen ausweichen, die horizontal fliegen. Trifft eine dieser Kugeln seinen Stein, bekommt der Stein an dieser Stelle ein zusätzliches Klötzchen - je schlechter der Spieler links manövriert, desto mehr muss der rechte Spieler managen.

Wenn der rechte Spieler einen Stein hat, bekommt verlässt der Stein links nicht die Warp Zone bis zum Zeitpunkt, an dem der rechte Spieler seinen aktuellen Stein verbaut hat. Hat links noch kein Stein die Warpzone erreicht, hat der rechte Spieler logischerweise keinen Stein zum Verbauen, was auf Dauer kritisch ist, da in der rechten Bildschirmhälfte von unten Steinreihen nachrücken.

[lytron]

Spielidee! Spielidee! Spielidee!

Kullerbahn.png (7.9 KiB) 5984 mal betrachtet

Kullerbahn

Es rollen Bomben über eine Kullerbahn.

Spieler 1 (Joypad/Maus) muss darauf achten, dass die Bomben zur "Entschärfungsstelle" rollen. Es dürfen keine zwei Bomben aneinanderprallen. Es gibt dazu einzelne Schotte, die geschlossen sind. Am Rande jedes Schotts sind 4 Buttons, von denen eine beliebige Anzahl und Auswahl leuchtet. Um das Schott zu öffnen, muss man die leuchtenden Buttons drücken. Danach öffnet sich das Schott für eine Weile und schließt wieder - und von Neuem leuchten Buttons.
Des weiteren gibt es die Möglichkeit, statt die Bomben konstant nach unten zu leiten, mittels Seitenweg und Sprungfeder die Bomben wieder nach oben zu befördern, wobei die Gefahr dadurch entsteht, dass "zu viele Kugeln im System" sind.

Die Bahnen sind von Level zu Level verschieden.
Als Sonderregelung kann man den Mauszeiger in zwei Geschwindigkeiten bewegen. Beim Controller muss man die L-Taste gedrückt halten, bei der Maus die rechte Taste, damit der Mauszeiger sich langsamer bewegt - auf diese Art und Weise kann man schnell über das Spielfeld huschen, aber gleichzeitig auch die vergleichsweise kleinen Schott-Knöppe treffen.

Spieler 2 spielt mit Controller; er muss die Bomben entschärfen. Keine Ahnung, wie er das macht. Meine erste Idee war, innerhalb von kurzer Zeit eine 10-teilige Tastenkombination eingeben. Eine andere Idee war, dass jede Bombe (je nach Farbe) eine andere Art der Entschärfung hat. Wobei mir da ein bisschen die Ideen ausgegangen sind, aber das macht nüchts.

Eine weitere Idee wäre gewesen, dass es gewisse Hindernisse in der Kullerbahn gibt (z. B. zwei Klappen, die direkt nebeneinander), die von Spieler 2(!!!) per L-/R-Taste gesteuert wird. Das fördert die Kommunikation.

[lytron]

Spielidee! Spielidee! Spielidee!

Restaurant-Jongleur

Bildschirmaufbau:
Oberste Reihe: Gäste-Slots (12?)
Darunter: (Bestell-Slot,) Empfang-Slots (8?)
Darunter, mit viel Abstand: Wurf-Slots (soviele wie Empfang-Slots)
Darunter: Gericht-Slots
Darunter: Küchenslots

Ein Spieler ist der Küchen-Jongleur, der andere Servierer.
Einfache Sache. Der Küchen-Jongleur kann seinen Cursor nur in den Wurf-Slots bewegen. Er hat ein Gericht in der Hand, beim Drücken von A oder B wirft er das Gericht in die "Luft". Das Gericht bewegt sich vertikal, bis es den Zenit seines Wurfs exakt in der Mitte des korresponiderenden Empfang-Slots erreicht und wieder runterfällt.
Dummerweise wird, sobald der erste Wurf gestartet wird, dem Cursor sofort ein neues Gericht zugewiesen (das aus dem ganz linken Gericht-Slot, der Rest rückt dann einen auf).
Das passiert solange, bis sich 3(/4?/5?/6?) Gerichte im Flug befinden. Ist der Cursor des Spielers nicht im richtigen Slot oder ist der Cursor durch ein anderes Gericht belegt, wenn ein Gericht seinen Fall "beendet", oder prallen zwei Gerichte im Wurf aufeinander (zwei im selben Slot hochgeworfen), verliert man eins seiner drei Herzen.
Man hat die Möglichkeit, das Gericht, dass sich gerade im Cursor befindet, mittels Y-Knopf (oder L- und R-Taste) zu tauschen: Dabei wird das aktuelle Gericht auf den ganz rechten Gericht-Slot gestellt, der Inhalt des ganz linken Gericht-Slots wandert in den Cursor und der Rest rückt einen nach links auf.

Der Servierer kann sich nur in den Bestell-Slot, Gäste-Slots und Empfang-Slots bewegen. Ein Gast erscheint in einem der Gäste-Slots.
Im Gäste-Slot liegt ein Zettel - eine Bestellung. Währenddessen erscheint über dem Gast eine Sprechblase mit dem Gericht, dass er sich wünscht.
Die Bestellung nimmt man und tut sie in den Bestellslot. Der Zettel wandert dann automatisch am linken Rand des Bildschirms abwärts in die Küchen-Slots. Dort verwandelt sich der Bestellzettel mit Ablauf einer gewissen Zeit automatisch in ein Gericht. Dieses wandert dann in einen der Gericht-Slots.
Wenn ein Gericht im Zenit des Wurfs des Jongleurs steht, kann der Servierer es im Empfangsslot "abgreifen" und einem Gast vorsetzen. Anschließend kann es passieren, dass der Gast noch etwas bestellt, oder geht. Falls er geht, muss man das schmutzige Geschirr nehmen und in den Bestell-Slot stellen, dass es in die Küchenslots eingereiht und schlussendlich gereinigt wird.

Die Gäste werden missgestimmt, wenn man sie zu lang warten lässt oder ihnen das falsche Essen vorsetzt. Geht zu viel falsch, verlassen sie wutschnaubend das Restaurant (= den Gäste-Slot). Und nehmen eins der drei Herzen mit.

Warum ich denke, dass das Spaß macht:
Weil bestimmt der eine Spieler ganz häufig zum anderen sagt: "Ich brauche zweimal Spaghetti, schnell!"

[lytron]

Bitte lasst jetzt trotzdem diesen Thread leben und schließt denhier nicht ab, wie man oben sieht nutze ich den noch für allerlei andere "Projekte".

[lytron]

Nachwuchs, Nachwuchs!




Und jetzt, lasst uns die Positive-Energy-Heuschrecken des Internets sein und kleistern wir diese Videos mit freundlichen Ermutigungen und warmen "Herzlich Willkommen"s zu, weil...

... je mehr Südamerikaner für das SNES programmieren, desto weniger muss ich hier für Entertainment sorgen.

[lytron]

Eine Idee, in den Äther hinein...

Thema: Collision Map.

Eine reguläre Collision Map, wie ich sie in meiner RPG-Engine eingebaut habe, ist recht speicherintensiv, also könnte man ja mal eine andere Methode wählen...
eine wäre natürlich, die Collision Map zu komprimieren und innerhalb des RAMs (irgendwo da, wos keiner sieht, ich meine zwischen $7E2000 und $7FFFFF) zu dekomprimieren.

Oder, kam mir gerade die Idee, man schreibt zwei aufsteigende Listen. Die eine Liste ist für die begehbaren, die andere für die nicht-begehbaren Tiles. Es wird jeweils nur *das erste Tile* der Reihe benannt, die nachfolgenden Tiles haben dieselbe Eigenschaft, bis in der anderen Liste ein entsprechender Eintrag ist. Was meine ich?

Beispiel:
Begehbar: $00, $08
Nicht begehbar: $04, $0A

Ergibt:
Begehbar: $00, $01, $02, $03
Nicht begehbar: $04, $05, $06, $07
Begehbar: $08, $09
Nicht begehbar: $0A...

Der Abgleich erfolgt dann folgendermaßen: Die zu-untersuchende Tile-Adresse wird genommen (das ist, z. B. beim Hoch gehen, aktuelle Adresse minus $20, beim rechts gehen plus eins etc.) und mit einer der Listen abgeglichen, bis in der Liste ein Eintrag gefunden wird, der größer ist. Dann wird der vorherige Eintrag genommen. Beisipiel: Zu untersuchen ist $07.
Er geht die Begehbar-Liste ab, bis er auf $08 stößt. Dann nimmt er den vorherigen Eintrag. Das ist $00.
$00 wird zwischengespeichert.
Den gleichen Abgleich führt er mit der zweiten Liste ab. Er bliebt bei $0A stehen, geht einen zurück und speichert $04 zwischen.
Jetzt führt er einen Abgleich zwischen den beiden durch. Da $04 größer ist, gilt für $07 dasselbe wie für $04. Und das ist nicht-begehbar.

Zur Optimierung des ganzen könnte man ihn die Listen nicht in der richtigen Reihenfolge absuchen lassen, sondern "immer die Mitte der noch zu untersuchenden Spanne" testen lassen.
Heißt: Bei 20 Einträgen untersucht er zuerst den zehnten, in Abhängigkeit davon untersucht er als nächstes entweder den fünften oder den fünfzehnten usw.

PRO:
- In der Masse sicherlich speichersparend

CONTRA:
- Rechenintensiv
- Wird derartig schwer, events in die Collision Map einzubauen

~~~

Praktikabler wäre sicherlich die Idee, die Tilemap im RAM zeichnen zu lassen.
Für soetwas könnte man dann etwas schreiben, dass auf 3-Byte-Befehle reagiert:
Befehl, Inhalt, Länge.
Befehl ist, z. B.: Schreibe, komplementiere oder beende die Subroutine.
Inhalt ist das, mit dem Geschrieben oder das Komplement gebildet wird, Länge ist die Menge der Loops, die es zu durchlaufen hat.
Und jetzt kommt der Clou: Man könnte sich z. B. im Befehls-Byte die untere Hälfte der Werte ($00 bis $7F) für spezielle Schreibbefehle vorbehalten.
Z. B. ist $01 das reguläre schreiben, bei $02 wird nur jedes zweite Tile beschrieben, bei $03 nur jedes dritte usw. Auf die Art und Weise kann man nämlich $20 schlicht vertikal "zeichnen".
Nach Ende dieser Subroutine kann man dann einzeln die Spezialfälle hineinstippeln (z. B. per Subroutine, die 2-Byte- oder 3-Byte-Befehle frisst, wahlweise ein Inhalt-AdresseLowByte-AdresseHighbyte, oder Inhalt-SchrittweiteVomLetztenStippelpunkt).

Wäre mal mehr drüber nachzudenken.

[Svambo]

Falls dir 128 unterschiedliche Tiles reichen, nimm doch einfach ein Bit für begehbar / nicht begehbar ... grad mal so als Idee...
Und wenn es 256 Tiles sein sollen, sortier die doch. Alle Tiles<$xx sind begehbar, Tiles >=$xx sind nicht begehbar.

[lytron]

Falls dir 128 unterschiedliche Tiles reichen, nimm doch einfach ein Bit für begehbar / nicht begehbar ... grad mal so als Idee...
Und wenn es 256 Tiles sein sollen, sortier die doch. Alle Tiles<$xx sind begehbar, Tiles >=$xx sind nicht begehbar.

Speichermäßig sicherlich eine gute Idee, allerdings hieße das, man müsste jeden einzelnen Tilemap-Eintrag nochmal einzeln anpacken (nämlich, um alle Most Significant Bits zu clearen), bevor man den Kram in den VRAM schmeißt.
Die zweite Methode macht sicherlich Sinn, könnte aber auch wieder bei komplexeren Sachen unbequem werden (z. B., wenn man eine Brücke hat, unter der man hergehen kann und über die man laufen kann).

Aber danke für die Anregungen, du hast mir neue Impulse zum Grübeln gegeben.

[Farbauti]

...nimm doch einfach ein Bit für begehbar / nicht begehbar ...

Diese Stati für die Tiles werden warscheinlich wirklich nur für den Anfang reichen.
Lytron meinte ja schon das Brücken und sowas schwer damit abzubilden werden.

Das könnte man vielleicht auch noch irgendwie durch Events lösen, die die Priority der Brückentiles hochschrauben und die Begehbarkeit switchen.

Für etwas coolere Sachen müssen dann aber definitiv mehr Stati her. Mir fallen da spontan die schräg verlaufendenden Tiles wie z.B. die großen Steine oder Zäune bei LoZ - Link to the past ein. Die sind ebend zur hälfte begehbar und zwar so, dass wenn man drauf zu latscht man plötzlich schräg dran vorbeiläuft.

Eine wirklich praktikable Idee habe ich jetzt auf Anhieb für das Problem nicht aber ich denke es ist noch der ein oder andere Impuls für Lytron dabei ;D

[lytron]

Eine wirklich praktikable Idee habe ich jetzt auf Anhieb für das Problem nicht aber ich denke es ist noch der ein oder andere Impuls für Lytron dabei ;D

Öh, eine galante Lösung für das Diagonal-Gehen war mir bisher noch nicht eingefallen, das Thema war eher ein Rosettenschmerz.

Weil:
Ich schätze/befürchte, man müsste dann noch einen Trigger/Check in der Handle-DPad-Signale-Subroutine einbauen, die sagt: "Wenn dieses Lämpchen glüht (= dieser Bit gesetzt ist), veränder nicht nur x, sondern auch y".
Wahrscheinlich müsste man da auch noch etwas differenzierter heran gesehen, ob jetzt, wenn y zunimmt (also: wir nach unten gehen), x zunehmen oder abnehmen soll (also: schräg rechts oder schräg links).

Desweiteren müsste man wahrscheinlich rund um die Diagonal-Geh-Einträge auf der Collision Map auch noch Reset-Einträge machen, die diese "Lämpchen" löschen, damit die Figur wieder richtig geht. Und dann gilt es zu bibbern, dass der Betatester of Death nicht eine Möglichkeit findet, an den Collision-Map-Einträgen vorbei zu segeln und das ganze schöne Game über nur noch diagonal zu gehen...

... davon Videos aufzunehmen und einen per Youtube zum Gespött zu machen.

[ChronoMoogle]

Ich empfele, Geiger mal vorsichtig anzuschreiben. Der hat CT meines Wissens nach quasi komplett disassembled und kann vll was zu der Loesung innerhalb dieser Spielengine sagen.
Muesste man da nicht auch bei dem Zelda disassemble ein paar Tipps finden koennen?
Oder stelle ich mir das gerade alles zu simpel vor mit der Kompatibilitaet von Abfragen innerhalb unterschiedlicher Engines?

[lytron]

Ich empfele, Geiger mal vorsichtig anzuschreiben. Der hat CT meines Wissens nach quasi komplett disassembled und kann vll was zu der Loesung innerhalb dieser Spielengine sagen.

Ich glaube, derartiges begegnet mir auch bei Ihatovo Monogatari.

Wobei ich mir da gerade nicht sicher bin, ob an einer entscheidenden Stelle nicht einfach ausgelöst wird, dass sich die Figur acht Pixel in die eine und danach acht Pixel in die andere Richtung bewegt, also schlicht nur zwei Schritte nach einander ausgelöst werden.

Wo wir gerade beim Thema sind: Die Spielfigur bei selbigem Spiel bewegt sich auch auf einem 8x8-Pixel-Raster, was die Bewegungsengine sicherlich um ein vielfaches erleichtert, im Vergleich zu CT, SoM, Zelda und Konsorten. Aber dazu an anderer Stelle mehr.

Ratet mal wo! Ratet mal wo!

[Farbauti]

Ich schätze/befürchte, man müsste dann noch einen Trigger/Check in der Handle-DPad-Signale-Subroutine einbauen, die sagt: "Wenn dieses Lämpchen glüht (= dieser Bit gesetzt ist), veränder nicht nur x, sondern auch y".
Wahrscheinlich müsste man da auch noch etwas differenzierter heran gesehen, ob jetzt, wenn y zunimmt (also: wir nach unten gehen), x zunehmen oder abnehmen soll (also: schräg rechts oder schräg links)

Das wäre meiner Meinung nach sehr unklug. Damit vermischt du Logik der Kollisionsabfrage mit der des Eingabehandlings.
Sowas sollte viel eher in der "Kollisionsengine" abgehandelt werden. Dann hast du auch alle Teile die zu einem Thema gehören zentral an einer Stelle und hast beim debugging/erweitern etc. nicht das Problem Dinge suchen zu müssen oder noch viel schlimmer zu vergessen das sie überhaupt existieren