Excellent 
Eins fiel mir aber noch auf; wenn man den Propeller nur kurz antippt (kurz nach oben drücken), fliegt unser kleiner Held aber recht lange. Ist das im Original auch so?
Hallo Besucher, der Thread wurde 94k mal aufgerufen und enthält 568 Antworten
letzter Beitrag von Hucky am
SUPERHERO: Grafik, Ideen und Programmierung
- Retrofan
- Erledigt
-
-
Ich finds erstmal Klasse, das sich der Propelor dreht beim abheben und wieder anhält, und das Verhalten beim Links/Rechts laufen. Ist das ein Motorrad Integralhelm den er aufhat?
Nicht böse gemeint. -
Eins fiel mir aber noch auf; wenn man den Propeller nur kurz antippt (kurz nach oben drücken), fliegt unser kleiner Held aber recht lange. Ist das im Original auch so?
Das ist im Original tatsächlich etwas anders. Unser Anspruch ist allerdings auch nicht, einen 100%igen Klon zu machen, sondern einen Nachfolger. Wir nehmen uns also die Freiheit, das eine oder andere Detail zu verändern, solange dabei (unserer Meinung nach
) ein schönes Spiel herauskommt. -
Toll
.Aber: Warum wird der Propeller beim Laufen kürzer? Bzw.: Beim umdrehen müsste er ja ggf. optisch vorübergehend kürzer und dann wieder lang werden. Je nachdem. Und die Reflexion auf dem Helm sieht irgendwie falsch aus. Ich würde mich da für eine Seite entscheiden (also nicht als Reflexion. Aber ich glaub', die Diskussion gab es schon...).
Weitermachen
. -
Das macht schon was her!
Dieses ruckartige aufsteigen könnte jedoch problematisch werden, wenn man in den späteren Levels pixelgenau von den roten Wänden manövrieren muss. -
Warum darf der Propellor sich nicht leicht drehen wenn er gelandet ist wie im Original? Der läuft halt leicht nach, ist doch nicht unrealistisch. Was das ruckartige Aufsteigen betrifft, im Original ist er auf den Wasserplatformen derart träge das du das vorher timen musst. Sollte auch mal angemerkt werden.
-
Warum darf der Propellor sich nicht leicht drehen wenn er gelandet ist wie im Original? Der läuft halt leicht nach, ist doch nicht unrealistisch.
Da bin in auch 'pro'. Fand ich auch beim Original ganz nett. Ist sicherlich wohl machbar (mit Arbeit verbunden natürlich), aber wohl auch nur ein (späteres?) i-Tüpfelchen (wie auch schon mein kurz/lang-Propeller, der damit aber auch gleichzeitig erledigt wäre), wenn es sonst nix mehr zu tun gibt.
-
Übrigends kackt das Original H.E.R.O. (Diskette) in Vice und CCS64 ab. Original Activision (Tape) bekomm ich erst gar nicht geladen, das von Firebird scheint stabil bis jetzt...
-
Die Original Disk-Version ist im 1. Level auch nicht identisch zur Tape Version.
-
Klasse.
Ich bin allerdings eben innerhalb der blauen Fläche direkt auf den Steinen geland und konnte nicht mehr links oder rechts laufen. Nur noch abheben.
Kann es leider nicht reproduzieren
-
Hi
Echt Klasse Arbeit. Für mich ist die Steuerung OK. Da freue ich mich auf das fertige Spiel.
Gruß Drachen
-
Aber: Warum wird der Propeller beim Laufen kürzer?
Ich muss sagen, gerade dieses winzige Detail finde ich im ersten Antesten besonders gut. Gibt dem ganzen eine Spur mehr Dynamik in der Animation, so als würde der Oberkörper noch etwas eindrehen beim Loslaufen.
-
Ich bin allerdings eben innerhalb der blauen Fläche direkt auf den Steinen geland und konnte nicht mehr links oder rechts laufen. Nur noch abheben.
Ja, den Bug kenne ich.
Aber immer, wenn ich ihn fixen wollte, konnte ich ihn auch nicht reproduzieren... Steht auf der TODO-Liste.
Echt Klasse Arbeit. Für mich ist die Steuerung OK. Da freue ich mich auf das fertige Spiel.
Danke! Das motiviert!
-
Warum wird der Propeller beim Laufen kürzer?
Das ist Absicht. Im Stand gebe ich dem Rotor die volle Breite, damit er z.B. auf Screenshots oder beim längeren Betrachten in voller Größe erscheint (er ist ja ohnehin sehr klein für den großen Mann). Im Lauf sah es für mich aber dynamischer aus, ihn in 45°-Stellung zu bringen. Und ich dachte mir, warum soll sich der Rotor in der Bewegung nicht leicht verdrehen können.
Das Verhalten wollen wir eigentlich auch nicht mehr unbedingt ändern. Beim original Roderick wurde das 2. Sprite mit der 4. Farbe alleine für den Rotor verwendet, wodurch er unabhängig vom Rest bewegt werden kann. Wir hingegen verwenden 4 Farben im ganzen Roderick, wodurch das 2. Sprite in den Animations-Prozess integriert ist. Man könnte versuchen, die Rotor-Drehbewegung mit der Laufanimation zu synchronisieren (und sie fest in den Sprites zu "verdrahten") aber da man fast jederzeit (im 8-Pixel-Raster) den Lauf stoppen kann, gäbe es nicht immer einen sauberen Übergang zu einer Rotor-Bewegung beim stehenden Roderick.
Mich hat es schon früher gestört, dass sich der Rotor beim Original immer bewegt und sich nur die Geschwindigkeit ändert. Von daher ist es jetzt eigentlich so, wie ich es haben wollte. Ich kann versuchen, da mal dran herumzubasteln, um Alternativen zu sehen aber im Prinzip bin ich zufrieden mit dem Status.
Die Original Disk-Version ist im 1. Level auch nicht identisch zur Tape Version.
Was ist denn da anders?
Ich bin allerdings eben innerhalb der blauen Fläche direkt auf den Steinen gelandet
Doof, wir dachten, der Bug sei endgültig raus. Danke für die Rückmeldung.
------
Für die, die das PRG nicht starten wollen oder können, habe ich ein kleines Video aufgenommen:
[Externes Medium: https://www.youtube.com/watch?v=M1onnXwVyTU] -
Dass der Rotor beim Laufen kuerzer wird, sieht wirklich ein bisschen seltsam aus, aber naja, gibt Wichtigeres.
Das sofortige Abheben bei 'oben' ist zwar praktisch, aber HERO mochte ich allerdings besonders dass man durch gutes Timing ueber Abgruende hinweglaufen konnte, gerade weil man das sehr praezise steuern konnte
Das seichte Abfangen beim Fallen warfuer mich eine der Hauptsteuerelemente. Das faellt hier weg. Muss ja auch nicht bleiben, gefiel mir aber immer am besten.
Wenn man jetzt kleine Schritte macht, nickt der Kopf immer - mir ist schon klar woher das kommt, aber vielleicht baut man diese anim erst nach mehr als einem minimalen Schritt ein?
Der Rotor beginnt sich zu drehen wenn man faellt, das ergibt nicht soviel Sinn.
Die Laufgeschwindigkeit empfinde ich als sehr angenehm so. -
Beim original Roderick wurde das 2. Sprite mit der 4. Farbe alleine für den Rotor verwendet, wodurch er unabhängig vom Rest bewegt werden kann.
Das könntet Ihr ja auch machen, indem Ihr direkt in das im nächsten Schritt angezeigte Sprite zeichnet, oder?
-
Dass der Rotor beim Laufen kuerzer wird, sieht wirklich ein bisschen seltsam aus
Alternativ wäre es kein Problem, ihn in vollen Breite zu zeigen. Vielleicht ändere ich das.
Das sofortige Abheben bei 'oben' ist zwar praktisch, aber HERO mochte ich allerdings besonders dass man durch gutes Timing ueber Abgruende hinweglaufen konnte
Genau das geht sehr gut – wie du in dem von mir aufgenommenen Video sehen kannst.
Das seichte Abfangen beim Fallen warfuer mich eine der Hauptsteuerelemente. Das faellt hier weg.
Das werde ich mir noch genau ansehen und vielleicht können wir davon noch was übernehmen. Was die vertikale Bewegung angeht, sind wir vielleicht noch nicht ganz am Ende.
Der Rotor beginnt sich zu drehen wenn man faellt, das ergibt nicht soviel Sinn.
Er fällt ja nicht – sondern fliegt so schnell herunter, wie er auch herauf fliegen kann. Wenn er mit ausgeschaltetem Rotor fallen würde, wäre die "Landung" sicherlich unangenehm.
Das könntet Ihr ja auch machen, indem Ihr direkt in das im nächsten Schritt angezeigte Sprite zeichnet, oder?
Das wäre natürlich eine Option – wenn auch schon etwas herausfordernd. Man könnte den Rotor aus den Sprites herauslassen und dann während der Animation on-the-fly in die Sprites hinein-malen. Ich denke, falls wir sowas machen würden, dann ganz am Schluss.
-
Alternativ wäre es kein Problem, ihn in vollen Breite zu zeigen. Vielleicht ändere ich das.
Man könnte den Rotor aus den Sprites herauslassen und dann während der Animation on-the-fly in die Sprites hinein-malen. Ich denke, falls wir sowas machen würden, dann ganz am Schluss.
Wenn man schon on-the-fly malt, dann könnte man die Ruhestellung doch auch per Zufall steuern, so daß er mal länger mal kürzer zu sehen ist.
-
Das wäre natürlich eine Option – wenn auch schon etwas herausfordernd. Man könnte den Rotor aus den Sprites herauslassen und dann während der Animation on-the-fly in die Sprites hinein-malen. Ich denke, falls wir sowas machen würden, dann ganz am Schluss.
Das am Ende zu machen ist sinnvoll - erst mal die wichtigen Features implementieren, dann am Ende schön machen. Der Aufwand sollte sich allerdings in Grenzen halten: situtationsabhängig 3 Bytes lesen und ins richtige Sprite schreiben...
