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

Naja zumindest wuerde ich halt so viel Python lernen, dass es reicht, mal damit was auf den Bildschirm zu bringen. Du brauchst jetzt natuerlich kein Python-Experte zu werden deswegen und es gibt sicher auch andere Sprachen, mit denen man arbeiten kann, ich selber empfehle halt nur Python weil ich damit die besten Erfahrungen gemacht habe. Python in Verbindung mit Pygame, und Du hast mit 200-300 Zeilen schon einen einfachen Spiele-Prototyp.

Was Deine Idee angeht: Natuerlich mag die ausgereift sein und die mag auch funktionieren. Aber wissen kannst Du es nicht, da Du das Spiel bisher nur im Kopf hast und noch nicht selbst gespielt hast. Es ist schon nochmal ein Unterschied, wenn man den Prototyp selbst spielt, im Vergleich zu "nur im Kopf haben". Und es moechte ja keiner Deine Idee als solche kritisieren, zumal Du sie auch bisher ja nicht wirklich detailliert erklaert hast (und das verlangt auch keiner). Es geht nur darum, dass eine Idee auch immer eine Umsetzung benoetigt, und hierbei kann es durchaus scheitern, entweder an der Plattform oder am eigenen Wissen. Oder eben am Prinzip, also z.B. hast Du ja unabhaengig davon, dass es mal auf dem C64 laufen soll, und unabhaengig davon, dass Du mit den Programmierkenntnissen noch nicht so weit bist, auch noch das Problem, dass Du noch gar nicht weisst, wie Du das mit dem Abprallen vom PRINZIP her loesen moechtest. Und um dieses Prinzip herauszufinden, ist ein Prototyp eigentlich unerlaesslich. Denn Du hast hier unbekannte Gefilde vor Dir, und bevor Du da keine genaue Loesung oder Idee hast, wie Du das vom Prinzip her umsetzt (also unabhaengig von Ziel-Plattform und -Sprache), musst Du es auf jeden Fall prototypenhaft ausprobieren und damit experimentieren. Selbst wenn es dann auf Anhieb auch schon perfekt sein sollte, dann hast Du immerhin die Gewissheit. Und dann kommt eben der naechste Schritt, dass Du Dir ueberlegen musst, wie Du das ganze auf die Ziel-Hardware bekommst. Denn auf dem C64 gibt es keine Multiplikation und keine Division, es gibt nur 8-Bit-Werte, und es gibt keine Kommazahlen. Zumindest nicht in einer performanten Art und Weise. Also musst Du tricksen und abstrahieren, wie bereits weiter vorne jemand sagte, sodass Du mit den simplen Mitteln so nah wie moeglich an Deine Idee im Kopf rankommst, ohne dass der Spieler merkt, dass hier simpelste Dinge getan werden, die das "mathematisch korrekte", realistische Prinzip eigentlich nur "faken" oder simulieren.

Niemand sagt dass deine Idee schlecht wäre. Ich spreche nur aus einiger Erfahrung mit Programmieranfängern und es zeigt sich nahezu ausnahmslos dass die "Idee" weit von dem "Spiel" entfernt ist, was am hohen Grad der Abstraktion liegt. Viele Designentscheidungen werden gar nicht getroffen, weil man "es ja im Kopf" hat. Ist fatal für jedes Projekt mit mehr als ein paar Dutzend Zeilen Code.

Eine Idee haben ist billig, eine Idee zum Konzept ausarbeiten eben nicht mehr. Das ist dann schon richtige Arbeit.

Die Erfahrung lehrt mich aber auch dass die meisten Jungs meinen bei ihnen wäre das generell was anderes, von daher werde ich das jetzt auch nicht lange weiterbeobachten. Manche Erfahrungen muss man wohl auch einfach selbst machen.

Ich wünsche Dir viel Erfolg bei der Realisierung deines Projektes.

Und noch was, es muss bei einem Prototyp auch nicht zwingend darum gehen, das gesamte Spiel vorab schonmal zu implementieren. Ich habe das zwar bei Shotgun so gemacht (inkl. Menu und allem), aber das heisst nicht, dass das jeder so machen muss. Es geht hier wirklich erstmal nur um die unbekannten Stellen. Diese als Prototyp zu implementieren halte ich fuer Pflicht. Aber rein prinzipiell gesehen reicht es auch, z.B. nur die Abprall-Logik in Python zu implementieren bis das passt, und dann mit dem Spiel direkt auf dem C64 loszulegen. Aber das ist jetzt keine Empfehlung an Dich, ich sage nur, dass man es so auch machen kann. Letztendlich musst Du selbst entscheiden, wie viel Du Dir in Assembler dann schon zutraust. Allerdings gehoert zur Spieleprogrammierung auch ein gewisses Grundwissen dazu, wie ueberhaupt Spiele programmiert werden. Also vom Ablauf und Aufbau her (rein von der Programmierung her betrachtet). Und da ich da Deine Kenntnisse nicht genau kenne, wuerde ich auch da vermuten, dass es da sicherlich noch einiges zu lernen gibt. Und sowas lernt sich halt leichter, wenn man das erstmal in einer "bequemen" Sprache macht und nicht gleich in Assembler, denn dann kommt Dir staendig die Programmiersprache dazwischen quasi, und Du kannst Dich nicht drauf konzentrieren, das eigentliche Thema zu erlernen.

Klingt für mich nach "Schatten-Charset definieren": Neben dem sichtbaren Charset definiert man auch ein Charset, welches Hindernisposition und -Winkel ablegt. Mit dieser Info, sowie den dx/dy Werten geht man in eine Tabelle, welche die neuen dx/dy Werte enthält. Das bedeutet auch, dass für "hier kein Hindernis" die Tabelle die gleichen dx/dy Werte entält, mit denen man "angekommen" ist.

Vorteil: Es gibt keine Fallabfrage, die Geschwindigkeit für einen Durchlauf ist immer identisch.

Nachteil: Die Tabelle könnte recht groß werden, je nachdem welche Winkel man zulässt. Da man jedoch nicht auf "gleichmäßige" Winkel angewiesen ist, könnte man die Tabelle für jedes Level anders auslegen und so die Illusion einer total variablen Winkelverteilung erzeugen.

Es ist eigentlich wie bei jeder Programmieraufgabe: Nicht die Programmierung, sondern die Planung für die nötigen Datenstrukturen ist der ausschlaggebende Faktor. Hier kommt wieder die "Prototyp"-Idee zum Tragen: Erstmal schauen wie sich das anfühlt wenn man Levels derart "doppelt" generiert (grafisch und technisch), dann entscheiden ob der Jens ne passende Idee hatte

Jens

Kleiner Nachtrag:

Wie man hier schön sehen kann:

Viertelkreis_winkel.png

könnte man bei einem 12x12-(Char-)Objekt (= halber Screen) in jedem Viertelkreis (Achtelkreis) 11(/2) Char-(Kollisions-)Positionen abgreifen. Eine 90°/8-Abfrage wäre prinzipiell somit theoretisch also kein Problem (= 11,25° ff.)

Coole Sache Markie. Viel Erfolg.

Pixelgenau abfragen kannst Du das nicht, aber das laesst sich ja leicht ausrechnen. Du kannst ja bestimmen in welchem Character-Feld er sich befindet, indem Du x und y jeweils durch 8 teilst (also 3x nach rechts shiften). Dann kannst Du den Character abfragen, kennst also das Muster, und dann musst Du nur noch von der x/y-Position des Gechosses das Offset dieses Characters abziehen, dann hast Du zwei x/y-Werte zwischen 0 und 7 und weisst dann direkt auf welchem Pixel der Schuss liegt.

Schuesse koennen auch als Character implementiert werden, z.B. bei Wizard of Wor ist das der Fall. Allerdings fliegen diese immer in 8-Pixel-Schritten. Zwischenschritte sind theoretisch auch moeglich, aber bei einer so freien Schuss-Bahn wie es wohl in Deinem Spiel der Fall sein wird, denke ich dass Sprites auf jeden Fall deutlich einfacher sind. Auch waere es schwierig, Schuss und Spielfeld in Deinem Fall zu kombinieren, denn der Schuss soll ja pixelgenau an die "Wand" ran, und wenn die Wand kein volles Char-Feld ist, dann braeuchtest Du ja Character-Zeichen die Wand und Schuss beinhalten usw.

Zitat von Markie

Die 8-Pixel Schritte

Das ist dem 40x25-Zeichen-Bildschirmspeicher geschuldet. Im normalen Textmodus kann ein Zeichen ja nur innerhalb dieses Rasters gesetzt werden, es sein denn man legt mehrere, jeweils um x Pixel verschobene Zeichen davon an und läßt den Schuß durch zwei (oder diagonal auch mehr) Zeichen 'wandern'.

Zu den mehr als 8 Sprites: Such' mal nach "Sprite-Multiplexing" o. ä.. Vergiss das aber besser erstmal.