Man kann sich übrigens auch mit Parallax-Mapping behelfen, wem die Autotiles im Ace unpassend erscheinen. ^^
MfG Sorata
Man kann sich übrigens auch mit Parallax-Mapping behelfen, wem die Autotiles im Ace unpassend erscheinen. ^^
MfG Sorata
@caesa_andy:
Ja stimmt ich kenn die seite schon Oo xD
Kennst du sonst noch ein script wo man die chars von der seite sieht also so ne art sks im vx ace?
Da ich nur die Demo des ACE getestet habe, das Programm selber aber (noch?) nicht besitze, bin ich diesbezüglich leider nicht allwissend
Ich habe die Sache mit den Scripts nur mal ausprobiert. Was es sonst noch so gibt ... weiß ich nicht.
Naja ich hab schon die vollversion und ich bin voll zufrieden mit dem ace.
Mich stört auch das blockige aussehen der autotiles überhaupt nicht,denn wer die guten SNES-Klassiker
gespielt hat der müsste sowas schon in der art gesehen haben.
Am besten find ich das Feature-System(auch wenn ich da noch nicht ganz durchgeblickt habe xD),denn da kann man dem
Char,dem skill,usw seine eigenen individuellen eigenschaften verleihen
Gruß
@porschefan
Ich weiß nicht direkt ob es so ein Skript schon gibt, aber eventuell lohnt sich ein blick in die Master Script List im offiziellen Forum.
Die meisten Leute sind halt von den selbstgemachten Tiles verwöhnt, die zweifelsfrei sehr viel detaillierter warenZitat
Da gibt's eigentlich nicht viel dran zu verstehen, das System erklärt sich doch von selber. Was blickst du denn nicht?
Ka sieht einfach auf dem ersten blick unübersichtlich aus aber ich checks so langsam^^
Sodale,
noch einmal vielen Dank für die guten Ratschläge. Ich habe mir letzte Woche den »VX Ace« gekauft und bin jetzt erst einmal ein wenig erschlagen. Ich glaube, ich muss damit erst einmal eine Weile herum spielen, bevor ich »zur Tat« schreite. Wenn ich bedenke, dass die Software nur $90 kostet (also ca. EUR 72,00) ist das wirklich eine unglaubliche Menge an Zeugs, was man da in die Hand bekommt. Und obendrein darf man die so erzeugten RPGs auch noch verkaufen.
Das »Event«-System gefällt mir sehr gut. Das ist eigentlich ziemlich einfach zu lernen (ich arbeite allerdings hauptberuflich als Programmierer). Was mir komplett fehlt, ist ein Einstieg in die Programmierung von – ich hoffe ich benutze jetzt keinen falschen Ausdruck – »RGSS3«. Also das eingebaute »Ruby«.
Kleine Beispiel. Nachdem ich eine Stunde mit den Events herum gespielt habe, hatte ich folgendes Problem: Mein Hauptcharakter soll kein einziges Gebäude in meiner Stadt betreten, bevor er nicht mit einer bestimmten Person gesprochen hat. Sprich: Er dreht sich zum Spieler um (also nach Süden), sagt einen schlauen Spruch (»Ich will da noch nicht rein! Lass uns erst mit der Person sprechen.« oder so etwas in der Art) und geht wieder einen Schritt zurück.
Gut, DAS ist mit den Events noch überhaupt kein Problem. Ganz im Gegenteil, das bringt sogar total Spaß, das zu basteln. Vorher fragt man noch einen Switch ab (der gesetzt wird, wenn er denn mit besagter Person gesprochen hat) und alles freut sich.
Jetzt kommt's aber: Wenn man, sagen wir einmal, zehn Gebäude in der Stadt hat, darf man für jeden der zehn Eingänge das Event kopieren. Da wäre eine – in der Programmierung nennt man das so – Unterroutine bzw. auf Ruby gemünzt ein eigenes Objekt von Vorteil. Das macht für jeden Eingang immer das gleiche (siehe oben). Oder noch besser: Nach zwei Eingängen könnte der Charakter einen schon etwas bestimmteren Spruch an den Spieler loslassen (»Ich habe doch schon gesagt, dass ich da noch nicht rein will!«). Tja, wie das geht: Keine Ahnung. Aber das kommt sicher noch.
Was ich aber während der Event-Programmiererei am Tollsten fand: Bei mir sprudelten sofort die Ideen, was man so alles machen kann. So habe ich kurz mal eine Platform gebaut, die beim betreten das Licht in »purpur« dimmt, eine neue Musik spielt und den Charakter erst einmal verwirrt umher sehen lässt. Total einfach und total klasse!
Die Kinnlade stand mir wirklich offen bei der Möglichkeit, ALLE Grafiken zu exportieren, diese in einem Grafik-Programm der Wahl (PhotoShop, GIMP, Paint Shop Pro) zu bearbeiten und dann wieder zu importieren. Kleines Beispiel: Aus dem eingebauten kleinen blauen »Slime« kann man so wirklich ruckzuck eine Horde von farbigen Monstern basteln, in dem man ihn in einem Malprogramm einfach umfärbt. Das ist grandios!
Ebenso die Möglichkeit, OggVorbis-Audio zu verwenden und dort auch noch Loop-Points setzen zu können.
Übrigens, kleiner Tipp: Ich habe die Software nicht sofort gekauft, sondern den Bestellvorgang nicht beendet. Nach zwei Tagen bekam ich eine E-Mail, die mir 15% Rabatt gewärt hat. Das ist doch was! :-)
Wie immer,
The Inflater
Geändert von Inflater (21.05.2012 um 10:37 Uhr)
@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:
--
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 14: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 13: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
