Technik-Diskuss

[Cherry]

Techink-Diskuss

In diesem Thread soll gefachsimpelt werden. Und zwar richtig. Das heißt, dass ein bisschen Fachwissen da sein sollte, damit der Thread nicht in "Was ist ein Switch?!"- und "w00t???"-Orgien ausartet. Den selben Thread haben wir im Quartier, und ich denke, dem Atelier schadet es nicht.

Fangen wir mal mit einem ersten Thema an:

In Kirby - Nightmare in Dreamland (GBA) gibt es ein Minispiel, das heißt glaub ich "Kirby's Kufengrind" oder so (kein Scherz!). Da muss man gegen 3 Computer-Spieler in einer Art Rennen gewinnen. Das ganze passiert auf einer Art Röhre (Regenbogen?), die schwarze Stellen enthält. Um Speed zu gewinnen, muss man mit "A" "grinden" (so heißt das). Grindet man auf einer schwarzen Stelle, verliert man stark an Speed, ein "!" erscheint. Man verliert aber auch Speed (nur nicht so stark), wenn man zu lange nicht grindet. Wenn man genau dann, wenn das Schwarze endet (nicht später), wieder auf "A" drückt, um weiterzugrinden, dann steht da "PRIMA" bzw. "SUPER" und man hat den vollen Speed wieder. Für "PRIMA" oder "SUPER" gibts auch Punkte.

Das Game macht mächtig Spaß und würde sich sicher auch in einem RM-Game gut machen.

Hier ein paar Screens:





Nun, kann man das im Maker umsetzen (ich denke jetzt vor allem an den 2k(3), mit dem XP dürfte es ja nicht soo schwer sein)?

Am Schwierigsten sind ja folgende Sachen:

• Die "Röhre", auf der man grindet, ist ja nicht gerade. Man muss dem Maker also irgendwie sagen, an welcher Y-Position die Figur dazustellen ist, wenn sie sich auf einer gewissen X-Position befindet. Außerdem muss der Maker wissen, wo die grauen Bereiche sind.
• Das selbe gilt für die Z-Position (!). Im Spiel ist Kirby mal weiter weg, mal näher.
• Der Bildschirm muss sich mit Stufenlosem Speed (!) bewegen lassen können.
• Kompliziert sind auch die Computergegner, zumal sich ja nicht nur der Bildschirm mit stufenlosem Speed bewegen lassen können muss, sondern auch die Gegner.

Für den 1./2. Punkt hätte ich schon eine Idee. Das als Block von Varis (ca. 2000) in eine Datei auslagern (wie? z.B. mit einem Proggi, wo man die Linien "zeichnet", und der speichert das oder so) und dann mit dem PP oder dem TP+eigenem Proggi in den Maker laden.

Große Frage ist natürlich auch die Performance.

Nun, was sagt ihr dazu? Ideen?

Happy Posting!

mfG Cherry

[Pasky]

Das Spiel ist so ähnlich wie Line Rider.

Hier wäre mein Vorschlag wie ich das Ungefähr mit dem Bildschirmproblem lösen würde. Ich weiß das Event was ich hier unten aufgelistet habe ist nicht Perfekt, ist aber nur so ein Vorschlag.

Parallel Process :

Bedingung : Variable 001ben = größer gleich 1
Bildschirm um ein nach Oben verschieben.
Variable 001ben - 1

Bedingung : Variable 002:Rechts = größer gleich 1
Bildschirm um ein nach Rechts verschieben.
Variable 002:Rechts - 1

Bedingung : Variable 003:Links = größer gleich 1
Bildschirm um ein nach Links verschieben.
Variable 003:Links - 1

Bedingung : Variable 004:Unten = größer gleich 1
Bildschirm um ein nach Unten verschieben.
Variable 004:Unten - 1

Ansonsten find ich deine Idee echt gut. Und ich hab Respekt vor Leuten die noch mit dem Rm2k oder mit dem Rm3k arbeiten anstatt mit dem XP.

MFG

Pasky 8)

[Cherry]

das nützt leider wenig.

Der Bildschirm muss sich mit Stufenlosem Speed (!) bewegen lassen können.

...

Und so hat man nur 6 Stufen (8x langs., 4x langs., 2x langs., norm., 2x schnell., 4. schnell.). Wir brauchen mindestens 25.

mfG Cherry

[MagicMaker]

Yeah das Minigame kenn ich.
Also ganz ehrlich, bei "Nightmare in Dreamland" verliere ich das Game immer xD.

Aber ansonsten gefällts mir total.

"Röhren (Regenbogen?)": Sag doch einfach Regenbogen-Röhren xD.

25 Stufen: Würde mich nicht wundern wenn da irgendwie dein PowerPatch helfen würde. (Mit nem LUA-Script und ggf ner DLL wirds schon gehen), denn
wie du sagst, 8 sind zu wenig.

Ne Sache wäre noch, wie die Strecke aufgebaut werden soll, sie sieht afaik immer anders aus.

Würden wir die bunten und schwarzen Röhren mit Terrain-IDs versehen, liese
sich auch leicht feststellen, ob man Speed verlieren soll aber es wird ja
sicher nicht Tiles-bassierend sein.

[Cherry]

du sagst es.
für den bg könnte man ein riesiges PIC nehmen und mit Varis anzeigen, so kann man auch das mit dem Speed hinkriegen.
mfG Cherry

[übelster Held]

wäre es denn, bei dem ganzen koordinaten-gemähr,
nicht am einfachsten, wenn man sich die strecke aus lauter
funktionen zusammenbastelt?
kompliziert wäre drann, nur die funktionen ohne knick miteinander zu verbinden,
und die funktionen dann als bahn zu malen....

[CapSeb]

Das mit dem Auslagern der Variablen ist ja schön und gut, aber was hat das dann noch mit dem Maker zu tun? OK, man kann die Vorteile verschiedener Programme verbinden. Aber geht es hier nicht vorrangig um das Anwenden der Maker-Technik? Allein dieser Punkt sorgt dafür, dass sicher nur die Wenigsten eine Idee beisteuern werden, da kaum einer das dafür nötige Wissen hat.

Hm, also das Minispiel hab ich grad noch mal getestet. ^^
(mein Bruder hats \o/)
Grundlegend wärs ja ganz praktisch das Spiel erstmal zu analysieren. Im Prinzip besteht es aus zwei komplett trennbaren Elementen:



1. Die zeitliche Ebene, dass heißt das Festhalten und Loslassen des A-Knopfes zum Richtigen Zeitpunkt ("Drückphasen" und "Wartephasen" wechseln sich schlicht und ergreifend ab), also das Gameplay.

2. Die graphische Darstellung, das heißt ein Hoch-/ Runterbewegen des Charakters (Kirby) und die daran angepasste Bahn.



Daraus würde ich Folgendes schließen. Die erste Komponente ist kein Problem. Man braucht nur einen Algorithmus, der die Phasen nach einem passendes Rhythmus wechselt. Muss man halt mal drüber nachdenken. Aber mit eindeutiger Sicherheit ist es umsetzbar.

Beim zweiten Punkt ist es ähnlich. eine Änderung der y-Position nach einer Kurvenbewegung. Dazu braucht man eine Formel, die sich variieren lässt. Es geht ja im Grunde immer hoch-runter. Dass das ganze einen 3D-Effekt besitzt, wäre eine vertiefende Übung.

Im Normalfall hieße das, dass am rechten Bildschirmrand Pixel für Pixel eine Höhe generiert wird, eben nach der Formel. Diese Pixel bewegen sich mit der Kirbygeschwindigkeit nach links. Ein Move-Event mit dauerhafter Aktualisierung der Position in Bezug auf die Kurvenformel der Bahn wäre da denkbar.

Doch das eindeutigste Problem ist die Begrenzung der Pictureanzahl. von links nach rechts gesehen müssen 320 X-Positionen abgedeckt werden. Unschöne 3x3-Pixel-Klötze würden das Ganze auf 108 Picture (nicht 107 ) herunterschrauben.

Daher ist hier wohl ein Umdenken nötig. Statt Kurvenformel und Pixelverschiebung bräuchte man Kurvenstücke. Die werden einfach aneinader gesetzt. Für diese Stücke braucht man dann drei Informationen. Die überwundene Höhe ist notwendig, um zu wissen wie das Höhenverhältnis von vor zu nach dem Kurvenstück ist. Man braucht außerdem die Steigung des Anfangs und des Endes. Nur gleiche Steigungen passen aneinander.
Hierbei ist dann zu beachten, dass dennoch ein flüssiger Kurvenverlauf entsteht. Die Bildschirmhöhe sollte also regelmäßig ausgenutzt werden. Ein ständiges Auf-Ab-Geschaukel wäre zu vermeiden.

Die X-Positionierung hängt wieder vom Bewegungs-Tempo ab. Jedes Kurvenstück erhält bei Einführung eine X-Position des linken Randes. Die X- Position des Kirbys im Verhältnis zur Bahn (nicht im Verhältnis zum Bildschirm, es ist ja schließlich immer in der Mitte) errechnet sich aus Zeit, Geschwindigkeit und zurückgelegter Strecke. Ein ständiges Move-Event aller Kurventeile erledigt das Übrige.

Zu den Gegner hab ich erstmal keine Idee.


CapSeb

[MagicMaker]

Zu den Gegnern:

Da fällt mir nur ein, dass man zuerstmal für die Strecke berechnen lässt, wie
sie sich im Optimalfall bewegen müssen und mit Zufallswert-Variablen
(=Irrtumswert xD) sie davon abweichen lässt, wie die vielen Sachen die dem
Spieler auch passieren können, dass sie zu zeitig oder zu spät drücken, was
den Spielverlauf natürlich beeinflusst.

3D-Tiefe der Spieler und Gegner:

Erster Fakt dazu ist: Bildgrösse in % ändern, ganz logisch.

Bildmenge:

Bei der Menge die CapSeb angibt (und wohl richtig ausgerechnet ist), stürzt
der Ressourcenvielfraß "RPG_RT.exe" nur unnötig ab.

Y-Position:

Wenn sich diese verringert dürfte Kirby ebenfalls an Tempo verlieren, obwohl
sich hier der Verlust in Grenzen hält. Die Kraft, die benötigt wird, um geneigt
nach oben zu grinden, kostet an Speed. Genau umgekehrt ist es abwärts, wo
sich das Tempo geringfügig erhöht. Da die Strecken kaum gerade Stücke
haben, werden diese Prozesse ständig ausgeführt, was schon zum Ruckeln
führen könnte.

[R.D.]

Wir wärs mir Pics?
Die Lines vllt vorher in einem Bild speichern, und dann mit Bilderüberdeckung arbeiten?
Somit könnte auch ein Stufenlose Geschwindigkeit problemlos realisieren
*überleg*
Das müsste fudeln!

dann lässt man ein PP-Evnt in welchem man Kirby steuern kann.
Aber wenn ich so überlege.... *denk*
Die Y-Bewegung ist dann vllt schlecht zu realisieren....

Ach so einfach ist das wirklich nich....

[Beril]

Ich hätte eine ganz banale Idee:
Man könnte ja eine Art "Abtast-Map" erstellen, die der Spieler natürlich nicht sieht. Sagen wir mal so:
wir bauen einfach eine Map in der Jedes Feld für einen Pixel auf der Bahn steht. Dann lassen wir einfach den Held diese Map entlangwandern und fragen immer die Terrain ID eines jeden Feldes links, unter und rechts vom Held ab.
Wenn zB unter dem Held ein Feld mit der sagen wir ID 1 ist, dann bewegen mir die ganze Bahn (Die Picture Variante) um einen Pixel hoch, wenn jetzt unter Kerby ein Feld mit der ID 2 ist, dann muss es einen Pixel nach rechts gehen.
Mit einer ID 3 könnte man dann auch ganz schön die schwarzen Partien der Bahn abtasten.

Hier noch mal eine kleine Veranschaulichung des ganzen (mit teilstücken):

[CapSeb]

Nette Idee.

Dabei wäre aber die Bahn starr, das heißt nicht automatisch veränderbar.
Zudem bräuchte man weiterhin eine Idee für die Bilderdarstellung. Chips sind zu grob.


CapSeb

[Knumonmaster]

er hat ja gesagt, dass ein Chip einem Pixel entsprechen. D.h. im Hintergrund würde der Held auf der Map die "Pixelpfade" abwandern; die gewonnenen Daten werden dann dazu benutzt, um mit Pictures die Bahn/den Helden darzustellen.

Ich sehe darin aber nur das Problem, dass man dazu sehr sehr große Maps braucht, da so ne bahn mind. 10.000 pixel weit sein sollte, müsste eine Map also 10.000 Chips breit sein, was ein bisschen an der Realität vorbeigeht

Das bedeutet wiederrum, dass man mit mehreren Maps arbeiten muss. Das einzige Problem wäre hier die Ladezeit, welche ein kurzes ruckeln verursachen würde ...

[CapSeb]

er hat ja gesagt, dass ein Chip einem Pixel entsprechen

...

Jop. Nur liegt das Problem nicht bei der Kurvenform sondern eher bei den Bilder, daher:

Zudem bräuchte man weiterhin eine Idee für die Bilderdarstellung. Chips sind zu grob.

...

Em, mal ne Frage. Auf was soll der Thread eigentlich hinaus laufen. Ich mein wir haben jetzt tolle Ideen und so und keiner hat was daran auszusetzen.


CapSeb

[Cherry]

er soll nur als Diskussionsplattform dienen. Ich habe halt mal ein Thema vorgeschlagen

mfG Cherry

[Marian]

die idee, das ganze über die terrain-id zu regeln, ist garnicht so verkehrt. wenn man den helden als bild darstellt, kann man ihn auch relativ flüssig bewegen. und die ecken und kanten in den chipsets malt man einfach rund. man berechnet nicht nur die id des tiles unter dem spieler, sondern auch die anderen in seiner umgebung, dann kann man die bewegung des bildes, das den helden darstellt, daran dann anpassen. jetzt stellt man das bild halt noch auf move with map (da gibts allerdings je nach maker- und rpg_rt.exe-version einige komplikationen) und bewegt der bildschirm je nach geschwindigkeit (wobei es hier auch wieder ne begrenzung der geschwindigkeit gibt...) mit dem bild/der strecke mit.

hmn. wenn ich mal irgendwann demnächst zeit und lust hab, such ich mir das original mal raus, guck mir das an und versuch das mal ein bischen nachzubauen.