Wenn wir jeden Pixel mit einer Variable unterlegen: Ja, pixelgenaue Kollision ist möglich.
Nur weil etwas Aufwand bedeutet, heißt es nicht dass es unmöglich ist~
Wenn wir jeden Pixel mit einer Variable unterlegen: Ja, pixelgenaue Kollision ist möglich.
Nur weil etwas Aufwand bedeutet, heißt es nicht dass es unmöglich ist~
--" Bis dass die Massen jubeln 'Friss oder stirb' und ich antworte dann 'Schickt die Kakadus in den Ring' "
@Kyuu: Ok, verstehe was du meinst. Die Standardmethoden sind nicht möglich, richtig. Und wenn man "Pixelgenaue Kollision" als Fachbegriff sieht, müsste man auf dem Maker erst ein Ersatzwort finden.
Dann würdest du also ein Script der Marke Lachsen unter die Kategorie Hacks-Whatever fallen lassen? Patches wurden ja nicht verwendet.
--
@Phno:
Cool, versuchs mal. Ist bestimmt wahnsinning praktisch. Wenn man von dem gigantischen Overhead absieht, den man mit Branches bei der Abfrage von Zehntausenden Variablen verursacht und dem gigantischen Speicherplatzverbrauch von Zehntausenden und viel mehr Variablen bleibt ja nur noch der Eigenaufwand. Ja du hast recht, könnte klappen! :)
Naja, schon eine 20x15 Map hat 300 Tiles und jedes Tile besteht aus 16x16 Pixeln. Das wären dann schon 76800 Variablen, falls ich das Rechnen noch nicht verlernt habe. Außerdem stellt sich die Frage, wie du die Masken in den Maker einlesen willst.Zitat
Edit: Kyuu war schneller und apropos Branches, der Editor braucht doch schon bei ca. 20 verschachtelten Branches merklich länger um das Fenster zu öffnen. Ich denke bei hundert Stück mit Code dazwischen kannst du dir schon mal den einen oder anderen Kaffee machen, bis überhaupt etwas angezeigt wird.
also ich hab jetzt nicht alle beiträge genau durchgelesen, wollt nur mal erwähnen, dass ich für den gebäudecontest ein jump&run skripten wollte, und so ne art prototyp zustande hab. mit pixelmovement, kollision und scrolling.
es ist also möglich (habs dann fallengelassen, da keine motivation).
das einzige das noch verbesserungswürdig wäre, ist das scrolling. hab noch nicht ganz genau herausgefunden, wie schnell ein "pan screen" ist, damit die spielfigur synchron mit dem scrolling ist.
schräge flächen mit z.b. 45° oder 22,5° (1tile höhe, 2tile breite) sind durchaus möglich mit der üblichen terrain-ID-abfrage-technik.
vielleicht mach ich ja ne techdemo, nur um euch zu zeigen, DAS MIT DEM MAKER EBEN DOCH FAST SOZUSAGEN ALLES MÖGLICH IST ZU MACHEN UND JAHA! RHABARBER!
ich mein minesweeper, tetris, picross, sudoku... dann ist ja wohl auch n popeliges jump&run im bereich des möglichen...
Geschicklichkeitsspiele und Actionspiele sind auf dem Maker dort möglich, wo es darum geht, schnell zu reagieren. Mit Variablen und 'nem Cycle oder mit einem Timer kann man was das betrifft schon viel erreichen. Kampfsysteme à la "Drücke im richtigen Moment den richtigen Knopf" sind relativ problemlos machbar (Habe gerade selber so eines gescriptet).
Bei Strategiespielen vom Typ C&C müsste man das Konzept etwas ändern. Echtzeit ist nicht machbar, also wird's rundenbasiert. Auch das Problem der Wegfindung wird man wohl nicht zufriedenstellend lösen können, also muss man es umgehen. Man könnte dem Gegner z.B. ausstatten mit Flugzeugen, die sich überall bewegen können. Oder mit Geschütztürmen, die feste Position und Reichweite haben.
Warum nicht? Warum kein asymetrisches Gefecht, bei dem der (zur Wegfindung fähige) Spieler mit Panzern und Infantrie kämpft, während der Gegner sich mit Geschütztürmen, Mittelstreckenraketen, Bunkern, Minenfeldern, Mauern und Stacheldraht verteidigt? Es wäre zwar schwierig, dann einen gegnerischen Angriff nachzuspielen, aber darauf müsste man eben verzichten. Der Spieler wäre immer in der Position des Angreifers (egal wie politisch-didaktisch bedenklich das auch sein mag) und müsste sich den Stellungen des Gegners möglichst strategisch nähern. Ich halte das für möglich, machbar und eine interessante Idee.
Beim RPG-Spiel "Zitronengras" wo Butterbrot und ich arbeiten, verwenden wir selber pixelgenaue Kollisionsabfrage um im J'n'R Action-KS die Schüße abzufragen.
Dabei legst du einfach eine Variable auf den Mittelpunkt des Charas/Pictures und trägst via x/- die X und Y Koordinate auf die äußersten Punkte. Darauf folgt eine Abfrage und dieser Punkt wandert dann weiter. Sogesehen bräuchte man dann auch nur soviele Variablen, wie das Template breit ist.
As said, etwas als "unmöglich" abzustempeln nur weil es einem zuviel Aufwand bereitet, ist Schwachsinn. Für sowas braucht man keine Patchs und erst recht keine Bitmasken Vergleiche.
Edit: Ich spreche jetzt nicht davon, dass wir alle Pixel auf einer Map verwenden sondern nur die, die man benötigt, oder noch schlimmer, wir sprechen einander vorbei.
--" Bis dass die Massen jubeln 'Friss oder stirb' und ich antworte dann 'Schickt die Kakadus in den Ring' "
Bei diesen Spielen ist aber keine pixelgenaue Abfrage notwendig. Ich würde sogar sagen, dass diese Spiele relativ trivial umzusetzen sind.
Insofern fördert der Maker die Kreativität. Mit Kanonen wie C oder den BASIC-Sprachen kann man so ziemlich jedes Problem lösen. Beim Maker muss man dessen beschränkte Möglichkeiten so effizient wir möglich nutzen. Er zwingt dazu, Probleme zu umgehen oder sie mit unkonventionellen Methoden anzupacken.
Das hat nicht wirklich was mit pixelgenauer Kollision zu tun. Du vernachlässigst so ziemlich fast alles, was mit pixelgenauer Kollision gemeint ist.
Nenn deine Kollisionsabfragen bitte anders.
Nochmal: Pixelgenaue Kollisionen, wie sie sonst durchgeführt werden, sind auf den alten Makern untragbar, absolut unpraktisch, idiotisch, unsinnig => unmöglich.
Wenn du es immernoch anders siehst, kann ich dir zwei Bilder liefern (der Einfachheit halber und um das Bitmaskenverfahren zu verdeutlichen, in schwarz/weiß) und du erstellst mir ein Projekt, in dem man diese Bilder beliebig überlagern kann und es mitgeteilt wird, sollten sich die weißen Flächen überlagern.
Du hast nicht ganz verstanden worauf ich hinaus wollte: Der Aufwand war nur als Spitze des Eisbergs dargestellt.
Kelven hat das "Warum" eigentlich auch schon erläutert.
Du wirst mir wahrscheinlich nicht glauben, aber C/C++ hat auch Grenzen und weit nicht alles lässt sich so umsetzen, wie man es gerne möchte. Ich würde eher sagen, dass du bei C/C++ viel kreativer arbeiten wirst, als beim Maker.
Geändert von Kyuu (03.11.2008 um 23:07 Uhr)
@Phno
Diese Methode ist aber dann letztendlich nichts anderes als eine tile-genaue Abfrage, es sei denn ich habe dich missverstanden. Wie definierst du z.B. Wände? Die können ja erstens nicht so wie Events abgefragt werden und wären zweitens bei einem Jump'n Run auch nicht unbedingt aus 16x16-Blöcken aufgebaut. Plattformen wären auf jeden Fall dünner und wenn der Charakter z.B. nur mit seinem Bauch die Plattform erreicht, dann landet er nicht auf ihr, sondern stürzt in sein Verderben. Eine einfache Kollision mit dem Event reicht also nicht aus. Man könnte höchstens die Standfläche des Charakters als Grundlage nehmen, obwohl es auch komisch wäre, wenn er nur noch mit einem Pixel auf der Plattform hängt.
Cool, ich hab grad einen schönen langen Post zum Thema Pixelmovement geschrieben, und als ich auf Antworten klickte, meinte das MMX, ich sei nicht eingeloggt und deswegen ging dann mein Post verloren. Sehr schön.
Jetzt fasse ich mich kurz: Pixelmovement ist machbar und nicht sonderlich schwer, wenn mans begriffen hat. Schrägen gehn auch recht einfach. Man sucht sich das Tile, auf dem man sich grad befindet und berechnet die Steigung vom linken oberen Pixel des Tiles zum Helden hin. So kann man herausfinden, ob sich der Held über oder unter der Schräge befidet, bzw. auf welcher Seite. ICh bastel grad übrigens ein AKS und ein Jump'n'Run, beide unterstützen Pixelmovement.
Und damit ihr auch wirklich zufrieden seid, mal mein Pixelmovementskript, das ich vor einiger Zeit mal hier im Forum vorgestellt hatte:
hier klicken
So, schnell posten und weg! Tschüss!
--
Bezüglich Strategiespiele... hat schon mal jemand Tactic Ogres versucht nachzubauen? Das Spiel hat zwei Ebenen - auf der einen Hand die Karte und auf der anderen die Kampfscreens. Auf der Karte zieht man nur Figuren herum und auf den Screens werden die eigentlichen Kämpfe zwischen kleinen Gruppen von Einheiten ausgetragen. Das müsste sich doch mit wenig Aufwand auf den RPG Maker übertragen lassen? Das Problem dabei wäre, dass man eine Möglichkeit finden muss, bis zu zehn Parties zu verwalten...
Bezüglich Actionspiele... ist ein Action-KS mit dem Tilesystem des Makers nicht vorstellbar? Man müsste eben mehr auf Timing gehen und die Pixelgenaue Abfrage auf einen Kreis um die Figuren beschränken.
Zu ein paar anderen Sachen, die mir inzwischen ins Auge springen, werde ich mich auch noch mal äußern.
--
also das bezieht sich jetzt alles auf den xp und eigene erfahrungen (ausgenommen simutlation, siehe unten)
nungut action ist recht allgemein...nen shooter ist machbar und gar nicht so schwer, vorausgesetzt man versteht was von rgss.
hab sogar mal nen online 2d shooter mit maus steuerung (ähnlich cs 2d) basierend auf dem np2+ system gemacht. funzt theoretisch auch....mal abgesehen davon, dass der server so lahm ist, dass der getroffene spieler erst 2 sec später den schaden bekommt. was bei echtzeit spielen fatal ist :/
aber offline für single player ist ein solches actionspiel nicht schwer
ebefalls möglich sind strategie spiele, sowohl echtzeit als auch rundenbasiert.
...wobei eine maximale einheitengrenze (wie zb bei empire earth nur viel niedriger) unumgänglich ist, da es sonst zu sehr laggt.
pathfinding muss nicht in echtzeit geschehen! nichtmal bei echtzeit strategie spielen.
bei dem script wird eine tabelle mit der entfernung (weg nicht luftlinie) zum ziel erstellt.
wenn nun die tabelle mit dem ziel goldmine (beispiel) vor dem spiel erstellt wird, kann man sofort darauf zugreifen ohne lade/rechen-zeit. funktioniert halt nur bei festen zielen....bäume die gefällt werden und danach nicht mehr existieren sind also unpraktisch für ein rmxp strategie spiele.
rundenbasiert ist das ganze um einiges einfacher. das Fire Emblem KS zum beispiel ist ohne weiteres machbar (momentanes projekt *werbung mach :P*)
simulation? nungut noch nicht ausprobiert, sollte aber gehen. allerdings nicht mit den standart events des xp.
heißt...erstmal alle script löschen und komplett neu schreiben.
von daher wäre es praktischer das ganze ohne den maker zu machen....schließlich bleibt nichts mehr von übrig xD
nur blöd wenn man nur ruby kann un deshalb ein ausweichen nicht möglich ist -.-'
@Shining Advances: XP und RGSS sind eindeutig von den größten Einschränkungen des 2k(3) befreit. Von daher sehe ich es dort schon als selbstverständlich an, dass (scheinbar) alles umsetztbar ist. In gewisser Weise ist es schon fast lagnweiliger dadurch. Damit meine ich allerdings das Scripten. Das Ergebnis ist dann natürlich umso schöner.
Selbst die ersten nonRTP XP-Projekte, die ich hier gesehen hatte, haben Schattenscripte und Co verwendet; das Thema war damit für mich gegessen.
Bleibt weiterhin die Frage offen, ob all das, was du auf dem XP hinzaubern möchtest, auch mit dem 2k(3) möglich gewesen wäre/ ist. Wegen folgendem Zitat denke ich, dass du eher "nein" dazu sagen würdest:
---
Warum wären zehn Partys schwierig zu verwalten? Der Maker (2k) bietet doch genug Variablen zur Verfügung, um skalierbare Werte zu speichern.
Hier würde ich wieder sagen: Die angesprochenen Probleme sind aus meiner Sicht irgendwie keine. Das wirklich "schwierige" ist doch Echtzeitsimulierung und Performanceschonung. Und durch die fehlende Objektorientierung muss man eben bei allem, was sich bequemer mit Objekten lösen lässt, improvisieren.
CapSeb
--
@Ianus
Das kommt darauf an wie intelligent der Computer im Spiel ist (ich kenne es nicht). Der Maker hat standardmäßig nur 5000 Variablen, um etwas zu berechnen.
Solche Action-Kampfsysteme wie du sie beschreibst gibt es auf dem Maker schon, aber sie spielen sich natürlich ziemlich schlecht.
@CapSeb
Nur weil es evtl. auf dem XP einfacher wäre, heißt das ja nicht, dass einen das Spiel in den Schoß fällt und deswegen würde ich dein "langweiliger" nicht unterstreichen wollen. Eigentlich dachte ich sowieso, dass man als Entwickler darüber froh ist, wenn ein Spiel weniger Arbeit macht. Und das ist ja das Ziel der ganzen Mühe, ein Spiel; kein bahnbrechendes, zehn Seiten füllendes Script im Eventcode, für das man mit einer höheren Programmiersprache gerade mal 10 Zeilen braucht.
Der Maker ist turingvollstaendig.
Damit ist bewiesen, dass jeder auf einem beliebigen Computer ausfuehrbare Algorithmus auch mit dem Maker nachgebaut werden kann. Damit ist eigentlich alles gesagt.
Andererseits sagt dies natuerlich nichts ueber konkrete Realisierungen aus oder (was ein Spezialfall ist) ueber die Spielbarkeit. Allerdings liesse sich auf einem beliebig schnellen Computer, dessen Graphikspeicher auf einen Subbereich der Makervariablen gemappt wird, jedes beliebige Spiel nachprogrammieren, solange man, wie mit patches geschehen, die Anzahl an Variablen fuer den Maker nur gross genug macht. Ob das ganze auf heutiger Hardware oder ueberhaupt Sinn macht, ist eine ganz andere Frage.
--
Also mit dem XP ist dank Ruby alles möglich^^
Beim RM2K3 weiß ich es nicht.
Aber selbst dafür gibt es viele Patchs........
Aber mal ein Online-Spiel-Wettbewerb?!?
Das wärs doche mal
OH DOCH,
wie Maker dieses spiel beweist (bei dem man sich 3D im Raum bewegen kann !!! )
--Das LichtStefan George
Wir sind in trauer wenn · uns minder günstig
Du dich zu andren · mehr beglückten: drehst
Wenn unser geist · nach anbetungen brünstig:
An abenden in deinem abglanz wes't.Wir wären töricht · wollten wir dich hassen
Wenn oft dein strahl verderbendrohend sticht
Wir wären kinder · wollten wir dich fassen -
Da du für alle leuchtest · süsses Licht!
Nicht wirklich, in dem Spiel wird nur ein optischer Trick benutzt. Auch in Makerspielen bewegt man sich in drei Dimensionen (wenn man das Springen berücksichtigt). Aber so genannte 3D-Spiele sind Spiele, in denen die Spielwelt durch Polygone dargestellt wird und sich die Spielfigur relativ frei durch die Welt bewegen kann. Resident Evil 1 und FFVII sind z.B. auch keine "3D-Spiele" (beide Spiele benutzen vorgerenderte Hintergründe).
Berechtigungen
Zitieren
