@Inflater
Dein Problem lässt sich mit "Common Events" lösen, falls es die im Ace noch gibt. Dabei handelt es sich um globale Events, die jederzeit aufgerufen werden können.
@Inflater
Dein Problem lässt sich mit "Common Events" lösen, falls es die im Ace noch gibt. Dabei handelt es sich um globale Events, die jederzeit aufgerufen werden können.
Falls du es ganz grob wissen willst:Zitat
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Gibt es.
@Inflater
Wenn du die Datenbank aufmachst, gibt es dort einen Reiter, der sich "Common Events" nennt. Events die du dort ablegst, kannst du von überall im Spiel aus aufrufen. Dazu baust du einfach ein "Call Common Event" in die Eventseite ein. Wenn du dann noch die ID deines Tür-Events an eine Variable übergibst, kannst du über das Common-Event sogar steuern, auf welche Map der Charakter beim durchschreiten der Tür gebracht wird.
Für das Ändern der Musik brauchst du übrigens kein Event. Das kannst du direkt in den Eigenschaften der jeweiligen Map einstellen (nennt sich "Autochange BGM" oder so ähnlich.)
Noch ein Hinweis zu Common Events:
Wenn du in einem Common-Event den Event-Bezug "This Event" verwendest, dann bezieht sich dieser IMMER auf das Event, welches das Common-Event aufgerufen hat, nicht auf das Common-Event. Damit lässt sich zum Beispiel ein Klasse Event für Monsterkämpfe machen. Du übergibst beim Zusammentreffen des Helden mit dem gegner einfach die ID der gewünschten Feindtruppe sowie die Terrain-ID an je eine Variable und rufst dann ein Common Event auf, das den kompletten Rest erledigt ... inklusive des Löschens deiner gegnergruppe von der Map.
Ich meine mich erinnern zu können, das sich "This Event" in den älteren Makern immer auf das Common-Event selbst bezogen hat.
Ihr Lieben,
noch mal vielen Danke für die vielen klasse Tipps!
Ich habe mal einen neuen Thread aufgemacht, weil der hier jetzt eher in Richtung »First Steps« driftet und meine Eingangs-Frage eigentlich beantwortet ist. Deswegen:
Wie immer,
The Inflater
Moin, Moin,
Tut mir Leid, dass ich den Thread hier noch einmal aus der Versenkung hole, aber ich fand ihn soweit schon sehr hilfreich; und habe dennoch eine Frage:
Also, ich bastel schon seit einiger Zeit mit dem RPG-Maker2000 und bilde mir ein, auch schon einiges damit auf die Reihe zu kriegen. Den XP habe ich nur mal probeweise angefasst und kann deswegen die Vergleiche zwische ACE und XP leider nicht nachvollziehen. Weil mir die höhere Auflösung der XP-Graphiken zu aufwändig war, um sie selbst herzustellen, und also keinen Vorteil brachte, mich außerdem dieses Diagollaufen genervt hat, das ich dann selbst irgendwie hätte blockieren müssen (was vielleicht einfach gewesen wäre, ich weiß es nicht) und ich außerdem kein Ruby konnte, sah ich für mich nicht so richtig den Vorzug des XP. War aber vielleicht auch zu kurz gedacht.
Nun möchte ich demnächst ein neues Spiel anfangen, das ich soweit für den 2000er geplant habe; dieser Thread lässt mich jetzt aber darüber nachdenken, ob ich nicht auf Ace umschwenken soll.
Um zum Punkt zu kommen:
Gibt es irgendwelche Aspekte am Ace, die mir gegenüber dem 2000er zum Nachteil gereichen könnten? Also, ich nehme an, es gibt keine Probleme, 2000er-Graphiken in den Ace zu importieren. Ein Kampfsystem möchte ich gern selbst schreiben, deswegen spielt das Standard-KS des Ace keine große Rolle für mich.
Desweiteren weiß ich noch nicht, ob ich Lust habe, mir die Skriptsprache anzugewöhnen - könnte ich trotzdem mit dem Ace prinzipiell allein über die Standardbefehle das Gleiche machen wie auf dem 2000er?
Und zuletzt: Kann mir noch einer erklären, was dieses Problem ist mit diesem "Quaderlook", der hier dauernd angesprochen wurde? Was meintet ihr zum Beispiel mit den "Autotiles"? Meint ihr damit diese Kacheln, die aus 3 x 3 Kacheln in der Bilddatei bestanden, aber nur aus einer Kachel im Karten-Editor im Maker, sich aber selbst arrangierten? Und falls ja: WAS ist jetzt anders am Ace?
Schönen Dank im Voraus!
Postscriptum: Ihr braucht mir nicht alle unbedeutenden Unterschiede in der Bedienung der beiden Maker aufzuzählen. Nur falls ihr bereits die Erfahrung gemacht habt: "Schau mal einer an, DAS war aber noch viel einfacher damals auf dem guten alten 2000er und wird hier in neumodischem Firlefanz ertränkt! Und wieso programmiert das eigentlich keiner auf meinem Abakus, der braucht nicht so lange zum Hochfahren wie dieser *'/&"(§ Kompjuter!", könntet ihr mir Bescheid sagen.
Geändert von Topp (26.07.2012 um 13:01 Uhr)
Theoretisch geht das bei den NORMALEN TILES. Bei den Autotiles geht's nicht, dazu weiter unten mehr. Beim Ace sind alle Tiles 32x32 Pixel groß, beim 2k nur 16x16. Du musst die Tiles also für den ACE hochskalieren.
Wenn du ein eigenes Kampfsystem nutzen willst, solltest du tatsächlich Ruby lernen, weil du damit tiefere eingriffe in das System vornehmen kannst. Den ACE zu benutzen, und dann ein Kampfsystem über Event-Scripting zu erstellen, ist, als wenn du dir einen Porsche kaufst und dann einen Trabbi Motor einbaust. Ansonsten kann das EVENT-SYSTEM nicht nur alles, was das den 2k kann, es kann sogar wesentlich mehr. Das Eventsystem des ACE ist ähnlich umfangreich wie das des 2k3.
Jetzt zu den Autotiles. Du hast recht, die Tiles, die sich automatisch zusammenfügen sind die Autotiles, und da hat sich beim ACE etwas verändert ... und zwar zum negativen. Beim 2k3 war ein Autotile 48x48 Pixel groß, bei einer Tilegröße von 16x16 Pixel entspricht das also 3x3 Tiles. Ein Mittelstück, 4 Kantenstücke und 4 Ecken. Beim Ace gibt es nun eine Autotile-Größe von 64x64 Pixeln, was bei einer Tile-Größe von 32x32 Pixeln aber nur noch 2x2 Tiles Entspricht. Das heißt, die Autotiles des ACE haben keine Mitte und keine Kanten mehr, nur noch ecken. Die übrigen Teile der Tiles, werden irgendwo aus der Mitte entnommen. Als Resultat daraus müssen die Ecken der Autotiles relativ grade sein, weil sie ja auch die "graden" Segmente der Flächen repräsentieren. Dadurch wirkt die RTP-Grafik des ACE extrem klotzig ...
Bei Gebäuden etc. geht das. Aber für Berge sind die Autotiles praktisch nicht nutzbar.
Ich habe das So gelöst, dass ich mir die Berg-Tiles aus einem Tileset vom XP "geklaut" habe, und für die Berge einfach keine Autotiles einsetze. Das ist mehr arbeit, sieht aber besser aus.
Geändert von caesa_andy (26.07.2012 um 12:36 Uhr)
Sooo viele sind seit RPGXP nicht mehr wirklich übrig geblieben. Bei Variablen und Switches fehlt eine
Pointerzuweisung, auf welche ID der Wert gespeichert werden soll, das schränkt dynamische Vorgänge
mit Schleifen um einiges ein.
Man kann ohne zusätzliche Hilfe auch keine Pictures auf der Map statt auf dem Bildschirm festtackern,
meine kürzliche Erfahrung damit hat allerdings ergeben, dass es sogut wie kein Rubywissen braucht um
da was zu rütteln, quasi Modifikation auf Schwierigkeitslevel 0.
Bis auf ein paar Ausnahmen sicher. Vorrangig mit RTP sollte aber keine Komplikation auftreten.
Ich sag mal fast. An ein paar Stellen mehr, an anderen weniger oder mit mehr Umwegen.
[Nein da sind Funktionen die über Patches manipuliert werden bei RPG2000 nicht einbezogen]
Sie sind im Maßstab kleiner, 2x2 Felder statt 3x3, bzw nehmen die äusseren Ecken nurnoch
halbsoviel Platz ein wie zuvor, das lässt die Tiles weit eckiger erscheinen als sie vorher möglich
gewesen wären (wenn auch nicht immer ausgenutzt). Es gibt einen etwas unangenehmen Weg,
das zu ignorieren, wenn man die Tilemitten nicht beachtet und die runden Ecken ganz auf den
2x2 Platz haben lässt, das könnte auf geraden Strecken aber noch hässlicher aussehen, wenn
sich der Tilegrafikverlauf wie eine Sinuswelle durchschlägt.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Super, herzlichen Dank, das ging ja erfreulich schnell.
Ich glaube, ich weiß jetzt alles, was ich wissen wollte.
Also schönen Dank nochmal.
Dazu von mir noch eine klitzekleine Anmerkung, die nicht direkt hilfreich für Dein Problem ist, aber doch vielleicht hoffentlich ein wenig »Motivation« liefern könnte, sich mit Ruby zu befassen:
»Ruby« ist keine frickelige Scriptsprache, die mal eben so mehr schlecht als recht in RPGMaker integriert wurde. Zum einen ist Ruby eine voll ausgewachsene Programmiersprache, mit der unter anderem auch Websites im Internet programmiert werden (Stichwort »Ruby on Rails«). Zum anderen ist Ruby integraler Bestandteil des RPGMakers, ohne die das System schlichtweg nicht funktionieren würde.
Ich will Ruby wirklich nicht über den grünen Klee loben (dafür sind zu viele Ungereimtheiten in der Sprache). Aber eine Beschäftigung mit dieser Programmiersprache ist sicherlich keine schlechte Investition in die Zukunft. Sowohl ganz direkt für Dein Projekt, als auch Abseits von Hobby und Spaß sondern eben auch für die berufliche Entwicklung (solltest Du etwas mit IT zu tun haben). Bisher hat es mir in Bewerbungsgesprächen noch nie geschadet, wenn man Programmierkenntnisse vorweisen kann (man muss ja nicht unbedingt vom RPGMaker erzählen).
Ich kann die durchaus intensivere Beschäftigung mit Ruby nur jedem empfehlen.
Wie immer,
The Inflater
Berechtigungen
Zitieren
