spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Unbegabt83«

Wenn ich bisher etwas gelernt habe, habe ich immer ganz vorn angefangen. Beim Programmieren wird aber (fast) immer gesagt nimm doch das und das da ist schon alles drin was du brauchst.
Was aber wenn ich quasi alles, Engine Bibliothek etc. selber schreiben will? Gibt es da auch Bücher für oder ergibt sich das eh wenn man Programmierung verstanden hat? (die Frage bekomme ich nicht besser erklärt)

Ich halte es für sinnvoll wenn du dir erst mal etwas fertiges ansiehst. SFML ist da kein schlechter Einstieg. Du hast ja immerhin noch keine Ahnung wie man so etwas aufbauen kann. Danach könntest du dir DirectX, OpenGL, Mantle oder wie sie nicht alle heißen ansehen. Dazu gibt es dann natürlich auch Bücher. Selbst zum Thema Engine Design gibt es Bücher. Oft wird gesagt dass es sinnvoll ist einfach Spiele zu entwickeln. Arbeitest du zum Beispiel mit DirectX so schreibst du dir haufenweise Klassen die dir bestimmten Aufgaben erledigen. Bei jedem Spiel versuchst du Teile des Codes wieder zu verwenden und dafür zu refactoren. Mit der Zeit entwickelt sich dann deine Engine von ganz allein. So wird es zumindest oft propagiert. Ich selbst habe mir die Mühe einer eigenen Engine nie gemacht, sondern einfach direkt auf SFML und Co aufgebaut. Selbst da hat sich mit der Zeit Code ergeben den ich mehrfach verwenden konnte.

Zitat von »Unbegabt83«

Kann ich, ohne Angaben von Entwickler, erkennen mit welcher Sprache, Engine, Bibliothek etc. ein Spiel geschrieben wurde?
Das ich den Quellcode nur einsehen kann wenn der Entwickler diesen freigegeben hat, weiß ich mittlerweile. (auch da bitte Korrektur falls nicht korrekt)

Es gibt schon Möglichkeiten. Du kannst anfangen das Spiel mit einem Hex Editor zu betrachten. Möglicherweise findest du so schon Informationen darüber womit gearbeitet wurde. Viel wirst du damit aber nicht anfangen können.
Eine weitere Möglichkeit wäre mit einem Disassembler zu arbeiten. IDA ist da ein Beispiel für. Das ist aber eine extrem anstrengende Arbeit und du kannst davon ausgehen dass du nicht unbedingt viel von der Logik des Spiels verstehen wirst. Ich wollte es nur für die Möglichkeit in den Raum werfen.
Ansonsten gab es grad einen Artikel bei Heise. Der Service war gestern total überlastet und ich hatte noch keine Zeit das Teil selbst zu kompilieren. Die Idee ist Programme in Quelltext zu überführen. Wie gut das am Ende wirklich geht kann ich aufgrund fehlender Tests nicht sagen. Laut dem Artikel geht da so einiges. Kannst du dir vielleicht einfach mal ansehen.

Ansonsten hast du halt die Möglichkeit dir Bücher über Spieleentwicklung zu besorgen, Quellcodes von Open Source Spielen anzusehen, Quellcode von Engines zu lesen oder eben einfach selbst haufenweise Spiele zu entwickeln. Selbst wenn du am Anfang nicht so den Durchblick hast wirst du mit der Zeit immer besser werden. Eben deshalb ist es auch nicht dumm wenn du mit einer fertigen Engine beginnst und dich erst mal nur ums Spieleentwickeln an sich kümmerst, und dich eben erst danach an grafische Grundlagen und Engines setzt. Am Ende musst du da aber deinen eigenen Weg finden.

Zitat von »Unbegabt83«

Frage 1:
Kann ich, ohne Angaben von Entwickler, erkennen mit welcher Sprache, Engine, Bibliothek etc. ein Spiel geschrieben wurde?
Das ich den Quellcode nur einsehen kann wenn der Entwickler diesen freigegeben hat, weiß ich mittlerweile. (auch da bitte Korrektur falls nicht korrekt)

Oft reicht ein Blick in das Spielverzeichnis um bereits einige Sachen herauszufinden. Da Spiele ohne Voraussetzungen lauffähig sein sollen, wird in der Regel alles an DLLs und Redistributables mitgeliefert. Open-Source Bibliotheken werden häufig sogar explizit in einer Textdatei aufgelistet. Mit etwas Hintergrundwissen lässt sich auch schon anhand Verzeichnisstruktur und/oder Paketformat auf Engines schließen.

Was das Decompilieren angeht, kommt es stark auf die verwendete Sprache/Technologie an. Bei Java und C# ohne Obfuscator kommt man z.B. relativ nah an den originalen Quellcode (ohne Kommentare). Und falls sich das nicht geändert hat, ist es bei Verwendung von Unity nur begrenzt möglich einen Obfuscator einzusetzen. Bei C und C++ trifft aber das zu was Schorsch geschrieben hat.

Zitat von »Unbegabt83«

Was aber wenn ich quasi alles, Engine Bibliothek etc. selber schreiben will? Gibt es da auch Bücher für oder ergibt sich das eh wenn man Programmierung verstanden hat?

schaue Dir an was in der demoscenelos ist. Du musst verstehen, wie du pixel zeichnen kannst, dann kannst du Dir bild formate wie PNG anschauen und deinem Programm beibringen, wie du solche dateien rauslesen kannst um die Pixel zu zeichenen, die demo scene kann das aber vermutlich auch ohne bildformate.

für 3d kannst du zum verständnis in das simple 3d format OBJmal reinschauen, da siehst du wie einfach ein modell im code aufgebaut ist

Zitat von »@zimmer«

schaue Dir an was in der demoscenelos ist. Du musst verstehen, wie du pixel zeichnen kannst, dann kannst du Dir bild formate wie PNG anschauen und deinem Programm beibringen, wie du solche dateien rauslesen kannst um die Pixel zu zeichenen, die demo scene kann das aber vermutlich auch ohne bildformate.

Das hat hier doch überhaupt nichts mit der Demoszene zutun. Und normalerweise nutzen die keine externen Daten. Da können andere hier aber mehr zu sagen. Wir haben ja ein paar Leute die sowas machen.

OK vermutlich kann directX schon bilddateien lesen, ich habe hier eine bild rausgesucht, also wenn TE nicht SDL möchte, kann er noch eine stufe lower gehen und DirectX lernen
ich frage mich ob framebuffer nur linux ist, gab es das nicht auch bei Command&conquer also bei MS-dos?

Guckst du hier.

Zitat

Das Linux Framebuffer Device (kurz fbdev) ist eine hardwareunabhängige Abstraktionsschicht unter Linux, um Grafiken auf der Konsole bzw. mit X-Window (xf86_fbdev) anzuzeigen. Dabei setzt das Framebuffer-Device nicht auf systemspezifischen Bibliotheken wie der SVGALib oder dem X Window System auf und ist somit eine ressourcensparende Alternative zum weiterverbreiteten X-Server, auf dem heute die meisten grafischen Oberflächen für Linux aufbauen. Es ist seit der Linux-Kernelversion 2.1.107 für alle Plattformen im Standardkernel enthalten.

Ich denke dein grösstes Problem gerade ist dass du alles auf einmal lernen und machen willst. Das geht aber nicht. Du kannst keine 20 Jahre Wissen und Erfahrung auf zwei Zeilen Foreneintrag eindampfen.

Meine Idee wäre, fang an einem Ende an, der Rest ergibt sich dann nach und nach. Und dann lösen sich auch viel Fragen von selbst