Programmierwettbewerb 2: Aaah a snake!

Da bin ich ja froh dass es jetzt läuft.

Ich habe jetzt mal die anderen Versionen angeschaut die es so gibt, hier mal mein ersten Anmerkungen:

Sehr schön umgesetzt, wusste gar nicht dass LabView sowas kann :D Spielt sich gut, auch dank des Input-Buffers. Die einstellbare Geschwindigkeit finde ich auch gut, wobei das die Punktzahlen natürlich schwer vergleichbar macht. Einziger Kritikpunkt: Die Bonuspunkte verschwinden manchmal zu schnell. Ich finde die sollten eine gewisse Mindestzeit lang da bleiben damit man überhaupt eine Chance hat. Teilweise verschwinden die schon nach einem Frame wieder.


Super hübsch anzuschauen, mit all den Grafiken. Die Steuerung ist etwas ungewohnt, aber das liegt wohl daran dass jede Version so seine Eigenheiten hat. Wenn man vorher die Novgorod Version gespielt hat fehlen einem die gepufferten Eingaben doch :D. Größter Kritikpunkt: Es fehlt eine "Neustart" Option nachdem man gestorben ist.


Spielt sich auch sehr gut. Die einstellbare Geschwindigkeit mit dem Punktmultiplikator macht es auch attraktiv schneller zu stellen um mehr Punkte zu bekommen. Kleine Unschönheit: Beim ersten Mal starten (nach dem Programmstart) beginnt die Schlange nach unten, bei jedem Neustart dann nach rechts.

Alle getesteten Versionen laufen bei mir gut und flüssig und ich habe keine Bugs oder irgendwas feststellen können, gute Arbeit alle. Gibt es noch andere spielfertige Versionen die ich jetzt übersehen habe? Auf gitlab gibt es noch die Lisp-Version von Thronplunder, das habe ich mir jetzt dank Mangel an Lisp-Kenntnissen nicht angeschaut.


Meine Version ist jetzt fürs erste die fertige Basisversion (bis auf eventuelle Bugfixes). Als nächstes werde ich mich jetzt am Startmenü versuchen. Es kann aber wieder eine Weile dauern bis ein Update kommt, wie es meine Zeit und Motivation eben zulässt.
 


Kurze Anmerkung zu meiner Version weil nicht sichtbar integriert, mit "P" lässt sich das Spiel pausieren und mit "R" kann es neu gestartet/resettet werden. :)
 
danke fürs feedback - ja, es würde sinn machen, die bonuspunkte mindestens für x frames anzuzeigen, sonst schlägt der zufallsgenerator manchmal zu schnell zu.. ich habe aber eh noch vor, alle wichtigen parameter per ini-datei einstellbar zu machen, so kann das jeder für sich tunen (buffergröße, spielfeldgröße, verhalten der bonuspunkte, ggf. auch ob die geschwindigkeit im spiel verändert werden kann oder nur vor dem start).. sonst noch irgendwelche feature-requests? :D
 
Ein Update meiner Version:
Habe nun den Grundstein gelegt das Levels geladen werden können, diese basieren auf rohen Bilddaten im RGBA Format (Export aus Gimp als ".data" Dateien mit Standardeinstellungen).
Die Schlange wird mit reinem Rot (R 255) G0 B0 im Level platziert wichtig nur, man sollte zwei Felder rechts von dem Punkt freilassen weil dorthin der Schlangenkörper aufgebaut wird. Man startet also immer nach Links.
Mauern werden mit reinem Schwarz gezeichnet.

Die Level müssen 38 breit x 26 hoch Pixel angelegt werden damit diese funktionieren.

Bisher gibt es neben dem Grundlevel (nur Äußere) Mauern auch ein Level das Barrieren innerhalb des Levels besitzt um den Code zu testen.
Um ein Level weiter zu kommen müssen mindestens 30 Gegenstände (Futter) eingesammelt werden. Danach kommt man ins nächste Level woraufhin man (Level * 2) + 30 einsammeln muß.
Es würde also mit jedem Level etwas schwerer werden.

Außerdem wird das Spiel beim Level wechsel etwas ausgebremst, so das man sich an ein neues Level gewöhnen kann.

Hat man alle Level geschafft, fängt der Level Zähler wieder bei null an, aber Zeit und Punkte bleiben dabei erhalten.

Die Levels werden numeriert nach dem Schema "level_LevelNummer.data" - Level eins heißt also "level_1.data" .
Um ein weiteres Level anzulegen, kann einfach ein neues Level mit dem Namen "level_2.data" gespeichert werden, dies wäre dann das dritte Level.

Zum antesten hier die Windows Versionen auf Gitlab zum Download:
32bit:
oder 64bit:
 
Zuletzt bearbeitet:
Der Weg ist zumindest leichter als der Versuch ein Level progressiv erstellen zu lassen. :D

Und besser als mit BMPs zu arbeiten die irgendwelche komischen Daten beinhaltet haben oder von Unten nach Oben kodiert sind oder oder oder (völlig wirr) ;)
 
Die Zeit neigt sich langsam dem Ende - ich habe mich dazu entschlossen an meiner Snake-Version nichts mehr zu verändern. Da fehlt derzeit dann wieder die Zeit dazu. Für jeden, der sich etwas mit Java auskennt, ist die Erweiterung der Powerups und der Barrierenfiguren ja nicht wirklich schwierig und auch die Spielparameter-Anpassung ist für jeden möglich (solang er ein Programm zum Kompilieren hat).
Ich gehe mal davon aus, dass mein Snake, auch wenn es nicht bei GitHub/GitLab (wo noch mal?) hochgeladen ist, aus diesem Thread mitbewertet wird ;-)
 
Weihnachts-Update 1:

Neue Features:
- Hintergrunkmusik und Soundeffekt
- Highscore-Liste

Amerkungen:
- Falls die Hintergrundmusik nervt kann sie im laufenden Spiel mit "M" aus (und auch wieder an) geschaltet werden.
- Ich bin aktuell nur mit dem Laptop unterwegs und habe deshalb nur eingeschränkte Testmöglichkeiten. Linux ist nicht getestet und auf Windows auch nur auf meinem Entwicklerrechner.

Eventuell gibt es noch ein zweites (und letztes) Update in den nächsten Tagen, das kommt aber darauf an ob ich die geplanten Änderungen noch fertig schaffe oder nicht.
 
Ich habe mich an den Feiertagen auch mal mit dem Thema auseinandergesetzt. Allerdings nicht durch die Implementierung eines fertigen Spieles, sondern erst einmal mit dem Aspekt, wie man da dem Spiel etwas neues hinzufügen kann.

Dabei war mein Gedanke, daß ich bei einer Implementierung auf ein Raster gesetzt hätte, sagen wir 100x100.
Das liefert das eckige Verhalten der Schlange.

Also habe ich überlegt, ob ein wenig Massenträgheit die Bewegung nicht natürlicher aussehen lassen würde. Für mich sah das Ergebnis positiv aus, aber wenn man kein Raster benutzt, dann erbt nicht jedes Element die Position des Vorgängers, sondern man muß Winkelfunktionen benutzen.

Hier mal, was sich bislang daraus ergeben hat. Einmal als Video, zum anderen als .NET Demo.




 
schaut ganz witzig aus, ist aber kein snake mehr, jedenfalls nicht mit der gewohnten spielmechanik ;).. was wäre in dem fall denn das ziel des spiels, wenn eine "präzise" navigation nicht möglich ist?
 
Natürlich nicht die gewohnte Spielmechanik. Dann hätte sie das Prädikat "neu" ja nicht verdient. ;)

Ansonsten ändert sich nichts. Somit ist nur die Herausforderung ein wenig höher, weil die Präzision mehr von den Fähigkeiten des Spielers abhängt.
 
Wirklich nett gemacht, gehört schon was zu das so hinzubekommen :T

Aber mit den klassischen Snake-Regeln kann ich mit bei der Umsetzung nicht gewöhnen, da würde ich an etwas anderes denken, Futter/Beute umkreisen, einfangen, auffangen, die Bewegung ausnutzen, ein Parkour wie Slalom/Ski mit Sidescrolling oder sowas.

Aber ich mag den Freeform-Ansatz :)
 
deswegen ja die frage - wie stellst du dir ein richtiges spiel damit vor, insbesondere wenn es kein festes positionsgitter gibt und die hinteren elemente sich auch noch seitwärts bewegen können (und z.b. in ein hindernis knallen, obwohl man nur den kopf bewegt hat)?
 
Wo siehst Du ein Problem bei fehlendem festem Positionsgitter?

Daß das Spiel am Spielfeldrand sehr schwierig werden könnte, bedeutet aus meiner Sicht folgende Optionen:

a) Ist halt so
b) Futter wird nur in einem gewissen Abstand vom Rand gelegt.
c) Es gibt keine Ränder. Das Spielfeld ist 2D Ansicht einer Kugel. Was auf der einen Seite rausgeht, kommt auf der anderen Seite wieder hinein.
 
das randproblem kann man sicher irgendwie lösen.. bei den kollisionen mit sich selbst siehts aber schwieriger aus, wenn sich die hinteren elemente seitlich bewegen können - das würde quasi unverschuldet zum game over führen.. oder man müsste die schlange für sich selbst unpassierbar machen (d.h. wenn elemente zusammenstoßen, drücken sie sich gegenseitig weg) und game over gibts nur, wenn der kopf ein schlangenelement trifft, aber das wäre ein ziemlicher aufwand für die "physik-engine".. ich bin jedenfalls gespannt wie das fertige spiel aussehen soll ;)..
 
Die können sich nicht seitlich bewegen.

So ein Ausbrechen wäre gar nicht mal so trivial zu programmieren.

Da müßte man zusätzlich zur Bewegungsrichtung noch eine Rotationsbewegung eins Elementes um das davor berechnen.
 
hm? in dem video sieht man doch ganz deutlich, dass sich die form der schlange (hinter dem kopf) ändert, z.b. in engen kurven, wellen oder schleifen.. und das geht nur, wenn sich die elemente senkrecht zum jeweiligen schlangenabschnitt (bzw. der tangente daran) bewegen können.. das passiert natürlich nicht unabhängig von den nachbarelementen (es tanzt nicht ein element aus der reihe, sondern wellen werden "gesmootht" usw.), hat aber trotzdem zur folge, dass ungewollt und praktisch unkontrollierbar kollisionen im hinteren teil der schlange passieren können, da die form nicht erhalten bleibt..
 
sn.jpg

Die mögliche Querbewegung ist (s. Bild) die, die entsteht, wenn ein Element seine Richtung an das voranlaufende Element angleicht. Das entspricht einem Anhänger ach einer Kurve, so das Zugfahrzeug und Hänger dann wieder i die gleiche Richtung fahren.

Den Effekt, den ich meine und der nicht implementiert ist, daß das Element sich wie ein Hänger verhält, der über die Fahrtrichtung des Zugfahrzeuges hinaus in die andere Richtung pendelt.

Ich sehe da keine Möglichkeiten für ungewolltes oder unkontrollierbares Verhalten.

Demo zum ausprobieren ist verlinkt.
 
was ich meine ist, dass genau dieses "smoothe" verhalten (anpassen eines elements an die nachbarelemente) zu unbeabsichtigten kollisionen führen kann, z.b. wenn man eine kurve um ein hindernis machen will.. mit der zeit wird das kurvenstück "langgestreckt" und kann mit dem hindernis kollidieren.. hier ist ein beispiel, wo der schwanz der schlange das hindernis ist:
float-snake.png

wenn man die schlange nach rechts weiterlaufen lässt, wird sie irgendwann den schwanz berühren (das gilt grundsätzlich für jede "schleife").. man kann das natürlich auch als "feature" verkaufen, denn die kollision ist ja zu verhindern, wenn man die schlange "entwirrt" - allerdings wird es ab einer bestimmten länge der schlange praktisch unvermeidbar sein, "schleifen" zu machen, was es ziemlich schnell ziemlich unübersichtlich werden lässt.. aber wie gesagt, ich bin aufs fertige spiel mit kollisionsabfragen gespannt ;)..
 
Dann muß ich das jetzt wohl zu Ende bringen? :eek:

Warum eigentlich nicht. Aber nicht mehr im Rahmen dieses Wettbewerbes. Der endet übrigens morgen.
 
Zurück
Oben