EatTheBlocks

[nufan]

Mal wieder ein Update von mir

Schon langsam wird es ja richtig spielbar *thumbs up*

Es ist schon nicht schlecht, aber ich finde immer noch Punkte an denen ich was verbessern kann

Leider habe ich keine stark unterschiedlich "starke" Computer, sodass ich das Spiel bezüglich Geschwindigkeit testen könnte.
Das Spiel ist optimiert auf 800*600 (bezüglich der Position und Größe des Textes). Auf der ToDo-List steht noch Schriftgröße und Blockgröße von der Auflösung abhängig machen.

Bei der Größe solltest du dir aber langsam einmal überlegen wie du den Code auf mehrere Dateien aufteilst. Sonst wird es doch etwas unübersichtlich.

Hab ich mir auch schon gedacht. Werde das Programm wohl auf 2-3 Header aufteilen.

Ich glaube das hast du wirklich etwas übertrieben

Ich hab absichtlich versucht das ein wenig zu übertreiben, damit ich das ein wenig übe und Kommentieren zur Gewohnheit wird.

Halte dich doch an die üblichen Konventionen und mach auch ein 'all'-Target.

Wofür genau? Statt dieser Zeile:

Code: Alles auswählen

EatTheBlocks: EatTheBlocks.c

also

Code: Alles auswählen

all: EatTheBlocks.c

?
Das ist nämlich "all", mehr Dateien gibts noch nicht

Wenn keine Highscoredatei vorhanden ist könntest du eventuell auch eine Fehlermeldung ausgeben. So weis man nicht so ganz was passiert. Du könntest auch einfach trotzdem die Highscore anzeigen und "keine Einträge vorhanden" hinschreiben.

Ja, das steht noch auf der ToDo-List. Zurzeit wird nur eine Fehlermeldung in das log-file geschrieben. Im Programm selbst passiert eigentlich nichts.

Ja, du solltest nur vorher die alte Surface freigeben, die du beim ersten Aufruf von SDL_SetVideoMode erhalten hast.

Das ist ein binäres 'oder'. Es werden allso beide Flags verwendet.

Klingt logisch, danke für die Info.

Nett wäre noch eine kleine Anmerkung zu den abhängigkeiten. Ich hab keine SDL Entwicklerbibliotheken installiert, und kann dementsprechend das spiel auch nicht kompilieren. Vielleicht solltest du für die wichtigsten Distributionen die benötigten Pakete dazuschreiben.

Ok, werde ich ins HELP-File schreiben.
Kann ich die Abhängigkeiten auch ins makefile packen?

[fat-lobyte]

So, nachdem Kerli mir per ICQ die benötigten Bibliotheken durchgegeben hat, hab ich folgende Kritikpunkte zu beanstanden:

• Es hat kompiliert! Ohne Fehler und sogar ohne Warnung (dabei war -Wall eingeschalten!) Gratulation. Von mir gibts schon mal nen haufen Pluspunkte.
• Es läuft! (Beim ersten Testen) keine abstürze, keine Fehlermeldungen auf der Konsole, keine sichtbaren Bugs! Gratulation. Pluspunkte.
• Es funktioniert! Es ist ein guter, funktionierender Snake Klon, den man spielen kann! Gratulation! Schon wieder pluspunkte!

Bis jetzt *Thumbs Up!*

So, genug der Lorbeeren, jetzt gehts ans konstruktive:

• Du hast anscheinend eine sehr Flüssige bewegung drinnen, die Schlange bewegt sich von Pixel zu Pixel. Das sieht einerseits gut aus, andererseits ist es etwas ungewohnt: andere Snake klone bewegen die schlange trotzdem auf einem diskreten Feld (also quasi einem Fließenboden). Das erleichtert die steuerung. Wenn man in einem anderen klon schnell umdrehen will, kann man kurz hintereinander die nach oben und die nach rechts taste drücken (angenommen man fährt zuerst nach links). Dadurch fährt dann die schlange Paralell zum schwanz.
  In deinem Spiel kann es passieren, dass wenn man zu schnell ist, die schlange in sich selbst hineinfährt, da man abbiegt bevor die schlange ihre eigene breite zurückgelegt hat. Ungefähr klar was ich meine?
• Also ich kenn mich in der Spieleprogrammierung gar nicht aus, deswegen weiß ich nicht ob mein Wunsch möglich ist:
  Dein Programm verbraucht einen ganzen CPU kern, wahrscheinlich in einer Schleife. In einem 3D Spiel ist es für mich akzeptabel, nicht aber in einem 2D Spiel. Vielleicht solltest du die Struktur deines Programms so umstellen, dass du nicht die ganze CPU verheizt (evtl mit einem Timer? Frage geht an unsere Game Profis).
• Wenn man auf das X Des Fensters klickt erwartet man, dass sich das Fenster schließt, nicht dass das Spiel beendet wird und danach gefragt wird ob man nochmal spielen will. Vielleicht kann man das irgendwie einbauen.

So, genug gemeckert. Nicht als beleidigung auffassen sondern als konstruktive Kritik! Dein Spiel ist echt super.
In den Code hab ich noch nicht reingeschaut. Falls ich zeit habe, werf ich mal einen Blick hinein. (Eher unwahrscheinlich, hab noch 2 große Prüfungen ausständig )

[nufan]

• Es hat kompiliert! Ohne Fehler und sogar ohne Warnung (dabei war -Wall eingeschalten!) Gratulation. Von mir gibts schon mal nen haufen Pluspunkte.
• Es läuft! (Beim ersten Testen) keine abstürze, keine Fehlermeldungen auf der Konsole, keine sichtbaren Bugs! Gratulation. Pluspunkte.
• Es funktioniert! Es ist ein guter, funktionierender Snake Klon, den man spielen kann! Gratulation! Schon wieder pluspunkte!

Bis jetzt *Thumbs Up!*

Das ist mal gut, Danke

So, genug der Lorbeeren, jetzt gehts ans konstruktive:

• Du hast anscheinend eine sehr Flüssige bewegung drinnen, die Schlange bewegt sich von Pixel zu Pixel. Das sieht einerseits gut aus, andererseits ist es etwas ungewohnt: andere Snake klone bewegen die schlange trotzdem auf einem diskreten Feld (also quasi einem Fließenboden). Das erleichtert die steuerung. Wenn man in einem anderen klon schnell umdrehen will, kann man kurz hintereinander die nach oben und die nach rechts taste drücken (angenommen man fährt zuerst nach links). Dadurch fährt dann die schlange Paralell zum schwanz.
  In deinem Spiel kann es passieren, dass wenn man zu schnell ist, die schlange in sich selbst hineinfährt, da man abbiegt bevor die schlange ihre eigene breite zurückgelegt hat. Ungefähr klar was ich meine?

Ich weiß sehr genau was du meinst und in der allerersten Version war die Bewegung auch "blockweise". Nur hab ich dann wieder das Problem mit der Geschwindigkeit. Auf meinem PC lief es in angenehmer Geschwindigkeit während Kerli und +Fuss+ nicht einmal zum Reagieren kamen...

[*] Also ich kenn mich in der Spieleprogrammierung gar nicht aus, deswegen weiß ich nicht ob mein Wunsch möglich ist:
Dein Programm verbraucht einen ganzen CPU kern, wahrscheinlich in einer Schleife. In einem 3D Spiel ist es für mich akzeptabel, nicht aber in einem 2D Spiel. Vielleicht solltest du die Struktur deines Programms so umstellen, dass du nicht die ganze CPU verheizt (evtl mit einem Timer? Frage geht an unsere Game Profis).

Ist mir auch aufgefallen, dass der CPU-Verbrauch ziemlich hoch ist *Frage an Game-Profis weiterleite*

[*] Wenn man auf das X Des Fensters klickt erwartet man, dass sich das Fenster schließt, nicht dass das Spiel beendet wird und danach gefragt wird ob man nochmal spielen will. Vielleicht kann man das irgendwie einbauen.[/list]

Ok, das ist mir bis jetzt noch nicht aufgefallen, danke für den Hinweis

So, genug gemeckert. Nicht als beleidigung auffassen sondern als konstruktive Kritik! Dein Spiel ist echt super.

Ich freue mich über jede Kritik, egal ob positiv oder negativ

EDIT:
Da kommt ja noch was...

EDIT:
OK... jetzt ists wieder weg...

[fat-lobyte]

Halte dich doch an die üblichen Konventionen und mach auch ein 'all'-Target.

Wofür genau? Statt dieser Zeile:

Code: Alles auswählen

EatTheBlocks: EatTheBlocks.c

also

Code: Alles auswählen

all: EatTheBlocks.c

Ich würds so machen: EatTheBlocks

Code: Alles auswählen

all: EatTheBlocks
EatTheBlocks: EatTheBlocks.c

Zum Makefile: es wäre gut wenn du dich an Konventionen halten würdest.
Der Name des Makefiles sollte "Makefile" und nicht "makefile" sein. Funktioniert beides, ersteres ist üblicher.

Wieso eigentlich

Code: Alles auswählen

 CC = gcc 

? Darf man keine anderen Compiler verwenden? Lass die Zeile einfach weg, dann wird der richtige compiler ausgewählt.
Kleiner Tipp:

Code: Alles auswählen

#statt 
CFLAGS = ...
#mach lieber
CFLAGS += ...

Was tut das? Es fügt den CFLAGS deine Zeile hinzu, anstatt sie zu setzen. Mit dem oberen tipp kann man ganz leicht aus der konsole aus, und zwar durch setzen der umgebungsvariablen noch optionen hinzufügen.
Beispiel:

Code: Alles auswählen

alexander@schlepdebian:~/source/EatTheBlocks/src$ # ich hätt gern nen andern compiler
alexander@schlepdebian:~/source/EatTheBlocks/src$ export CC=gcc-4.1
alexander@schlepdebian:~/source/EatTheBlocks/src$ # Meine header liegen an einem ganz komischen Ort
alexander@schlepdebian:~/source/EatTheBlocks/src$ export CFLAGS="-I/usr/local/include/einganzkomischesverzeichnis"
alexander@schlepdebian:~/source/EatTheBlocks/src$ make
gcc-4.1 -I/usr/local/include/einganzkomischesverzeichnis -o EatTheBlocks EatTheBlocks.c -Wall `sdl-config --cflags --libs` -lSDL_ttf

Ok, werde ich ins HELP-File schreiben.
Kann ich die Abhängigkeiten auch ins makefile packen?

Makefile ist keine gute Idee, da das für jeden Computer persönlich ist. Schreibs lieber ins INSTALL file.

[nufan]

Wieso eigentlich

Code: Alles auswählen

    CC = gcc 

? Darf man keine anderen Compiler verwenden? Lass die Zeile einfach weg, dann wird der richtige compiler ausgewählt.

Code: Alles auswählen

    #statt
    CFLAGS = ...
    #mach lieber
    CFLAGS += ...

Was tut das? Es fügt den CFLAGS deine Zeile hinzu, anstatt sie zu setzen. Mit dem oberen tipp kann man ganz leicht aus der konsole aus, und zwar durch setzen der umgebungsvariablen noch optionen hinzufügen.

Wusste ich nicht, man lernt nie aus
Danke für die Hilfe mit dem Makefile, es ist das erste Mal, dass ich so was verwende. Ist auch ganz praktisch

[Kerli]

Ist mir auch aufgefallen, dass der CPU-Verbrauch ziemlich hoch ist *Frage an Game-Profis weiterleite*

Ich hoffe ich bin damit auch gemeint

Dein "Problem" solltest du mit einer fixen Framerate bzw. besser mir einer Begrenzung der Framerate leicht in den Griff bekommen. Das heißt du schaust dir nach jedem Frame die dafür benötigte Zeit an und falls die Zeit unter einem bestimmten Wert liegt, dann legst du den Prozess so lange schlafen bis die restliche Zeit der für die maximale Framerate benötigten Zeit pro Frame verbraucht ist.

Schlafenlegen kannst du den Prozess mit SDL_Delay. Wie hoch die Framerate liegen soll musst du ausprobieren, ab ca. 30 FPS sollte es flüssig erscheinen. Etwas mehr kann aber auch nicht schaden.

Achja, es wäre vielleicht besser wenn du nicht die List mit den unterstützten Auflösungen vorgeben würdest. Manche Leute bevorzugen doch andere Auflösungen als die, die vorgegeben hast. Versuch es doch einmal mit SDL_ListModes.

[nufan]

Dein "Problem" solltest du mit einer fixen Framerate bzw. besser mir einer Begrenzung der Framerate leicht in den Griff bekommen. Das heißt du schaust dir nach jedem Frame die dafür benötigte Zeit an und falls die Zeit unter einem bestimmten Wert liegt, dann legst du den Prozess so lange schlafen bis die restliche Zeit der für die maximale Framerate benötigten Zeit pro Frame verbraucht ist.

Schlafenlegen kannst du den Prozess mit SDL_Delay. Wie hoch die Framerate liegen soll musst du ausprobieren, ab ca. 30 FPS sollte es flüssig erscheinen. Etwas mehr kann aber auch nicht schaden.

Kann sein, dass ich jetzt im Prinzip nochmal das gleiche sage:
Ich versuche auf 30 FPS zu kommen, d.h. jeder Frame 1/30 Sekunde. Wenns weniger ist mit SDL_Delay warten.
Sollte ich hinbekommen

Achja, es wäre vielleicht besser wenn du nicht die List mit den unterstützten Auflösungen vorgeben würdest. Manche Leute bevorzugen doch andere Auflösungen als die, die vorgegeben hast. Versuch es doch einmal mit SDL_ListModes.

Ich hab das zuerst auch so versucht. Ich habe alle verfügbaren Auflösungen in einem Array gespeichert zwischen denen man dann wählen konnte.
Im Fenstermodus ist jedoch jede Auflösung möglich (Any dimension is okay for the given format, Referenz). Damit hätte ich unendlich viele Möglichkeiten... dann hab ich mich entschieden bestimmte häufig verwendete Auflösungen vorzugeben.
Also Standard 800*600. Dann etwas größer 1024*768. Und dann noch für Widescreens. Das soll aber hauptsächlich für den Vollbild-Modus sein. Die am häufigsten verwendeten Formate 4:3, 16:9, 16:10 sind vorhanden. Sollte es wirklich noch Probleme geben, werde ich noch ein paar hinzufügen.


PS: Das Problem mit der leeren Highscorelist hab ich schon gelöst

[nufan]

Ich habe jetzt versucht alle Vorschläge unterzubringen.
Das mit "Schließen" ingame funktioniert jetzt. Wenn man die Highscores ausgeben will und keine Liste vorhanden ist, erscheint "No available highscores".

Dann hab ich schnell meine Version umgekrempelt und sie ist jetzt näher an das "Original"-Snake angelehnt. Ein Frame sollte immer 1000 /level ms dauern. Level steigt mit jedem gefressenen Block. 10 Pixel pro Frame, das Spiel ist jetzt "gerade".
CPU-Verbrauch während Pause gedrückt ist, wurde von 50 % auf 5 % gesenkt...

Zuerst dachte ich, dass ich das mit der steigenden Geschwindigkeit bei der neuen Methode nicht hinbekomm. Tja, wenn man zu einem int immer 0.01 dazuzählt, dauert es lange um die Geschwindigkeit zu erhöhen...

Nur weiß ich jetzt nicht, an welcher Version ich weiterarbeiten soll.

Die Vorteile an der neuen Methode:
Die Bewegung ist gerade. Man kann leichter überprüfen, ob ein Block gefressen wurde.
Man kann leichter Überprüfen, ob man sich selbst gefressen hat.

Nachteile:
Alte PCs (jene, die einen Frame nicht in der vorgegeben Zeit schaffen) bleiben auf der Strecke.
Die Bewegung ist nicht mehr so flüssig (kann man aber auch als Vorteil sehen).

Welche Version würdet ihr bevorzugen?

In die nächste Version will ich auch ein kleines Logo im Menü einbauen. Dabei hab ich an etwas ähnliches wie das Logo von Python IDLE vorgestellt:

Mal sehen, was GIMP so ausspuckt...

Link
(beide Versionen, 2 ist die neue)

[fat-lobyte]

Nice nice nice...
Gefällt mir schon sehr gut, die Kritikpunkte schnurstracks eingebaut. Das mit der CPU gefällt mir besonders. Hast du den ganzen Tag dran gecodet?

Aber gleich mal vorweg:
Eine version mit "programmname_new" zu benennen ist keine gute Idee. Sonst arbeitest du nächste Woche an "EatTheBlocks_newRemake_changedFinal3".
Benenne deine Programme gleich nach Versionen: 0.1, 0.1.2 oder ähnliches. Wie du das machst ist dir überlassen, es gibt kaum Konventionen. In der Opensource Welt ist es aber unüblich mit 1.0 anzufangen und gleich mit 2.0 weiterzumachen (vielleicht weils etwas Großkotzig nach SuperTollesSharewareProgramm 11 klingt, wo zwischen version 6 und 10 fast keine Unterschiede erkennbar waren).

Sieh dir übrigens noch Versionsverwaltungssysteme wie SVN oder Git an. Weiß nicht, ob Xin die Repositories noch anbietet (ob sie schon funktionieren), aber wenn nciht kannst du auch lokal eines anlegen.
Glaub mir, am Anfang wirst du dich etwas wundern, aber nach der Zeit wirst du SVN lieben lernen, und echt spaß dran haben.

Nachteile:
Alte PCs (jene, die einen Frame nicht in der vorgegeben Zeit schaffen) bleiben auf der Strecke.

Das verstehe ich eigentlich nicht so ganz...
Wenn du eine Gameschleife hast, die nach oben hin gedeckelt ist, es also eine Maximalframerate hat, wo ist dann der Unterschied zwischen den PC's ?
Solltest du nicht sowieso die Strecke die du zurücklegst nicht konstant lassen sondern von der Framezeit abhängig machen?

t ... Zeit des letzten Frames
s ... Weg der zurückgelegt werden muss (in einer beliebigen Einheit, z.B. Sekunden)
v ... Gewünschte Geschwindigkeit

v = s / t
s = v * t

Für mich sieht das nicht sehr Rechenintensiv aus, und so furchtbar komplex auch nicht

Übrigens: vielleicht solltest du dir eine Lizenz überlegen, unter der du es Veröffentlichen willst. Wenn es Opensource sein soll, dann würde ich eher zu einer Vorgeschriebenen (GPL, mod. BSD, ...) raten.
Es gilt der Grundsatz: Wenn die Lizenz länger ist als das Programm, kann man von einem Overkill ausgehen

[nufan]

Gefällt mir schon sehr gut, die Kritikpunkte schnurstracks eingebaut. Das mit der CPU gefällt mir besonders. Hast du den ganzen Tag dran gecodet?

Naja, ich hab RL auch noch und dafür musste ich noch ein anderes Programm schreiben ^^
Für die Änderungen hab ich ca 20 - 30 Minuten gebraucht. Das mit dem Highscores war nur copy&paste und 5 Zeilen geändert. Das mit "Schließen" war auch schnell erledigt.

Eine version mit "programmname_new" zu benennen ist keine gute Idee. Sonst arbeitest du nächste Woche an "EatTheBlocks_newRemake_changedFinal3".
Benenne deine Programme gleich nach Versionen: 0.1, 0.1.2 oder ähnliches. Wie du das machst ist dir überlassen, es gibt kaum Konventionen. In der Opensource Welt ist es aber unüblich mit 1.0 anzufangen und gleich mit 2.0 weiterzumachen (vielleicht weils etwas Großkotzig nach SuperTollesSharewareProgramm 11 klingt, wo zwischen version 6 und 10 fast keine Unterschiede erkennbar waren).

Normalerweise lösche ich immer die alte Version. Dieses mal hab ich sie aber on gelassen. Versionen hab ich mit 0.1 angefangen und ich bin inzwischen bei 0.2 (wie man auch im Menü rechts unten sieht). Das EatTheBlocks2 sollte nur zeigen, dass da was anderes drin ist. War vielleicht unglücklich gewählt...
Es ist keine echte neue Version sondern einfach ein Versuch das Spiel komplett anders aufzubauen.

Weiß nicht, ob Xin die Repositories noch anbietet (ob sie schon funktionieren), aber wenn nciht kannst du auch lokal eines anlegen.

Als svn.proggen.org ist zurzeit noch down. Lokal? Wie du meinst das direkt über mich gedownloaded wird? Das würde mich nicht stören... aber meine und auch die Downloadgeschwindigkeit des Spiels wären wahrscheinlich ziemlich niedrig.
Vielleicht mach ich auch meine alte Homepage wieder auf.

Das verstehe ich eigentlich nicht so ganz...
Wenn du eine Gameschleife hast, die nach oben hin gedeckelt ist, es also eine Maximalframerate hat, wo ist dann der Unterschied zwischen den PC's ?

Angenommen soll mit 30 FPS laufen. Pro Frame werden 10 Pixel "zurückgelegt". Also ein Frame dauert 1/30 Sekunde. Ein schneller PC braucht nur 1/40 Sekunde und wartet dann noch damit er auch auf die 1/30 Sekunde kommt (SDL_Delay).
Ein langsamer PC packt das vielleicht nicht in 1/30 Sekunde sondern nur in 1/20 Sekunde. Er braucht also länger für die gleiche Strecke. Somit läuft das ganze Spiel langsamer.

Solltest du nicht sowieso die Strecke die du zurücklegst nicht konstant lassen sondern von der Framezeit abhängig machen?

So hatte ichs vorhin. Das ist jetzt auch noch in Code 1.
Eine Variable "speed".
speed = (1 / fps) * level;
Und der zurückgelegte Weg wird mit "speed" multipliziert.
Schneller PC --> viele FPS --> (1 / fps) hat kleinen Wert --> kleiner Speed --> kleiner zurückgelegter Weg pro Frame
Langsamer PC --> wenige FPS --> (1 / fps) hat großen Wert --> großer Speed --> großer zurückgelegter Weg pro Frame

großer Weg * wenige FPS ~ kleiner Weg * viele FPS

Nur variiert dann der zurückgelegte Weg pro Frame. Und dann bekommt ich die regelmäßigen Bewegungen nicht mehr hin.

Ich weiß nicht inwieweit du diesen Thread jetzt gelesen hast, aber wir haben hier schon ein bisschen über die Möglichkeiten dieses Problem zu lösen diskutiert.

Übrigens: vielleicht solltest du dir eine Lizenz überlegen, unter der du es Veröffentlichen willst. Wenn es Opensource sein soll, dann würde ich eher zu einer Vorgeschriebenen (GPL, mod. BSD, ...) raten.

Ich kenn mich mit diesem ganzen Lizenzkram nicht aus...
Hier (ganzen unten im Beitrag) findest du eine Original "dani93 - ETB - Lizenz"

Es gilt der Grundsatz: Wenn die Lizenz länger ist als das Programm, kann man von einem Overkill ausgehen

Keine Angst, soweit werd ichs nicht kommen lassen

Ein Nachteil zum neuen Code fällt mir noch ein:
Die Event-Verarbeitung ist logischerweise deutlich langsamer.