Hallo Besucher, der Thread wurde 7,2k mal aufgerufen und enthält 30 Antworten

letzter Beitrag von Hexworx am

Ich hab eine Spielidee: Bitte ein paar Tipps für einen Anfänger

    Hallo allerseits


    Bis jetzt hab ich mich noch nicht sehr mit C64-Programmierung befasst. Klar wollte ich
    damals auch unbedingt Assembler und Spieleprogrammierung lernen, bin aber wie
    wohl so viele an den zahlreichen Hürden gescheitert.


    Jetzt hat mich ZeHa ein wenig 'angesteckt' und ich hab auch auf anderen Plattformen
    ein wenig programmiert und auch schon ein Büchlein zu Assembler durchgearbeitet.
    Deswegen möchte ich jetzt nochmal schauen ob ich selber ein C64 Game hinbekomme.
    - Das Problem ist natürlich wie bei vielen Anfängern, dass man nicht etwas *einfaches*
    machen will, sondern ein Spiel das einem selbst reizt, etwas das man selbst spielen will,
    was also eben nicht unbedingt besonders einfach ist... :/:rolleyes:


    Jedenfalls hab ich eine 'fixe' Spielidee im Kopf und möchte die umsetzen und mir dabei
    das nötige Wissen aneignen ("learn by doing"). - Falls möglich...
    Anstatt dass ich jetzt zahlreiche Tutorials durcharbeite die irgend ein anderes Spiel
    basteln, möchte ich am liebsten gleich mit meinem *eigenen* Spiel anfangen können.
    Bzw. das eine tun und das andere nicht lassen: Während ich den Code von anderen
    durchgrabe und Tutorials wälze, möchte ich eben sehr gerne auch schon mit dem
    eigenen Spiel anfangen weil das für meine Motivation sehr wichtig ist. :D


    Nun gibt es dafür ein Problem: Das Wissen reicht bei weitem noch nicht aus, um
    am Anfang schon die richtigen Entscheide zu treffen (und das wird noch lange so
    bleiben fürchte ich... ;-). Das birgt ein sehr grosses Frustrationspotential.
    Deswegen möchte ich hier gerne ein paar erfahrne Spieleprogrammierer fragen,
    ob sie mich in die richtige Richtung lenken können bezüglich ein paar grundsätzlicher
    Entscheide?


    Meine (schwierige) Spielidee:
    Ich möchte einen Side-Shooter basteln wo man durch ein (grösseres) Labyrinth
    mit 4-Weg scrolling geht. Das Spezielle: Die Schüsse sollen von den Wänden teilweise
    (nicht von allen) und von manchen Objekten in einem möglichst realistischen Winkel
    abprallen können. Auch mehrfach hintereinander. Von der Implementierung wohl so
    ähnlich wie in einem Pinball Game.


    Das 4-Weg Scrolling sollte machbar sein, dafür gibt es ja scheinbar einige Source Codes
    im Netz von denen man lernen kann.
    Aber das möglichst realistische, auch mehrfache Abprallen der Schüsse von manchen
    Wänden und Objekten dürfte ziemlich schwierig werden. Kennt jemand eine Routine dafür?
    Gibt es Source Code für Pinball Games?


    Meine erst Frage ist: Welchen Grafik-Modus soll ich für mein Spiel wählen?


    Wenn ich den Grafik-Modus falsch wähle, kann das ja glaub ziemlich frustrierend werden.
    Deswegen die Frage an die Profis:
    Für ein Shooter mit 4-Weg Scrolling und einem Labyrinth durch das man hindurchgehen
    kann und an dessen Wände (nicht an allen) die Schüsse teilweise in möglichst realistischem
    Winkel abprallen sollen, welches ist der beste / richtige Grafikmodus? (Ja, bunt ist besser!)


    Ich glaube der Grafikmodus hängt davon ab, was man will / braucht. Und ich brauche
    eben ein möglichst realistisches Abprallen der Schüsse von manchen Wänden und Objekten.
    Das Problem der Wahl des richtigen Grafikmodus ist jetzt, dass das davon abhängt, wie
    man dieses Abprallen implementiert. Und dazu hab ich eben noch nicht die geringste
    Ahnung, also kann ich auch unmöglich den richtigen Grafikmodus wählen und somit eben
    auch kaum anfangen, ohne fast sicher ziemlich viel falsch zu machen und entsprechend
    frustriert zu werden.


    Kann da jemand helfen der sich gut auskennt mit Grafikmodi und Implementierung
    solcher Spiele?


    Schöne Grüsse,
    Markie

    Also ich wuerde Dir (wie Du ja schon weisst) erstmal zu einem Prototyp raten. Vor allem wenn es um Dinge geht, die Du noch nie gemacht hast. Wenn Du ein Spiel machen willst, bei dem Dir saemtliche Dinge klar sind, dann kann man das auch in Reinform programmieren (selbst da wuerde ich inzwischen lieber erst nen Prototypen machen, weil es ja nicht nur um die Technik geht sondern auch darum, ob das Spiel ueberhaupt Spass macht). Aber wenn es um Dinge geht, bei denen Du noch gar nicht genau weisst, wie Du das machst, da wuerde ich auf jeden Fall einen Prototypen erstellen. Zum Beispiel in einer simplen Sprache wie Python. Der muss auch nicht zwingend so aussehen wie das finale Spiel, aber allein schon das Abprallen der Kugeln koennte man darin sehr einfach testen. Mein spontaner Vorschlag hierzu waere uebrigens, der Kugel zwei Richtungsvariablen zu geben, in x und y, und diese unterschiedlich stark gewichten, z.b. x_dir = 4 und y_dir = 0, x_dir = 3 und y_dir = 1, x_dir = 2 und y_dir = 2, usw - aber ich bin kein Experte fuer so Geometrie-Kreis-Winkel-Sinus-Zeugs, da gibts sicher andere, die Dir besser weiterhelfen koennen. Aber wenn ich das vorhaette, wuerde ich das einfach mal direkt in nem Prototypen implementieren und dann sehen, ob das realistisch genug ist oder nicht.


    Was den Grafikmodus angeht, wuerde ich behaupten, liegt es hauptsaechlich daran, wie Du das Spiel gestalten willst. Mit dem Abprallen hat das glaube ich weniger zu tun. Ich wuerde mir da also an Deiner Stelle Gedanken machen, wie das Spiel aussehen soll oder mal ein paar Mockups in GIMP usw erstellen. Ich denke das musst Du letztendlich selbst entscheiden. Schaue Dir am besten auch ein paar andere Spiele an, wie die so aufgebaut sind und was Dir vom Stil her besser gefaellt. Die meisten Spiele auf dem C64 nutzen wahrscheinlich Multicolor-Character-Modus.

    Jo, das dürfte auf Multicolor-Textmodus hinauslaufen. Die Bitmap-Modi fallen raus, da man sie nicht schnell genug scrollen kann. Ok, Democoder können das dank VSP/AGSP dann doch, aber es hat schon seinen Grund, dass das niemand in einem Spiel macht.
    Und falls Du im Nachhinein von MC-Textmodus zu Hires-Textmodus oder ECM wechseln willst, ändert sich am Code damit so gut wie gar nichts.

    Zitat von ZeHa

    Prototyp

    +1! Bei so einem Spiel ist Steuerung, Geschwindigkeit etc. entscheidend für das Spielgefühl, daher brauchst Du eine möglichst einfache Sandbox zum experimentieren, also bloß noch nicht zu viel Arbeit in Loader, Menüs, Punktanzeigen etc. investieren (auch wenn man manchmal sowas braucht, um den Kopf wieder frei zu bekommen).


    Genau, vier-Wege-Scrolling legt Dich eigentlich schon auf den MC-Charmodus fest. EIne Frage die sich stellt ist, ob Du die Level als Characters speicherst (flexibel, braucht aber viel Speicher), oder mehrere Character zu Tiles zusammenfasst (2x2, 4x4, ...) und die Level aus diesen zusammensetzt.


    Versuch bloß nicht, anhand der Grafik zur Laufzeit irgendwelche Abprallwinkel zu bestimmen. Auf dem C64 musst Du schauen, dass Du so viel wie möglich vorberechnest. Eine Möglichkeit wäre es, pro Character auf dem Bildschirm einen Winkel zu speichern. Einfacher ist immer besser :) .


    Ich fand es übrigens extrem motivierend, an einer Compo teilzunehmen. Das zwingt einen, sich auf das wesentliche zu konzentrieren und auch etwas fertigzustellen. Nach der Compo kann man solch ein Prequel dann ausbauen ^^

    Zitat von ZeHa

    der Kugel zwei Richtungsvariablen zu geben, in x und y, und diese unterschiedlich stark gewichten, z.b. x_dir = 4 und y_dir = 0, x_dir = 3 und y_dir = 1, x_dir = 2 und y_dir = 2, usw

    Bei einem Anprall auf einen rechten Winkel funktioniert das ja noch recht simpel, weil nur die eine Richtung umgekehrt werden muss. Etwas schwieriger wird's natürlich bei anderen Winkeln. Da müsste man sich wohl Tabelle basteln (EDIT: Siehe Claus). Man muss es mit der Anzahl der Winkel ja auch nicht übertreiben (z. B. ein Kreis/Bumper ist dann eben nur ein Acht-/ Sechzehn- oder was auch immer für ein Viel-Eck).


    Erste Hürde wird auch die Kollisionsabfrage sein (natürlich nicht über die VIC-Dinger).


    Ich würde wohl erstmal als Prototyp sowas wie "Pong" basteln.

    Schade, dass es hier (noch) nicht weiterging :cry : Einfache Spieleentwicklung am Beispiel :-)


    Da kann man aber schon mal einiges mitnehmen.

    Zitat von ZeHa

    Mein spontaner Vorschlag hierzu waere uebrigens, der Kugel zwei Richtungsvariablen zu geben, in x und y

    Jo, dadurch werden die Berechnungen in einigen Fällen sehr simpel:


    Abprallen von senkrechter Wand: dx = -dx
    Abprallen von waagerechter Wand: dy = -dy


    Bei 45° Schrägen müsste man noch zusätzlich dx mit dy vertauschen und die Vorzeichenänderung kann ja nach Einfallswinkel variieren wenn ich mich nicht irre, aber das kriegt man auf dem 6510 auch noch mit wenig Aufwand erschlagen.


    Andere Winkel erfordern mit der Methode deutlich mehr Rechenaufwand und sollten daher vermieden werden :)

    Hey! Danke Euch allen für die vielen Antworten! :):)


    @ZeHa
    Einen Prototypen werde ich wahrscheinlich nicht machen... Tatsächlich weiss ich schon sehr genau
    was ich will, bzw. habe den Prototyp den Du mir rätst bereits jetzt schon fixfertig im Kopf!!
    - Das geht noch schneller als mit Python...!! ;-)


    Mein Problem ist ja nicht - wie vielleicht bei Dir - herauszufinden ob meine Spielidee gut genug
    ist für ein Spiel, oder ob sie Spass macht zum spielen...
    Wäre ich von meiner Idee nicht schon sehr überzeugt, würde ich nicht bereits mit der Umsetzung
    anfangen wollen... ;-)
    Ich will ja Programmieren, um das Spiel endlich zu haben, nicht weil ich programmieren will... ;-)
    Und extra noch eine Programmiersprache lernen, nur um mir anzusehen was ich mir gut vorstellen
    kann dafür hab ich im Moment nicht die Nerven... ;-)
    Und, falls etwas nicht Spass machen sollte, dann ändere ich das ad-hoc. Die Grundzüge sind mir
    klar und ich bin überzeugt, damit kann man was machen das Spass macht. Details hängen dann
    natürich noch von kleineren Dingen ab und vom Leveldesign, aber das kommt eh erst später,
    ist also kein Hindernis.


    Meine Gedanken gingen eben genau auch in die gleiche Richtung wie jene von Claus und Hexworx:


    Zitat von Claus

    Versuch bloß nicht, anhand der Grafik zur Laufzeit irgendwelche Abprallwinkel zu bestimmen.


    Das ist genau der springende Punkt den ich mir eben auch überlegt habe! =O
    Anstatt irgendwelche Winkel eines Hintergrundreliefs und Aufprallwinkels mit sin und cos zu
    berechnen, ist es sicher zweckmässiger, bestimmte Characters zu verwenden die entweder:


    A: Auf der ganzen Aufprallfläche einen fixen Winkel haben, wie etwa '\', '/', '|', '-', etc.
    und dann vielleicht ein wenig wüste "ASCII-Art" zu zeichnen.


    B: Die Pixelgenau bemerken, WO (= welches Pixel) ein Schuss auftrifft. also z.B. bei einer
    Kollision mit einem runden Objekt ("O") von der Seite auf dem untersten Pixel, dem
    zweituntersten, dem drittuntersten, dem Mittleren, usw. Also nicht für den ganzen
    Character einen Winkel verwenden, sondern eine Tabelle, je nach Kollisionspixel.


    Wann man A macht, dann gibt das wohl hässliche Reliefes denke ich. - Ok, - hier wäre ein
    Prototyp evtl. sinnvoll, um sich das vorzustellen... Das ist tatsächlich nicht so einfach.
    Ich denke an ASCII-Art in alten Textdateien... Natürlich sind 4x4 Characters einiges besser,
    und die eigenen Charcters sind ja dann hinten auch "aufgefüllt", aber trotzdem... ob das
    noch schön wird???
    Gerade bei kleinen Objekten wird es dann kaum möglich, viele verschiedene Winkel zu haben.
    Zum Beispiel wenn man eine Kugel etwa in der Grösse der Sprites will, wird die sicher nicht
    sehr schön mit 4x4 pixel grossen Characters zusammengesetzt, die überall den selben Winkel
    haben. Aber Du hast mich überzeugt ZeHa: Ich probier das in Photoshop mal aus...! :D


    Wenn man B macht, bestimmte Characters oder Objekte komplett selber zeichnen, dann wird
    die Grafik wohl schöner. Man kann beliebig kleine Rundungen selber zeichnen anstatt sie klobig
    zusammensetzen zu müssen. Allerdings braucht man dann eben eine wirklich pixelgenaue
    Kollisionsdetektion, die je nach Aufprallpixel auf den Character oder das Objekt einen anderen
    Winkel (und damit eine andere Reflektion) fest einprogrammiert hat. Also zum Beispiel eine
    selbst gezeichnete Kugel als 8 x 8 Character oder als 12 x 12 Character, etc. Das hat den
    positiven Effekt, dass Grafik und Reflektions-Winkeln dann gar nicht aneinander gebunden
    sein müssen und man zum Beispiel einem Dreiek auch eine Reflektion wie einer Kugel geben
    kann... :bgdev
    Man denke da zum Beispiel an das Spiel "Showdown 2100 AD" auf dem Magnavox Odyssey 2,
    bzw. bei uns bekannt als "Philips Videopac G7000". Da gab es so lustige dreieckige Kakteen...
    Wenn man darauf schoss, dann reflektierten sie die Schüsse überhaupt nicht gemäss ihrer
    Oberfläche, sondern fast genau wie wenn sie Kugeln wären. Also fix eingestellte Abprallwinkel
    je nach Kollisions-Pixel und X- und Y- Geschwindigkeit des Schusses.


    Wirklich interessant wäre also von jemand zu hören, der schon mal ein Flipper programiert hat.


    Wenn man das also so oder so alles mit Characters machen kann, entweder mit pixelgenauer
    Kollisionsabfrage (B) oder mit fixen Characters welche überall den selben Winkel haben (A),
    dann muss man sich überlegen, welche grösse von Charcters dafür in Frage kommen?
    Bei A müssten es sicher kleine Characters sein, sonst wird die Grafik *sehr* hässlich. Also wohl
    etwa 4 x 4. Bei B könnten die Characters auch grösser sein, etwa 8 x 8, da man dann ja irgendwas
    zeichnen kann.


    Geht denn beides, Characters mit 4 x 4 oder solche mit 8 x 8 gleich gut für Mutlicolor Character Mode?


    Ich denke das ist die erste Frage. Das Scrolling wird wohl mit beidem gehen.


    Und die zweite Frage ist dann, da die Grösse der Characters auch schon eine ganz früh gestellte
    Weiche ist: Welche Grösse und damit welche Art der Implementierung soll ich wählen?
    A.) Mit 4 x 4 Pixeln und gleichem Winkel überall (damit müsste man dann versuchen 'Kugeln',
    usw. zu "basteln", was wohl im Endresultat nicht optimal aussieht - muss ich im Photoshop
    ausprobieren...).
    B.) Mit grösseren Characters (etwa 8 x 8), aber mit einer pixelgenauen Kollisionsabfrage.


    Oder kombinieren ;-):
    C.) 4 x 4 Pixel mit einer pixelgenauen Kollisionsabfrage (falls das Sinn macht?).


    Die letztendliche Frage ist wohl die: Kann man bei einem selbst gemachten Character
    ( zB. 8 x 8 ) auf das Pixel genau abfragen, mit welchem Pixel ein Schuss kollidiert?


    Liebe Grüsse,
    Markie


    PS: Ja, der Thread "Einfache Spieleentwicklung am Beispiel :-)", den muss ich
    mir auch noch zu Gemühte führen, der sieht auch sehr interssant aus! :-)

    Ich habe den Prototyp allerdings vorgeschlagen um das Abprall-Zeug zu testen, nicht um die Spielidee als solche zu testen. Und das mit dem Abprallen wäre in einer simplen Sprache a la Python bestimmt bereits mit weniger als 200-300 Zeilen testbar. Sowas direkt in Assembler zu programmieren und dann erst auszuprobieren wie es am besten hinhaut, das halte ich für sehr ungünstig.

    Zitat von Markie

    B: Die Pixelgenau bemerken, WO (= welches Pixel) ein Schuss auftrifft. also z.B. bei einer
    Kollision mit einem runden Objekt ("O") von der Seite auf dem untersten Pixel, dem
    zweituntersten, dem drittuntersten, dem Mittleren, usw. Also nicht für den ganzen
    Character einen Winkel verwenden, sondern eine Tabelle, je nach Kollisionspixel.

    Oha, da haste dir aber was vorgenommen. Weisst du schon, ob alle Projektile ne fixe Geschwindigkeit haben sollen, oder ist das variabel?

    Zitat von oobdoo

    Auch wenn ich wieder haue bekomme

    :versohl:


    Zitat von Markie

    Geht denn beides, Characters mit 4 x 4 oder solche mit 8 x 8 gleich gut für Mutlicolor Character Mode?

    Da gibt es glaube ich noch ein Missverständnis: die Characters die Du selber definierst, haben natürlich eine Pixel-Auflösung. Mit 4x4 und 2x2 meinte ich sogenannte Tiles, die wiederum aus mehreren Charaktern bestehen. Da geht es nur um das Speichern eines Levels: Du kannst den Level komplett durch Character beschreiben, aber da ein Bildschirm 1000 Character umfasst, brauchst Du dann pro Bildschirm eben 1 Kilobyte, was für einen länger scrollenden Level schnell zu viel werden kann. Definierst Du aber Tiles, die aus 4x4 Charaktern bestehen und setzt Deine Level aus diesen zusammen, brauchst Du schon mal nur 1/16 des Speichers (plus dem Speicher, den Du für die Tiledefinition benötigst).

    Zitat von Markie

    B: Die Pixelgenau bemerken, WO (= welches Pixel) ein Schuss auftrifft. also z.B. bei einer
    Kollision mit einem runden Objekt ("O") von der Seite auf dem untersten Pixel, dem
    zweituntersten, dem drittuntersten, dem Mittleren, usw. Also nicht für den ganzen
    Character einen Winkel verwenden, sondern eine Tabelle, je nach Kollisionspixel.

    Das ist wirklich alles nicht ohne...


    Ich hab mir da vorhin auch nochmal Gedanken gemacht:


    Sinnvoll denkbar wäre vielleicht folgendes:


    Steigungen:


    1:1 45°
    1:2 22,5°
    1:4 11,25°
    1:8 5,625°


    Damit ließe sich schon (char-basierend) z. B. ein 'Kreis' mit einem Durchmesser von ca. 13 Chars (=halbe Screen-Höhe) realisieren (bzw. ein 32-Eck).


    Daraus resultieren dann aber so lustige Sachen wie: 11,25° treffen auf 22,5° und werden somit zu 45° etc.


    Mach' mal :) .

    Zitat von oobdoo

    Auch wenn ich wieder haue bekomme... aber man kann Excel prima für Programmierprojekte mißbrauchen. :)

    Man kann auch schnell in Excel (oder einer anderen Tabellenkalkulation) sowas wie einen Prototyp eines Leveldaten Generators mit Formeln (also ohne VBA & co) basteln, ohne dass man zuerst ein Tool programmieren muss.
    Ich finde da nichts Verwerfliches daran. Man bekommt so schnell Resultate und ein Gefühl für das Ganze. Wenn dann die Leveldaten Mechanik/Berechnungen funktioniert, kann man immer noch einen komfortableren Leveleditor auf dem PC proggen.


    Ausserdem lassen sich Berechungen wie z.B. Winkeldaten oder Geschwindigkeiten in Excel schnell für verschiedene Szenarien erstellen und als Tabellen in das eigene Programm einfügen.

    Ohne das böse zu meinen, aber dein jetziger Ansatz an das Problem heranzugehen ist zum Scheitern verurteilt.


    Kernproblematik:
    - keine wirklichen Kenntnisse der Sprache, aber größere Projekte angehen. Das funktioniert einfach nicht. Erst mal klein bleiben.
    - Überzeugung, dass die eigene Idee im Kopf komplett gereift ist. Böser Fehler. Schreib Dir kein Konzept auf. Überlege dir die Wechselwirkungen der einzelnen Komponenten. Ideen als solches sind billig, und meist sehr weit abstrahiert. Erst beim durchdenken fallen Inkonsistenzen auf. Ein Fehler den fast jeder Anfänger macht.
    - Die technischen Einschränkungen sind unbekannt. Und davon gibt es beim C64 viele. Beschäftige dich erstmal ausführlich mit dem was (und wie) der C64 so kann. Denn das wird dir schon dein Konzept beeinflussen.
    Beispiel:
    Maximale Schuzsszahl begrenzt, wenn viele Winkel nötig, da nur 8 Sprites. -> (Multiplexer?),(Charset -> weniger Winkel)

    Zitat von BladeRunner

    Schreib Dir kein Konzept auf

    Du meinst sicherlich "Schreib Dir das Konzept auf" :D
    Ich habe die Erfahrung gemacht, dass man Probleme dadurch, dass man sie jemanden erklären/ausformulieren muss, oft selbst auf Ungereihmtheiten stösst.
    Oder auch manchmal selbst die Lösung sieht. Aber man muss es halt aufschreiben oder für jemanden erklären, also ausformulieren.

    Danke nochmals allen für die vielen guten Ratschläge!
    :-)


    Grundsätzlich hast Du mit Deiner Kritik bezüglich Anfängern und grösseren
    Projekten natürlich völlig recht.
    Aber: Alles fängt klein an. Auch dieses Projekt.
    Die Idee ist nicht von Anfang an ein grosses Projekt oder Spiel zu machen, sondern nur,
    möglichst ohne nochmal ganz neu anfangen zu müssen ein Spiel von ganz klein auf
    zu basteln, dass bereits im kleinen funktioniert (zuerst noch ohne Scrolling) und dass
    dann ausgebaut werden kann, ohne eben komplett neu anfangen zu müssen und ohne
    erst viele andere, kleinere Projekte machen zu müssen.
    Ob das klappt ist hier aber wohl nebensächlich, denn wenn es nicht klappt, mach ich eben
    in der Zwischenzeit noch kleinere Projekte - falls mir dazu was einfällt das mich reizt..
    Deswegen geht diese Idee und damit auch die Fragen dazu hier ja nicht weg, sprich,
    fragen und sich Gedanken dazu machen darf man ja trotzdem schon... :)
    Man muss ja irgendeine Motivation haben, nicht?


    Die Idee im Kopf zum Spiel ist ziemlich komplett gereift. - Änderungen vorbehalten. ;)
    Bitte die Idee zum Spiel nicht mit der Implementierung verwechseln.
    Ich bin Anfänger im Programmieren, sprich ich weiss nicht wie implementieren.
    Ich bin nicht Anfänger was Computerspiele angeht. Nur weil ich noch nie ein Spiel
    für den C64 selber programiert habe, heisst nicht dass meine Idee für ein Spiel
    nicht gut ist. - Vielleicht ist sie schwierig oder gar unmöglich umzusetzen oder
    zu implementieren, das könnte sein, aber nur weil ich das Spiel noch nicht
    geschrieben habe, heisst nicht dass die Spielidee deswegen falsch oder schlecht ist.


    Und keine Sorge, ich beschäftige mich schon damit, was der C64 so kann. Das sieht
    man ja demonstrativ an tausenden Programmen, mit denen ich mich ausführlich
    als User beschäftigt habe!! :rolleyes::love:
    Und ja, Du hast recht, genau dieses Wissen hat mich in meinem Konzept beeinflusst.
    Abprallen geht grundsätzlich, siehe Flipperspiele, Scrolling geht grundsätzlich,
    siehe diverse Spiele.
    Ich glaub nicht dass meine Idee unmöglich ist umzusetzen. Nur jetzt im Moment
    für mich. Aber das lässt sich vielleicht ändern. - Mal sehen.


    Jedenfalls hab ich den Ratschlag von ZeHa zu Herzen genommen und mir 2
    Anfängerbücher zu Python bestellt. Ich glaube was ZeHa mir immer sagen wollte
    ist schlicht eine uralte Programmierer-Weisheit:
    -----------------------------
    Erst wenn man ein Programm geschrieben hat, weiss man wie man es
    schreiben muss. - Bzw. wie man es hätte schreiben müssen...
    -----------------------------
    Denn erst dann versteht man alle Probleme die dabei auftauchen richtig.
    Und ZeHa meint jetzt einfach sich damit eine Menge Arbeit sparen zu können,
    wenn man den ersten Entwurf erst mal nicht gerade mit C64 Assembler
    baut, eben weil das ziemlich Hardware-spezifisch und schwierig ist. - Ich werde
    also mal schauen wie schnell ich in Python reinkomme (C und C++ und wie gesagt
    ein wenig Assembler hab ich mir mal selbst beigebracht). Dann kann ich das
    ganze Zeugs mit den Winkeln und allem in Python ausprobieren und
    spare damit vielleicht ein wenig Zeit...
    Wenn ich viele Spiele programmieren werde, so wie ZeHa, dann lohnt sich
    die Kenntnis von Python sicher noch sehr viel mehr, da man damit ja dann
    immer wieder "Entwürfe" schreiben kann (abgesehen davon dass manche es
    auch bei der Arbeit brauchen).
    Aber Python interessiert mich schon auch ein wenig. Hab davon schon
    paarmal Gutes gehört.


    LG,
    Markie