Seite 5 von 5 ErsteErste 12345
Ergebnis 81 bis 95 von 95

Thema: Neuer RPG Maker - RPG Maker MV

  1. #81
    Zitat Zitat von Corti Beitrag anzeigen
    Die Abteilung Budget- und Zeitplanung möchte dich sprechen, sofort.


    Echt? Ich bin schon froh wenn der Kunde selbst weiss, was er will
    Ich sage nicht, dass es in Videospielen notwendiger ist, oder, dass es in Industrieprojekten nicht notwendig ist. Ich sage, dass es in Videospielen eher zu finden ist.
    Wenn du alte Software warten musst, welche in den 60, 70 oder 80 Jahren geschrieben wurde wirst du halt nicht mit dem Stand der Technik konfrontiert werden. Du wirst mit dem Arbeiten müssen was die Leute damals verwendet haben. Ein kompletter Neustart ist zu kostenspielig und fehleranfällig und darum wird einfach weiter gewartet.
    Wenn etwas schlecht angefangen wurde kann man in einem multimillionen Euro Projekt nicht einfach neu anfangen. Man muss in den sauren Apfel beißen und es durchziehen. Wenn ein Spieleunternehmen wie Blizzard eine schlechte Engine für ein Spiel entwickelt hat können sie einfach bei dem nächsten Spiel von vorne anfangen. Da es alle 1 - 3 Jahre ein neues Spiel gibt muss man sich nicht lange mit dem alten Code quälen. Man lernt aus gemachten Fehlern und verbessert seine Arbeit bei der nächsten Iteration.

    Wenn bei uns die Studenten im ersten Praktikum einen schlechten Code-Stil verwenden und als Folge dessen ein Grauenvolles Projekt abgeben merkt man schon beim nächsten Praktikumsprojekt wie sie ihre Lektion gelernt haben und mehr Softwarepattern verwenden und weniger rumhacken. Ich rede von empirischen persönlichen Beobachtungen.

  2. #82
    Zitat Zitat von Cornix Beitrag anzeigen
    Ich sage, dass es in Videospielen eher zu finden ist.
    Weisst du das von den kommerziellen Spiele-Projekten an den du mitgearbeitet hast oder von den Berichten von Spieleprojekten bei denen genug Zeit und Geld vorhanden war um besonders sorgfältig zu arbeiten?

  3. #83
    java lol. java ist der grund weshalb ich android entwicklung so abstoßend finde. (und natürlich die sinnflut an china garbage im play store.) und wer will denn heutzutage noch applets im browser? okay minecraft. aba ansonsten ... dann lieber noch flash lol.

    wasn der unterschied zwischen javascript und typescript? ich hoffe mal typescript ist nicht noch mehr grammar nazi als javascript. semiklons am ende von befehlen ist zwar kein zwang aber schon teil der offiziellen javascript coding conventions (soweit ich weiß) und das ging mir schon ganz schön auf die eier. und all die klammern ugh. aber hey whatever javascript ist die zur zeit angesagteste skriptsprache also werd ich mal nicht weiter meckern und mich ordentlich freuen denn das klingt alles schon ziemlich cool...

    aba eins noch, ich mein 816×624 das ist doch ein schlechter witz wtf!????

  4. #84
    Zitat Zitat von Corti Beitrag anzeigen
    Weisst du das von den kommerziellen Spiele-Projekten an den du mitgearbeitet hast oder von den Berichten von Spieleprojekten bei denen genug Zeit und Geld vorhanden war um besonders sorgfältig zu arbeiten?
    Was ich eher sagen wollte war, dass in Videospielen die Vorraussetzungen eher vorhanden sind. Ob es wirklich eher zu finden ist kann ich nicht sagen. Das hängt wohl stark von der Art der Spiele ab. Bei AAA Titeln gehe ich davon aus, dass guter Programmierstil der Standard sein sollte. Bei billigen kleinen Scriptkiddy-Hacks wohl eher nicht.

  5. #85
    Zitat Zitat von Cornix Beitrag anzeigen
    Was ich eher sagen wollte war, dass in Videospielen die Vorraussetzungen eher vorhanden sind.
    Es gibt wohl kein Projekt dieser Welt, dass nicht von einheitlichem Codingstyle, sorgfältiger Arbeit, Unit-Tests, Dokumentation und angemessenem Einsatz von Codequalitätswerkzeugen profitieren würde. Ich bin nicht gegen das Zeugs, oder finde es gar nutzlos oder so, ich find sowas klasse. Da du auf Compiler als Antibockmist-Schutz stehst, schau dir mal statische Codeanalyse an. Da gibt es tolle Werkzeuge und aufgrund von Meckereien solcher Werkzeuge ( Hallo FxCop ) und den Begründungen hab ich schon eine Menge Dinge gelernt, die ich sonst wohl kaum erfahren hätte. Der Arbeitsalltag ist allerdings, sowohl was die an der Uni gelehrten Ideale, als auch optimierte Arbeitsweisen angeht, oft sehr desillusionierend. Je nach Produkt ist in der Praxis mehr oder gar kein Platz und/oder keine Zeit/Geld-opfernswerte Notwendigkeit dazu. John Carmack hat zu statischer Codeanalyse auf seiner Doom3-Engine mal einen lesenswerten Artikel geschrieben. Deren Quellcode kann man sich mittlerweile aus dem Netz ziehen und sie gilt als gutes Beispiel für sehr saubere Arbeit. Ist aber auch eine Grafikengine, ist dafür ausgelegt, dass andere Firmen sie kaufen und auch mit dem Quellcode arbeiten, wäre da Pfusch am Bau, würde das Produkt ja auch keiner kaufen. Das von Lachsen genannte Beispiel mit den kleinen oder mittleren Schweinereien, (die aber für die jeweilige Sache funktionieren) bei Naughty Dog ist in sofern auch normal weil Spielebusiness nicht unbedingt der Bereich mit dem tolerantesten Budget und den flexibelsten Zeitplänen ist. Sogar Firmen mit Geld wie Heu greifen ab und an zum unsauberen Hack. Blizzard wollte den Flugpatch für Warlords schon vor 'nem Monat bringen, sind noch immer damit beschäftigt die Nebenwirkungen der schnellen Problembeseitigung vom Releasewochenende auszubügeln.

    Ich finds gut, dass du ein Bewusstsein für Codequalität entwickelt hast, nur zügle deine Hoffnungen, die Welt da draussen hat so viele schmutzige Ecken

  6. #86
    Ich kenne mich ziemlich gut mit statische Code-Analyse aus. Meine Bachelorarbeit war ein Framework um beliebige dynamischen Code-Analyse an bereits existierenden Java-Programmen durchführen zu können ohne den Quellcode zu ändern.
    Dass nicht jeder sich an die besten Standards hält ist natürlich klar. In jeder Branche gibt es Menschen die gewissenhafter Arbeiten und Andere die es nicht tun.

    Mir geht es auch nur darum Leuten in die Quere zu kommen, welche dahergehen und soetwas wie das hier behaupten:
    Zitat Zitat
    ich [bin] aber davon überzeugt das gerade bei der Spielentwicklung viele der strikten Design-Praktiken aus der allgemeinen Softwareentwicklung einfach nicht angebracht sind.
    oder
    Zitat Zitat
    dass ein besondere Augenmerk auf Erweiterbarkeit und sauberer Struktur ein verschwendeter Zeitaufwand ist. [sic]
    Solche Aussagen sind einfach nur unprofessionell und sollten nicht ohne Weiteres stehen gelassen werden. So eine Denkweise war vielleicht in den 80ger Jahren angebracht, aber heute sind wir doch hoffentlich schon ein wenig weiterentwickelt.

  7. #87
    Corti hat das eigentlich bereits ausreichend ausgeführt. Dir fehlt scheinbar die nötige Erfahrung aus dem echten Berufsleben. ••••••••rei hat selten was mit einem mangel an Gewissenhaftigkeit zu tun. Man hat einfach selten die Möglichkeit seine Arbeit so gut zu verrichten, wie man selber könnte oder wollte.
    Und wirf nicht so mit dem Begriff "unprofessionell" um dich. Du weisst in dem Zusammenhang einfach nicht, wovon du redest.

    Und, ja, ich freu mich schon ein wenig auf den neuen Maker. Zum Glück interessiert mich das ganze Scripten nicht die Bohne. Ich bin altmodisch und nutze Events. Mal schauen, wie komfortabel es diesmal ausfällt. Was mich am meisten interessiert, ist allerdings die Sache mit der Auflösung. Enterbrain kriegt mein Geld nur, wenn man nicht wieder so ein kaputtes Format ertragen muss.

  8. #88
    Hier muss einfach zwischen Software und Software differenziert werden.

    Bei Software für betriebswirtschaftliche Zwecke z. B. liegen 60 % des Entwicklungsaufwandes in der Wartung und somit auch das meiste Geld was zu verdienen ist.

    Da ist es eine absolute Katastrophe wenn schlechter/schlecht nachvollziehbarer Code geschrieben wurde.

    Da lässt sich wunderbar mit Unit-Tests, Pair-Programming, saubere Dokumentation usw. dagegen wirken.

    Auch bei AAA-Spiele-Titeln sehe ich die Notwendigkeit dafür.

    Bei einer kleinen Spiele-App die 3 Entwickler schreiben ist wohl eher Extreme-Programming angebracht welches eine Dokumentation eig. komplett außen vorlässt(bis auf Kommentare).

    Fakt ist einfach, dass es eine Katastrophe ist wenn Code noch mal umgeschrieben werden muss und er nicht sauber geschrieben und auskommentiert ist, denn dann kann man ihn eig. komplett neu schreiben.

    Da hat @Cornix absolut recht.

    Geändert von Pepo (29.08.2015 um 05:35 Uhr)

  9. #89
    Zitat Zitat von Nagasaki Beitrag anzeigen
    Corti hat das eigentlich bereits ausreichend ausgeführt. Dir fehlt scheinbar die nötige Erfahrung aus dem echten Berufsleben. ••••••••rei hat selten was mit einem mangel an Gewissenhaftigkeit zu tun. Man hat einfach selten die Möglichkeit seine Arbeit so gut zu verrichten, wie man selber könnte oder wollte.
    Und wirf nicht so mit dem Begriff "unprofessionell" um dich. Du weisst in dem Zusammenhang einfach nicht, wovon du redest.
    Ich würde nicht raten über Erfahrungen wild fremder Leute im Internet zu diskutieren. Wenn keine Seite überhaupt irgendwelche Informationen über die jeweils andere hat wird daraus nur eine Schlammschlacht.

    Ich bezeichne die Aussage von Lachsen mit gutem Grund als unprofessionell, und zwar weil sie es ist. Zusammenhang hin oder her. Wenn man eine Allaussage macht und ein Werkzeug schlichtweg als Zeitverschwendung bezeichnet kann man auch nichts anderes als "unprofessionell" dazu denken.
    Werkzeuge sind für Zwecke entwickelt worden. Nur weil eine einzelne Person das Werkzeug nicht benutzt heist das noch lange nicht, dass es nicht Andere gibt, die es benutzen. Der gute Lachsen darf gerne der Meinung sein, dass guter Programmierstil in seinem Projekt nicht nötig ist oder nicht helfen würde (das kann sehr wohl sein, je nach Team-Dynamik), aber er darf deswegen nicht mir-nichts-dir-nichts behaupten, dass soetwas völlig nutzlos ist. Das ist eine kurzsichtige und egozentrische Denkweise.

  10. #90

    "Vibration of Nature" - It's a long story
    stars_mod
    Hallo mal wieder

    @Cortix Ich will erstmal anmerken, dass meine Aussagen vom letzten Post durchaus überspitzt waren und weshalb ich verstehen kann, dass du das als unprofessionell siehst.

    Corti hat an sich schon sehr gut erläutert worauf ich hinaus wollte. Ich will dann trotzdem nochmal das ganze etwas differenzierter wieder geben.

    Ich hatte ja dieses Video von Naughty Dog verlinkt. Das ist ein Entwickler von großen AAA Spielen und sehr erfolgreich in dem was sie machen.

    Der Prozess der in dem Video beschrieben wurde ist wie folgt.
    - Neue Features werden zunächst schnell und pragmatisch eingebaut die Funktionsweise auszutesten
    - wenn es passt wird optimiert und die Architektur überarbeitet
    - Sollte die Feature sehr spezifisch sein und nur wenige mal im Spiel Einsatz finden, muss es von der Architektur nicht unbedingt optimiert werden

    Mit anderen Worten: Features die oft Wiederverwendung finden (Enginefeatures wie Physik, Rendering) sollten eine gute Struktur und Architektur haben und dann auch alle möglichen Anwendungsfälle unterstützen.

    Andere sehr Spiel-spezifische Features, wie z.B die Steuerung vom Hauptcharakter, sind sehr auf einen bestimmten Use-Case zugeschnitten - und hier ist eine saubere Architektur in meinen Augen unangebracht weil es zuviel Zeit kostet und keinen entsprechenden Gegenwert bringt.

    Generell kann man sagen das bei der Entwicklung der Spielengine eine saubere Architektur tatsächlich essentiell ist, wie du sagt.
    Bei der Entwicklung eines Spiels, insbesondere wenn es bereits auf einer soliden Engine aufbaut, ist eine saubere Architektur stellenweise überflüssig.

    Der Grund warum ich das schreibe, ist ich oft mitbekomme wie Leute Ideale wie "Singletons = Bad" und "Immer Unit-Tests machen" von sich geben... CrossCode nutzt massiv Singletons und null Unit Tests. Das Projekt ist technisch jetzt schon sehr weit fortgeschritten und ich seh einfach nicht wie Singeltons und das Fehlen von Unit Tests für uns ein großes Problem darstellen werden.

    Es gibt halt Ideale und dann gibt Praxis bzw. "Sachen fertig bekommen" (und ja, ich sehe die Ironie, dass gerade ich das sage.)

    C ya,

    Lachsen

  11. #91
    Aber solche Aussagen wie "Singletons = Bad" und "Immer Unit-Tests machen" sind ebenfalls keine ordentliche Programmierung. Das sind selbst wieder All-Aussagen, welche überhaupt nicht richtig sind.
    Singletons sind immerhin ein allgemein anerkanntes Pattern und haben ihren Platz und Zweck. Wenn du sagst, dass Singletons bei deiner Software einen passenden Einsatz finden, dann benutzt du doch gerade ordentliche Software-Praktiken und Patterns.

    Gute Praxis in der Programmierung bedeutet es zu erkennen, was angebracht ist und was nicht. Es bedeutet nicht blind irgendeinem Trend zu folgen oder eine Programmierart anzuwenden, weil es das einzige ist was man kennt. Singletons sind Werkzeuge. Unit-Tests sind Werkzeuge. Observer sind Werkzeuge. Werkzeuge werden für einen gewissen Zweck geschaffen. Sie sind niemals unnötig oder immer nötig. Sie sind genau dann anzuwenden, wenn man ihren Zweck braucht.

  12. #92
    Äh ja, back to topic...

    Ein neuer Maker ist im Anmarsch und ich muss sagen es ist endlich ein Schritt in die richtige Richtung.
    Mein Eindruck:
    + endlich Unterstützung für mehrere Plattformen und durch HTML5 theoretisch auch auf Linux u.a.
    dadurch lassen sich Makerspiele auch professionell z.B. für Smartphones vermarkten
    + höhere Auflösung, sogar bis FullHD (die Auflösung wird dem Endgerät entsprechend wohl eh skaliert)
    + JS statt Ruby, kein DirectX Zwang
    + Touch- und Maussteuerung inkl.
    + 2 Battle Systeme für Unetschlossene und Dynamiker
    + Plugins! keine Kollisionsprobleme mit verschiedenen Scripten mehr
    + Eventsuche kehrt endlich zurück

    - nur 3 Layer...gab es beim RMXP (2005) schon und dort konnte man es manuell einstellen
    - Map/Tile System des VX
    - anscheinend keine großartigen Änderungen im Map-Editor
    - anscheinen auch keine neuen grafischen Änderungen wie z.B Partikeleffekte, simples 3D

    Einiges lässt sich mit JS vielleicht beheben, aber generell hat der MV schon einen großen Schritt nach vorne gemacht.
    Interessant wird's wenn es irgendwann die Möglichkeit gibt alte Makerspiele auf den MV zu portieren. Dann könnte man die Reise ins All auch auf dem Handy antreten.

  13. #93
    Nur eine Frage: Ständig is von höheren Auflösungen die Rede, aber kann man das Ding dann auch auf LoRes bringen? 320x240 wäre super, oder noch geiler, 256 x 240/224.
    Und kommt mir nicht mit man kann die Grafiken doch hochskalieren. Man muss doch nich überall Speicherplatz und CPU Ressourcen verbrennen, nur weils geht

    Ich verzieh mich wieder...
    Zocker out!

  14. #94
    Ein Eventfeld ist schon 48x48 groß. Da passen 9 16x16 2k Charaktere rein. Selbst wenn du nur einen Chara in das Feld platzierst und ihn nur einen Schritt machen lässt, geht er ganze 48px vorwärts. Die Dimensionen stimmen also schon mal gar nicht. Es muss also hochskaliert werden, damit alles optisch und auch technisch passt.
    Dennoch war auch schon der VX in der Lage das Fentser auf 320x240 zu kürzen, was im Grunde aber nur den Mapausschnitt verkleinert hat, was nicht wirklich viel Sinn macht.

  15. #95
    Zitat Zitat von DerZocker Beitrag anzeigen
    Nur eine Frage: Ständig is von höheren Auflösungen die Rede, aber kann man das Ding dann auch auf LoRes bringen? 320x240 wäre super, oder noch geiler, 256 x 240/224.
    Und kommt mir nicht mit man kann die Grafiken doch hochskalieren. Man muss doch nich überall Speicherplatz und CPU Ressourcen verbrennen, nur weils geht

    Ich verzieh mich wieder...
    Zocker out!
    Resourcen-Sparen und der RPG-Maker. Ich hoffe das soll ein Witz sein.

Stichworte

Berechtigungen

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