27.03.2018, 11:08
Ihr schreibt viel zu viel. Jetzt muss ich die Antwort themenspezifisch aufteilen 
Thema Technologie:
Irgendwann geisterte hier im 1. Thread mehrmals die Idee C++ als Basis und skriptbar mit Lua herum. Die finde ich persönlich immer noch sehr gut. Mit Lua sind verdammt viele (auch sehr große) Spiele erfolgreich geskriptet worden. Es ist leicht erlernbar (ähnlich wie Python, zugegeben) und ziemlich einfach einbettbar (besser als Python).
Für die Basis, also Audio und Video, wäre eine Nicht-Skriptsprache wahrscheinlich besser. Bspw. würde ich das Laden von Ressourcen modularisieren, mit Loadern für die Originaldaten und Loadern für neue Formate (PNG bei Bildern, OGG/MP3/WAV bei Sounds & Musik). Somit könnte man für neue Daten (Landkarten, Städtetexturen, NPC-Bilder,...) in modernen, vernünftigen Formaten haben und sie trotzdem im Spiel ganz parallel zu den existierenden Daten nutzen, ohne dass ein Unterschied merkbar ist.
Diese Aufteilung bzw. Architektur ist meiner Erfahrung nach mit einer Sprache wie C++ besser zu machen.
@Rabenaas: Was genau ist denn an Rust so gut, dass Du das vorschlägst? Ich weiß außer der Tatsache, dass es für die Rendering-Engine vom Firefox verwendet wird, recht wenig darüber. Die Syntax hab ich mal grob angesehen, die ist reichlich hässlich. Aber irgendwas kann die Sprache ja bestimmt. Wenn Du da Erfahrungen hast, immer raus damit
Thema Aufbau:
Was wäre denn, wenn man alles Engine-spezifische in einen systemnah geschriebenen Teil legen würde? Damit meine ich, dass Darstellung der verschiedenen Screens (Reiseansicht, Stadtansicht, Inventar, Kampf, etc.) völlig unabhängig vom Regel/Quest/Simulations-Teil abläuft? Die Screens nehmen einen Snapshot der Welt und stellen den dar. Mehr würde da nicht passieren.
Daneben gibt es dann einen Skript-Teil, der die Regeln darstellt, Quests durchführt, NPCs agieren lässt, die Welt simuliert und Kämpfe berechnet. Komplett ohne Ausgabe, die ist hier nicht wichtig. So könnte man diesen Teil ganz gut mehrfach erstellen, je ein Set an Skripten für jedes verschiedene Regelwerk. Und die eigentliche Schick-Engine wäre davon losgelöst.
Die Auftrennung sieht am Anfang evtl. etwas komplex aus. Aber mit der Zeit merkt man immer mehr, was man sich für Ärger und Probleme erspart hat.
So wurde in fast allen Firmen, in denen ich war, Software gebaut. Hab mir das übernommen und bring das gerade meinem Azubi bei
Was denkt ihr?
Thema Technologie:
Irgendwann geisterte hier im 1. Thread mehrmals die Idee C++ als Basis und skriptbar mit Lua herum. Die finde ich persönlich immer noch sehr gut. Mit Lua sind verdammt viele (auch sehr große) Spiele erfolgreich geskriptet worden. Es ist leicht erlernbar (ähnlich wie Python, zugegeben) und ziemlich einfach einbettbar (besser als Python).
Für die Basis, also Audio und Video, wäre eine Nicht-Skriptsprache wahrscheinlich besser. Bspw. würde ich das Laden von Ressourcen modularisieren, mit Loadern für die Originaldaten und Loadern für neue Formate (PNG bei Bildern, OGG/MP3/WAV bei Sounds & Musik). Somit könnte man für neue Daten (Landkarten, Städtetexturen, NPC-Bilder,...) in modernen, vernünftigen Formaten haben und sie trotzdem im Spiel ganz parallel zu den existierenden Daten nutzen, ohne dass ein Unterschied merkbar ist.
Diese Aufteilung bzw. Architektur ist meiner Erfahrung nach mit einer Sprache wie C++ besser zu machen.
@Rabenaas: Was genau ist denn an Rust so gut, dass Du das vorschlägst? Ich weiß außer der Tatsache, dass es für die Rendering-Engine vom Firefox verwendet wird, recht wenig darüber. Die Syntax hab ich mal grob angesehen, die ist reichlich hässlich. Aber irgendwas kann die Sprache ja bestimmt. Wenn Du da Erfahrungen hast, immer raus damit
Thema Aufbau:
Was wäre denn, wenn man alles Engine-spezifische in einen systemnah geschriebenen Teil legen würde? Damit meine ich, dass Darstellung der verschiedenen Screens (Reiseansicht, Stadtansicht, Inventar, Kampf, etc.) völlig unabhängig vom Regel/Quest/Simulations-Teil abläuft? Die Screens nehmen einen Snapshot der Welt und stellen den dar. Mehr würde da nicht passieren.
Daneben gibt es dann einen Skript-Teil, der die Regeln darstellt, Quests durchführt, NPCs agieren lässt, die Welt simuliert und Kämpfe berechnet. Komplett ohne Ausgabe, die ist hier nicht wichtig. So könnte man diesen Teil ganz gut mehrfach erstellen, je ein Set an Skripten für jedes verschiedene Regelwerk. Und die eigentliche Schick-Engine wäre davon losgelöst.
Die Auftrennung sieht am Anfang evtl. etwas komplex aus. Aber mit der Zeit merkt man immer mehr, was man sich für Ärger und Probleme erspart hat.
So wurde in fast allen Firmen, in denen ich war, Software gebaut. Hab mir das übernommen und bring das gerade meinem Azubi bei
Was denkt ihr?