spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Thoran«

Die Diskussion mit pragma once hatte ich schon mal auch unter Berücksichtigung der besseren Performance beim Kompilieren, aber man gibt die Plattformunabhängigkeit auf, wenn nur #pragma once verwendet wird.

Alle einigermaßen verbreiteten Compiler unterstützen pragma once (MSVC, GCC, clang, Intel), aber ja. Darum eben einfach beides verwenden, ein Compiler der pragma once nicht unterstützt, sieht dann immer noch die Include Guards...

Wer Zahlen sehen will: http://tinodidriksen.com/2011/08/31/cpp-include-speed/

Ich denke dass die Coding-Conventions schon wichtig sind, aber nicht die quintessenz. halten werden sich eh die wenigsten dran, solange da keiner drüber wacht. finde den kompromiss mit beidem sehr gut. wäre es vllt nicht erstmal wichtiger, das spiel an sich genau abzustecken?

Zitat von »TrommlBomml«

wäre es vllt nicht erstmal wichtiger, das spiel an sich genau abzustecken?

Genau den Part werde ich wohl etwas konkreter voran treiben müssen, aber mir fehlt irgendwie noch das richtige System dafür. Bugzilla finde ich wirklich nur für Bugs geeignet, Wiki ginge gerade noch, Jira wäre natürlich super, ist aber nicht zu bekommen.

Jira ist bei kleineren Projekten auch eindeutig mein Favorit. Alternativ könnte man noch Redmine vorschlagen...

Zitat von »Yannic«

Ich weiß nicht, ob jetzt neuerdings zu sensitiv und verweichlicht bin, aber mir würde das ganz schön auf die Nerven gehen, wenn ich in jeder Datei einen anderen Stil vorfinden würde, und mich da reinlesen müsste.
Grade als Programmierer sollte man sich an sowas wie Coding-Conventions halten können.

ja aber wenn du ein commutiy-projekt hast, hat jeder total andere Vorstellungen. Und je nach Charakter interessiert denjenigen die Conventions oder ignoriert sie gekonnt. Im Arbeitsleben ist - bzw. sollte - das ein Akzeptanzkriterium sein, hier wird es denke schwer. Wenn jemand dafür verantwortlich ist, das zu Prüfen, dann klappt das meiner Meinung nach.

Zitat

Genau den Part werde ich wohl etwas konkreter voran treiben müssen, aber mir fehlt irgendwie noch das richtige System dafür. Bugzilla finde ich wirklich nur für Bugs geeignet, Wiki ginge gerade noch, Jira wäre natürlich super, ist aber nicht zu bekommen.

Textuell kurz formuliert, ein paar Storyboards reichen doch erstmal .

Danach kann man langsam anfangen, sich über die Aufgaben Gedanken zu machen. Für den Anfang reicht doch eine Priorisierte Liste als Excel-Tabelle mit folgenden Spalten:
- Priorität
- Art (Bug, Feature, ...)
- Beschreibung
- Zustand (offen, in Bearbeitung, Erledigt)

Darauf sollte nur einer Schreibzugriff haben und wird per E-Mail kommuniziert. Also kann man so machen . Jira würde ich ja auch vorziehen!

Von eMails mit Excel Files halte ich rein gar nichts. Maximal noch über SVN. Außerdem finde ich es nicht gut, wenn nur einer darauf Schreibzugriff hat. Erstens deswegen, weil sich andere dann ausgeschlossen oder weniger Wert fühlen und zweitens, weil Tasks dann immer über ein Bottleneck auf Implemented oder Done geschoben werden müssen.

Es gibt doch zwei Vorschläge für Server die verwendet werden können. Ein Anfang wäre doch dann Jira dort einzurichten. Falls es, warum auch immer, nicht Jira werden soll, würde ich auch Redmine vorschlagen.
Für Coding Conventions wäre eine Art CheckStyle was feines Vielleicht kennt ja jemand was vernünftiges für C++. Ansonsten könnte man ja sagen, wer an einer Datei arbeitet und Code findet, der nicht passend aufgebaut ist, guckt im SVN wer als letztes dran gearbeitet hat. Dann kann er denjenigen anschreiben. Die Leute sollten sich halt schon dran halten. Für Leute die sich einfach nicht dran halten wollen weil sie zu Faul sind oder warum auch immer, könnte man sich was überlegen. Leute die es bewusst nicht umsetzen werden vom Projekt ausgeschlossen oder so. Destruktives Verhalten braucht man ja nicht. Wer Fehler macht und hinterher wieder aufräumt und guten Willen zeigt darf bleiben. Irgendwie sowas. Mal als Vorschlag in den Raum geworfen.

Zitat von »BlueCobold«

Von eMails mit Excel Files halte ich rein gar nichts. Maximal noch über SVN. Außerdem finde ich es nicht gut, wenn nur einer darauf Schreibzugriff hat. Erstens deswegen, weil sich andere dann ausgeschlossen oder weniger Wert fühlen und zweitens, weil Tasks dann immer über ein Bottleneck auf Implemented oder Done geschoben werden müssen.

Ich auf dauer auch nicht. Aber solange Jira nicht läuft und eh kein festes Team ist, macht über svn keinen Sinn.

Jira selbst ist halt nicht kostenlos. Ich kennen auch keinen Anbieter, der Jira kostenlos zur Verfügung stellt. Redmine kenne ich persönlich nicht, sieht für mich auf den ersten Blick etwas chaotisch aus.
Sowas wie Checkstyle wäre ok, allerdings bin ich der Meinung, dass in die Team-Charta das Vier-Augen-Prinzip aufgenommen werden sollte. Das heißt ein Task ist erst implemented und muss von jemand anderem strukturell und syntaktisch gereviewed werden, damit er als done gilt. Wenn wir das nicht machen, sehe ich den Code ganz schnell im Chaos versinken.
Allerdings würfeln wir hier gerade ein paar Themen mächtig durcheinander, was ich nicht so schön finde. Das sollte alles beim nächsten Meeting mal vernünftig diskutiert und bereits Aufgaben dafür verteilt werden. Ein paar Sachen habe ich da schon auf der Liste stehen.

Edit:
Jira ist scheinbar für OpenSource Projekte doch free, muss ich mal genauer nachschauen.