BERATUNG EINES AMATEURS
// Über Jahre des Lernens von Null zu Amateur
Ich würde mich definitiv von High-Level-Motoren wie Unity oder Torque2D MIT fernhalten. Sie eignen sich hervorragend für kleine Prototypen, aber ich würde sie nie ernst nehmen, um mein eigenes Videospiel zu entwickeln. Warum sollte ich? Was ist der Sinn, wenn es nicht mehr als ein einfaches SideScroller- oder Arcade-Remake war?
Die meisten Spiele-Engines, Bibliotheken oder Frameworks erledigen nur die einfachsten Aufgaben mit einer Menge aufgeblähtem Code und Funktionen, die Sie niemals verwenden werden.
Als ich vor Jahren neu in der Spieleentwicklung war, habe ich ganz oben angefangen. Sehr hochwertige Motoren. Nicht allzu hoch wie RPG MAKER, aber definitiv hoch wie Unity und Torque. Dann ging ich tiefer zu XNA und C #, weil es so viele Ressourcen und Tutorials gab. Mein primäres Projekt brauchte die Leistung, oder vielleicht bin ich nur besessen und zwanghaft, eine unglaubliche Leistung in meiner Software zu wollen, auch wenn es sich nicht um ein großes Projekt handelt. XNA hat es einfach nicht geschafft, und ich hatte viele Probleme mit der Engine, die ich gelesen habe. Was nützt es, etwas "Höheres" wie XNA / C # zu verwenden, wenn Sie die gleiche Arbeit (Beheben von XNA-Fehlern und -Problemen) ausführen, als würden Sie Ihre eigene Engine in C ++ rollen?
Nach einer Weile des Lernens lernte ich schließlich, wie Game-Engines gestaltet sind, und begann, den Code der Engines selbst zu untersuchen. Als ich las, was die meisten Profis zu sagen hatten, und die Beschwerden der Kritiker von Game Engines erkannten, warum überhaupt eine Engine verwendet wurde.
Es hat mir sehr geholfen, mein C ++ aufzufrischen und mich wirklich mit den in dieser Sprache verwendeten Philosophien vertraut zu machen. Ich hatte jedoch so viel Zeit damit verbracht, so viel zu lernen, dass ich nur anfangen wollte, ein Spiel zu machen.
Am Ende hatte ich ziemlich viel Lob, C ++ und ein sehr niedriges Level: SDL. Leider war dies Kopfschmerzen. Es ist so niedrig, dass ich so gut wie keinen Grund sehe, diese Bibliothek überhaupt zu benutzen. Ich möchte lieber einfach OpenGL lernen und es von Grund auf selbst machen. Ehrlich gesagt war es hauptsächlich die Tatsache, dass ich meinen eigenen Code implementieren musste, um etwas so Grundlegendes wie das Spiegeln eines Images zu tun (und die Implementierung eines anderen funktionierte nicht, weil ich mit Sprites umging), was mich dazu veranlasste, SDL dauerhaft zu verwerfen. Es ist großartig, wenn Sie einen Software-Renderer wollen, aber IMO würde ich es lieber in den Papierkorb werfen, um mit Hardware (OpenGL) oder höher (SFML) niedriger zu werden.
Da ich kein weiteres Buch über Amazon kaufen und keine weitere API lernen wollte, ging ich noch einen Schritt weiter. SFML ist einfach wunderbar, ganz zu schweigen von den über das Internet hochgelobten. Ich habe fast endlos viele positive Bewertungen gelesen, fast ohne Negative. Das kann ich für SDL nicht sagen. Es behandelt alle extremen Grundlagen, überlässt aber den Rest mir und anderen Bibliotheken meiner Wahl. Ich bin seitdem dabei geblieben.
IMO, eine Game-Engine ist einfach albern. Bibliotheken auf niedriger Ebene sind sowohl für Experten als auch für Anfänger eine viel bessere Wahl.
Außerdem habe ich mehr über Programmierkonzepte gelernt und meine Fähigkeiten in der Softwareentwicklung verbessert, als ich mit WYSIWYG-Game-Engines auf höherem Niveau arbeiten musste.
Was gibt dir so etwas wie Unity über XNA? Visuelle Bearbeitung und eine Krücke. Neulinge werden irgendwann feststellen, dass Sie das gesamte Spiel noch so gut wie mit C ++ programmieren müssen, und die visuellen Editoren sind ineffizient für Dinge, die Sie selbst erstellen könnten.
Was bietet Ihnen XNA gegenüber SFML oder Ihrer eigenen Implementierung von OpenGL und anderen nützlichen Bibliotheken? IMO, absolut nichts Gutes. Schlechtere Leistung, C # anstelle von C ++, eine Fülle von Tutorials für Anfänger, aber deutlich weniger Professionalität, und einige Kopfschmerzen, die IMO noch einmal als Krücke für das ansehen, was Sie mit C ++ lernen sollten. Ich war anfangs von C ++ eingeschüchtert und mochte C #, vor allem wegen der Gerüchte über die Meinungen von Dummköpfen, die die gleichen Probleme hatten, die ich anfangs mit C ++ hatte: Ich wollte nur einen Programmierer, der gut genug ist. Ich erkannte, dass ich mehr Grundlagen lernen und meine Schwächen schärfen musste, um die Probleme zu überwinden, die ich mit C ++ hatte, was C # "leicht gemacht" hat. Vermisse ich jemals die Einfachheit einiger Dinge in C #? Nicht mal! Ich weiß, wie man es in C ++ mühelos macht.
Wenn Bibliotheken auf niedriger Ebene oder das Erlernen von DirectX / OpenGL Sie einschüchtern, warten Sie einfach, bis Sie sich mit der Komplexität der Erstellung eines vollständigen Videospiels befassen.
Meine Philosophie zu Game Engines lässt sich in zwei Beispielen zusammenfassen, die die Redundanz und Nutzlosigkeit von Engines erklären, außer in Einzelfällen.
Neulinge, die von Bibliotheken auf niedriger Ebene eingeschüchtert sind, werden feststellen, dass sie selbst mit einer Engine auf hoher Ebene wie Unity (abgesehen von Grafik-Rendering, Audiowiedergabe, Laden von Inhalten; echte Grundfunktionen) fast identisch mit dem Erstellen eines Spiels sind von Grund auf neu. Die Komplexität besteht darin, ein Spiel zu entwickeln, die API nicht zu verstehen oder die Klassen zu entwickeln, die für die Anzeige gerendert werden sollen.
Experten, die sich nicht von der Komplexität der Erstellung eines vollständigen Spiels in Unity einschüchtern lassen, können mit Unity nichts anfangen, da die Zeit, die zum sicheren Erlernen der API und der Anforderungen einer bestimmten Engine benötigt wird, wahrscheinlich eher Kopfzerbrechen verursacht Mehr Zeit als nötig, um die wenigen Klassen zu programmieren, die für die Grundlagen erforderlich sind.
So sind Motoren für Neulinge nutzlos, weil Neulinge nichts damit anfangen können, weil ihnen die technischen Fähigkeiten fehlen. Ebenso sind Engines für Veteranen nutzlos, da sie bereits über die technischen Fähigkeiten verfügen, um auf eine Engine zu verzichten, und ihre eigene effizientere, spezifischere "Engine" entwickeln können, als sich den Kopf zerbrechen zu müssen, die API der Game Engine zu erlernen. Funktionen und Leistungsmerkmale. Ganz zu schweigen von dem Albtraum, mit Motoren zu arbeiten, die man manchmal nicht anfassen kann, weil sie kein Open Source sind (oder selbst wenn dies der Fall ist, kann das Lesen des Codes anderer manchmal ein Albtraum sein).
Selbst einige "Low Level" "Game Frameworks" sind nichts weiter als ein paar Klassen, um ein Fenster zu erstellen, auf dem Bildschirm zu rendern und Audio abzuspielen. Dies kann ein Profi selbst tun, indem er andere Bibliotheken wie SDL / SFML oder eine eigene Implementierung von OpenGL / DirectX / OpenAL verwendet, und das in einem Bruchteil der Zeit, die für die Fertigstellung eines vollständigen Videospiels erforderlich ist.
TLDR;
Wenn Sie programmieren möchten, lernen Sie, ein Programmierer zu sein .
Vermeiden Sie die Verwendung von Engines , aber machen Sie sich nichts vor und ignorieren Sie unglaublich nützliche Bibliotheken.
Wenn Sie ein Game Designer sein möchten , probieren Sie eine WYSIWYG-Engine aus und pumpen Sie diese Spiele aus!
Wenn Sie ein sein wollen Spiel - Programmierer , wie vermeiden Motoren die Krücke , dass sie sind.
Für mich hat die Verwendung von übergeordneten Spiel-Engines meine Fähigkeit, Programmierer zu werden, beeinträchtigt. In dem Moment, in dem ich anfing, Bibliotheken auf niedrigerer Ebene zu verwenden oder überhaupt keine Bibliothek zu verwenden, lernte ich so viel, dass ich schnell von einem absoluten Neuling zu jemandem überging, der jetzt Videospiele ohne Referenz, Tutorials oder Buch neben mir erstellen kann. Nur mein Compiler und viel Engineering und Übung.
Die Menge an Lernen, die ich in KURZER ZEIT von Bibliotheken mit niedriger Stufe erhalten habe, war viel größer als die Menge, die ich in SEHR LANGER ZEIT mit ENGINES mit höherer Stufe gewonnen habe. **