Seite 4 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 61 bis 80 von 95

Thema: Neuer RPG Maker - RPG Maker MV

  1. #61
    Zitat Zitat von Shining Beitrag anzeigen
    Java ist vlt ganz nett um ein ganzen Spiel darin zu schreiben, aber das ist nicht der Zweck des Scriptinteraces des Makers.
    Das Scriptinterface ist dazu gedacht kleine Plugins, Änderungen etc zu ermöglichen.
    In Ruby und JS kann man zB ohne Probleme ein neues Script hinzufügen, welches vorhandene Methoden einer Klasse überschreiben und oder hinzufügen kann - auch wenn die Klasse ganz woanders definiert wurde.
    Ein neues Script kann so zB einige Aspekte des Menüs ändern, ohne das Menüsystem komplett neu schreiben zu müssen.
    In Java geht das hingegen nicht, da muss die gesamte Klassendefinition in einer einzigen Datei stehen.
    Wie bitte?
    In Java geht so ziemlich alles. Sogar Kompilieren zur Laufzeit und das dynamische Erzeugen von Klassen und Methoden.
    Alles was eine Scriptsprache kann, kann eine kompilierte Sprache ebenfalls, allerdings tut man es mit kompilierten Sprachen oftmals nicht, weil es als hässliches Design betrachtet wird.
    Aber wo ein Wille ist, ist auch ein Weg.

  2. #62
    Etwas offtopic, da es nicht mehr um den MV geht, aber ich möchte jetzt wirklich etwas dazu lernen.
    Erklärt mir mal (ggf per pn), wie ihr folgendes Problem in Java lösen würdet.

    Angenommen wir haben folgendes vorhandenes Skript:
    (zunächst Ruby)
    Code:
    class GameActor
    	[...]
    	def speed
    		[...]
    	end
    end
    Ich möchte die Formel für die Geschwindigkeit ändern. Da das ganze ein Plugin werden soll, will ich nicht bereits bestehenden Code verändern, sondern nur neuen hinzufügen.
    Desweiteren gibt es ja vielleicht mehrere verschiedene Plugins, die beide die Klasse GameActor manipulieren sollen, ich kann also auch nicht einfach die Klasse GameActor durch eine neue ersetzen.
    In Ruby reicht ein neues Script mit
    Code:
    class GameActor
    	def speed
    		neuer kram
    	end
    end
    dadurch wird nur die speed Methode überschrieben.

    Wie würde man soetwas in Java lösen?

    Vergleichbare Klasse in Java:
    Code:
    public class GameActor {
    	[...]
    	public int getSpeed() {
    		[...]
    	}
    }
    Mein erster Ansatz wäre wie Pepo Vererbung zu benutzen. zB
    Code:
    public class MyGameActor extends GameActor {
    	public int getSpeed() {
    		[...]
    	}
    }
    Jetzt muss ich aber überall, wo ein GameActor Objekt erzeugt wird, stattdessen ein MyGameActor Objekt erzeugen.
    Ich muss also doch bereits bestehenden Code verändern. Außerdem habe ich nun das Problem, dass bei verschiedenen Plugins, die die Klasse verändern, jedes Plugin eine eigene Unterklasse von GameActor verwenden will.

    Was für andere Wege Methoden zu ersetzen gibt es? Ich weiß man kann auf Methoden von Klassen zugreifen, ich kenne aber keinen Weg, sie direkt zu ersetzen.
    Code:
    Method speed = GameActor.getMethod("getSpeed")
    setMethod gibts ja leider nicht...

  3. #63
    Erstens: Was du in Ruby getan hast ist grauenvolles Design und es wird dir von jedem erfahrenen Programmierer davon abgeraten werden soetwas zu tun. Vorhandenen Code von einer anderen Stelle aus zu überschreiben verstößt gegen alle Arten von Regeln guter Programmierung.

    Wenn du es allerdings in Java tun willst, dann kannst du, zum Beispiel, Byte-Code Injection verwenden um den vorhandenen Byte-Code deiner GameActor Klasse mit beliebigem anderen Code zu überschreiben. Du wirst aber nirgendwo Freunde mit soetwas finden. Falls du jemals ein Portfolio für mögliche Arbeitgeber zusammenstellen möchtest würde dir solch ein Code wahrscheinlich sofort Tür und Tor versperren.

    Ganz Nebenbei:
    Alles geht beim Programmieren. Es gibt keine Naturgesetze die uns an irgendetwas hindern. Du hast zu jedem Zeitpunkt die vollständige Kontrolle über deine Hardware; du kannst den Speicherplatz beliebig beschreiben. Am Ende sind alles nur Bits und Bytes.

  4. #64
    Es ist ja auch nicht so, dass im Beispiel oben die Methode speed erweitert wird, sie wird komplett überschrieben. Wenn nun ein neues Plugin eingebunden wird, das wieder eine andere speed-Methode hat, dann wird die Methode nochmal überschrieben. Es kann immer nur eine Speed-Methode geben. Was würde es schaden, die Methode direkt in Game Actor umzuschreiben?

  5. #65
    Zitat Zitat
    Erstens: Was du in Ruby getan hast ist grauenvolles Design und es wird dir von jedem erfahrenen Programmierer davon abgeraten werden soetwas zu tun. Vorhandenen Code von einer anderen Stelle aus zu überschreiben verstößt gegen alle Arten von Regeln guter Programmierung.
    Zitat Zitat
    Was würde es schaden, die Methode direkt in Game Actor umzuschreiben?
    Es geht um Plugins, also Code den du zB hier im Forum posten kannst und jemand ohne Ahnung einfach in sein Spiel kopieren kann - das klassische "erstelle ein neues Skript über Main und füge das hier ein".
    Mein Beispiel ist da natürlich extrem simpel. Stellt euch ein komplexeres Skript vor, dass viele standard Klassen verändert. Ziel ist es doch ein einfaches Plugin System zu haben, bei dem man eben nicht an 5 verschiedenen Stellen etwas ändern muss.

  6. #66
    Dann müssen einfach die entsprechenden Standardklassen derart designed werden, dass man soetwas wie Plugins angenehm einfach verwenden kann.
    Was du in Ruby machst ist in der Software-Entwicklung verpönt. Aber im RPG-Maker bist du mehr oder minder dazu gezwungen, weil der Code der Standardklassen unter aller Sau ist. (Vielleicht ein bisschen übertrieben, aber der Code ist dennoch ziemlich schlecht)

    Wenn du ein gutes System haben möchtest, welches Plugins unterstützt, dann würdest du eine ordentliche Klassenhierarchy mit Factories und Delegation aufbauen um alle einzelnen Bestandteile modular austauschen zu können. Allerdings muss man dafür etwas mehr als minimale Programmierkenntnisse besitzen, also schätze ich soetwas ist für die Entwickler des RPG-Makers zu viel.

  7. #67
    Zitat Zitat von Cornix Beitrag anzeigen
    Aber im RPG-Maker bist du mehr oder minder dazu gezwungen, weil der Code der Standardklassen unter aller Sau ist. (Vielleicht ein bisschen übertrieben, aber der Code ist dennoch ziemlich schlecht).
    Dafür aber sauber auskommentiert, was ich für wichtiger halte.

    So kann ich den Code verstehen. Aber ich habe mich entschieden z. B. mein Spiel eh komplett über Events laufen zu lassen, da ich keine Lust habe mich nochmal neu in Ruby bzw. die Feiheiten von RGSS3 einzuarbeiten.

    Klar, so was wie eine Hypoth-Funktion bzw. allgemein eine Wurzel wird schmerzhaft vermisst aber da ja nicht alles 100 % korrekt in einem RPG-Maker-Spiel laufen muss kann man da super irgend nen Quark runterscripten der halt läuft und Ergebnisse im richtigen Bereich liefert.

    Guter Code? Nein! Spaß beim "Spiel machen"? Ja!

    Und für ein Hobby-Projekt auch voll ok.

    PS: Sorry für´s Offtopic.


  8. #68
    Zitat Zitat von Pepo Beitrag anzeigen
    Dafür aber sauber auskommentiert, was ich für wichtiger halte.
    Eh? "Sauber auskommentiert" mag Ansichtssache sein, mMn zählen die Kommentare im RPG Maker mit zu den unnützesten überhaupt, weil sie fast nie genutzt werden, um Code zu erklären, sondern oft - manchmal wortwörtlich - wiederholen was als Code schon da steht.
    Im Ace wurde das reduziert, aber im XP (und vermutlich auch im VX), wo scheinbar krampfhaft versucht wurde wirklich jeder Zeile einen Kommentar zu verpassen, findet sich zuhauf Blödsinn wie das hier:
    Code:
    def moveto(x, y)
      super
      # Centering
      center(x, y)
      # Make encounter count
      make_encounter_count
    end

  9. #69
    Exakt. Die Kommentare im RPG-Maker (zumindest im XP) sind die absoluten Anti-Kommentare. Sie verbessern den Code nicht, ganz im Gegenteil, sie machen die Qualität des Codes sogar schlechter.

  10. #70
    Zitat Zitat von Cornix Beitrag anzeigen
    Exakt. Die Kommentare im RPG-Maker (zumindest im XP) sind die absoluten Anti-Kommentare. Sie verbessern den Code nicht, ganz im Gegenteil, sie machen die Qualität des Codes sogar schlechter.
    Ich besitze den Ace und da waren die Kommentare zumindest aus meiner subjektiven Sicht gut, da ich mit ihnen den Code schnell nachvollziehen konnte.

  11. #71
    Das kann sein. Es sollte nicht schwer sein bessere Kommentare als im XP zu schreiben wenn man bedenkt, wie schwer es sein muss schlechtere Kommentare schreiben zu können.

  12. #72
    Typescript statt Ruby ist mal megascheiße. Sonst hört sich das alles ziemlich gut an.

  13. #73

    "Vibration of Nature" - It's a long story
    stars_mod
    Also ich find es ja sehr cool, dass der neue RPG-Maker auf JavaScript und HTML5 setzt.

    Und Java? Bloß nicht.
    Klar kann man mit Java das selbe erreichen wie mit jeder Skriptsprache - nur mit dem Unterschied, dass es keinen Spaß macht und man sich die Finger wund schreiben muss.

    Im Vergleich zu Ruby/JavaScript ist Java vom Design sehr viel strikter veranlagt. Typen werden sehr genau genommen und jede Erweiterung muss vom Design exakt berücksichtigt werden (über Interfaces oder abstrakte Klassen).
    Shining hat in seinem Beispiel ja bereits erklärt, wie es das Erweitern von Klassen umständlich macht.

    Ruby/JavaScript sind hier was Erweiterbarkeit angeht viel flexibler. Natürlich kann man damit viel Mist bauen und sich damit in Richtung "schlechtes Design" bewegen, muss man aber nicht zwangsläufig.

    Letztendlich bin ich aber davon überzeugt das gerade bei der Spielentwicklung viele der strikten Design-Praktiken aus der allgemeinen Softwareentwicklung einfach nicht angebracht sind.
    Spiele brauchen a) nicht die Wiederverwendbarkeit von generischen Software-Libraries/Modulen und sind b) von ihrer Nutzungs/Lebensdauer derart beschränkt, dass ein besondere Augenmerk auf Erweiterbarkeit und sauberer Struktur ein verschwendeter Zeitaufwand ist. Insbesondere Spiel-spezifischen Inhalte darf man ruhig hacken. (wird z.B. auch von Naughty Dog so gemacht: http://www.dualshockers.com/2014/03/...our-long-talk/ )

    ...Im Endeffekt ist es natürlich alles persönliche Präferenz. Ich hatte meine paar Jahre mit Java und vermiss die Zeit jedenfalls nicht. :P

  14. #74
    Zitat Zitat von Lachsen Beitrag anzeigen
    Und Java? Bloß nicht.
    Klar kann man mit Java das selbe erreichen wie mit jeder Skriptsprache - nur mit dem Unterschied, dass es keinen Spaß macht und man sich die Finger wund schreiben muss.

    Im Vergleich zu Ruby/JavaScript ist Java vom Design sehr viel strikter veranlagt. Typen werden sehr genau genommen und jede Erweiterung muss vom Design exakt berücksichtigt werden (über Interfaces oder abstrakte Klassen).
    Shining hat in seinem Beispiel ja bereits erklärt, wie es das Erweitern von Klassen umständlich macht.

    Ruby/JavaScript sind hier was Erweiterbarkeit angeht viel flexibler. Natürlich kann man damit viel Mist bauen und sich damit in Richtung "schlechtes Design" bewegen, muss man aber nicht zwangsläufig.

    Letztendlich bin ich aber davon überzeugt das gerade bei der Spielentwicklung viele der strikten Design-Praktiken aus der allgemeinen Softwareentwicklung einfach nicht angebracht sind.
    Spiele brauchen a) nicht die Wiederverwendbarkeit von generischen Software-Libraries/Modulen und sind b) von ihrer Nutzungs/Lebensdauer derart beschränkt, dass ein besondere Augenmerk auf Erweiterbarkeit und sauberer Struktur ein verschwendeter Zeitaufwand ist. Insbesondere Spiel-spezifischen Inhalte darf man ruhig hacken. (wird z.B. auch von Naughty Dog so gemacht: http://www.dualshockers.com/2014/03/...our-long-talk/ )

    ...Im Endeffekt ist es natürlich alles persönliche Präferenz. Ich hatte meine paar Jahre mit Java und vermiss die Zeit jedenfalls nicht. :P
    Dass Java strikt ist ist ein Vorteil gegenüber den anderen Sprachen. Das, was nicht erlaubt ist (wegen der Striktheit), sind für gewöhnlich Dinge, welche in den anderen Sprachen auch zu einem Absturz führen würden. Aber Java warnt den Programmierer ohne, dass man das Programm dafür testen muss. Wie irgendjemand solch ein Verhalten als Nachteil ansehen kann ist außerhalb meiner Vorstellungskraft.
    Ich habe meine Zeit mit Ruby und den ganzen Scriptsprachen verabscheut. Die fehlende Sicherheit eines schützenden Compilers, die zusätzliche Zeit, welche in das Debugging gesteckt werden muss um triviale Fehler zu finden, welche mit anderen Sprachen garnicht möglich gewesen wären.

    Das Beispiel von Shining war, wie Shining es auch selbst herausgestellt hat, ein extrem schlechtes Beispiel. Die vorgestellte "Erweiterbarkeit" war hier eher etwas abstoßendes. Das Fehlerpotenzial solcher Scripte ist gigantisch und der Wartungsaufwand explodiert sobald man solchen Code schreibt.

    Zu dem was du zur Spieleentwicklung sagst, würde ich das komplette Gegenteil behaupten. Gerade Videospiele profitieren am meisten von gutem Design. Sie zählen zu den komplexesten Programmen überhaupt und eignen sich vortrefflich für die Anwendung von Programmier-Pattern und Software-Prinzipien.
    Besonders wenn man bedenkt, was für eine riesige Anzahl an Spiele-Projekten regelmäßig abgebrochen werden, ganz sicher auch wegen zu schlechtem Code. Denk nur darüber nach wie dringend Videospiele heutzutage von Updates abhängig sind. Neue Funktionalitäten, neuer Content, verbesserte Nutzeroberflächen, optimierte Performance, etc etc. Deine Philosophie im Sinne von "hoffen wir, dass es gut wird" ist keine gute Taktik für die großen Spieleentwickler, welche heutzutage Millionenbeträge in die Entwicklung von Spielen stecken. Spiele, welche in dieser Zeit den höchsten Qualitätsanforderungen gerecht werden müssen.

  15. #75
    Haha, großartig.

    Irgendwie könnt ihr beide letzendlich Recht haben, zumindest kann ich beide Meinungen nachvollziehen. Nur kommt es wahrscheinlich auf die Skalierung eures Teams an. Ein millionenschweres Blizzardspiel, das über die nächten 10 Jahre mit Erweiterungen zugeballert werden soll, würde ich auch niemals in einer Skriptsprache entwickeln und sollte an jeder Stelle auf sein Design achten. Das "kleine" Indieprojekt hingegen kann schnell an so einer fein säuberlichen Arbeitsweise dahingerafft werden. an dieser Stelle sind schnelle Entwicklung und unsaubere Handgriffe schon weitaus mehr zu verkraften, wenn am Ende ein fertiges Produkt bei rumkommt.

    Geändert von csg (28.08.2015 um 02:31 Uhr)

  16. #76
    Zitat Zitat von Cornix Beitrag anzeigen
    Gerade Videospiele profitieren am meisten von gutem Design. Sie zählen zu den komplexesten Programmen überhaupt
    Meinst du das ernst?

  17. #77
    Aber natürlich. Videospiele haben ALLES was es gibt. Man braucht ein ordentliches Model für die Datenhaltung, Nutzereingaben, Speichern / Laden, Netzwerkkommunikation, GUI programmierung, künstliche Intelligenz, Grafikprogrammierung, Zeitverhalten, Multithreading, Plugins, komplexe Algorithmen (Pathfinding, Graphenalgorithmen, etc) und wahrscheinlich noch viel mehr.

    Natürlich hat nicht jedes Videospiel all diese Dinge, aber Videospiele im Allgemeinen können eine beliebige Kombination aus all diesen Themenbereichen verwenden.
    Andere Applikationen, zum Beispiel Simulationssoftware, Finance oder Controller von eingebetteten Systemen müssen sich immer nur um ein paar ganz spezielle Teilbereiche kümmern. Aber in Videospielen sind alle diese Dinge wichtig, sie sind perfekt dazu geeignet um gutes Programmieren zu lernen und zu üben, darum verwenden wir in unseren Praktiken an der Universität immer Videospiele für die Gruppenarbeiten.
    Man kann sie zudem auch noch beliebig schwierig und komplex machen. Von Pong über Zelda zu World of Warcraft kann man die komplexität der Arbeit ins unendliche steigern.

  18. #78
    Ich stimme zu, dass die vielen Disziplinen es zu einem guten Lehrmittel machen, allerdings lassen deine Vergleiche darauf schließen, dass du von den Inhalten von Videospielen mehr weisst als von langweiliger Softwareentwicklung für Business und Industrie ;-)

    Wenn letztere wirklich "nur" so Arbeiten in einem Teilbereich wären, dann hätte ich wohl einen viel leichteren Job. Ein Spiel ist ( MMOs ausgenommen ) ein abgeschlossenes Produkt. Das Team fängt damit an und kontrolliert was rein kommt und wie es zusammen arbeitet. In der weniger spassigen Softwareentwickung ist ein sauberer Neustart, auch noch bei einem Produkt, dass nur für sich selbst funktioniert, ein Luxus, den man leider nur selten genießt.

  19. #79
    Es stimmt, dass man nicht so einfach neustarten kann bei einem kommerziellen Industrieprodukt, aber das ist nur ein weiterer Grund dafür, warum sich ordentliche Programmierung eher in Videospielen finden lässt. In ein Altprojekt kann man nur extrem schwer den "neuesten Stand der Technik" im Sinne von ordentlicher Programmierung integrieren. Und auch wenn es theoretisch geht, so ist es praktisch meistens eine dumme Entscheidung. Es entsteht zusätzlicher Aufwand ohne neue Funktionalität.
    In einem Industrieprojekt muss man mit dem Arbeiten was man bekommt, den Luxus sich an aktuelle Standards zu halten erlebt man nur mit Glück.

    Außerdem sind solche Programme meistens sehr viel stringenter gebaut. Sie tun eine Sache und nur diese Sache müssen sie gut machen. Ein Videospiel ist die Eier legende Wollmilchsau. Es muss in allen Teilbereichen der Programmierung ordentlich gearbeitet werden. Man kann nicht auf einer Seite anfangen ohne zu wissen wie die andere Seite aussehen wird. Bei Industrieprojekten weis man schon sehr viel eher wie das Endprodukt aus zu sehen hat, man kennt die Nutzer (meistens macht man vorher sogar eine Analyse der Nutzer) und Eigenheiten der Software kann man den Nutzern erklären.
    Spiele müssen für die breiteste Allgemeinheit erstellt werden. Plattformunabhängig (am besten auf Konsole und PC) und auch für allerlei Altersgruppen und in verschiedenen Sprachen. Sie sind einfach viel komplexer (im Allgemeinen, natürlich gibt es immer Ausnahmen).

  20. #80
    Zitat Zitat von Cornix Beitrag anzeigen
    aber das ist nur ein weiterer Grund dafür, warum sich ordentliche Programmierung eher in Videospielen finden lässt.
    Die Abteilung Budget- und Zeitplanung möchte dich sprechen, sofort.

    Zitat Zitat
    Bei Industrieprojekten weis man schon sehr viel eher wie das Endprodukt aus zu sehen hat, man kennt die Nutzer (meistens macht man vorher sogar eine Analyse der Nutzer) und Eigenheiten der Software kann man den Nutzern erklären.
    Echt? Ich bin schon froh wenn der Kunde selbst weiss, was er will

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •