Christoph.Krn
Advanced Member
Also ich möchte mal einen Tipp abseits der Wahl der verschiedenen Programmiersprachen und technischen Hilfsmittel geben, und zwar einen kleinen Einblick darin, auf welche Art und Weise ich das Programmieren damals gelernt hab. Als konkrete Methode kann ich folgendes empfehlen:
------------------------------------------------------------------------
Für einen praktischen Einstieg in das Thema 3D-Spieleentwicklung empfehle ich noch immer das "3d-Gamestudio", mit dem auch ich damals meinen ersten Kontakt mit C (bzw. "C-lite", einer C-Untermenge) und virtuellem dreidimensionalen Raum gemacht habe.
Damit kann man zwar am Ende nicht viel anfangen (es ist kein echtes C, und für die Pandora entwickeln kann man damit schon mal gar nicht), der Beispielcode ist mittelgrausam (oder war es zumindest damals), aber es ist ein guter Einstieg, denn erst einmal muss man abstrakt verstehen, wie man z.B. im virtuellen dreidimensionalen Raum (oder auch im zweidimensionalen Raum) navigiert, wie einzelne Einheiten miteinander agieren, wie die Algorithmen hinter graphischen Effekten aussehen etc. (das ist genau das, was du, CF-Freakx, mit "mich interresirt wie man generellen den Sprung ins 2D game Progen. kommt ! Wo lernt man von der C++ tehorie in die 2D spiele Praxis zu springen?" meinst.)
Genau dafür ist das Gamestudio als Komplettpaket hervorragend geeignet, und sonderlich teuer ist es auch nicht (Version 7.5 kostet momentan etwa 30 Euro, Version 8 erscheint wie ich gerade gesehen habe am 15. Oktober für 75 Euro, aber 7.5 reicht vollends aus, es geht hierbei ja nur um die abstrakten Mechanismen und nicht um eine opulente Grafikengine u.Ä.).
------------------------------------------------------------------------
Ein weiteres Problem besteht gerade bei Spielen darin, dass ein gut geschriebener Programmcode noch lange kein gutes Spiel macht (genau so, wie ein kompilierender Code noch lange nicht fehlerfrei ist).
Quelle: http://forum.gp2x.de/viewtopic.php?f=7&t=9723&start=30#p125249Christoph.K said:Mein Tipp: versuch nicht, es [das Buch, Anm.] von vorne nach hinten durchzulesen, sondern stöbere darin herum bis du etwas entdeckst, das für dich so klingt als könntest du Spaß an einer konkreten Umsetzung dessen haben. Und dann versuch dich an der Umsetzung, der Schwierigkeitsgrad ist erst einmal von untergeordneter Rolle, denn je schwieriger desto höher der potenzielle Wissensgewinn pro Codezeile. Das musst du dann ausloten, wie viel oder wenig Schwierigkeit für dich am besten ist, und das findest du mit der beschriebenen Methode dadurch heraus, dass es dir noch Spaß macht. Wenn es frustrierend wird, dann blättere einfach noch einmal im Buch umher und suche dir etwas anderes heraus.
Das ganze kannst du dann für deine erste veröffentlichte Software konkret ausweiten, indem du dir einen Satz an Voraussetzungen zulegst die du an deine eigene Software stellst. Ich z.B. habe beispielsweise Sicherheit eine hohe Priorität gegeben. Wenn ich mir also Wissen zu etwas aneigne, um daraus letztlich etwas schaffen zu können, das andere nutzen werden, dann verifiziere ich laufend, ob dieses Wissen mit sicherheitskritischen Problemen behaftet ist. (Deswegen sehe ich C auch längst als Medaille mit - Überraschung - ZWEI(!) Seiten. )
Das ist jedoch nur mein bescheidener persönlicher Senf und durchaus "with a grain of salt" (mit Skepsis) zu konsumieren (vorsicht, fantastulöses Wortspiel ).
So mach ich's auch meistens, ist auch für einen Einstieg eine gute Sache. Später können dann allerdings (gute!) Bücher das auf diese Weise erworbene Wissen teilweise hervorrangend komplementieren, nicht nur bei Programmiersprachen. Es kommt natürlich immer auf das konkrete Thema an, und wie gut die dazu erhältlichen Informationen in Büchern respektive dem Internetz letztlich sind. Spontan fällt mir da z.B. "The Art of Deception" und http://www.sicherheitskultur.at/social_engineering.htm#schutz ein.foxblock said:Ich lerne selber kaum mit Büchern, als mit Tutorials und Beispielprogrammen aus dem Netz.
Ich bin der Meinung, dass man am besten lernt, wenn man das direkt praktisch angeht, also man sich ein paar Grundkenntnisse holt und dann einfach mal loslegt (Hello World, der Standard, dann evtl ein kleines "Textadventure", dann was mit Grafiken, etc.) und sich so anhand einigen Beispielen nach und nach das aneignet was man braucht oder wissen will.
Zudem kann man sich etwas kompliziertere OpenSource Programme oder Spiele herunterladen und sich dann mal durch den Quelltext schlagen um zu gucken wie gewisse Strukturen umgesetzt wurden, etc.
------------------------------------------------------------------------
Für einen praktischen Einstieg in das Thema 3D-Spieleentwicklung empfehle ich noch immer das "3d-Gamestudio", mit dem auch ich damals meinen ersten Kontakt mit C (bzw. "C-lite", einer C-Untermenge) und virtuellem dreidimensionalen Raum gemacht habe.
Damit kann man zwar am Ende nicht viel anfangen (es ist kein echtes C, und für die Pandora entwickeln kann man damit schon mal gar nicht), der Beispielcode ist mittelgrausam (oder war es zumindest damals), aber es ist ein guter Einstieg, denn erst einmal muss man abstrakt verstehen, wie man z.B. im virtuellen dreidimensionalen Raum (oder auch im zweidimensionalen Raum) navigiert, wie einzelne Einheiten miteinander agieren, wie die Algorithmen hinter graphischen Effekten aussehen etc. (das ist genau das, was du, CF-Freakx, mit "mich interresirt wie man generellen den Sprung ins 2D game Progen. kommt ! Wo lernt man von der C++ tehorie in die 2D spiele Praxis zu springen?" meinst.)
Genau dafür ist das Gamestudio als Komplettpaket hervorragend geeignet, und sonderlich teuer ist es auch nicht (Version 7.5 kostet momentan etwa 30 Euro, Version 8 erscheint wie ich gerade gesehen habe am 15. Oktober für 75 Euro, aber 7.5 reicht vollends aus, es geht hierbei ja nur um die abstrakten Mechanismen und nicht um eine opulente Grafikengine u.Ä.).
------------------------------------------------------------------------
Ein weiteres Problem besteht gerade bei Spielen darin, dass ein gut geschriebener Programmcode noch lange kein gutes Spiel macht (genau so, wie ein kompilierender Code noch lange nicht fehlerfrei ist).
Quelle: http://forum.gp2x.de/viewtopic.php?f=7&t=9723&p=124972#p124972Christoph.K said:Viel problematischer als das reine Programmieren an sich ist allerdings, auch ein gutes Spielkonzept zu haben und am Ende mit einer Software dazustehen, die anderen auch tatsächlich SPAß bereitet. Ich weiß leider nicht mehr, wer es gesagt hat, wann oder wo, und kenne auch nicht mehr den genauen Wortlaut, aber irgendwann habe ich mal gelesen, ein bekannter Spieldesigner habe mal von sich gegeben (sinngemäß):
Besser kann man es eigentlich nicht ausdrücken. Bei mir hat es auch einiger Spiele bedurft, ehe etwas dabei herauskam das ich auch heute (also mit mehr Abstand) noch als spaßig bezeichnen würde. Denn es geht darum, herauszufinden was den BENUTZERN Spaß macht, und das stimmt nicht unbedingt intuitiv mit dem überein was den jeweiligen ENTWICKLERN am Spiel spaßig erscheint.Ein Bekannter Spieldesigner said:Your first 10 games will be horrible.
Ein guter Programmierer macht eben noch keinen guten Spieleentwickler. Solange man sich dessen bewusst ist und Spaß an der Sache hat kann man allerdings nicht viel falsch machen, denn wenn man motiviert bei der Sache ist und Rückmeldungen der Spieler analysiert, dann werden folgende Spiele immer besser.
Auch deshalb, und vor allem aber wegen dem hohen Programmieraufwand und der Komplexität, kann auch ich nur davon abraten, zu Anfang gleich ein größeres Projekt starten zu wollen. Ein Pong-Klon oder etwas ähnlich triviales ist für den Anfang genau das richtige, und dann ist es auch von eher untergeordneter Bedeutung, welche Komplexität die jeweils verwendete Programmiersprache und Werkzeuge vorweisen.