Aufbau eines Pc-Games

[p]A[n]

Hallo Leute!

Ein Pc-Game besteht ja bekanntlich aus einem rießen Haufen an Dateien.
Mich würde interessieren, wie diese miteinander arbeiten.

Um einen Counter-Strike Ordner als Bsp. zu nennen.
Darin befinden sich haufenweise .dll Dateien und Fotodateien.
Weiters .cfg und .txt Dateien.

Angenommen ich möchte ein Game programmieren, habe eine Idee+storybook und eine Programmiersprache.
Womit beginne ich?
Was genau sind diese .dll Dateien, kann ich sie öffnen und ansehen?
Installiert werden Spiele übelicherweise über eine .exe Datei, was macht diese eigentlich?

In einer Ix Ausgabe hab ich mal gelesen, dass .Net Arbeiten immer aus .exe und .dll Dateien Bestehen.Diese .dll Dateien bestehen dann noch aus Klassen usw. das habe ich aber nicht ganz verstanden :)

Heißt das jetzt das Counter-Strike mit .Net Programmiert wurde?

Mfg Pan

[Einfachkrank]

Oh je, dieser Punkt kommt mir bekannt vor :)
Du solltest dir auf jeden Fall erst mal einen allgemeinen Überblick verschaffen! Eine DLL Datei hat nichts mit .NET Sprachen oder jeglichem zu tun. DLL steht ganz einfach für Dynamic Link Libary und das ist, um es einfach zu beschreiben, eine Bibliothek mit Funktionen und Variablen die von jedem Programm, dass erstell wird eingebunden und genutzt werden können.

Aber zum Traum vom eigenen Spiel - das was du auf jeden Fall brauchst ist Geduld! Ich habe vor 5 Jahren mit 14 mir genau die selben Fragen gestellt und habe bis heute noch immer kein Quake4 programmiert und weiß aber mittlerweile, dass ich das alleine auch niemals schaffen werde ;)

Wenn du dich allgemein fürs Programmieren und trotzdem weiterhin für ein eigenes Spiel interessierst, dann such erst mal in den ganzen Stickys und vor allem Google nach geeigneten Themen. Fang mit dem hier im Programmierungsforum an. Da hat unser lieber Zeckensack den Thread "Tutorials, Tools, Dokumentation" angefangen und da hat sich auch einiges gesammelt. Des weiteren ist hier en recht gutes Forum was Spieleprogrammierung angeht: http://www.zfx.info

Allgemeiner Tipp: Immer erst vor dem Fragen selbst suchen ;)

[mapel110]

A[n']Angenommen ich möchte ein Game programmieren, habe eine Idee+storybook und eine Programmiersprache.
Womit beginne ich?

Kann man die Frage mal irgendwie kurz und knackig beantworten? Darüber zerbreche ich mir nämlich auch schon ewig den Kopf. Sicher fängt man mit der engine ansich an. Aber womit fängt man dort konkret an?

[tatarus]

Ich würde mal mit einer Programmiersprache z.B. C++ anfangen. Danach würde ich die OpenGL Libraries lernen. Ich finde die einfacher als die DirectX Libraries. Außerdem solltest du dich eingehend mit Mathematik beschäftigen. Vor allem mit linearer Algebra und Vektoranalysis für die graphischen Darstellungen und mindestens mal einfachen Differentialgleichungen für das Physikmodel.

Generell kann man aber sagen, dass mein Vorredner da schon recht hat. Mehrere Jahre wird das dauern und ein Studium für den ganzen Mathe Kram wäre auch nicht schlecht.

Ich selbst hab letztens ein einfaches Billardspiel in C++ mit OpenGL geschrieben. Die Physikengine (Rotation, Treffer durch hüpfende Kugel etc.) funktioniert bis heute noch nicht richtig. So einfache Sachen sind schon sauschwer.

[govou]

Am Anfang allen Übels steht die Idee.
1. Die Idee muss konkretisiert und konzepiert werden. Man sollte also haargenau wissen, was man will (es geht nicht um die Story oder um "Levels", sonder um die Grundidee und das Spielprinzip).
2. Als nächstes sollte man, wenn man Punkt 1 gut erledigt hat, sich überlegen, wie man es umsetzen will. Welche Programmiersprache ist geeignet? Mit was fängt man an?
3. Wenn man nun z.B. mit einer ganz simplen 3D-Engine anfängt (immer klein beginnen und dann langsam aufbauen!), sollte man sich, bevor man mit dem Programmieren loslegt, eine grobe Struktur des geplanten Sourcecodes aufzeichnen. Besonders wenn das Projekt etwas größer wird, verliert man sonst sehr schnell die Übersicht.
4. Erst jetzt sollte man anfangen seine Idee wirklich umzusetzen. Niemals alles aufeinmal anfangen (z.B. 3D-Engine, Physikengine etc.), sondern einzelnt abarbeiten. Ich empfehle logischerweise immer mit einer einfachen 2D-/3D-Engine zu beginnen und die weiter auszubauen. (Z.B. erst ein simples OpenGL-Window, dann Textureloading, dann Modelloading etc.)
5. Weitere aufbauende Programmteile sollten auch konzepiert werden, bevor sie umgesetzt werden.


Ich würde empfehlen, nicht versuchen mit großen 3D-Sachen anzufangen. Ein kleines 2D-Spiel ist schon eher für eine Person möglich umzusetzen :)

[Gast]

Am Anfang allen Übels steht die Idee.
[...]
3. ...sollte man sich, bevor man mit dem Programmieren loslegt, eine grobe Struktur des geplanten Sourcecodes aufzeichnen.
[...]


Das sollte man sowieso immer. Und zwar so richtig ausgiebig, ca. 75% der zeit mit Papier und Bleistift designen, wenn mans richtig macht reichen die restlichen 25% locker zum Coden und man hat ein (hoffentlich) fehlerfreies Programm. :)

mfg

[Melc]

Gibt es da einen Kurs, den man machen kann

[Demirug]

Das sollte man sowieso immer. Und zwar so richtig ausgiebig, ca. 75% der zeit mit Papier und Bleistift designen, wenn mans richtig macht reichen die restlichen 25% locker zum Coden und man hat ein (hoffentlich) fehlerfreies Programm. :)

mfg

Die alte Legende von der gute Plannung. Ich kenne mehr als ein System das nachdem viele Seiten mit Plannungunterlagen geschrieben wurden in den Papierkorb gewandert ist. Softwaresysteme sind nun mal leider keine Brücken die man genau im Vorraus planen kann.

[del_4901]

Die alte Legende von der gute Plannung. Ich kenne mehr als ein System das nachdem viele Seiten mit Plannungunterlagen geschrieben wurden in den Papierkorb gewandert ist. Softwaresysteme sind nun mal leider keine Brücken die man genau im Vorraus planen kann.

Nananana, dann hat's aber leider auch an der Erfahrung derjehnigen gehapert. Papier und Bleistift sollten eigendl. reichen! Bei Betriebssystemen kann man debuggen sogar ganz und gar knicken.

[Demirug]

Nananana, dann hat's aber leider auch an der Erfahrung derjehnigen gehapert. Papier und Bleistift sollten eigendl. reichen! Bei Betriebssystemen kann man debuggen sogar ganz und gar knicken.

Ein Mangel an Erfahrung kann es wohl kaum gewesen sein denn davon hatten die entsprechenden Personen genug. Die Problemstellungen waren nur dermassen komplex das sie auf diese Art nicht mehr bewältigt werden konnte. Zudem habe ich während meiner Bundeswehrzeit noch ganz andere Dinge bezüglich der Plannung von Softwaresystemen erlebt. Leider darf ich diese haarsträubenden Geschichten nicht erzählen.

Warum sollte man bei Betriebssystemen das debuggen knicken können? OK man braucht heute spezial debugger für sowas aber mit zum Beispiel SoftIce ist das kein Problem.

[Trap]

Nananana, dann hat's aber leider auch an der Erfahrung derjehnigen gehapert. Papier und Bleistift sollten eigendl. reichen! Bei Betriebssystemen kann man debuggen sogar ganz und gar knicken.
Woher soll man die Erfahrung nehmen wenn man keine hat? Ohne Erfahrung bringt planen nicht viel. Vor allem ohne Erfahrung mit dem Problembereich.

Wenn man schon vorher genau weiß wie man es sinnvoll löst kann man mit Papier und Bleistift planen.

[Nagilum]

Ich kenne mehr als ein System das nachdem viele Seiten mit Plannungunterlagen geschrieben wurden in den Papierkorb gewandert ist.
Was aber nun überhaupt kein Argument gegen eine Projektplanung ist.

Denn umgekehrt kennt wohl jeder von uns haufenweise Projekte, die dank fehlender Planung völlig den Bach runtergegangen sind.

[Trap]

Man muss unterscheiden ob man Projektziel planen oder Projektverlauf/-ablauf planen meint. Sonst ist es total sinnlos dafür oder dagegen zu argumentieren.

[Nagilum]

Man muss unterscheiden ob man Projektziel planen oder Projektverlauf/-ablauf planen meint. Sonst ist es total sinnlos dafür oder dagegen zu argumentieren.
Das lässt sich schwerlich trennen, da die Projektziele selten einmal in Zement gegossen werden und für immer feststehen. Und welcher Projektverlauf berücksichtig nicht die Erreichung der Projektziele?

[Trap]

Und welcher Projektverlauf berücksichtig nicht die Erreichung der Projektziele?
Extreme Programming, zumindest einige Interpretationen davon.

Ich spiel grad, nachher genauer.

[Asmodeus]

Ich finde, fast nirgends gehen Theorie und Praxis so weit auseinander wie bei der Programmierung von komplexen Softwareprojekten. Sicher, es gibt mehr oder weniger aufwendige Planungs- und Spezifikationsphasen, die Programmierer wissen über objektorientiertes Programmieren genauso bescheid wie über die Notwendigkeit einer guten Quellcodedokumentation, aber letztendlich sieht die Praxis doch immer so aus, dass gerade bei grossen Projekten (z.B. 1 Millionen Zeilen Code aufwärts) es immer Programmfragmente oder ganze Softwareteile gibt, die einfach nur "reingehackt" wurden, sei es aus Zeitdruck, Bequemlichkeit oder ähnlichem. Und schon wurde quasi die Planung nicht 1:1 umgesetzt. Auf eine Planung verzichten sollte man deswegen natürlich nicht. Aber Demirug hat schon recht, wenn man mal das "Glück" hat, bei kommerziellen Produkten auf den Sourcecode schauen zu können, dann stehen einem oft die Haare zu berge. Und Software in fertiger, binärer Form offenbart nunmal nicht gleich, was oft für ein Wust an Programmcode dahinter steckt und solang "richtig gerechnet" wird ist es dem Anwender auch meist egal.

Und mal Hand aufs Herz, schreibt ihr eure Programme auch immer durchgehend brav in ungarischer Notation ;)

Gruss, Carsten

[Demirug]

Was aber nun überhaupt kein Argument gegen eine Projektplanung ist.

Denn umgekehrt kennt wohl jeder von uns haufenweise Projekte, die dank fehlender Planung völlig den Bach runtergegangen sind.

Das war ja auch nicht als Argument gegen eine Plannung zu verstehen sondern das selbst eine gute Plannung nicht zwangsläufig dazu führt das man das ganze am Schluss schnell und fehlerfrei implentieren kann.

[Nagilum]

Das war ja auch nicht als Argument gegen eine Plannung zu verstehen sondern das selbst eine gute Plannung nicht zwangsläufig dazu führt das man das ganze am Schluss schnell und fehlerfrei implentieren kann.
Ack. Darauf kann man sich einigen.

[Exxtreme]

Also einen "Grundriss" sollte man schon haben. Bei pingelingen Projektbeschreibungen kommt einem die Realität oft in die Quere. :D

[maximAL]

Sicher fängt man mit der engine ansich an.

erstmal fängt man an, kleine konsolen-programme zu schreiben...

[Gast]

Was hab ich da angerichtet? :O :D

Das war ja auch nicht als Argument gegen eine Plannung zu verstehen sondern das selbst eine gute Plannung nicht zwangsläufig dazu führt das man das ganze am Schluss schnell und fehlerfrei implentieren kann.

Den Nagel auf den Kopf getroffen!

Ich kenn aber keine andere Methode mit dem Ziel "Wie schreiben wir ein fehlerfreies, leicht wart- und erweiterbares Programm" die so oft Erfolg hat

[Einfachkrank]

Das mit der Projektplanung ist eine Sache der Gewöhnung! Ich hab kleine Programme bis 5000 Zeilen Quellcode jetzt schon so oft neu begonnen, weil ich mir dann immer selbst in die Quere gekommen bin, dass ich es mittlerweile schaffe, sie doch ohne Planung zu vollenden :D