Du bist nicht angemeldet.

Werbeanzeige

1

31.10.2010, 01:12

Teamarbeit wie aufteilen?

Ich würde gerne ein kleines Projekt realisieren, zusammen mit ein bis zwei anderen Leuten die ungefähr so gut Programmieren können wie ich.

Wie teilen wir die Arbeit in einem Projekt gut auf, sodass wir uns nicht gegenseitig auf die Füße treten?

Gruß dennis-.-

drakon

Supermoderator

Beiträge: 6 529

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

2

31.10.2010, 01:28

Schaut aus welchen Bausteinen euer Projekt so besteht und dann trennt das auf.
Z.b bei einem Spiel: UI, Game Logik, AI, Physik usw.

Kommt halt sehr drauf an um was es sich für ein Projekt handelt.

n0_0ne

1x Contest-Sieger

  • Private Nachricht senden

3

31.10.2010, 07:43

Mit Subversion z.B. kann man auch zusammen am selben code arbeiten. Dass es halt mal zu Konflikten kommt ist klar, aber die sind schnell aufgelöst, vor allem mit den heutigen grafischen tools dafür.

4

31.10.2010, 09:37

wir wollten mercurial verwenden als versionsverwaltung...

das problem was ich da sehe ist halt hauptsächlich dass wir bisher alle ausschließlich alleine an was programmiert haben und uns noch nie über die schnittstellen wirklich gedanken machen mussten. selbst wenn man mal bei einem eigenen projekt 20 klassen hat und ein paartausend zeilen code ist das immer noch recht gut ohne ausgiebige vorherige planung zu stemmen (ein bisschen gedanken machen über die programmstrukturierung sollte man sich aber schon).

die bestandteile die so derzeit geplant sind halt UI, game logik und evtl. die anbindung an sowas wie http://www.mapeditor.org/ damit man auch mal was bauen kann... das problem bei der aufteilung ist halt dass da alles voneinander abhängt.

um was genau für ein projekt es sich handelt ist seltsamerweise jedem egal, hauptsache genug anspruch (aber nicht zu viel).

vllt kennt jemand zu dem thema zusammenarbeit ja ein paar onlineartikel auf http://www.makinggames.de/ oder so und kann die posten. dann könnten man sich von den problemen die da so auftreten könnten schonmal grob ein bild machen und rennt nicht voll ins messer...

gruß dennis-.-

idontknow

unregistriert

5

31.10.2010, 09:53

Ist halt wichtig, dass ihr/einer der AHnung hat euch mal über Das Design Gedanken macht, was für Klassen ihr braucht, welche Assoziationen die untereinender haben, was von was erbt, ob ihr Singletons verwendet, sofern ihr das tut wo wären die notwendig ect.... (aber singletons sind ne sache für sich generell wurds darauzf hinauslaufen dass hier die mehrheit sagt ihr sollt keine verwenden :P)

6

31.10.2010, 10:17

das problem ist glaub ich weniger "ob" jemand ahnung hat, denn das denkt jeder zu haben, zumindest von der theorie xd. aber niemand hat sowas vorher gemacht. deswegen machen wir das ja.

singleton hab ich bisher noch nie selbst programmiert, hatte ich bisher auch eher nich auf der liste der design patterns die "besonders" nützlich sind, ich dachte da eher an das observer pattern was mir iwie elegant erscheint... so arg viele kenn ich jetzt aber auch nich.

dot

Supermoderator

Beiträge: 9 833

Wohnort: Graz

  • Private Nachricht senden

7

31.10.2010, 10:50

singleton hab ich bisher noch nie selbst programmiert

Wunderbar, just keep it that way.
Vertrau mir, du kannst Singleton gleich von der Liste der nicht ganz so nützlichen Patterns auf die Liste der Antipatterns schupsen, du wirst es nie bereuen ;)

Nox

Supermoderator

Beiträge: 5 282

Beruf: Student

  • Private Nachricht senden

8

31.10.2010, 12:20

Kein ganz triviales Problem, aber aus meiner Erfahrung weiß ich, dass es bei kleinen bis mittelgroßen Projekten kein Megaumldiagramm sein muss, allein schon weil man über die Zeit vieles lernt und daher dann komplett anders machen würde. So frei in den Raum geplappert ohne zu wissen, was genau ihr umsetzen wollt, kann ich mich nur auf allgemeine Thesen beschränken:
-UI ist meist recht leicht abzuspalten (methoden zum auslesen von infos bzw reinfüttern sind meist nicht all zu komplex)
-KI ebenfalls
-Darstellung lässt sich meist von der Spielmechanik trennen

Meiner Meinung nach ist das Kernelement eines Spiels die Spielmechanik und alles andere muss nur mit der Spielmechanik interagieren. Meist steckt auch in der Spielmechanik ansich nicht unbedingt das meiste an Code sondern eher der Hirnschmalz. Wenn ihr euch also über die Spielmechanik im Klaren seid bzw. diese existiert ist der "Rest" "nur" aufbauend.

Mein Fazit: werdet euch über die (grundlegende) Spielmechanik einig, stampft die als Prototyp gemeinsam aus dem Boden (wenn das geht am besten ein Wochenende treffen und durchentwickeln). Wenn diese dann steht ist der Rest gut aufzuteilen. Und ganz wichtig ist Kommunikation (und viel effektiver als die tollsten uml Diagramme).
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

idontknow

unregistriert

9

31.10.2010, 12:21

Was hab ich gesagt :D. Wusste doch dass sowas kommt :P.
Ich find generell Situationen wos imo ganz neutzlich wäre aber naja wenn du dann willst das dir wer weiterhilft musst dir idR nen Vortrag anhören warum du da überhautp Signeltons nutzt und blablabla besser lgiech weglassen =D

10

31.10.2010, 12:55

Hallo dennis-.-,

wo du schon MakingGames ansprichst, da ist mir eingefallen, dass in der Ausgabe 2/2010 ein Artikel über die Organisation eines Lef4Dead-Mod-Teams war. Ich hab ihn dir mal auf der Website von MakinGames rausgesucht. Vielleicht sind ein paar interessante, hilfreiche Infos für dich dabei. Hier gehts lang>>

Gruß
SaRu_

Werbeanzeige