Selber Spiele programmieren?

Ich denke das problem bei grßen SPieln ist nicht nur das programmieren allein, sondern auch das man vorher planen muss wie man was löst...und das überfordert viele

 

Ja. In größeren Projekten ist die Planung das A&O, und Programmierkenntnisse in bestimmten Sprachen sind eher zweitrangig bzw. werden dann angeeignet, wenn erstmal klar ist, was die Software überhaupt machen soll.

 

Gibts da eigentlich nen weg das irgendwie zu lernen?
Stoße in meinen Projekten immer häufiger an dieses Problem, habe aber keinen plan wie man sowas ordentlich organisiert

 

k.A ... vielleicht gibt es da Bücher drüber. Ich habe erst angefangen, mir das anzueignen, als ich beruflich angefangen habe zu Programmieren. Dann kann man das Projekt icht mehr einfach aufgeben, wenn es einem über den Kopf wächst ( ), sondern muß wohl oder übel anfangen, es in Teilprobleme zu zerlegen, ordentliche Kommentare zu schreiben, zu dokumentieren ...

Und ich habe noch das Glück, daß ich alleine an meinem Projekt arbeite. Koordination zwischen mehreren Teammitgliedern ist dann nochmal eine Klasse höher.

 

Auch hier wieder ein Buch von Bruce Eckel: Thinking in Patterns (www.bruceeckel.com). Dieses Buch war ursprünglich mal "das letzte Kapitel" in Thinking in Java und erklärt die Grundlagen und verschiedene Aspekte des Softwaredesign. Allerdings wurde es wohl ein wenig erweitert und ist jetzt als eigenes Buch da! Es stellt die Beispiele zwar mittels Java dar, aber das auf eine mehr "spieletaugliche" Programmiersprache, C++ hauptsächlich, zu übertragen, ist nicht unbedingt schwierig. Außerdem geht's ja um allgemeine Sachen, nicht Implementierungsdetails.

Nimm dir am besten ein kleines Projekt vor, wirklich klein, heißt, wenn du meinst, es ist klein genug, dann nimm eins, das halb so groß ist. Dann fange an, alles durchzuplanen. Je nachdem, wieviel du vom Plan abweichen musst, war die Planung eher gut oder eher schlecht. Das übt sich aber auch mit der Zeit. Aber wie gesagt, nimm ein kleines Projekt zum Anfangen...

Wirklich niemand scharf auf ein Programmiererforum?

Gruß,
Drag0n

 

+++

 

Ich hab' mal den "Object-Oriented Analysis & Design" Kurs von John Deacon mitgemacht. Der hat mir gut gefallen. Vielleicht gibt es dazu ja auch Material im Netz.

Schwerpunkt war die CRC Methode (Class-Responsibility-Collaborator).

 

Ich habe mit QBASIC angefangen, dann Pascal, und dann endlich C++. Ich wünsche mir sehr, direkt mit C++ angefangen zu haben. Damit lernt man auch gleich, sauber zu programmieren. Denn mit C++ kann man ja auch prozedural coden!

Gruß,
Drag0n

 

*reusper*
Das mit dem "sauber" soll wohl ein Witz sein, oder?
Bei (Object) Pascal gibt es einen einheitlichen Style-Guide, eine einfach zu lesende Syntax und einen klar strukturierten Aufbau - ist eben eine Lehrsprache.
C++ ist dagegen alles andere als einheitlich. Jeder schreibt seinen Code wie es ihm passt, da wird dann noch der Code mit ungarischer Notation versaut und Anfänger machen alles falsch, was man falsch machen kann (ich sage nur Varibalen-Deklaration, Aufbau und Schreibweise). Im Endeffekt kommt ein Wischiwaschi-Code raus, den nach 2 Wochen keiner mehr lesen kann.
Wer die Theorie verstehen will, muss es sich nicht unnötig schwer machen. Wer noch nie mit einer Programmiersprache in Berührung gekommen ist, wird zu großer Wahrscheinlichkeit mit C\C++ scheitern.

 

@Bel-Garadh: Generell hast du 3 Möglichkeiten:

1. Du besorgst dir ein Tool mit dem man Spiele erstellen kann. Diese erfordern keine oder nur wenig Programmierung, da man die Spiele einfach mit der Maus zusammen klickt. Beispiele sind der bereits erwähnte RPG Maker oder Klick'n'Shoot, Adventure Game Studio etc. Nachteil: Du bist bei den Features deiner Spiele beschränkt auf das, was die Entwickler der Tools eingebaut haben. Vorteil: ohne Kenntnisse kannst du in kurzer Zeit ansehnliche Resultate erzielen.

2. Du machst eine MOD zu einem bestehenden Spiel. Viele Entwickler sehen heute diese Möglichkeit in Ihren Spielen vor indem sie die Schnittstellen zu ihren Spielen offenlegen. Nachteil: Du musst dich informieren wie du ein Spiel moddenn kannst und das kann evtl. auch das Schreiben von Code notwendig machen. Vorteil: Engine, KI usw. sind bereits vorhanden, du passt nur noch die Monster, Level, Waffen etc. an deine Bedürfnisse an.

3. Du lernst programmieren. Für den Anfang kann ich da wirklich Blitz Basic empfehlen, einen simplen 2D Space Shooter schreibst du mit 100 Zeilen Programmcode. Das Buch 'Jetzt lerne ich Spiele programmieren mit Blitz Basic (http://www.amazon.de/exec/obidos/AS...r=2-1/ref=sr_aps_prod_1_1/028-3295085-0054900)' von Rene Meyer ist für Einsteiger ziemlich gut.

Wenn deine Projekte jedoch größer werden wirst du wohl irgendwann an die Grenzen von Blitz Basic stoßen. BB unterstützt zum Beispiel keine objektorientierte Programmierung. Natürlich geht es auch ohne, aber bei großen Projekten ist es schon recht mühsam. Auch der Debugger von BB ist nicht gerade toll.

Daher würde ich dir auch zu C++ raten. Das Argument, daß man damit nicht sauber programmieren kann ist Unsinn. Man kann mit *jeder* Sprache sauber und unsauber programmieren, das hängt vom eigenen Willen und der eigenen Disziplin ab. Außerdem ist C++ in der Spieleprogrammierung am weitesten verbreitet, d.h die meisten Bibliotheken und Beispiele sind in C++.

Dennoch ist C++ für Anfänger ein harter Brocken, also für komplette Einsteiger nicht wirklich geeignet. Also, fang mit Blitz Basic an, und nur wenn das wirklich beherschst, dann kannst du dir überlegen die nächste Stufe zu erklimmen.

Und beherzige die hier oft ausgesprochene Empfehlung: Fang klein an! Wenn du mit einem großen Projekt startest wirst du irgendwann nicht mehr weiterkommen und die ganze Sache hinschmeißen. Am Anfang brauchst du Erfolgserlebnisse, also mit kleinen Sachen anfangen und die dann auch zuende bringen, dann erst die nächste etwas größere Sache angehen.

BTW: Ich bin auch für ein Programmierforum!

 

doch ich ernst!

 

Pascal schreibt keinen Codestil vor! Schlimmer noch, nichtmal zwischen Groß- und Kleinschreibung wird unterschieden. Das heißt, da kommt man nochmal zusätzlich durcheinander. Wie auch MarkusSeger in der Zwischenzeit angemerkt hat, hängt es immer vom Lernenden ab, ob man sauber programmiert oder nicht. Und ob jemand daran scheitert, das Programmieren zu lernen, hängt meiner Meinung nach nur unwesentlich von der Sprache ab.

Cool! Jetzt sind wir schon zwei!!!

Gruß,
Drag0n

 

Oha, hab ich dich glatt vergessen!

3!!!

Gruß,
Drag0n

 

Gruß,
Drag0n

 

Naja, an einem Programmier Forum wuerde ich mich zwar beteiligen, aber ich glaube nicht wirklich, dass eins noetig ist. SW Forum tut's auch IMHO.

 

Das denke ich auch. Schließlich müsste ich dann in zwei Foren mitlesen.

 

keiner mag mich

 

man kann auch in C OO programmieren. Es ist alles nur eine Frage, wie du die Syntax von OO definierst

.net ist kein Dreck. .net ist eine skalierbare, flexible, plattformunabhängige, stabile und große Plattform fürs Programmieren.

 

Ich gehe von Object Pascal aus:
http://community.borland.com/soapbox/techvoyage/article/1,1795,10280,00.html

 

Stimmt. Seitdem ich mal 'ne zeitlang gar nicht ins GSPB gekommen bin, beschraenke ich mich inzwischen nur noch auf das SW Forum.

 

@Halabalusa: Ein Style Guide ist lediglich eine Ansammlung von Konventionen und Vorschlägen an die man sich halten *kann* aber eben nicht *muß*. Der Compiler kann dich nicht dazu zwingen diese Konventionen einzuhalten, im Grunde ist es ihm nämlich vollkommen egal wie du deinen Quellcode formatierst.

Solche Style Guides gibt es auch für C, C++, C#, Java etc. und nicht nur für (Object) Pascal. Somit ist die Existenz dieses Style Guides kein Zeichen dafür, daß man nur in Pascal sauber programmieren kann.

Und, wie schon angemerkt worden ist: .NET ist kein Dreck! Wer schon mal größere Projekte mit C# gemacht hat wird begeistert sein von der Produktivität, die mit dieser Sprache möglich ist. Nur weil irgendwas von Mircosoft kommt muß es nicht automatisch böse sein.

 

btw
wie integriet man eigentrlich grafik-engines in ein spiel
und kann man ein spiel auch in 2 programmiersprachen schreiben?
sprich: ein kleiiner teil z.b visual pascal und der andere c++

 

Werden eingebunden, bzw. gleich als Quellcode mit eingebaut.

Indem man den Compilern sagt, sie sollen nur Objektcode (.obj und so) erzeugen und die einzelnen Objektcodefiles dann mit dem Linker zusammenlinkt. Man muß auch auf ein paar Sachen achtgeben, z.B. daß die beiden Programmiersprachen die selben Regeln beim Aufruf von Funktionen verwenden (welches Argument steht wo auf dem Stack oder in welchem Register...).

 

thx
das heisst, man kann auch sagen, dass bestimmte programmiersprachen nicht kompatibel sind??
also ich kann mir nicht vorstellen, dass man qbasic mit c++ kombiniert ;D

 

In der Regel besteht die Engine aus einer .lib-Datei, dann wird sie mit dem Linker in deine .exe eingebunden. Per .h-Datei werden die in der Engine definierten Klassen und Funktionen dem Compiler bekannt gemacht und du kannst sie in deinem Quelltext aufrunfen. Oder aber die Engine kommt als .dll, dann wird sie bei der Installation neben deine .exe gepackt.

Der von SilentHunter vorgeschlagene Weg ist wohl eher seltener anzutreffen, da die verschiedenen Compiler unterschiedliche Formate bei den Objektdateien haben.

Am häufigsten wird wohl der Weg über eine DLL gewählt. Z. B. schreibe ich eine Funktion in C++ und kompiliere diese als DLL. Dann kann ich von einer anderen Sprache aus diese DLL laden und die darin enthaltene Funktion aufrufen. Das ist aber alles sehr sprachspezifisch, kommt also auf den Einzelfall an.

 

Wenn sie die gleichen Regeln beim Funktionsaufruf befolgen, kann das schon klappen. Ich glaube, es gibt eigentlich nur zwei verbreitete Arten, Funktionen aufzurufen, und ein Problem hat man erst dann, wenn Compiler A unbedingt Format X verwenden will, und Compiler B Format Y, und keiner der beiden Compiler sich dazu überreden läßt, das andere Format zu verwenden.

Mit QBasic gibt's allerdings ein kleines Problem - es ist nur ein Interpreter, kein Compiler (die Compilervariante heißt glaube ich QuickBasic oder so).

 

Zeig mir mal wo pascal keinen codestil vorschreibt?
Natürlich KANNST du jeden code mit 100tabs verunstalten, aber pascaöl ist so angelegt das eigentlich jeder damit halbwegs lesbar schreibt..von alleine
hinzu kommt das pascal "spechender" ist als c/c++, bei pascal kann man den sinn der befehle meist aus dem befehl selbst erschliessen (begin end, brush,colo,etc. pp) während man bei c/c++ einfach nur am rätselraten, bzw am f1 drücken ist

 

wärs nicht günstiger mit dlls zu arbeiten?

 

Aber nur wenn man dynamisch linkt.

 

@Schattengarde: Der Streit um die schönste, sauberste, schnellste und leckerste Programmiersprache ist so alt wie die Programmierung als solche. Aber Pascal schreibt nun mal keinen Stil vor, wie auch? Ich kann meinen Variablen und Funktionen kurze, nichtssagende Namen geben, ich muß Schleifenkörper nicht einrücken, ich muß meinen Code nicht kommentieren etc. Dazu kann mich der Compiler schließlich nicht zwingen. Und wer sonst sollte es tun?

Wenn ich will, kann ich mit Pascal schlampig programmieren. Wenn ich will kann ich aber auch mit C++ sauber programmieren. Ich kann aber auch mit Pascal sauber programmieren und mit C++ schlampig. Das hängt aber von mir ab und nicht von der verwendeten Sprache.

Und ob ich jetzt lieber begin und end schreibe oder { und }:
1. Bedeutet beides das Gleiche
2. Ist das eher Geschmackssache.

Ich z. B. mag { und } lieber als begin und end. Ist halt kürzer, ich kann mit weniger Zeichen das Gleiche ausdrücken. Ist aber halt eben meine persönliche Meinungen. Andere finden begin und end schöner.

Jeder sollte die Sprache wählen mit der er am besten zurecht kommt. Es gibt keine beste Programmiersprache.

 

Ich mixe im Moment nur Assembler und C und das ist die andere Möglichkeit besser, weil sowieso alles in der selben IDE abläuft.

 

Ich mixe im Moment nur Assembler und C und da ist die andere Möglichkeit einfacher, weil sowieso alles in der selben IDE abläuft.

 

Das stimmt aber z.T. auch nur fuer bestimmte Sprachen (C++ z.B.).

Also hier (lese: Analysesoftware in der Elementarteilchenphysik) werden munter Fortran, C und C++ Objekt Dateien zusammengelinkt.

Hm, nach meiner Erfahrung ist es recht Wurst, ob man Name Mangling Probleme bei Objekt Dateien oder Bibliotheken bekommt.

 

Bei Python muss man's.

 

Klar funktioniert das, weil Fortran und C halt eben beide Objektdateien erzeugen. Wenn die Compiler dann auch noch zueinander kompatibel sind dann klappts auch mit dem Linker

Das muß aber nicht so sein. Es gibt ja auch Sprachen die keine Objektdateien erzeugen und dann gibt es eben auch nix zu linken z.b. VB, C# etc.

Es ging mir ja auch nicht um das Name Mangling sondern eher um die Problematik mit den Objektdateien und deren Kompatibilität zueinander. Das Problem hast du bei DLLs nicht, da diese Compiler- bzw. Linkerunabhängig sind.

 

Er sprach aber explizit von Objektdateien...

Woher kommen denn noch Inkompatibilitaeten?

Aha, ist das bei Windows so?

 

Ja, aber Objektdatei ist nicht gleich Objektdatei, siehe unten.

Es gibt keinen Standard für Objektdateien, jeder Compilerhersteller kocht da sein eigenes Süppchen und hat daher sein eigenes Dateiformat. Es ist daher nicht garantiert oder sogar eher unwahrscheinlich, daß der Linker der Firma A mit den Objektdateien des Compilers der Firma B klar kommt und umgekehrt.

Ja. DLLs enthalten keinen Objektcode sondern werden vom Linker mit allem versorgt was sie zum Ausführen brauchen, sie enthalten z. B. den Runtime-Code, was ja bei Objektdateien nicht der Fall ist, der Runtime-Code wird ja erst durch den Linker hinzugefügt. DLLs werden ja auch nicht zu einem Programm gelinkt, sondern erst zur Laufzeit geladen.

Im Prinzip ist eine DLL eine EXE die man nicht direkt starten kann.