Lieber Besucher, herzlich willkommen bei: RPG Studio - Make your World real. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Donnerstag, 13. September 2012, 13:02

Eigenen Maker erstellen oder RPG Maker benutzen - Was ist besser?

Hey hi Leute,

Ich bin Informatikstudent (leider noch im 1. Semester). Am Anfang sollte ich einmal meine Programierfähigkeiten unter beweis stellen. Da dachte ich mir, dass ich auch nen eigenen RPG Maker mache und hier wurde schonmal der erste Grundstein gelegt.

-> Java/Tutorials – Scientia

Mit Java kenne ich mich am besten aus und würde daher, meinen Maker auch mit Java SE programmieren.

Die Sache ist nun, wenn ich schon nen kleinen eigenen Maker mache, wäre es Sinnvoll mit dem später weiterzuarbeiten? Ich würde es schon geil finden.
Ansonsten würde ich gerne ein Spielprojekt mit dem VX oder so anfangen. Welche Erfahrungen und Tipps könnt ihr mir geben?

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

2

Donnerstag, 13. September 2012, 15:31

Ave!
Ich verkneif mir mal Kommentare zu Kaffee/Java. Bin nicht gut auf die Sprache zu sprechen.
Da hängen viel mehr Fragen dran, als auf dem ersten Blick ersichtlich ist. Hast du schonmal zuvor einfache Sachen programmiert, oder ist dein erstes Semester so zu sagen der kalte Einstieg? Ein eigener Maker ist ein ziemlich großes und komplexes Projekt.
Zu aller erst solltest du aufpassen, dich nicht zu übernehmen. Setze dir ruhig hohe Ziele, aber welche, die in deiner Reichweite sind, und arbeite dich so Stufe für Stufe zum fertigen Maker vor. Solche Teilziele erreichst du am besten, indem du deinen Maker Stück für Stück in seine Teile zerlegst (Audio, Graphik,...). Abgesehen davon stellt sich natürlich die Frage, was du willst und was du brauchst. Soll der Maker allgemein brauchbar sein, oder ist er am Ende nur für dein Spiel? In letzterem Fall musst du dich weniger darum kümmern, Code allgemeingültig zu halten, Schnittstellen für Scriptsprachen zu verbauen, Editoren für jeden Pups zu basteln, und so weiter, da du nur das implementieren müsstest, was du selbst brauchst. Die nächste - und kniffligste - Frage wäre, ob du eine fertige Engine nutzen möchtest, oder lieber alles von Grund auf neu schreibst. Wenn du noch nicht mit viel Erfahrung besegnet bist, würde ich dir ans Herz legen, eine fertige Engine zu verbauen. Ich würde jetzt spontan SDL sagen, aber für Kaffee gab's da doch auch so was in der Art... Fertige Engines haben in aller Regel eine zu Mindest gute Leistung und sind gut zu Handhaben. Sie sind bis auf wenige Ausnahmen fehlerfrei, haben sich über Jahre bewehrt und entwickelt, und ersparen dir viel, viel, sehr viel Frust. Solltest du allerdings doch selbst die Engine deines Makers basteln wollen, rate ich dir, deine Ziele nicht höher zu stecken als das, was dein Spiel braucht. Nachher kann man sie immer ausbauen. Die Entwicklung einer sehr starken und komplexen Engine dauert lange, frustriert oft, und erfordert viel strategisches Wissen und Wissen um die Schnittstellen, die man verwendet (wie z.B. OpenGL), die oft extrem unterschiedlich zu Handhaben sind. (Glaub mir... ich kenn das.)
Aber Eines ist sicher:
Wie komplex und leistungsfähig dein Maker auch sein mag, und wie hoch auch immer der Eigenanteil am Code sei - Es wird ein ziemlich knorke Gefühl sein, damit das eigene Spiel zu entwickelt ;3 (Der Haken daran ist natürlich, dass sich so die Entwicklung des eigentlichen Spiels enorm verzögert, was wiederum frusten kann. Glaub mir... das kenn ich auch.)

Gruß und Segen,
Imperator Mundi
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

3

Donnerstag, 13. September 2012, 16:29

Ein Sprung ins kalte Wasser ist das jetzt nicht.
Im Abitur haben wir schon programmieren gelernt. Zwar "richtig kleine Games", aber für die Abschlussprüfung mussten wir schon die wichtigsten Funktionen gelernt haben.
Klar will ich mir den Maker nicht aus der Hand schütteln. Ich habe mir gedacht, dass ich das zu einem 3-Jahresprojekt mache! :D
Dieses Jahr will ich halt die wichtigsten Funktionen schaffen, damit mein Team anfangen kann.
Ich habe einen extra für Sounds und Testgaming.
Der andere kann gut Graphics selber erstellen ..... ist son Künstler^^
Und ich werde wahrscheinlich mit einem oder zwei weitere halt Codes schreiben. Vieles wird sich auch bei der Arbeit herausstellen, was getan werden muss.
Wir werden erstmal am Anfang an der Story basteln, bevor wir zur Umsetzung kommen. Bis dahin sollte, dass wichtigste fertig sein.

Innerhalb des Informatikstudiums werde ich mich auch weiterbilden und das Projekt sehe ich eher als "Spielwiese", wo ich mich auch ausprobieren kann.
Zudem wie gesagt, gibt es bestimmt einige fertige Engines und andere Entwickler die einem bestimmt helfen können.

4

Freitag, 14. September 2012, 15:39

Moin,

Gegenfrage, wozu das Rad neuerfinden ? Der Maker ist doch schon da, also warum irgendwas eigenes zusammenkloppen, was eh schon bald inner Ecke liegt?
Die passende Antwort dazu wäre: Flexibilität. Leider ist der Maker relativ eingeschränkt, indem, was man machen kann.

Ich Schraube seit gut 3 Jahren jetzt an einem Editor rum, der dem Maker sehr nahe kommt.
Jedoch ist dieser genau auf mein Spiel zugeschnitten, welches ich damit bearbeiten will.
Sonst nichts. Einen weiteren Maker zu bauen, lohnt sich nicht. Eine weitere ganze Engine?
Auch nur wenn die bisherigen nicht reichen. Vorallem sind solche Projekte nichts für jemanden der mit dem Programmieren anfängt.
Du lernst dabei nämlich nichts, es ist meistens nur ein und das selbe. Textbox einfügen, Werte laden, speichern etc.

Ein kleines Spiel zu schreiben, macht da viel mehr Sinn. Jedoch muss man die Grundlagen kennen.

Achja und eine vernünftige Sprache sollte man wählen, dazu zählt Java nicht gerade. Zumindest nicht für Spiele. Wieso? Lernt Java dann wisst ihr wieso :3
Eine alternative wäre C# und XNA oder wenns wirklich was gutes werden soll vllt noch C++

Alle die sagen, äh wieso C++ oder C#, das brauch doch keiner, haben sich nie wirklich mit Spiele entwicklung beschäftigt :D Oder arbeiten bei EA ;)

Evrey

Oberschurke im Ruhestand

Motto: "Satzzeichen sind keine Rudeltiere." - Chesra

  • Nachricht senden

5

Freitag, 14. September 2012, 18:22

Ich sag das als C++- und Assembly-Fan: Die Sprache ist theoretisch gesehen wumpe und sollte nach eigenen Bedürfnissen gewählt werden. Wer eine Hochleistungs-Engine basteln will, der kann sich an C/C++ bedienen, Compiler-Fetures wie declspec(...) unter MSVC oder __attribute__(...) und die Builtins unter GCC nutzen, Intrinsics für tolle Befehlssatz-Erweiterungen nutzen, wo es sinnvoll ist, oder für die, die wirklich wissen was sie tun und mit Intrinsics nicht weiter kommen, oder einfach wahnsinnig sind, Inline-Assembly verbauen.
Er wird wohl kaum vor haben, Physik, unscharfe Logik, drölfhundert Mapping-Layer, und das alles mit gefühlt 7000 Bots auf einer Karte, oder andere Leistungsfresser zu verbasteln. Auch mit Kaffee kann man nette 2D-Spiele im RMXP-Leistungsbereich und auch gern mal technisch anspruchsvolleres entwickeln. Kaffee bietet auch ein wesentlich breiteres Spektrum nützlicher Standard-Bibliotheken als C++. Somit kann man es sich dort auch sparen, zigtausend Libs wie Boost, Qt, oder was nicht noch alles zu verbasteln.

Zitat

Gegenfrage, wozu das Rad neuerfinden ?
Tut nicht weh, macht Spaß, und bringt erkenntnis. (Setzt allerdings nötige Erfahrung voraus, es so weit bringen zu können. Andernfalls bringt es nur Frust.)

Zitat

Leider ist der Maker relativ eingeschränkt, indem, was man machen kann.

Zitat

Ich Schraube seit gut 3 Jahren jetzt an einem Editor rum, der dem Maker sehr nahe kommt.
Jedoch ist dieser genau auf mein Spiel zugeschnitten, welches ich damit bearbeiten will.
Das ist der Punkt. "Leider" ist der RPG Maker 2k, XP, VX, VXA, <insert future maker here> als allgemeinnütze(r) Engine und Editor für RPGs eingeschränkt. So lange man einen solchen Maker auf das eigene Spiel zu schneidet, ist es wumpe, was er kann. Wenn man allerdings das Rad als "Massen-Tool" neu erfinden will, muss man schon ganz schön was bieten können.

Zitat

Einen weiteren Maker zu bauen, lohnt sich nicht. Eine weitere ganze Engine?
Auch nur wenn die bisherigen nicht reichen. Vorallem sind solche Projekte nichts für jemanden der mit dem Programmieren anfängt.
Du lernst dabei nämlich nichts, es ist meistens nur ein und das selbe. Textbox einfügen, Werte laden, speichern etc.
Siehst du den Widerspruch? Zwei Szenarien...
Erstens: Du nimmst eine fertige Engine. Um dafür eine Editor-Sammlung zu basteln, musst du zunächst die Engine verstehen lernen, lernen, sie so zu verbauen, dass sie tut, was du von ihr als Engine für deine Pläne erwartest (z.B. ob es RPGs oder Jump'n'Runs oder Ähnliches ausführen soll, sofern die Engine nicht bereits spezialisiert ist). Und dann erst kommt die lästige Arbeit, Parameter von Fenstern aus in für die Engine verständliche Dateien zu schubsen.
Zweitens: Du baust die Engine selbst. Dass der Lerneffekt hierbei enorm sein kann (Sofern man die Grundfähigkeiten hat, so ein Projekt zu beginnen) sollte offensichtlich sein.
Und selbst beim Parameter-Geschubse von GUI nach Datei lernt man zumindest, mit der verbauten GUI-Lib umzugehen, was auch ganz schön was ist.
Vom Einbinden möglicher Scriptsprachen brauche ich nicht erst zu reden.

Zitat

Eine alternative wäre C# und XNA
Außer, Cross Platform -fähiger Code ist ein wichtiges Kriterium.

Zitat

Im Abitur haben wir schon programmieren gelernt.
Das beste Praxiswissen ist oft selbst angeeignet.

Zitat

Ich habe mir gedacht, dass ich das zu einem 3-Jahresprojekt mache!
Wenn du diszipliniert und fleißig lernst, ist das ein durchaus realistischer Zeitrahmen. Und plane auch bei kleineren Zielen immer mehr Zeit als nötig ein. Es kommt immer etwas da zwischen.

Zitat

Und ich werde wahrscheinlich mit einem oder zwei weitere halt Codes schreiben
Plane gut und sprech' dich gut mit ihnen darüber ab, wer was tut, wie welche Schnittstellen sind, und so weiter. Programmieren im Team ist kompliziert und ohne gute Verwaltung zeitfressend und eine reine Fehlerfabrik. Erst gute Planung macht daraus einen bequemeren und beschleunigten Arbeitsablauf.

Zitat

Vieles wird sich auch bei der Arbeit herausstellen, was getan werden muss.
Vieles lernt man auch erst in der Praxis. Vor dem Bau meines Makers habe ich zum Beispiel noch nie mit OpenGL und Qt zu Tun gehabt. Das änderte sich zwangsweise. Dennoch müssen grundliegende Fähigkeiten im Idealfall bereits vor Projektbeginn sitzen. Ansonsten endet das darin, dass man dreiviertel der Engine fertig hat, und dann alles neu schreibt, weil man plötzlich begreift, was man zuvor für einen Schrott-Code fabriziert hat.

Ich kann dir nur raten, viel und gut zu lernen und zu üben. Schul- und Erstsemesterwissen allein wird dich nicht weiter bringen.
  • :medal: Werbung

    Bild

    Cpp Quellcode

    1
    
    #define TRUE FALSE //Happy debugging suckers
    (Einfach nur wundervoll.)
  • :palette: 1plus3 :cake:

    Bild
  • :fires: Nuuuhminaaah

    Bild
  • :medal: compétences

    mes compétences
    :heart_full: :heart_full: :heart_full: :heart_full: :heart_full: max.
    :ruler-triangle: Maps machen :heart_full: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :media-player: Musik machen :heart_full: :heart-half: :heart-empty: :heart-empty: :heart-empty:
    :cup: Scripts machen :heart_full: :heart_full: :heart_full: :heart_full: :heart-break:
    :paper: Story ausdenken :heart_full: :heart_full: :heart_full: :heart-empty: :heart-empty:
    :cut: Pixeln und so :heart-empty: :heart-empty: :heart-empty: :heart-empty: :heart-empty:
    :game: Events proggen :heart_full: :heart_full: :heart_full: :heart_full: :heart_full:
    (Dieser Tab ist rein satirisch.)
  • :folder-open: mes projets

    • :addressbook: Silentium
      :book: Name: Silentium
      :rmxp: Maker: Eigenbau (C++, x86-SSE/AVX-Assembly, Ruby/Lua)

      :paper: Story
      :game: NPCs
      :cup: Scripts
      :drill: Ressis
      :ruler-triangle: Maps
      :compile: Gesamt
      (3+4)% 42 69% 0815 -17.438 103.38% ± 6.3mm²

      (Die Tabelle erfüllt lediglich satirische Zwecke.)
    • :compile: Onyx
      Eine in C++ implementierte, modulare, plattformunabhängige, virtuelle Maschine. Die Test-Version ist bereits halb fertig. Ab dann gibt es vielleicht mehr Infos. Sie soll die auf dem ersten Blick LISP-artige und eigens dafür konstruierte Sprache Obsidian ausführen können. Experimentell wird auch ein Lua-Compiler für Onyx gebaut. Ziel ist eine leistungsfähige, virtuelle Maschine für beliebige Scriptsprachen. Theoretisch gesehen müsste man bloß noch einen kompatiblen Compiler schreiben, der Quellcode jener Sprache in Onyx-Assembly, oder direkt in Onyx-Bytecode übersetzt. Ob die jemand nutzen wird, ist eine andere Frage und nur ein sekundäres... nein, eher tertiäres Ziel dieser VM. Primär dient es mir lediglich dazu, mein Verständnis von Hardware, ISA, und Assembly zu vertiefen, sowie eigene Grenzen auszutesten.

      :exclamation: Warnung!
      Das Entwickeln einer virtuellen Maschine oder Programmiersprache (im wahnsinnigsten Fall beides) ist eine höchst komplizierte Tätigkeit, aus der viel Frust und Hirnmatsche hervor gehen. Sollte sich dennoch ein ähnlich wahnsinniger finden, der sowas zusammen schustern will, so lege ich ihm/ihr die folgenden Bücher ans Herz:
      • Compiler - Das Drachenbuch [978-3-8273-7097-6]
        Dieses Buch schlachtet ausführlich und leicht verständlich die Grundlagen bis hoch zu den Experten-Techniken des Compilerbaus aus. Es fängt mit der Automaten-Theorie und formalen Sprachen an, arbeitet sich durch Analysetechniken vor, und landet schließlich bei Techniken wie Optimierung und Register-Zuweisung. Das Buch wiegt 3Kg oder 4Kg. Hab's mal gewogen. Ist also nicht gerade die Lektüre für unterwegs.

      • Computerarchitektur [3-8273-7016-7]
        Hier werden leicht verständlich die wichtigsten Entwicklungen der Rechnerarchitekturen erklärt (Gut, das Buch ist in die Jahre gekommen, aber der Weg zu heute ist ein winziger Schritt, den man sich nach diesem Buch selbst erdenken kann). Hauptbestandteil des Buchs ist eine relativ umfassende Betrachtung der Funktionsweise dreier gänzlich unterschiedlicher, aber dominierender Prozessor-Typen am Beispiel des Pentium II, UltraSPARC II, sowie picoJava. Die meisten Elemente dieses Buchs sind zwar für die Konstruktion einer virtuellen Maschine irrelevant, oder aufgrund der Tatsache, dass die VM Software ist und z.B. Byte-Grenzen hat, sogar zu Leistungseinbußen führen kann, doch ist ein hinreichendes Verständnis dieser Maschinen, mit denen wir arbeiten, äußerst hilfreich für die Überlegungen, wie die VM arbeiten soll.

      Es kann sehr hilfreich und inspirierend sein, den Code quelloffener, virtueller Maschinen anderer Sprachen zu überfliegen. Meine Lieblings-Quelle war und ist stets die VM von Lua. Sie ist schlank, verständlich, in C implementiert, und basiert im Gegensatz zu vielen anderen Scriptsprachen-VMs auf einer Register-Maschine statt einer Stapelmaschine. Es wäre natürlich vorteilhaft, die entsprechende Sprache zu verstehen, in der man auch die eigene VM implementieren will. Weiterhin ist es äußerst vorteilhaft, eine leistungsstarke und bequeme Sprache wie C++ zu beherrschen, um die VM zu implementieren. Und bevor irgendwer auf die Idee kommt: Assembly ist NICHT als dominierende Sprache für den Bau einer VM geeignet. Wer die Frage des "Warum?" nicht beantworten kann, sollte zunächst die gewählte Sprache und Assembly hinreichend verstehen lernen, und es dann erneut mit der Frage versuchen. Es lohnt sich dennoch, Assembly zu lernen. Allein schon, um erneut das Verständnis zu vertiefen, zumal ihr mehr oder weniger gezwungen seid, auch für eure VM eine Assembler-Sprache zu entwickeln (Außer natürlich ihr schreibt eure Test-Programme Bit für Bit ;3).
  • :locale: enfin

    Je ne peux pas parler français.
    C'est tout ce que Goodle et les restes de cours de français.
Signaturstand: 24.07.2013

Blitz 2

Krieger

Motto: Das Leben ist ein Auf und Ab wie Hantelcurls

  • Nachricht senden

6

Samstag, 15. September 2012, 22:34

Wieso gleich einen Maker erstellen ? Benutz dein Programmier wissen und erstell soo ein spiel.
Ich finde das viel besser, weil der Maker manche funktionen nicht hat (Nervt mich öfters)
Könnte ich programmieren würde ich mein Spiel so programmieren.
Aber schließlich ist es ja deine endscheidung.


LG Blitz 2 :D
Bild

7

Sonntag, 16. September 2012, 02:07

Bei der Erstellung eines [Insert Genre]-Makers programmiert man letztendlich nur ein Data Driven Game Framework welches eine Grafik Engine nutzt. Für die Erstellung der Daten entwirft man dann einen passenden Editor. Im folgenden möchte ich auf diese drei Punkte eingehen.

Grafik Engine
Heutzutage setzt eigentlich alles auf DirectX und OpenGL auf. Im mobilen Bereich ist OpenGL ES (Embedded Systems) führend. Kernelement der heutigen Libraries ist die Graphic Pipeline. Früher noch von den Grafikkarten-Herstellern hardcoded, sind die heutigen Pipelines darauf ausgelegt vom Spieleentwickler programmiert zu werden. Dies geschieht hauptsächlich durch Vertexshader und Pixel/Fragment -shader. Neuerdings auch Geometry Shader. Falls man also ansprechende und einzigartige Effekte erzeugen will, sollte man sich intensiv mit diesen Thema außeinandersetzen. Das erlernen einer weiteren Speziellen Shader Language wie z.B. GLSL oder HLSL ist dabei unabdingbar.

Als Einzelperson oder Hobby Entwickler ist es zwar möglich, mit diesen Libraries zu arbeiten, aber ein ziemliches lästiges Unterfangen. An dieser Stelle muss man das Rad nun wirklich nicht neu erfinden. Gerade wenn es schnell gehen soll und man sich hauptsächlich auf sein Spiel konzentrieren will. Wenn man sich also nicht unbedingt auf dieses Gebiet spezialisieren will um später in einer entsprechenden Firma angestellt werden, dann gibt es als Ersatzlösung viele kommerzielle Engines wie und auch Open Source Lösungen. 2D? 3D? Hardwarebeschleunigt? Je nach Wahl fällt der Funktionsumfang entsprechend aus. Je mehr Funktionen, desto länger die Einarbeitungszeit. Viele der Lösungen bieten dem Programmierer glücklicherweise weiterhin die Möglichkeit Shader einzubinden.
Wie z.B Irrlicht, OGRE, Unity, Unreal, Cry Engine oder speziell für Java die LWJGL. Welche auch von Minecraft genutzt wird. Auf jedenfall einen Blick Wert.
Nun sind die meisten der genannten Engines auf 3D Spezialisiert, deswegen sollte man sich hier die Frage stellen: "Brauche ich diesen Funktionsumfang?"
Wenn nein, dann sollte man lieber etwas weiter suchen und vielleicht doch eher auf kleinere Engines ausweichen. Braucht man generell keine 3D und Shader Funktion, dann sollte man sich speziell auf 2D Engines konzentrieren wie z.B. SFML, Allegro, Flixel oder FlashPunk
Gerade die letztend Beiden der genannten sind extrem einsteigerfreundlich und führend schnell zu Ergebnissen. Schau dir entsprechende Showcases an. Falls du mehr der Typ für klassische 2D Spiele bist, kann ich dir diese nur wärmstens empfehlen. Beide sind Action Script 3 Frameworks für Flash/Flex und erzeugen letztendlich .swfs für den Flash Player (aktuell 11.4). AS3 ist Java, von der Syntax her, sehr ähnlich, wenn nicht sogar fast identisch. Falls dir der Flash Player als Platform nicht ausreicht, so gibt es weiterhin die möglichkeit mittels AIR Android Native Applikationen zu erzeugen, welche du auch z.B. bei Google Play verkaufen kannst. Seit Version 11 bietet der Flash Player außerdem einen neuen Funktionsumfang an, welcher vielen Leuten noch nicht so bekannt ist. Es handelt sich um Stage3D, einer Schnittstelle zur Grafik Hardware (oder eher OpenGL/DirectX). Womit nun auch grafikintensive Anwendungen und Spiele möglich sind. Speziell für Stage3D gibt es bereits einige 3D und 2D Frameworks wie z.B. Flare3D, Axel 2D. Insgesamt tendendiere ich hiebei eher zu Stage3D als WebGL, welches angeblich mit HTML5 im Kommen ist. Ich warte noch immer.

Data Driven Game Framework
Findet man Grafik Engines noch wie Sand am Meer, so gibt es reine datenbetriebene Game Frameworks recht selten. Einer der Gründe ist wohl, das Spiele mitunter sehr unterschiedlich aufgebaut sein können. Das Framework ist jedenfalls das Bindeglied zwischen Spieledaten vom Editor und der Grafik Engine. Das Framework ist dabei zumeist das Spiel selbst, oder das Spiel in einer abstrahierten allgemeinen Form. Im Falle des RPG Makers wäre das der RGSS Player oder die RPG_RT. Beide laden alle Daten (Spieleressourcen, Maps, Sprites, Musik ect.) und generieren daraus einen Programmablauf, welcher durch die entsprechende Grafik Engine dargestellt wird. Das Spiel selbst ist in diesem Sinne auch ein Datensatz, nicht das Programm, da das Spiel selbst ja vom Player interpretiert wird. Dies geschieht durch Skriptsprachen und Interpreter. In diesem Sinne ist es nützlich sich das Interpreter Software Pattern anzuschauen.

Häufig ist es so, dass die entsprechende Spiele- oder Grafikengine das Handling der Daten vorgibt oder übernimmt. Das ist nicht immer nützlich, aber zumeist eine große Hilfestellung.
Das Game Component System von XNA ist ein gutes Beispiel. Hier werden die meisten Grundfunktion vorgegeben. Der Programmierer brauch letztendlich nur von den notwendigen Klassen erben und kann sein Spiel nach Belieben mit neuen Funktionen versehen. Vorraussetzung dafür ist natürlich eine gewisse Einarbeitungszeit in die Struktur von XNA.

Bevor ich zum Editor Punkt komme. Einige Grafik Engines übernehmen auch den Editor Funktionsumfang. Gute Beispiele hierfür sind Unreal, Cry Engine und Unity 3D. Da es sich bei Unreal und Cry Engine um zwei hochkarätige und komplexe Engines handelt (zumeist eher für 3D Ego Shooter) empfiehlt sich hierbei eher Unity als "All in One" Alternative. Unity ist vom Umfang her einfach leichter zu verstehen.

Editor
Das Tool zum editieren der Spieledaten. Das Programmieren eines solchen Tools ist die reinste Banalität für einen Programmierer und stinklangweilig. Soweit es geht würde ich hier nach fertigen Alternativen Suchen, oder gänzlich verzichten. Als 2D Map Editor kann ich Tiled empfehlen. Tiled konzentriert sich hierbei nur auf das Mapping, die Tileset Verwaltung und auf allgemeine die Objekterstellung. Das Skripting von Objekten ist nicht wirlich möglich, aber dafür kann man jedem Objekt gewisse Parameter zuweisen, welche intern im Game Framework auswerten werden können. Als Ausgabeformat erzeugt Tiled das .tmx Format, welches letztendlich nur ein Custom XML Format ist. Wahlweise wird die Map dabei zlib komprimiert, oder als JSON gespeichert. An dieser Stelle empfehle ich dir eher auf genormte Formate auszuweichen als, falls es entsprechende Parser für deine jeweilige Programmiersprache gibt. Auch hier muss man das Rad nicht neu erfinden. Es sei denn du willst dein Format entsprechend binär verschleiern.

Alles erstmal sehr technisch und ohne großen Bezug zum Spiel oder RPG Maker. Doch ist dieses Hintergrundwissen einfach nötig um erforlgreich größere Projekte zu bewältigen. Und ein RPG Maker ist definitiv ein großes Projekt. Viele wollen das nicht glauben, aber es ist schon einiges an Erfahrung nötig um so ein Projekt zu bewältigen. Ob man den Maker dann so umsetzt, dass ein normalsterblicher damit umgehen kann ist eine andere Frage^^
Generell sollte man immer vor Augen haben was das eigentliche Ziel ist. Will ich mich intensiv mit der Materie beschäftigen, oder will ich einfach nur ein Spiel erstellen? Wenn es um das Spiel geht, dann empfehle ich den RPG Maker. Lass dich nicht von einer Idee blenden die auf den ersten Blick großartig wirkt. Ich kann dir sagen, dass viele an diesem Versuch gescheitert sind. Six years later... try it again.

Motto: Aus Fehlern lernt man

  • Nachricht senden

8

Sonntag, 23. September 2012, 02:05

Ja. Die eigentliche Arbeit wird nicht das Spiel werden, sondern der Maker selber ;) :arbeit.arbeit:
Bild :yahoo!:
By MinekTerra

9

Sonntag, 23. September 2012, 11:00

ich mach mal eigenwerbung: wir haben es uns auch als Ziel gesetzt einen eigenen Maker zu machen ... aber in Ruby (nicht in Java)
OpenRubyRMK - Overview - α→developer’s_corner


(aber ich bau auch grad an einer 3D engine für ruby was da interessant sein könnte)
Realität ist nur eine subjektive Wahrnehmungsstörung.

Alles ist wahr, wenn man für wahr einen bestimmten Wert annimmt.

10

Donnerstag, 27. September 2012, 11:03

nett, aber leider ist ruby einfach zu langsam, als das man damit wirklich gut 3d spiele entwickeln könnte.

11

Donnerstag, 27. September 2012, 13:15

das halte ich für eine Lüge! ich bekomme bei dem Test Programms die gleiche FPS-Rate wie wenn ich das Game mit C++ allein starten würde.

und das sind mit dem richtigem Treiber über 250FPS
Realität ist nur eine subjektive Wahrnehmungsstörung.

Alles ist wahr, wenn man für wahr einen bestimmten Wert annimmt.

Kagurame

Alopex Lagopus

Motto: Ich Böse, Du Teufel

  • Nachricht senden

12

Donnerstag, 27. September 2012, 14:46

nett, aber leider ist ruby einfach zu langsam, als das man damit wirklich gut 3d spiele entwickeln könnte.

Stimme Hanmac zu, es kommt drauf an, wie du programmierst (:
Bild

  • Hallo

    Tabs klicken unso, ne?
  • Lyric

    Meine schwarze Liste, beginnt mit einem Satz:
    "Wer zuletzt lacht, lacht am besten!", und am Ende ist noch Platz.
    Auf der Liste meiner Feinde, ist auch für euch noch Platz
    Wer zuletzt lacht, lacht am besten!
    Merkt euch diesen Satz!

    Ode an die Feindschaft von Saltatio Mortis

  • Outtakes

    • Nummer 3
      20.09.2012 - 19:46
      "Yah, ich bin ihre Motivazin." "Motivazin - gibts das jetzt in der Apotheke rezeptflichtig?"
    • Ich mag Kekse
    • Nummer 2
      08.09.2012 - 01:29 Uhr
      "Die Erlebnismacher zu Hannovre - Exlibre - ääääh... Excalibur"

      *Lachflash*
    • Nummer 1
      07.09.2012 - 22:58 Uhr
      *Bööarps* - Die Erlebnismacher zu Hannovre - Excalibur... "Mahlzeit... also... doch nicht Mahlzeit... war nur die Website"
      "Ich hab gerülpst -.-" "Du hast was?" *LACHFLASH*
      "Nicht dein Ernst, oder?" "DOCH!" *LACHFLASH second tour*
  • Profile

    Bild
  • Ich

    Dass bin ich:

    Maker: RPG-XP, RPG-VX
    Story:
    Für andere mehr als für mich: 60%

    Grafik:
    Ich werde besser: 35%

    Pixeln:
    Ich stehe an den Anfängen: 7%

    Mapping:
    Es fehlen nur noch (alle) Feinheiten: 67%

    Scripting:
    Informatiker, mittlerweile auch andere Sachen am skripten: 93%
  • Neues aus der SB

    Neues aus der SB:

    Spoiler: Die Camper
    (03:41:36) Kagurame: n8 du
    (03:41:37) Irrlicht: Nacht Mozilla
    (03:41:47) MozillaBabybird: Kagu: der witz war flach
    (03:42:01) Kagurame: welcher witz?
    (03:42:14) Heatra: geh nicht benji
    (03:42:21) Heatra: spiel lieber ats2 :D
    (03:42:25) MozillaBabybird: nacht leute ^^ ijemand sollte diesen verlauf im studio bash posten, damit die mal wissen wer die echten camper hier sind :D
    (03:42:35) Kagurame: ich bin scripten
    (03:42:38) MozillaBabybird: Heat: tut mir sorry xD
    (03:42:40) Kagurame: ich mach das...^^
    (03:42:48) MozillaBabybird: bis .... mittag ?
    (03:42:49) Heatra: ^^
    (03:42:55) MozillaBabybird: ja mittag dürfte passen
    (03:42:56) MozillaBabybird: :D
    (03:42:57) Kagurame: ^^
    (03:43:02) Heatra: ich steh morgen eh erst um 5 uhr mittags auf
    (03:43:07) Kagurame: bis heute
    (03:43:11) Steve: MozillaBabybird verlässt den Chat.
    (03:43:15) Kagurame: ich so um 3
    zum Lesen den Text mit der Maus markieren


    Spoiler: Die Informatiker vom Dienst
    (03:05:32) Ankou: bist du dir SICHER, dass es die Performance an der Stelle kritisch ist und c.a. 30% sind KEIN großer Unterschied?
    (03:05:41) Ankou: oh
    (03:05:45) Ankou: okay
    (03:06:21) Asandril: Oh Ha was habt Ihr gerade für ein Thema?
    (03:06:41) Ankou: das ist in der Tat eine performancekritische angelegenheit, aber ich denke dennoch nicht, dass das die Dinge sind auf die du dein Hauptaugenmerk richten solltest.
    (03:07:01) Heatra: maschine
    (03:07:01) Ankou: derartige Mikrooptimierungen werden Performanceprobleme sogut wie niemals beseitigen können
    (03:07:01) Irrlicht: anhand der Tatsache dass es 20 000 000 Durchläufe waren nicht wirklich :-/
    (03:07:08) Ankou: änder was konzeptionelles oder lass es bleiben.
    (03:07:31) Ankou: evtl. kannst du mehr der Interpretation nach vorne verlagern
    (03:08:06) Ankou: aber solche Dinge zu versuchen wie die case Abfragen durch send zu ersetzen in der Hoffnung ein paar Prozent einzusparen bringens dir nicht
    (03:08:26) Asandril: Bin ich gerade hier in einem Kurs gelandet ..
    (03:08:36) Irrlicht: hatte mal in Erwägung gezogen die Befehle evtl. schonmal etwas "vorzuinterpretieren", aber das dürfte dann mehr Speicher verbrauchen als es Geschwindigkeit bringt...
    (03:09:11) Ankou: Asandril: ja, erstaunlich, angetrunken an Silvester über so etwas zu reden
    (03:09:28) Heatra: -> lampenfieber
    (03:09:40) Asandril: Kann ich nur beipflichten.
    (03:09:46) Irrlicht: atm bin ich mir nicht sicher was genau den doch vergleichsweise erheblichen Lag von Parallel-Process-Events verursacht (oder ob es einfach an der gesammten Masse liegt) wenn ich bei 2 000 000 solcher Durchläufe unter einer Sek. bleibe...
    (03:09:57) Ankou: Irrlicht: das ist durchaus üblich. Speicher gegen Geschwindigkeit einzustauschen ist sehr populär und bringt oft viel
    (03:11:23) Irrlicht: mal schaun :)
    zum Lesen den Text mit der Maus markieren


    Spoiler: Auch noch später^^
    (03:32:35) (Kagurame_AnkündigungImForumMach): es da ne methode wie beim xp?
    (03:32:48) Irrlicht: Cache.system("Iconset")
    bekommst das Iconset
    (03:32:50) (Kagurame_AnkündigungImForumMach): brauche es dringend, aber nix gefunden bisher
    (03:33:01) (Kagurame_AnkündigungImForumMach): und dann per id?
    (03:33:06) (Kagurame_AnkündigungImForumMach): drauf zugreifen?
    (03:33:07) Irrlicht: Index berechnet sich einfach aus
    x = index % 16
    y = index / 16
    (03:33:17) Irrlicht: afaik warens 16 nebeneinander^^
    (03:33:28) (Kagurame_AnkündigungImForumMach): ok, danke.
    (03:33:51) (Kagurame_AnkündigungImForumMach): ich glaub ich scripte dann noch ein bissl
    (03:34:01) Steve: (Kagurame_AnkündigungImForumMach​) heißt jetzt Kagurame.
    (03:34:04) Irrlicht: im XP hast die einzelnen Icons anhand des Namens aus dem Icon-Ordner aufgerufen
    (03:34:09) Steve: Kagurame ist nun Scripten!
    (03:34:17) Irrlicht: (geht natürlich im VX auch, aber wozu gibts das Iconset)
    (03:34:23) Kagurame: ja ich weis, daher war ich heut mittag verwirrt
    zum Lesen den Text mit der Maus markieren

13

Donnerstag, 27. September 2012, 16:07

Das ist falsch, Ruby ist eine Interpreter Sprache wie PHP etc. Sie ist um das 50 fache langsamer als c# und sogar noch weit langsamer als Java.
Es hat schon einen Grund, warum Unity3D keine Ruby engine hat :) Zwar ist es seit der 1.9ner schneller, aber es ist und bleibt eine der langsamsten sprachen.... Vor 1.9 wars noch langsamer als PHP :) das hat schon was zubedeuten.

Kagurame

Alopex Lagopus

Motto: Ich Böse, Du Teufel

  • Nachricht senden

14

Donnerstag, 27. September 2012, 16:15

Also wenn bei dir Ruby 50 mal langsamer ist als andere Sprachen, dann programmierst du sehr sehr unsauber... ^-^
Ich habe nicht gesagt das Ruby so schnell ist wie C und Freunde, aber Ruby ist nicht zu langsam für 3D-Games. Man muss nur sauber programmieren.

Falls es dich interessiert: C#, VB und andere .Net-Sprachen werden auch Interpretiert. (Stichwort Jit-Compile / Debugging - Ich bin schließlich .Net- und Ruby-Entwickler)
Bild

  • Hallo

    Tabs klicken unso, ne?
  • Lyric

    Meine schwarze Liste, beginnt mit einem Satz:
    "Wer zuletzt lacht, lacht am besten!", und am Ende ist noch Platz.
    Auf der Liste meiner Feinde, ist auch für euch noch Platz
    Wer zuletzt lacht, lacht am besten!
    Merkt euch diesen Satz!

    Ode an die Feindschaft von Saltatio Mortis

  • Outtakes

    • Nummer 3
      20.09.2012 - 19:46
      "Yah, ich bin ihre Motivazin." "Motivazin - gibts das jetzt in der Apotheke rezeptflichtig?"
    • Ich mag Kekse
    • Nummer 2
      08.09.2012 - 01:29 Uhr
      "Die Erlebnismacher zu Hannovre - Exlibre - ääääh... Excalibur"

      *Lachflash*
    • Nummer 1
      07.09.2012 - 22:58 Uhr
      *Bööarps* - Die Erlebnismacher zu Hannovre - Excalibur... "Mahlzeit... also... doch nicht Mahlzeit... war nur die Website"
      "Ich hab gerülpst -.-" "Du hast was?" *LACHFLASH*
      "Nicht dein Ernst, oder?" "DOCH!" *LACHFLASH second tour*
  • Profile

    Bild
  • Ich

    Dass bin ich:

    Maker: RPG-XP, RPG-VX
    Story:
    Für andere mehr als für mich: 60%

    Grafik:
    Ich werde besser: 35%

    Pixeln:
    Ich stehe an den Anfängen: 7%

    Mapping:
    Es fehlen nur noch (alle) Feinheiten: 67%

    Scripting:
    Informatiker, mittlerweile auch andere Sachen am skripten: 93%
  • Neues aus der SB

    Neues aus der SB:

    Spoiler: Die Camper
    (03:41:36) Kagurame: n8 du
    (03:41:37) Irrlicht: Nacht Mozilla
    (03:41:47) MozillaBabybird: Kagu: der witz war flach
    (03:42:01) Kagurame: welcher witz?
    (03:42:14) Heatra: geh nicht benji
    (03:42:21) Heatra: spiel lieber ats2 :D
    (03:42:25) MozillaBabybird: nacht leute ^^ ijemand sollte diesen verlauf im studio bash posten, damit die mal wissen wer die echten camper hier sind :D
    (03:42:35) Kagurame: ich bin scripten
    (03:42:38) MozillaBabybird: Heat: tut mir sorry xD
    (03:42:40) Kagurame: ich mach das...^^
    (03:42:48) MozillaBabybird: bis .... mittag ?
    (03:42:49) Heatra: ^^
    (03:42:55) MozillaBabybird: ja mittag dürfte passen
    (03:42:56) MozillaBabybird: :D
    (03:42:57) Kagurame: ^^
    (03:43:02) Heatra: ich steh morgen eh erst um 5 uhr mittags auf
    (03:43:07) Kagurame: bis heute
    (03:43:11) Steve: MozillaBabybird verlässt den Chat.
    (03:43:15) Kagurame: ich so um 3
    zum Lesen den Text mit der Maus markieren


    Spoiler: Die Informatiker vom Dienst
    (03:05:32) Ankou: bist du dir SICHER, dass es die Performance an der Stelle kritisch ist und c.a. 30% sind KEIN großer Unterschied?
    (03:05:41) Ankou: oh
    (03:05:45) Ankou: okay
    (03:06:21) Asandril: Oh Ha was habt Ihr gerade für ein Thema?
    (03:06:41) Ankou: das ist in der Tat eine performancekritische angelegenheit, aber ich denke dennoch nicht, dass das die Dinge sind auf die du dein Hauptaugenmerk richten solltest.
    (03:07:01) Heatra: maschine
    (03:07:01) Ankou: derartige Mikrooptimierungen werden Performanceprobleme sogut wie niemals beseitigen können
    (03:07:01) Irrlicht: anhand der Tatsache dass es 20 000 000 Durchläufe waren nicht wirklich :-/
    (03:07:08) Ankou: änder was konzeptionelles oder lass es bleiben.
    (03:07:31) Ankou: evtl. kannst du mehr der Interpretation nach vorne verlagern
    (03:08:06) Ankou: aber solche Dinge zu versuchen wie die case Abfragen durch send zu ersetzen in der Hoffnung ein paar Prozent einzusparen bringens dir nicht
    (03:08:26) Asandril: Bin ich gerade hier in einem Kurs gelandet ..
    (03:08:36) Irrlicht: hatte mal in Erwägung gezogen die Befehle evtl. schonmal etwas "vorzuinterpretieren", aber das dürfte dann mehr Speicher verbrauchen als es Geschwindigkeit bringt...
    (03:09:11) Ankou: Asandril: ja, erstaunlich, angetrunken an Silvester über so etwas zu reden
    (03:09:28) Heatra: -> lampenfieber
    (03:09:40) Asandril: Kann ich nur beipflichten.
    (03:09:46) Irrlicht: atm bin ich mir nicht sicher was genau den doch vergleichsweise erheblichen Lag von Parallel-Process-Events verursacht (oder ob es einfach an der gesammten Masse liegt) wenn ich bei 2 000 000 solcher Durchläufe unter einer Sek. bleibe...
    (03:09:57) Ankou: Irrlicht: das ist durchaus üblich. Speicher gegen Geschwindigkeit einzustauschen ist sehr populär und bringt oft viel
    (03:11:23) Irrlicht: mal schaun :)
    zum Lesen den Text mit der Maus markieren


    Spoiler: Auch noch später^^
    (03:32:35) (Kagurame_AnkündigungImForumMach): es da ne methode wie beim xp?
    (03:32:48) Irrlicht: Cache.system("Iconset")
    bekommst das Iconset
    (03:32:50) (Kagurame_AnkündigungImForumMach): brauche es dringend, aber nix gefunden bisher
    (03:33:01) (Kagurame_AnkündigungImForumMach): und dann per id?
    (03:33:06) (Kagurame_AnkündigungImForumMach): drauf zugreifen?
    (03:33:07) Irrlicht: Index berechnet sich einfach aus
    x = index % 16
    y = index / 16
    (03:33:17) Irrlicht: afaik warens 16 nebeneinander^^
    (03:33:28) (Kagurame_AnkündigungImForumMach): ok, danke.
    (03:33:51) (Kagurame_AnkündigungImForumMach): ich glaub ich scripte dann noch ein bissl
    (03:34:01) Steve: (Kagurame_AnkündigungImForumMach​) heißt jetzt Kagurame.
    (03:34:04) Irrlicht: im XP hast die einzelnen Icons anhand des Namens aus dem Icon-Ordner aufgerufen
    (03:34:09) Steve: Kagurame ist nun Scripten!
    (03:34:17) Irrlicht: (geht natürlich im VX auch, aber wozu gibts das Iconset)
    (03:34:23) Kagurame: ja ich weis, daher war ich heut mittag verwirrt
    zum Lesen den Text mit der Maus markieren

15

Donnerstag, 27. September 2012, 16:27

Also wenn bei dir Ruby 50 mal langsamer ist als andere Sprachen, dann programmierst du sehr sehr unsauber... ^-^
Ich habe nicht gesagt das Ruby so schnell ist wie C und Freunde, aber Ruby ist nicht zu langsam für 3D-Games. Man muss nur sauber programmieren.

Falls es dich interessiert: C#, VB und andere .Net-Sprachen werden auch Interpretiert. (Stichwort Jit-Compile / Debugging - Ich bin schließlich .Net- und Ruby-Entwickler)

Falsch, C# und Co werden nicht interpretiert, sie werden lediglich zur Laufzeit compiliert. Das ist ein himmelweiter Unterschied. Ähnlich wie Java, dass ja in einer VM läuft, wird beim "Erstellen" der C#, VB Source auf eine andere Sprache umgebaut, die Common Intermediate Language. Der Jit-Compiler erzeugt diese. Danach wird diese jedoch in systemeigenen Programmcode übersetzt. Das geschieht bei Ruby nicht. performance - Why do people say that Ruby is slow? - Stack Overflow
mandelbrot benchmark | Computer Language Benchmarks Game

16

Donnerstag, 27. September 2012, 16:29

Es hat schon einen Grund, warum Unity3D keine Ruby engine hat :)

ganz einfach, weil ich Features wo ich bei Unity3d zahlen müsste, von Ogre3d gratis bekomme.

auserdem muss die engine so sein das du auch von außen an die funktionen ran kommst die du wrappen willst und nicht nur von innen

Edit:
Der Jit-Compiler erzeugt diese. Danach wird diese jedoch in systemeigenen Programmcode übersetzt. Das geschieht bei Ruby nicht.

doch seit version 1.9.* kann das MRI auch, Jruby und Rubinius können das auch schon eher
Realität ist nur eine subjektive Wahrnehmungsstörung.

Alles ist wahr, wenn man für wahr einen bestimmten Wert annimmt.

17

Donnerstag, 27. September 2012, 16:33

Es hat schon einen Grund, warum Unity3D keine Ruby engine hat :)

ganz einfach, weil ich Features wo ich bei Unity3d zahlen müsste, von Ogre3d gratis bekomme.

auserdem muss die engine so sein das du auch von außen an die funktionen ran kommst die du wrappen willst und nicht nur von innen

Edit:
Der Jit-Compiler erzeugt diese. Danach wird diese jedoch in systemeigenen Programmcode übersetzt. Das geschieht bei Ruby nicht.

doch seit version 1.9.* kann das MRI auch, Jruby und Rubinius können das auch schon eher

ja, seit v 1.9, dennoch, siehe die links die ich gepostet habe Mono C# liegt da bei 65.43 sekunden, Ruby 1.9 bei ? 1h 32 min. Jetzt sagt nochmal, dass es nicht langsamer ist :)
ich hab ja nix gegen Ruby, aber ich finde, es macht keinen sinn, damit eine "Engine" zu schreiben, wobei das Wort Engine sowieso meistens nicht zutrifft. Eher Framework ;)

18

Donnerstag, 27. September 2012, 16:37

ich glaub du verstehst es nicht
natürlich ist es bescheuert sowas wie eine 3dEngine in reinem ruby zu schreiben, das will ja auch keiner.
dewegen benutzen wir ja Bindings ... so haben wir die geschwindigkeit von C kombiniert mit dem syntax-sugar von Ruby

und damit kann man wirklich an den Speed von C ran kommen ... ob du das jetzt nun glaubst oder nicht
Realität ist nur eine subjektive Wahrnehmungsstörung.

Alles ist wahr, wenn man für wahr einen bestimmten Wert annimmt.

19

Donnerstag, 27. September 2012, 16:47

ich glaub du verstehst es nicht
natürlich ist es bescheuert sowas wie eine 3dEngine in reinem ruby zu schreiben, das will ja auch keiner.
dewegen benutzen wir ja Bindings ... so haben wir die geschwindigkeit von C kombiniert mit dem syntax-sugar von Ruby

und damit kann man wirklich an den Speed von C ran kommen ... ob du das jetzt nun glaubst oder nicht

Ja dann sag das doch mensch :) Aber wie war das noch in Ruby mit Arrays? Objekt=Book, Array=Books? Da gabs doch sowas lustiges, das kenne ich von meiner Ausbildung damals noch.
Das fande ich ganz witzig.

20

Donnerstag, 27. September 2012, 17:19

Zitat

Aber wie war das noch in Ruby mit Arrays? Objekt=Book, Array=Books? Da
gabs doch sowas lustiges, das kenne ich von meiner Ausbildung damals
noch.

Das fande ich ganz witzig.
Weiss nit was du hier meinst.

Ruby Quellcode

1
2
3
array = []
array << 'Katze'
array << 'Hund'


In Ruby ist (fast) alles ein Objekt. Gibt nur ganz wenige Ausnahmen, aufgrund der Performance.

Ruby Quellcode

1
2
  x = 5; def x.hi; puts "hi"; end
  TypeError: can't define singleton method \"hi\" for Fixnum


Zum Thema Geschwindigkeit, ohne Frage gibt es schnellere Sprachen als Ruby.

Aber du hast vorher behauptet das Ruby langsam wäre:

Which programming languages are fastest? | Computer Language Benchmarks Game

Da ist Ruby schneller als Perl, Python und PHP. Nur Lua ist deutlich schneller, von
den Skriptsprachen, aber noch immer sehr langsam. Dennoch wird Lua sehr oft
als Scriptsprache bei Spielen verwendet. Matz arbeitet an mruby, das wird eines
Tages mit Lua konkurrenzieren können: mruby/mruby · GitHub

Nur, einfach so zu sagen Ruby sei für alles zu langsam, passt einfach nicht
mit der Tatsache zusammen das selbst Lua nun auch nicht Welten schneller
ist, und dennoch oft verwendet wird.

Die Script-Sprachen sind nun mal populär geworden:
TIOBE Software: The Coding Standards Company

Ähnliche Themen

Social Bookmarks