Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Open Pursuit (Hilfe!)

Werbeanzeige

the[V]oid

Alter Hase

  • »the[V]oid« ist der Autor dieses Themas

Beiträge: 775

Wohnort: Aachen

  • Private Nachricht senden

1

02.10.2009, 15:51

Open Pursuit (Hilfe!)

Vor einigen Monaten hatte ich immer wieder an einem kleinen Spiel gearbeitet, das an das bekannte Trivial Pursuit angelehnt ist. Irgendwann kam ich zu einem Punkt, wo ich mich mit einem Fehler beschäftigte, der mir völlig absurd schien und dessen Ursache ich partout nicht finden konnte. So viel das Projekt für einige Monate auf Eis. Nun hab ich es wieder hervorgekramt und ein wenig aufgeräumt. Ich veröffentliche hier die Quelltexte, in der Hoffnung, dass jemand einen Hinweis auf die Ursache des Fehlers bringen könnte. In der Datei debug.h setzt man die Präprozessor-Variable PSB, falls man mit dem Partikelsystem-Bug kompilieren möchte. Setzt man die Variable nicht, funktioniert das Partikelsystem zwar, aber dafür kommt es zu Fehlern bei der Plazierung der Spielsteine bei mehr als einem Spieler. Die entscheidenden Stellen dazu finden sich in main.cpp. Der Bug des Partikelsystems besteht darin, dass sobald ein Spielerstein auf ein schwarzes Feld gekommen ist, der Spieler fortan keine Partikel mehr zu sehen bekommt.


(Link)


In der aktuellen Version kompiliert das Projekt nur auf Linux, da die Makefiles und Code::Blocks Projektdateien für die Windowsversion lange Zeit nicht mehr aktualisiert wurden. Mit einigen wenigen Kniffen müsste es sich aber wieder fit for Windows machen lassen können. Das Projekt wird unter der GNU GPL v3 vertrieben. Zum Kompilieren verwendet man vorzugsweise das Makefile, möchte man mit Code::Blocks kompilieren, muss man dran denken, nach Abschluss des Vorgangs das Shellskript substitute.sh auszuführen.

Open Pursuit 02.10.2009 A
Open Pursuit 02.10.2009 A Linux Binary (mit PSB)

Benötigt wird SFML 1.5 und GLUT, welches ich in der Version 3.8 verwende.

PS: Ich weiß, die Klassenstruktur ist besonders bei der GUI bischen chaotisch...
<< an dieser Stelle ist eine Signatur verstorben >>

Das Gurke

Community-Fossil

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

2

02.10.2009, 16:00

Ist das jetzt eine Bitte nach dem Fehler zu suchen, eine Projektvorstellung oder ein "Ich gebs auf und machs vorher OpenSource" Thread?
http://trash.gurxite.de/userbarmarcusbloggt.png
http://img.flowergame.net/flower/77.pnghttp://img.flowergame.net/flower/221.pnghttp://img.flowergame.net/flower/223.png

the[V]oid

Alter Hase

  • »the[V]oid« ist der Autor dieses Themas

Beiträge: 775

Wohnort: Aachen

  • Private Nachricht senden

3

02.10.2009, 17:10

Eigentlich dachte ich mich klar genug ausgedrückt zu haben:

Zitat von »"the[V«

oid"]Ich veröffentliche hier die Quelltexte, in der Hoffnung, dass jemand einen Hinweis auf die Ursache des Fehlers bringen könnte.


Das ist mein Anliegen.
<< an dieser Stelle ist eine Signatur verstorben >>

Das Gurke

Community-Fossil

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

4

02.10.2009, 17:14

Naja, damit hast du ja die beiden anderen Optionen ja noch nicht ausgeschlossen ;) Aber du willst also noch weiter dran arbeiten?

Ich fands nur n bisschen komisch, ne Projektvorstellung mit ner Bugsuche zu beginnen. Ist möglicherweise aber auch nur mein persönliches Empfinden.

Ich muss allerdings sagen, dass ich gerade weder einen Linux Rechner in Reichweite, noch die Muße das Projekt umzuwandeln habe. Aber vielleicht findet sich ja wirklich wer.

Der Screenshot sieht auf jeden Fall schonmal nett aus.
http://trash.gurxite.de/userbarmarcusbloggt.png
http://img.flowergame.net/flower/77.pnghttp://img.flowergame.net/flower/221.pnghttp://img.flowergame.net/flower/223.png

the[V]oid

Alter Hase

  • »the[V]oid« ist der Autor dieses Themas

Beiträge: 775

Wohnort: Aachen

  • Private Nachricht senden

5

02.10.2009, 17:35

Klar will ich noch daran weiterarbeiten. Nur komme ich alleine im Moment nicht mehr weiter.
Und das 'zu Open-Source Machen' hat nix mit Aufgeben zu tun, das war von Anfang an geplant, auch am Projektnamen zu erkennen ;)

Eigentlich war es auch nicht als wirkliche Projektvorstellung gemeint.
Aber jetzt frage ich mich, warum eigentlich nicht?
Also hier erstmal noch ein paar mehr Screenshots:


(Link)



(Link)



(Link)



(Link)




Noch ein paar Hintergrundinformationen...

Die Spielzustände werden über einen einfachen Automaten gesteuert. Im Detail gibt es die folgenden Zustände, derer Rollen wohl selbsterklärend sind: CounterMovementChoiceState, CounterMovementState, DiceIdlingState, DiceRollingState, GameSetupState und QuestionState. Alle diese Zustandsklassen sind von einer abstrakten State-Klasse abgeleitet, die die folgende Schnittstelle definiert:

C-/C++-Quelltext

 
1
2
3
4
5
6
7

public:

        virtual void onInit (Frame& frame) { }
        virtual void onExit (Frame& frame) { }
        virtual void onMouseInput (Frame& frame, const sf::Event::MouseButtonEvent& mi) { }
        virtual void onKeyInput (Frame& frame, const sf::Event::KeyEvent& ki) { }
        virtual void onAnimationEnd (Frame& frame, Animation& anim) { }


Ferner kennt jedes State die Instanz der StateMachine, um Zustandsübergänge auslösen zu können. In diesem Zusammenhang ist es noch wichtig, auf die Rolle der Klasse Frame einzugehen. Ein Frame wird hier als die Summe folgender Elemente verstanden: Einer Liste aller Spielersteine, ergo Tupeln aus Position, Größe und Farbe; Einem Würfel, der ebenso durch Position und Größe defniert wird; Einer Liste aller Partikel, die auch wieder durch Positition, Größe und Farbe gegeben sind; Der Momentanen Kamera-Position und -Blickrichtung; Und noch einigen weiteren, weniger wichtigeren Elementen.

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9

private:

        std::vector <Counter> m_vCounters;
        Dice m_dice;
        std::vector <BoardFieldChoiceIndicator*> m_vBoardFieldChoiceIndicators;
        WindowStack m_wstack;
        Exclamation* m_pExclamation;
        Camera m_camera;
        Particles m_particles;


Alle diese Elemente haben eine gemeinsame Oberklasse, die entweder Entity ist, oder eine davon abgeleitete. Durch Klassen, die von der abstrakten Klasse Animation abgeleitet sind, werden die Eigenschaften, die allen Entities gemein sind, fortlaufend manipuliert. Im Detail gibt es unter Anderem die folgenden Animationsklassen: CounterMovementAnimation, DiceAnimation, FadeAnimation, GrowthAnimation, PopAnimation, WindowAnimation und NullAnimation, welches zum Einbauen von Wartepausen verwendet wird. Während der Hauptthread das zuletzt berechnete Frame-Objekt rendert, beschäftigt sich ein zweiter Thread mit der Anwendung der Animations-Objekte auf das nächste Frame-Objekt. Dabei wird die Funktion setTime() auf jedem einzelnen Animationsobjekt aufgerufen, dieser wiederum ruft die folgende Funktion auf, wobei f einen Wert zwischen 0.0 und 1.0 erhält, der den Fortschritt der Animation repräsentiert und somit zusammen mit der voranschreitenden Zeit wächst:

C-/C++-Quelltext

 
1
2
3

protected:

        virtual void update (const float& f) = 0;
<< an dieser Stelle ist eine Signatur verstorben >>

Werbeanzeige