Hexwars

Alles rund um Projekte, LAN-Parties und Clan-Events.

Moderator: Moderator

Hexwars

Beitragvon Bauer87 » 21.12.2008, 14:55

Ich lerne grade Programmieren (C++) und wollte das bisher gelernte mal in die Tat umsetzen. Herausgekommen ist ein kleines Spiel für die Bash (oder jedes andere Terminal). Wer mag, darf sich das Spiel nun saugen, es testen, Vorschläge machen (Ja, ne GUI mache ich auch noch.) und alles andere, was euch so einfallen könnte (außer Closed Source draus zu machen --> protected by GPLv3).

Spielidee:
Die ursprüngliche Idee zielt eigentlich darauf ab, dass zwei Spieler ihren Armeen jeweils gleichzeitig Kommandos geben und diese dann abschicken. So soll eine Situation entstehen, die vorherige Einplanung schon des aktuellen gegnerischen Zuges benötigt. Diese noch sehr frühe Version verzichtet darauf und lässt beide abwechseln mit je einer Einheit ziehen, was dem recht nahe kommt, da kein Spieler dem anderen stark voraus ist, weil er anfangen durfte. Das Spielbrett basiert auf Sechsecken, da diese die Vielecke mit den meisten je gleich weit entfernten Nebenflächen ist, die sich als zusammenhängende Fläche darstellen lassen. Klassische Quadrate haben den nachteil, dass man entweder nur in vier Richtungen ziehen kann oder diagonales Ziehen deutlich schneller geht als gradliniges. Felder sind meiner Meinung nach aber hervorragend, um strategisches Denken zu fördern und somit das Spielgefühl zu verbessern. Die Einheiten gehorchen im Moment noch dem sehr simplen Papier-Stein-Schere-Prinzip, das soll aber noch weiter ausgefeilt werden. In der CLI erscheint es mir aber zu anstrengend, mehr als drei verschiedene Einheitentypen zu kommandieren. Auch auf Healthpoints und andere tiefere Spielmechaniken habe ich noch nicht zurück gegriffen. Das verschiebe ich auf die GUI-Version.

Spielablauf:
Spieler 1 und 2 ziehen abwechseln. Welche Einheiten wem gehören, erkennt man an der Zahl, die sie trägt. Die Einheiten sind: Krieger (W), Scout (S) und Terraformer (T). Der Scout darf drei Felder laufen, der Krieger nur eins, ist aber ist unverwundbar und der Terraformer macht Wasser zu Land bzw. Land mit Einheit darauf zu Wasser, er zieht zwei Felder weit. In jedem Zug wählt der aktive Spieler eine Einheit per Eingabe ihrer Koordinaten und schickt sie dann mit den Nummern-Tasten (ausgelegt auf Numpad) durch die Gegend. 8 bedeutet nach oben, 7 nach links oben und so weiter, ungültige Eingaben (alles außer 1,2,3,7,8,9) werden als aussetzen interpretiert.
Achtung: Die Einheiten sind alle sehr blutrünstig und besiegen auch befreundete Einheiten bzw. schaufeln deren Grab. Zudem sind sie sehr gehorsam und rennen ohne Nachfrage von der Karte oder ins Wasser. (Im Klartext: Der Abfrage-Code ist sehr simpel und bewahrt den Spieler nicht vor Fehleingaben.)

Map laden:
Einfach den Dateinamen der Map eingeben, wenn die Aufgeforderung dazu kommt. Dabei ist der relative Pfad zur Binary gemeint. Beispiel: "maps/level1.map"

Leveldesign: (technisch)
Levels bestehen aus Textdateien. Die ersten zwei Zahlen geben an, wie groß die Map ist (horizontal, vertikal). Die Maximale Größe eines Levels ist 64x64. Der Rest der Zahlen ist dann die Map selber. Die Zehnerstelle steht für den Besitzer eine Einheit, (für Wasser oder Gras "0" benutzen), die Stelle darauf für den Typ der Einheit oder der Landschaft. Dabei ist 0 Wasser, 1 Wiese, 2 der Krieger, 3 der Scout und 4 der Terraformer. Einheiten können theoretisch auch neutral sein ("0" als Besitzer). Diese werden dann die ganze Zeit umher stehen und gegen alles kämpfen, was sich ihnen nähert. Neutrale Terraformer und Scouts
sind also witzlos, da sie Defensiv totale Nieten sind. Neutrale Krieger dagegen können nur durch Terraformer "besiegt" werden und sind so ein echtes Hindernis.


PS: Ich hänge nur den Code an, "make" eintippen sollte wohl jeder können. Und die Abhängigkeiten sind auch nicht grade groß, sollten also schon automatisch zum GCC installiert worden sein. Falls Bedarf besteht, kann ich auch noch vorgebackene Binärdateien nachreichen.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon wakeup » 22.12.2008, 12:17

Klingt gut. Also praktisch gesehen ein tbs mit synchronen Zügen. Sind die maps jetzt textfiles oder binaries? Wenn möglich würde ich empfehlen es bei einfachen textfiles zu halten!
Benutzeravatar
wakeup
 
Beiträge: 566
Registriert: 28.04.2007, 22:56
Wohnort: bonn

Beitragvon Bauer87 » 22.12.2008, 17:42

Die Maps sind Textfiles, kannst du ja in der Version, die ich hier online gestellt habe, auch sehen.

Hat denn jemand von euch schon gespielt? Was meint ihr, sollte ich als nächstes umsetzen? Haltet ihr es für Sinnvoller, erst die Spielregeln möglichst komplett umzusetzen (gleichzeitige Züge etc.), oder muss erst die GUI her? Beides sollte ja aufgrund meines Ansatzes, Front- und Backend konsequent zu trennen, gut funktionieren. Allerdings sind meine Fähigkeiten in OpenGL-Programmierung noch sehr beschränkt. (Habe mir grade mein erstes Buch aus der Unibin geholt, vorher habe ich nur durch Lesen von Fremdcode gelernt.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon nasenbaer » 22.12.2008, 19:36

[quote=Bauer87,index.php?page=Thread&postID=32794#post32794]Allerdings sind meine Fähigkeiten in OpenGL-Programmierung noch sehr beschränkt. (Habe mir grade mein erstes Buch aus der Unibin geholt, vorher habe ich nur durch Lesen von Fremdcode gelernt.[/quote]

Ich denke mal, du kennst das alles schon, aber hier:
1) http://nehe.gamedev.net/, da findest du ein wenig dazu, und für Linux und Fenstermanagment kann ich dir glfw empfehlen:
http://glfw.sourceforge.net/

Hilft dir bei:
-Fenster erstellen
-noch mehr Setup
-Timer
-Bilder laden
-Threads (wenn du das brauchst)
-Eingaben von: Joystick, Maus, Tastatur
-Mac, Linux, Win, ...
-nette Lizenz ;)

Denke, das kann man recht einfach zusammenbasteln, musst halt wissen, ob du da direkt OpenGL nimmst, weiß ja nicht, ob es was großes werden soll... :)

Achso: Ich habs mir noch nicht angucken können, musste mal ein wenig aufräumen und Platte leeren ;) Werd ich gleich aber wohl mal mal machen müssen
Zuletzt geändert von nasenbaer am 22.12.2008, 19:41, insgesamt 1-mal geändert.
Benutzeravatar
nasenbaer
 
Beiträge: 190
Registriert: 16.11.2007, 20:27
Wohnort: localhost oder Flugplatz :D
Kernelversion: 2.6

Beitragvon Bauer87 » 22.12.2008, 20:12

Die erste Seite kannte ich, die zweite noch nicht. Hatte mich schon ziemlich auf GLUT eingestellt, aber das GLFW sieht auch sehr gut aus. Das Buch, was ich mir in der Uni geliehen habe, geht sehr auf die Theorie ein, schafft also Grundlagen. Mir geht es ja auch vor allem darum, zu lernen. Daher möchte ich auch möglichst direkt OpenGL schrieben und keine fertigen Grafikengines nutzen. Wobei ich die Eingabegeräte nicht selber ansprechen will. Ich könnte mir aber auch vorstellen, dass ich zu Weihnachten ein Buch über 3D-Grafik und Spieleentwicklung bekomme. Das könnte meine Entscheidung für ein Framework stark beeinflussen.

Das Programm ist im Moment noch ein reines Konzept und nur für die Konsole. Ich will es aber kompatibel halten, sodass ich einen direkten Zugang zum Backend behalte und so die GUI-Version zur Analyse nutzen kann. Außerdem rockt die Konsole XD.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon nasenbaer » 22.12.2008, 20:21

Joa GLUT und glfw machen sich nicht viel, hab mich i-wann mal (warum auch immer) für glfw entschieden (irgend einen Grund gab es aber...)
Sind beides keine Engines, von daher...

Also von der Benutzung im Moment am schlimmsten ist die map-Wahl, hab erstmal ne Endlos-Schleife betreten (falsche Eingabe)
Das würd ich als erstes umbauen, also am Backend basteln...
Dann fällt mir direkt auf, dass Buchstaben als Koordinaten/Richtungen das gleiche machen, da tut Fehlerüberprüfung Not... :D
(Hab dir da mal was angehängt, musste mal sehen...)

So, ich muss erstmal was futtern, bg

P.s.: grummel, .cpp ist nicht erlaubt... :(
Benutzeravatar
nasenbaer
 
Beiträge: 190
Registriert: 16.11.2007, 20:27
Wohnort: localhost oder Flugplatz :D
Kernelversion: 2.6

Beitragvon Bauer87 » 22.12.2008, 22:35

Ah, cool. In der Uni benutze ich nur mathematische Funktionen der Standardbibliotheken, daher kannte ich "numeric_limits", "streamsize" und die Funktionen in "istream" noch gar nicht. Im Prinzip Programmieren wir nur Dinge, die uns Werte interpolieren oder extapolieren, dabei haben wir fest vorgegebene Eingabedateien. Also waren Abfragen dieser Art bisher nicht nötig. Ich werde morgen (fahre den ganzen Tag Zug, feiere Weihnachten bei meiner Familie) wohl mal ein wenig über die Standardbibliothek lesen. Ich werde aber auf jeden Fall möglichst schnell eine Abfrage für die Gültigkeit der Levelnamen einbauen. Auch wenn das in der GUI-Version (da klickt man ja einfach einen Namen an) nicht relevant sein wird. Die CLI-Version will ich ja auf jeden Fall behalten.

PS: Ich weiß deinen Grund für GLFW: Glut ist einfach eine Grafikbibliothek, die OpenGL (C) in C++ (mit Objekten) abbildet. GLFW dagegen ist ein ganzes Framework und daher viel mächtiger. Und Glut kann man damit sicher auch verwenden.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon nasenbaer » 22.12.2008, 23:38

Dann noch frohe Weihnachten, und viel Spaß!

Ich werd mal gucken, vllt. hab ich morgen mal etwas mehr Zeit, bin den Code jetzt nur flüchtig durchgegangen, vllt. hab ich ja noch ein paar Ideen ;) :P
Benutzeravatar
nasenbaer
 
Beiträge: 190
Registriert: 16.11.2007, 20:27
Wohnort: localhost oder Flugplatz :D
Kernelversion: 2.6

Beitragvon Bauer87 » 04.01.2009, 13:38

Ich habe jetzt das Spiel beim dritten Milestone. Erster war das Grundgerüst, zweiter war eine GUI und jetzt habe ich auch erreicht, dass zwei Spieler gegeneinander spielen können,ohne dass man immer sieht, was der Gegner so macht. Man kann also zu zweit vor einem PC schon Spaß haben. Die Steuerung ist wie folgt:
Selektieren der Einheit und Geben von Kommandos mit Linksklick.
Selektion und Kommandos aufheben mit Mittelklick.
Rundenende mit Rechtsklick (Kommando wird ausgeführt).
Den Schirm, wer nun dran ist, bekommt man per Linksklick weg.

Sollte keine weitere Nachfrage nach der CLI-Version bestehen, werde ich die aber wohl einstellen. Außerdem bin ich im Moment von der Objektorientierung ab, da ich so schneller voran komme. Sobald es aber etwas komplexer wird, sehe ich in der OO wieder Vorteile.

http://www.fighting-bytes.de/bauer/Hexwars_09.01.03a.tar.bz2

PS: Das Spiel benötigt Allegro (in den meisten Distributionen "liballegro4.2") und muss momentan selbst kompiliert werden. Makefile liegt bei, sollte mit installiertem Allegro-Dev so durchgehen.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon Cheeky@Boinc » 04.01.2009, 14:45

Mir würde das ganze mit GUI besser gefallen und wenn du soweit bist, pack ich das gerne auch für Fedora ins offizielle repo :D
<3 SuL <3
Benutzeravatar
Cheeky@Boinc
 
Beiträge: 7388
Registriert: 28.06.2006, 14:19
Wohnort: Werther
Lizenz: GPL

Beitragvon cassmodiah » 04.01.2009, 20:35

@ cheeky - hinten anstellen.
obwohl, mach du hexwars ich bastel noch an maxr. heute abend oder morgen mach ich evtl ein review mit auf
[img]http://card.mygamercard.net/DE/gbar/cassmodiah.gif[/img]
Benutzeravatar
cassmodiah
 
Beiträge: 525
Registriert: 08.06.2007, 17:36
Wohnort: Fulda

Beitragvon Bauer87 » 04.01.2009, 21:32

Ich habe von einigen Testern schon wieder ne Liste mit Änderungswünschen bekommen. Auf meiner eigenen Wunschliste steht auch noch einiges. Unter anderem (am aufwändigsten) sollen ja alle Einheiten in einer Runde mit Kommandos versorgt werden und dann für beide Spieler gleichzeitig durchgeführt werden. Dann habe ich noch den Wunsch zugetragen bekommen, dass schon gesehene Gebiete angegraut sichtbar bleiben sollen (Fog of War), obwohl sich das ja ändern kann. Der erste Punkt und eine intuitive GUI (Button zum Beenden der Runde, Levelauswahl, etc) sollen auf jeden Fall noch rein, bevor ich das Spiel größer publik mache. Das zweite habe ich hier angesprochen, um weitere Meinungen zum Thema zu hören.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon nasenbaer » 04.01.2009, 22:18

1) Also die GUI ist sicher bequemer... ;)
2) Solltest du dir mit der "Veröffentlichung" so viel Zeit lassen, wie du brauchst. Überstürzen bringt gar nichts.
3) Ich würde den Screen, wo steht wer dran ist, beschriften.
4) Dass man alle Einheiten pro Runde 1x bewegen kann wäre Klasse, geht mit ein paar Objekten ja wohl recht einfach. Musst jedem Objekt einen Status "schon_in_diesem_zug_bewegt" geben, aber ansonsten sollte das kein Problem sein, oder?
5) Vor allem bei der Dateiauswahl und dem Einlesen dieser solltest du auf Fehler prüfen, denn der Nutzer ist "immer einmal DAU mehr wie du". (Falsches Dateiformat, falsche Formatierung, sinnlose Werte) Auch eine Versionsnummer für die map-dateien wäre gut, damit man später eine Funktion für die alten Map-Daten und eine für aktuelle Daten einbauen kann. Denke ja mal, dass da durchaus noch Änderungen kommen könnten.
6)Was hältst du von einem "Lade-Bildschirm" vor dem Spiel, der per Tastendruck verschwindet, aber kurz die Einheitentypen erklärt und die Bedienung aufzeigt. Sollte auch kein Problem sein, eine Bitmap zu malen und hinzuzeichnen, oder? (Ich musste erst den Namen der Bilder nachgucken... :huh: )
7) Sieht schon gut aus! :)

wg. Fog of War:
Schon einen Plan? Ich würde 2Bit pro Feld für "schonmal da" und "in Sicht" benutzen. Ein solches Array für jeden Spieler und gut ist... (Geht mit OOP besser... :P )
Dann kannst du immer auf "in Sicht" (=zeige Feind) und "schonmal da" (=rendern in grau, Feind nicht zu sehen) überprüfen.
Benutzeravatar
nasenbaer
 
Beiträge: 190
Registriert: 16.11.2007, 20:27
Wohnort: localhost oder Flugplatz :D
Kernelversion: 2.6

Beitragvon Bauer87 » 05.01.2009, 10:17

Damit wir nicht aneinander vorbei reden: Ein "Release" meint so etwas wie Aufnahme in eine Distribution oder intensivere Werbung. Das soll (natürlich) erst passieren, sobald das Spiel weiter entwickelt ist. Da ich aber einen offenen Entwicklungsprozess möchte (nicht nur ein offenes Spiel am Ende), muss ich ja vorher schon ein wenig darauf aufmerksam machen. Ich beginne ja grade erst mit C++ (OO ist mir noch etwas fremd) und da ist das sicherlich nicht schlecht, gleich etwas Feedback zu bekommen. Daher habe ich hier ja schon früh (vor der GUI) mein Projekt vorgestellt.

Ich werde zunächst mal ein Designdokument schreiben, damit klar wird, was aus dem Spiel überhaupt werden soll. Das hier ist ja quasi mein erstes eigenes Projekt und da möchte ich mich auch etwas an Projektmethodik üben. Erstmal kommt jetzt also etwas Ordnung - auch damit Anregungen leichter aufgenommen werden können.

PS: Der Fog of War ist nicht ganz so leicht: Im Moment speichere ich ja nur, wo Einheiten sind und wie die Karte aussieht. Daraus wird dann live die Sicht berechnet. (Hier kann noch deutlich optimiert werden, die Sicht müsste ja nur ein Mal pro Runde neu berechnet werden.) Das Problem beim Speichern, ob man ein Feld schon mal gesehen hat, liegt darin, dass sich die Art des Feldes ja ändern kann. Als es in Sichtweite war, könnte es Wasser gewesen sein, jetzt hat ein Terraformer Land daraus gemacht. Wenn ich nur speichere, ob man es schon gesehen hat, würde bei Änderung der Landschaft das automatisch mit aktualisiert und gäbe Auskunft über die Position des Gegners. Und eben das soll ja nicht der Fall sein. Eher würde ich zusätzlich Kopien der Map anlegen (eine für jeden Player), die dann den zuletzt gesehenen Status beinhalten. Das würde dann in einem Schlag auch das Aktualisieren erleichtern. Aber was das angeht, werde ich mir noch etwas Bedenkzeit geben. Schlussendlich soll die Möglichkeit, an einem Bildschirm mit einer Maus zu Spielen ja nur eine Möglichkeit sein, die wohl seltener genutzt werden wird als z.B. Spielen über Netzwerk. Ich habe es jetzt nur so gemacht, weil meine Fähigkeiten noch nicht mehr hergeben. Schlussendlich wird das Spiel wohl klassisch in Client und Server getrennt werden.
Raubcodierer sind Verbrecher. Stop DRM!
Benutzeravatar
Bauer87
 
Beiträge: 1233
Registriert: 31.10.2006, 23:28
Wohnort: Oldenburg
Lizenz: CC BY-SA 3.0
Distribution: Debian Stretch
Kernelversion: 4.9

Beitragvon Cheeky@Boinc » 05.01.2009, 12:33

@ cheeky - hinten anstellen.
obwohl, mach du hexwars ich bastel noch an maxr. heute abend oder morgen mach ich evtl ein review mit auf


Für maxr drängel ich schon seit ich beko kenne.... -.- Wäre nicht nett wenn du das jetzt machst.
<3 SuL <3
Benutzeravatar
Cheeky@Boinc
 
Beiträge: 7388
Registriert: 28.06.2006, 14:19
Wohnort: Werther
Lizenz: GPL

Nächste

Zurück zu Projekte / Clans / LANs

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

cron