# Suche Partner für Hobby-Projekt: 2D-Strategie-Spiel



## hdi (6. Jan 2009)

Hallo,

ich möchte gerne ein 2D-Strategie-Spiel in Java machen. Ich habe schon einige Ideen, es ist aber noch nichts
fest. Natürlich habe ich aber eine Skizze, hier eine Liste von Dingen, die mir so im Kopf herumschwirren:

- Basis des Spiels ist das Brettspiel Risiko
- d.h. es ist auch voll rundenbasiert
- keine scrollbare komplexe Landschaft, einfach nur ein Brett
- aber mit zufälligen Karten
- Kämpfe werden auch per Würfeln ausgetragen
- und erweitert durch Elemente von Echtzeit-Strategie-Spielen
- d.h. es gibt verschiedene Einheiten, die bestimmte Eigenschaften haben (Angriffswert, Armor, Speed, evtl Specials)
- das Kampfsystem ist demnach etwas komplexer als nur "wer hat die höhere Zahl gewürfelt"
- Es gibt auch Gebäude die man bauen kann (Defence Towers, Research Facility,...)
- um das zu realisieren gibt es nicht jede Runde x neue Einheiten wie bei Risiko, sondern x Geld. Dieses benutzt
man dann wie man möchte für Einheiten, Upgrades, ...
- Erstmal nur Offline 1 Spieler vs. CPU
- und erstmal ohne "Aufträge", d.h. Ziel ist World Domination -> alle gegnerischen Einheiten auslöschen
- Visualisierung ganz simpel mit Swing, keine eigene Engine und auch kein DirectX etc.

So, wie gesagt das ist alles nicht so fest. Es geht einfach darum, eine Art Risiko (mmN eines der geilsten Brettspiele)
zu erweitern, aber nicht auf Teufel komm raus eine Floodware machen. Wenn etwas schlecht ist, kommt es auch 
nicht rein. Aber ich denke aus der Mischung von Risiko mit sowas wie Starcraft/Warcraft kann man was nettes machen.

Mir ist btw klar, dass das lange dauern wird und nicht leicht ist. Aber ich hab Zeit, und ist ja kein Stress 
Hauptsache etwas Fun haben und am Ende n nettes Game haben.

Ich selber bin kein absoluter Anfänger mehr, aber in einigen Gebieten brauche ich Unterstüzung, d.h.
ich suche Leute, die sich in einem oder mehreren der folgenden Dinge auskennen:

- KI für einen PC-Gegner der einigermassen intelligent spielen kann (zB Geld sparen für Upgrades, an sinnvollen
Stellen angreifen)
- Grafiken für nette Texturen, zB für ein ansprechendes Ingame-Menü oder die Einheiten/Gebäude
- generell einen einigermassen erfahrenen Coder, der am Core mitprogrammiert. D.h. der mir hilft bei Algorithmen
für die Erstellung von Zufalls-Karten u.ä.

Wie gesagt: Ich weiss, dass es viel Arbeit ist, aber ich erwarte von keinem dass er da jetzt abgeht. Hauptsache
Geduld, und nicht unbedingt mitten drin abspringen..

Ich denke realisieren sollte man das dann über SVN (kann ich einrichten), wenn ihr Skype und noch besser ein
Headset habt, wär's auch gut, weil ich euch ja auch an der konkreten Spiel-Planung beteiligen will.

*Auf sauberes Coding lege ich wert*, ist vllt überflüssig zu erwähnen aber ich hab schon Leute in Projekten gehabt,
die eine Variable "qrztX" nennen und einen 400-Zeilen Algorithmus ohne eine Zeile Kommentar implementieren 
Ich denke eine Klasse sollte zu etwa 40% aus Kommentar und 60% aus Code bestehen (kann man natürlich nicht
vollkommen pauschalisieren, aber so als richtwert)

Joa, wer hat Bock? Alleine will ich nicht anfangen, weil ich mir über den Aufwand und die Schwierigkeit bewusst bin.
Aber mit ein paar (2-3) Leuten denke ich kann jeder was lernen, Spass haben, und wenn's was gutes wird,
machen wir das am Ende noch Netzwerk-kompatibel und zocken uns gegenseitig (Der Aufwand wär's ja dann wert).

Wer mitmachen möchte, bitte melden! 

*PS: Bitte keine totalen Anfänger, das bin ich auch nicht mehr. ich denke eher an so Leute wie Quaxli (mit dem Zaunpfahl wink)*

Bis denn (vllt)


----------



## Quaxli (6. Jan 2009)

hdi hat gesagt.:
			
		

> *PS: Bitte keine totalen Anfänger, das bin ich auch nicht mehr. ich denke eher an so Leute wie Quaxli (mit dem Zaunpfahl wink)*



Danke, für die Blumen 



			
				hdi hat gesagt.:
			
		

> ...So, wie gesagt das ist alles nicht so fest. Es geht einfach darum, eine Art Risiko (mmN eines der geilsten Brettspiele)
> zu erweitern



Aber leider fehlt mir momentan die Zeit für komplexere Geschichten. Außerdem gibt es von Risiko schon 1 Million Versuche/Klone  und ich mag es auch überhaupt nicht, weil es viel bessere Spiele gibt.  
Du kannst Dich mal rühren, wenn Du über sowas wie 
Samurai Swords, Axis an Allies oder gar Warlords 2 nachdenkst.


----------



## hdi (6. Jan 2009)

Also, eigentlich ist es mir ja einigermassen latte was genau das für ein Spiel ist. Ich dachte dieses erweiterte Risiko wäre nett, aber klar gibt es tausend andere auch sehr gute Spiele. Mir geht's ja mehr um's Programmieren, natürlich soll das Endprodukt gefallen sonst fehlt die Motivation.

Dieses Warlords scheint so ne Art simples Heroes of Might and Magic zu sein, und das ist ein zu großes Projekt.
Aber die anderen beiden sind ja statischere Brettspiele, so wie eben auch Risiko. Ich denke ausser den Regeln
ähneln die Spiele Risiko auch (vom Aussehen und dem Grundkonzept)

Ich lass mich also sehr gerne umstimmen, es muss nicht Risiko sein, es muss nur Spass machen. 
Aber du sagtest ja auch du hast grad generell keine Zeit  :?:


----------



## homer65 (6. Jan 2009)

Hallo hdi,
ich hätte schon Lust mal ein nicht zu komplexes Spiel mitzuprogrammieren. Die Frage ist nur was. Risiko hab ich mal vor ca 15 Jahren gespielt, kann mich kaum dran erinnern. Was denkst du über Frozen Bubbles? Ich denke das wäre für den Anfang nicht zu schwer. 
Nebenbei, sooo viel Zeit habe ich auch nicht. Und von Java2D habe ich noch exakt Null Ahnung, aber was nicht ist kann ja noch werden. Hauptsache ist es macht Spaß.


----------



## manuche (6. Jan 2009)

Hallo hdi!
Ich hätte Lust auf sowas allerdings weiss ich nicht mit wieviel Aufwand du daran gehen möchtest... Sowas kann sich ja unendlich aufblähen sowas!
An was für Technologien hast du Gedacht? JOGL oder ähnliches oder willst du komplett mit Boardmitteln arbeiten?


----------



## hdi (6. Jan 2009)

Hey ihr 2.

@homer:
Ich würde schon gerne ein 2D-Strategie Spiel machen. Ich hab schon zwei mal irgendwelche Tetris-Verschnitte
programmiert und ich denke, der Spass ist länger gegeben bei Strategie-Spielen.

@manuche
Ich versteh nicht ganz wovon du redest  Sind das Frameworks? Und was sind "Board"-Mittel? Das
musst du mir etwas erklären bitte. 

Zum Aufwand: Ich möchte schon, dass es schön wird und nicht einfach am Ende ein Haufen Chaos-Code
ist und ein Game mit Bugs.. Aber keiner sagt, dass das ganze schnell fertig werden muss. Wenn man 1-2 mal
in der Woche für paar Stündchen Zeit hätte irgendwas zu machen, würd das ja schon langen.


----------



## manuche (6. Jan 2009)

Man kann es ja so machen, einfach die Paintmethode zu überschreiben und sich somit selbst ums zeichnen zum kümmern...
Oder man benutzt halt externe Bibliotheken um z.B. OpenGL zu benutzen!
Aus eigener Erfahrung kann ich sagen, dass ohne externe Bibliothek schnell Schluss ist mit der Performance...
Ich weiss ja nicht wie graphisch anspruchsvoll das sein soll!

Suche allerdings schön länger einen Grund mich ein wenig in OpenGL einzuarbeiten ^^


----------



## hdi (6. Jan 2009)

Achso, naja ich hab das bisher immer per Hand gemacht. Denke die Perforfance würde darunter nicht leiden,
ich meine es sind nur Bilder und simple Swing-Zeichnenvorgänge. Ich dachte ja nicht mal an sowas wie Sprites.

Aber - ich würd auch mal gern mal mit sowas arbeiten, weil bisher hab ich nur "pure java" programmiert. Keine Frameworks, keine Erweiterungen, keine 3rd Party Plugins etc.

Also gegen OpenGL habe ich nichts, ich weiss nur gerade überhaupt gar nicht, wie viel schwerer es das
ganze macht.


----------



## manuche (6. Jan 2009)

Ich kann es ehrlich gesagt auch nicht wirklich beurteilen... Hab zwar schonmal angefangen mich einzuarbeiten allerdings schnell wieder aufgehört weil ich keine Idee hatte für was ich es nutzen könnte...
Allerdings dürfte es eine andere herangehensweise sein was die Zeichenlogik betrifft.
Viellicht kennt sich ja hier wer besser mit OpenGL aus und kann uns da  ein wenig auf die Sprünge helfen!
Da es sich allerdins "nur" um ein Strategiespiel handelt könnten die Boardmittel reichen!
Problem ist nur, dass das nachträgliche Umstellen auf eine externe Bibliothek problematisch sein dürfte...


----------



## hdi (6. Jan 2009)

Hm ja.. Aber was wäre denn folgendes: Wir machen erstmal das Spiel ohne Schnick-Schnack (auch ohne externe
Bibliothek), und wenn das läuft und Spass macht, kann man ja durchaus mal eine v2 rausbringen, und die dann
mit hübscherer Grafik, OpenGL, Online-Modus und solche Spielchen.
Und soo ein Aufwand ist das Umstellen auch nicht.

Aber es ist wirklich nicht gerade ein Klacks, alleine schon ersteres zu machen. Wie gesagt von der Performance
denke ich nicht dass wir Probleme kriegen. Ich meine ein Raster von n*n simplen Texturen und dann nur noch
ein kleines Menü und paar Bildchen auf den Feldern.. Ausserdem verändert sich ja immer nur ein wenig etwas,
also mit dirty region repaint sind wir eh im grünen Bereich.

Würde also das ganze wirklich erstmal unten halten. Man überschätzt sich da schnell und verliert dann die Lust
daran. Es gibt ja jetzt schon auch mit Swing genug zu tun, die Grafik ist ja eig. so das leichteste.


----------



## homer65 (6. Jan 2009)

Das mit Frozen Bubble war nur so eine Idee, mehr nicht. Aber vor dem WIE sollten wir vielleicht doch erst das WAS klären. Gegen einen Risiko Clone hätte ich auch nichts einzuwenden. Was mich angeht, ich wäre dabei. So 2-3 Stunden pro Woche könnte ich aufbringen. Bei dem Tempo wird man dann allerdings Monate bis Jahre brauchen.


----------



## manuche (6. Jan 2009)

Das ist ja immer so das nette an solchen Projekten: Man weiss nie was so kommt!
Aber wie gesagt, ich würde mich da gern anschliessen! Rest kann man ja per PN klären!


----------



## Guest (6. Jan 2009)

Ich hätte interesse mitzumachen


----------



## Gast=Developer_X (6. Jan 2009)

Sorry, ich hab vergessen zu sagen ich heiß Developer_X


----------



## Guest (6. Jan 2009)

Nur um ehrlich zu sein mach das beste am liebsten mal in 3D


----------



## hdi (6. Jan 2009)

Jahre wird es wohl nicht dauern, dafür hab ich einfach zu viel Zeit  Allerdings ist die Frage, wie viel Spass
es einem selbst macht, wenn man nur 1x pro Woche kurz reinschaut und quasi gar nicht mehr mitkommt.
Aber wir gehn das erstmal locker an.

Und das WAS klären wir natürlich auch erstmal von der Haarspitze bis zu den Fußnägeln, bevor wir überhaupt anfangen.
Ich dachte mir wir machen das so:

- Spiel bis ins Detail ausplanen
- Dann erstmal nur Interfaces schreiben um eine grobe Struktur reinzukriegen
- dann erst Stück für Stück implementieren, mit einzelnen Phasen die wir immer durchtesten

Ich fasse jetzt mal zusammen:

Homer und Manuche und ich, das sind 3 Leute. Aber kann hier einer Grafiken machen? Oder kennt
sich einer mit AI aus? Wenn nein, brauchen wir dafür noch Leute. *Zumindest einen Grafiker*, weil entweder
man kann sowas oder nicht. AI könnten wir uns ja noch selber beibringen..

Ich würde also sagen wir warten noch bis wir einen Grafiker haben. Zu viert könnten wir dann anfangen,
d.h. uns an Zeitpunkten, wo jeder bisschen Zeit hat, in Skype als Konferenz zusammenfinden o.ä. und über
das Spiel reden.

*edit: @ Developer-X*
Mach du mal lieber dein Rayman  :roll:


----------



## homer65 (6. Jan 2009)

Also Grafiker bin ich überhaupt nicht. :-(
Mit AI habe ich mich noch nicht beschäftigt. :-(
Habe aber schon einiges in Swing programmiert. 

Mit der Vorgehensweise:

- Spiel bis ins Detail ausplanen
- Dann erstmal nur Interfaces schreiben um eine grobe Struktur reinzukriegen
- dann erst Stück für Stück implementieren, mit einzelnen Phasen die wir immer durchtesten 

bin ich einverstanden.
Mit Punkt 1 dem Planen können wir auch schon ohne Grafiker anfangen.


----------



## hdi (6. Jan 2009)

Ok ich hab jetzt nochmal etwas genauer überlegt und eine Zusammenfassung gemacht. Wir können ja erstmal
diesen Thread hier nutzen um zu kommunizieren, stört ja keinen und unser Projekt ist ja auch nicht geheim 

Am besten ihr lest euch das durch und schreibt dann selbst dazu, was ihr davon haltet, was ihr für weitere Ideen habt usw. Und dann arbeiten wir das hier Stück für Stück durch bis wir eine genaue Vorstellung des Spiels und aller Regeln haben, mit der wir alle einverstanden sind.

Dann können wir mal Konferenz machen und besprechen wie wir beginnen wollen.

Hier mein Part:

- Grundkonzept: 2D rundenbasiertes Kriegs-Brettspiel mit Würfel
- Visualisierung komplett mit Swing (keine externen Bibliotheken)
- Spielbrett ist ein Raster von hexagonalen Feldern (implementiert als 2d-Array) :



(Über die beste Art der Durch-Nummerierung muss man noch nachdenken)

- Die Karte besteht aus 2 Typen von Feldern: Wasser und Kontintental-Felder
- Wasserfelder sind nicht begehbar
- Ein Kontinentalfeld gehört zu einem Land (ein Land hat mehrere Felder!)
- Ein Land wiederum gehört zu einem Kontinent (d.h. ein Kontinentalfeld gehört auch zu einem Kontinent)
- Die Kartengenerierung erfolgt zufällig (*eine der grossen Herauforderungen!*)
- Man kann die Grösse einer Karte bestimmen, was aber nicht die tatsächliche Anzahl von feldern im Raster
beeinflusst (die ist immer gleich) sondern lediglich die Anzahl an Kontinental-Feldern
- Die Karte muss auch eine runde Welt darstellen, sprich es muss eine Verbindung von links nach rechts geben,
analog oben/unten. Wasserwege zwischen Kontinenten müssen auch sinnvoll erstellt werden können.

- Es spielt ein Spieler vs. x Computer-Gegner (*Die AI für den PC ist denk ich das allerschwerste*)
- Anfangs hat jeder x Geld und damit kann man sich sein Ausgangs-Heer zusammenkaufen
- Dann werden alle Einheiten von den Spielern auf der Karte verteilt (jeder immer eine, dann der nächste etc)
- Ein Feld kann theoretisch unendlich viele Einheiten bergen
- Spielverlauf ist folgender:
  1) Ein Spieler bekommt zu Anfang seiner Runde x Geld, abhängig von Anzahl an Ländern die er besitzt +
      Kontinent-Bonus + evtl andere Boni
  2) Er kann dann soviel Geld ausgeben wie er hat
  3) Man kann für Geld folgendes Kaufen:
             - Einheiten (Soldat, berittener Soldat, Samurai-Meister etc whatever
             - Militär-Gebäude (Defense Tower, Stacheldrahtzaun oder sowas)
             - Forschungsgebäude (Können Einheiten upgraden)
      Eine Einheit hat bestimmte Eigenschaften: Lebenspunkte, Angriffswert, Schaden, Verteidigungswert, Rüstung
      Militärische Gebäude haben keine Rüstung (das sind bei ihnen direkt die Lebenspunkte)
      Forschungsgebäude können weder angreifen noch verteidigen und haben *nur* Lebenspunkte.

  4) Dann _kann_ man beliebig angreifen

      Ein Angriff sieht so aus:
      1) Man klickt auf ein Feld, das man besitzt (wo man also Einheiten drauf hat)
      2) Man klickt auf ein Nachbarfeld mit gegnerischen Einheiten
      3) Jede Angreifer-Einheit würfelt mit 2 Würfeln. Wenn die Summe <= Angriffswert der Einheit, ist der angriff
          erfolgreich.
      4) Dann würfelt jede Verteidiger-Einheit mit 2 Würfeln. Wenn die Summe <= Verteidigungswert wird
          der Angriff  abgeblockt.
*INFO:* Welche Einheit nun welche angrifft, bzw. wer verteidigt... müssen wir uns noch überlegen
      5) Wenn die Verteidigung fehlschlägt, wird dem Verteidiger 
            (Schaden von Angreifer - Rüstung von Verteidiger) Lebenspunkte abgezogen.

      Schritte 3-5 werden solange wiederholt, bis entweder der Angreifer den Verteidiger komplett zerstört hat
      oder andersherum.
      Man kann sich hier aber noch feinere Reglements ausdenken, das ist nur eine Idee von vielen.

   5) Nach einem Angriff kann man evtl. noch Einheiten verschieben (zwischen einzelnen eigenen Feldern), wie
       auch bei Risiko

Spiel ist zu Ende wenn nur noch 1 Spieler mind. 1 Einheit hat -> World Domination

Über so Dinge wie Menü usw. denk ich brauchen wir noch nicht reden, wir sollten uns erstmal über die Regeln
des Spiels im Klaren sein.

Also dann sagt mal, was habt ihr so für Ideen?


----------



## manuche (6. Jan 2009)

Sieht doch schonmal ganz gut aus...

Hab allerdings noch ein paar Punkte die mir noch unklar sind:
- Wo spawnen gekaufte Einheiten
- Sind sie sofort vergügbar oder müssen sie zuerst gebaut werden?
- Wie sind die Regeln für das Bewegen von Einheiten? Jede Einheit nur ins nächste Feld oder Anzahlländer / x Züge?
- Was geschieht mit Gebäuden wenn das Land eingenommen wird (wobei Defense-Tower o.ä. wahrscheinlich eh zerstört wurden)
- Müssen Eineheiten erst zu einem Gebäude um upgegradet zu werden oder wird einfach bestimmt welche Einheit upgegradet werden soll?


----------



## hdi (6. Jan 2009)

Also ich hab mir das so gedacht:

- Wo spawnen gekaufte Einheiten
Dort, wo du sie hinsetzt. D.h. du klickst im Kauf-Menü auf "Soldat" und dann klebt an deiner Maus der Soldat
und du klickst ihn auf das Feld, auf dem du ihn haben willst. Das muss natürlich ein Feld sein, dass du besitzt.

- Sind sie sofort vergügbar oder müssen sie zuerst gebaut werden?
Ich würde sagen sofort. Gebäude auch sofort, mann kann das ja durch recht Hohe Kosten ausgleichen.

- Wie sind die Regeln für das Bewegen von Einheiten? Jede Einheit nur ins nächste Feld oder Anzahlländer / x Züge?
Hier bin ich mir auch nicht sicher. Ich glaub bei Risiko war das doch so, dass du festlegen musstest aus welchem Feld
du angreifst, und dann konntest du rumziehen bis du keine Einheiten mehr hattest. (Weil du beim weiterreisen immer
mindestens eine Einheit auf dem alten Feld lassen musstest). Man kann's auch anders machen, ich weiss grad auch nicht. Muss man sich überlegen, wie es am meisten Spass macht und fair bleibt.

- Was geschieht mit Gebäuden wenn das Land eingenommen wird (wobei Defense-Tower o.ä. wahrscheinlich eh zerstört wurden)
Militärische Gebäude sind ja wie feindliche Einheiten, das heisst man muss sie zerstören bis man das Feld eingenommen hat. Bei den Forschungsgebäuden könnte man sagen, dass man diese überträgt auf den Angreifenden Spieler.

- Müssen Eineheiten erst zu einem Gebäude um upgegradet zu werden oder wird einfach bestimmt welche Einheit upgegradet werden soll?
Ne ich würd sagen ganz klassisch wie bei Starcraft etc: Man hat dort einen Knopf im Gebäude, der Kostet x Geld
und wenn man drauf klickt sind alle entsprechenden Einheiten upgegradet.

Hab grad versucht n Interface für eine Einheit zu machen:


```
public interface Unit {

	/**
	 * Tosses the dice and determines whether this unit's attack attempt
	 * succeeded.
	 * 
	 * @return true if unit has not yet tried to attack in this round and dice
	 *         pips <= unit's attacking value, false else.
	 */
	public boolean mayAttack();

	/**
	 * Tosses the dice and determines whether this unit's defense attempt
	 * succeeded.
	 * 
	 * @return true if unit has not yet tried to defend in this round and dice
	 *         pips <= unit's defense value, false else.
	 */
	public boolean mayDefend();

	/**
	 * @return true if this unit has no more hit points left, false else.
	 */
	public boolean isDead();

	/**
	 * Lets damage impact on this unit, meaning the hit points will be reduced.
	 * 
	 * @param dmg
	 *            Amount of damage dealt out by the attacking unit.
	 */
	public void receiveDamage(int dmg);

	/**
	 * Calls receiveDamage(this unit's damage value) on the target unit.
	 * 
	 * @param target
	 *            The unit which shall be attacked.
	 */
	public void dealDamage(Unit target);

       /**
	 * Calculates the difference between the attackers damage value and this 
         * unit's armor, and then calls receiveDamage(difference) on this unit.
	 * 
	 * @param dmg
	 *            Amount of damage dealt out by the attacking unit.
	 */
	public void defend(int dmg);

	/**
	 * @ return true if this unit has not yet moved in this particular round,
	 * false else.
	 */
	public void mayMove();

	/**
	 * Resets all actions so that this unit may move, attack and defend again.
	 */
	public void reset();

	/**
	 * @return a BufferedImage of the image file representing this unit's
	 *         graphical appearance.
	 */
	public BufferedImage getPic();
}
```

Ich hab überlegt ob es ein getOwner() geben sollte, aber ich denke es ist schlauer das auf einem Feld zu setzen. Immerhin kann es kein Feld geben, auf dem Einheiten unterschiedlicher Spieler drauf sind.

Die Methoden mayAttack() / mayDefend() kann man theoretisch auch direkt in die Methoden dealDamage und
receiveDamage einbauen.

Die Klasse Unit, also die Implementation, sollte halt denke ich abstract sein. Weiss nich ob da jetzt noch was
grundlegendes fehlt oder etwas doof gemacht ist.


----------



## manuche (6. Jan 2009)

Wie wäre es mit folgender Implementation:

```
public interface Movable{
  public void move(...);
}

public interface Drawable {
  public void draw (...);
}

public abstract class Sprite implements Movable, Drawable {
  ...
  public void doLogic (...);

  public void move (...){...}
  public void draw (...){...}
}

public interface Unit {
  ...
  s.o.
}

public abstract class UnitBase extends Sprite implements Unit {
  //Durch die Klasse Sprite kann die Einheit schon gezeichnet und bewegt werden
  protected int hp;
  ... //Implementationen der Funktionen aus dem Unit-Interface
}
```

Dadurch könnte man noch leicht eine Klasse für Menüs implementieren die einfach nur von Sprite erbt und somit schon gezeichnet und evtl bewegt werden kann...
Da fehlt jetzt natürlich noch einiges an Methoden aber vom Grundgerüst her wäre es das einleuchtenste...
Von UnitBase erben dann natürlich alle speziellen Einheiten! Parallel dafür dann evtl das Interface Building und die abstrakte Klasse BuildingBase


----------



## homer65 (7. Jan 2009)

Halt, Stop, ihr seid mir viel zu schnell. Ich denke wir sollten uns erst mal auf die Regeln einigen, bevor wir anfangen Programm Code zu schreiben. Ich werd mir mal euere hier geposteten Ideen genau angucken und dann meine Fragen und Meinugen dazu hier posten. Aber bitte nicht so schnell.


----------



## hdi (7. Jan 2009)

Jo stimmt. Wir sind noch weit davon entfernt, die Regeln genau ausgearbeitet zu haben. Bevor wir
sinnvolle Interfaces schreiben oder skizzieren können, müssen wir ja wirklich *ganz klar* wissen, was eine Einheit kann, welche verschiedenen es gibt (um ihre Gemeinsamkeiten zu sehen), usw usf.

Das Game muss echt bis ins letzte Detail ausgeplant sein, also reeeewind


----------



## manuche (7. Jan 2009)

Der Eifer des Gefechts halt xD
Zu den Einheiten denke ich es sollten nicht allzu viele werden! Also wirklich nur 3 bis 4. Die Gebäude sollten maximal 3 werden...
Sonst kommt man schon sehr stark von Risiko weg!
Außerdem hat man ja schon die Upgradefunktion mit der man Einheiten modifizieren kann! Dazu frag ich mich auch grad ob man eine Einheit wirklich nur generell upgraden kann (à la Level 1, 2 und 3) oder ob man spezielle Fähigkeiten upgradet wie Verteidigung oder Angriff...

Also ich würde zu 3 Einheiten mit 2 verschiedenen Upgrades und zwei Gebäuden tendieren...
Sprich man bekommt eine Einheit auf Level 1 und kann sie dann zweimal bis auf Level 3 upgraden.
Für die Gebäude reicht vermutlich auch ein Upgrade!


----------



## hdi (7. Jan 2009)

Ja ich würde es auch nicht übertreiben.
Aber ich würde die Upgrades trotzdem unterteilen in Lvl 1-3 für jedes Attribut.
Das bringt schon strategischen Aspekt rein, weil du zB lieber Defence von 1 auf 3 upgradest
statt alles um 1, wenn vor deinen Toren ein paar Panzer stehen 

Allerdings kommt mir auch grad: verschiedene Einheiten machen irgendwie echt nur Sinn
wenn man auch ein Attribut "Bewegungspunkte" oder so hat. Weil wer kauft sich noch Soldaten,
wenn Panzer genauso schnell sind und mehr aushalten und austeilen? Irgendwas müssen wir uns
da einfallen lassen. Vllt nicht unbedingt Bewegungspunkte, vllt gibt es ja was anderes.

Und bei Gebäuden: Ich denke ein "Castle" oder so, d.h. dann bevor überhaupt die Einheiten auf dem
Feld angegriffen werden können, muss das Castle down gehen. Das wär dann als Schutz für Einheiten 
sozusagen.

Und das langt eig. schon als militärisches Gebäude, und dann noch eine Research Facility. 

Wenn beide sehr teuer sind, sind sie etwas sehr spezielles, und dann passt es find ich auch wenn
es echt nur diese 2 Gebäude gibt...


----------



## homer65 (7. Jan 2009)

Hab mir mal einige Gedanken zu den Spielregeln gemacht:
==> Grundkonzept: 2D rundenbasiertes Kriegs-Brettspiel mit Würfel
---> ok
==> Visualisierung komplett mit Swing (keine externen Bibliotheken)
---> ok
==> Spielbrett ist ein Raster von hexagonalen Feldern
---> ok
==> Die Karte besteht aus 2 Typen von Feldern: Wasser und Kontintental-Felder 
---> ok
==> Wasserfelder sind nicht begehbar 
---> ok
==> Ein Kontinentalfeld gehört zu einem Land (ein Land hat mehrere Felder!) 
---> ok, plus (ein Land hat mehrere zusammenhängende Felder)
==> Ein Land wiederum gehört zu einem Kontinent (d.h. ein Kontinentalfeld gehört auch zu einem Kontinent) 
---> ok
==> Die Kartengenerierung erfolgt zufällig (eine der grossen Herauforderungen!) 
---> Halte ich für den Anfang für zu schwer, würde lieber mit einer vorher erstellten Karte anfangen
==> Man kann die Grösse einer Karte bestimmen, was aber nicht die tatsächliche Anzahl von feldern im Raster beeinflusst (die ist immer gleich) sondern lediglich die Anzahl an Kontinental-Feldern 
---> Wäre bei einer vorher erstellten Karte nicht von Bedeutung
==>Die Karte muss auch eine runde Welt darstellen, sprich es muss eine Verbindung von links nach rechts geben, analog oben/unten. Wasserwege zwischen Kontinenten müssen auch sinnvoll erstellt werden können.
---> Das könnte man lösen, indem man für jedes Land festlegt, welche Ländern benachbart sind. 
==> Es spielt ein Spieler vs. x Computer-Gegner (Die AI für den PC ist denk ich das allerschwerste) 
---> ok
==> Anfangs hat jeder x Geld und damit kann man sich sein Ausgangs-Heer zusammenkaufen 
---> ok, plus zu Anfang dürfen nur Einheiten und keine Gebäude gekauft werden
==> Dann werden alle Einheiten von den Spielern auf der Karte verteilt (jeder immer eine, dann der nächste etc) 
---> ok
==> Ein Feld kann theoretisch unendlich viele Einheiten bergen 
---> Ein Feld kann theoretisch unendlich viele Einheiten und ein Gebäude bergen
==> Spielverlauf ist folgender: 
---> ok
==>Ein Spieler bekommt zu Anfang seiner Runde x Geld, abhängig von Anzahl an Ländern die er besitzt + Kontinent-Bonus + evtl andere Boni 
---> ok, aber muß noch genauer festgelegt werden
==>Er kann dann soviel Geld ausgeben wie er hat 
---> ok
==> Man kann für Geld folgendes Kaufen: 
- Einheiten (Soldat, berittener Soldat, Samurai-Meister etc whatever 
- Militär-Gebäude (Defense Tower, Stacheldrahtzaun oder sowas) 
- Forschungsgebäude (Können Einheiten upgraden) 
---> ok, plus und verteilt das Gekaufte beliebig auf eigene Felder
==> Eine Einheit hat bestimmte Eigenschaften: Lebenspunkte, Angriffswert, Schaden, Verteidigungswert, Rüstung 
---> ok
==> Militärische Gebäude haben keine Rüstung (das sind bei ihnen direkt die Lebenspunkte) 
---> Hmh, besser: Militärische Gebäude verstärken Schaden bzw Rüstungt der Einheiten
==> Forschungsgebäude können weder angreifen noch verteidigen und haben nur Lebenspunkte.
---> Forschungsgebäude nehmen nicht am Kampf teil, werden aber mit dem Feld auf dem sie stehen erobert
==>  Dann kann man beliebig angreifen 
---> ok
==> Ein Angriff sieht so aus:
---> ok
==>  Man klickt auf ein Feld, das man besitzt (wo man also Einheiten drauf hat) 
---> ok
==> Man klickt auf ein Nachbarfeld mit gegnerischen Einheiten 
---> ok
==> Jede Angreifer-Einheit würfelt mit 2 Würfeln. Wenn die Summe <= Angriffswert der Einheit, ist der angriff erfolgreich. 
==>  Dann würfelt jede Verteidiger-Einheit mit 2 Würfeln. Wenn die Summe <= Verteidigungswert wird der Angriff abgeblockt.
==>  INFO: Welche Einheit nun welche angrifft, bzw. wer verteidigt... müssen wir uns noch überlegen 
==>Wenn die Verteidigung fehlschlägt, wird dem Verteidiger (Schaden von Angreifer - Rüstung von Verteidiger) Lebenspunkte abgezogen.
---> Hier hätte ich gerne eine ähnliche, aber doch etwas andere Kampfweise:
Die angreifenden Einheiten werden der Reihe nach durchgegangen.
Zu einer angreifenden Einheit wird zufällige aus den bis dahin überlebenden verteidigenden Einheiten eine ausgewählt.
Jede Angreifer-Einheit würfelt mit 2 Würfeln. Wenn die Summe <= Angriffswert der Einheit ist, ist der Angriff erfolgreich, der verteidigenden Einheit werden (Schaden von Angreifer – Rüstung von Verteidiger) Lebenspunkte abgezogen
Die verteidigende Einheit würfelt mit zwei Würfeln.  Wenn die Summe <= Verteidigungswert ist die Verteidigung erfolgreich, der angreifenden Einheit werden (Schaden von Verteidiger – Rüstung von Angreifer) Lebenspunkte abgezogen
==> Schritte 3-5 werden solange wiederholt, bis entweder der Angreifer den Verteidiger komplett zerstört hat oder andersherum. 
---> ok
==> Nach einem Angriff kann man evtl. noch Einheiten verschieben (zwischen einzelnen eigenen Feldern), wie auch bei Risiko 
---> Nach allen Angriffen kann man evtl. noch Einheiten verschieben. Ich weiß leider nicht mehr wie bei Risiko die genauen Bedingungen sind? Müßte man sich noch Gedanken machen.
==> Spiel ist zu Ende wenn nur noch 1 Spieler mind. 1 Einheit hat -> World Domination
---> ok

Das wird aber langsam unübersichtlich. Ich denke die Spielregeln werden zu umfangreich, um sie hier weiter zu posten. Wie wäre es wenn einer das ganze als Open Office Text Dokument ausarbeitet und sie dann an die anderen zwecks Diskussion verteilt.


----------



## hdi (7. Jan 2009)

Wegen der Diskussion: Ich denke wir können das durchaus hier machen. Ich meine es ist zu stressig ein Dokument zu schreiben, an alle anderen zu schicken, abzuwarten was sie zurückschreiben, und dann den anderen beiden jeweils die Antwort des anderen schicken.

Wenn wir den ersten Milestone haben, also die Spezifikation vom Spiel komplett, machen wir eh ne komplette
Zusammenfassung und das kann sich ja dann jeder selbst in eine Datei speichern, wenn er mal was nachschlagen
will beim Programmieren etc.

Zu deinen Ideen:



> würde lieber mit einer vorher erstellten Karte anfangen



Gut, ist im Nachhinein ja eh sehr leicht austauschbar durch zufällige Karten



> zu Anfang dürfen nur Einheiten und keine Gebäude gekauft werden



Das würde ich einfach von selbst durch mangelndes Start-Geld regeln. Ausserdem könnte die Research
Facility nicht nur Upgrades für Einheiten bieten, sondern Voraussetzung für militärische Gebäude sein?!



> Ein Feld kann theoretisch unendlich viele Einheiten und ein Gebäude bergen



Okay. Wir müssen uns aber überlegen wie wir das grafisch darstellen können. So gross ist nämlich ein
Feld nicht, wenn die Karte einigermassen gross sein soll. Und da 2 verschiedene Einheits-Typen + noch ein
Gebäude draufmalen... Sehen wir dann wenn wir eine Karte haben, wie gross wir die einzelnen Felder
machen können.



> Ein Spieler bekommt zu Anfang seiner Runde x Geld, abhängig von Anzahl an Ländern die er besitzt + Kontinent-Bonus + evtl andere Boni
> ---> ok, aber muß noch genauer festgelegt werden



Dann sollten wir das mal machen. Vllt Felder + Länder-Bonus nur, und halt Geld bekommen wenn man erfolgreich
eine Schlacht gewonnen hat oder so? Die feindlichen Einheiten quasi plündern?

Wegen Kontinenten: Bin mir nicht sicher ob wir das von der Grösse der Karte hinkriegen. Bei Risiko gibts ja
nur Ländern und die bilden einen Kontinent. Bei uns bilden aber Felder ein Land. Und dann noch mehrere Länder
ein Kontinent ? Ich glaube soviele Felder haben wir nicht...


```
und verteilt das Gekaufte beliebig auf eigene Felder
```

genau direkt beim Kauf werden die gesetzt.



> Hmh, besser: Militärische Gebäude verstärken Schaden bzw Rüstungt der Einheiten



Das ist ne geile Idee! Vllt trennt man das, dann gibt's doch mehr als 1 militärisches Gebäude..

Nun zu deiner Idee eines Kampfverlaufs:
Ich finde das ist etwas unlogisch, dass beide Seiten Lebenspunkte verlieren, wenn der Verteidiger geblockt hat.
Wie wär's wenn wir uns in der Mitte treffen und es so machen:

1) Angreifer würfelt ob sein Angriffsversuch gelingt, also <= Angriffswert
2) Wenn er trifft, hat der Verteidiger einen Verteidigungsversuch, also <= Verteidigungswert.
3) Wenn der Verteidiger den Versuch erflogreich absolviert, kassiert er nix *und macht einen Gegenangriff*.
4) Ansonsten verliert er (Damage-Armor) Lebenspunkte und macht KEINEN Gegenangriff
5) Wenn der Angreifer nicht trifft, kriegt der Verteidiger automatisch seinen Gegenangriff!

Und beim Gegenangriff ist das nun so, dass der Angreifer nur dann einen Verteidgungsversuch hat, wenn
seine Angrifffsprobe gelungen ist! Ist denke das ist am logischsten.

Ich will hier nochmal die Idee eines *"Critical Strike" bzw. "Perfect Block"* erwähnen:

Wenn der Angreifer seine Probe sehr gut besteht (zB mit beiden Würfeln eine 1 würfelt), dann geht doppelter
Schaden durch ohne dass der Verteidiger verteidigen darf.
Und analog dazu wenn der Verteidiger etwas mit 2x1 Würfeln blockt, kassiert der Angreifer einen doppelten
Gegenangriff ohne dass er sich verteidigen darf.

Ich finde dieses Element sehr sehr wichtig, weil man so auch eine Schlacht gewinnen kann, wenn man viel
weniger Einheiten hat! Das hält das Spiel spannend bis zum Ende, muss also find ich unbedingt rein!


----------



## hdi (7. Jan 2009)

Ich schieb noch was dazwischen. Ich hab mir nun konkretere Gedanken gemacht zu den Einheiten/Gebäuden.

Legende:
a = Angriffswert, man muss mit *3* Würfeln <= a würfeln, um erfolgreich anzugreifen
v = Verteidigungswert, regeln analog zum Angriff
d = damage, also Schadenspunkte die man austeilt
r = rüstung, wird bei einem Treffer erst vom Schaden abgezogen und dann verliert man den Rest von den hp
hp = Lebenspunkte
$ = Kosten der Einheit

*Bewegliche Einheiten:*

*Soldat*
$ = 100
a = 8
v = 8
d = 10
r = 2
hp = 25

*Berserker*
$ = 250
a = 14
v = 6
d = 30
r = 0
hp = 1

*Tanker* 
$ = 500
a = 6
v = 14
d = 10
r = 4
hp = 50

*Priester*
$ = 500
a = 0
v = 0
d = 0
r = 0
hp = 125
*Info:* Der Priester erhöht den Angriffs- und Verteidigunswert aller eigenen Einheiten, die sich bei einem Kampf
auf dem gleichen Feld befinden wie er.

*Gebäude (nicht beweglich):*

*Abwehrturm*
*Info:* beteiligt sich als normale Einheit am Kampfgeschehen
$ = 1500
a = 10
v = 0
d = 10
r = 0
hp = 250

*Forschungs-Zentrum*
*Info:* Ist nicht in Kämpfe verwickelt, bietet Upgrades und Freischaltungen an
$ = 5000
a = 0
v = 0
d = 0
r = 0
hp = n/a

Optionen in diesem Gebäude:
- Angriffswerte aller Einheiten und Gebäude +1 (max +3, also 3x ausbaubar) 
- Verteidigungswerte aller Einheiten +1 (max +3)
- Rüstung aller Einheiten +1 (max +3)
- Schaden aller Einheiten, sowie auch dem Abwehrturm: +1 (max +3)
- 20% Kosten-Senkung für alle Einheiten inkl. Upgrades etc 

Preise:
Die Kosten-Senkung kann nur einmalig zu einem Preis von $10.000 erforscht werden.
Die anderen Dinge können 3 mal ausgebaut werden, wobei:

Level 1 : $ 1500
Level 2 : $ 3000
Level 3 : $ 10.000

----------------------------------------------------------------------------------------------------------------

So, was haltet ihr von dieser Zusammenstellung von Einheiten? Fehlt was? Oder ist was überflüssig?

*Wegen den einzelnen Werten, also Preise und Attribute:*

Das ist jetzt einfach mal so ein Wert, das wird so ziemlich das letzte sein, was
wir festlegen. Sowas kann man alles erst ausbalancieren wenn das Spiel läuft und man es 
ausgiebig gespielt hat. Aber für's erste haben diese Zahlen ja nix mit der Implementation am Hut, ich
dachte nur damit wir wissen welche Einheiten es gibt, sodass wir das OO-Design machen können und wissen,
auf welche Spezial-Fähigkeiten (zB Priester, Forschungs-Zentrum) wir so achten müssen..

So, und jetzt versuch ich erstmal mehr euch zu Wort kommen zu lassen! Bin nur grad ziemlich motiviert also
sorry für meine Ausschweife


----------



## Quaxli (7. Jan 2009)

Also, wenn Ihr noch jemanden braucht, bin ich dabei  - ich wollte mich schon länger mal mit AI beschäftigen 
Grafisch kann ich ein bißchen was liefern. Bei der Ausarbeitung der Figuren bin ich dann aber auch überfordert.

Eine Idee noch, die von "Samurai Swords" geklaut ist: Armeen.

Ein Figur auf dem Brett repräsentiert eine Armee, die extern dargetstellt wird und n Figuren enthält. Im Falle eines Kampfes, würfeln die Figuren der Armee in einer bestimmten Reihenfolge (Bogenschützen zuerst, ...). Im Verlauf des Spiels kann die Armee ihre Erfahrung und damit ihre Zugweite bestimmen und so u. a. Angriffe tief ins feindliche Gebiet vortragen.

Das wäre ja was, was man bei einer ersten Version erst mal weglassen könnte, um es dann in Version 1.1 einzubauen.
Nachdem von uns keiner Erfahrung mit AI hat, sollten wir erst mal eine einfache Version basteln, die aber halbwegs vernünftige Computergegner enthält.


----------



## hdi (7. Jan 2009)

Super, dass du nun doch mitmachst! Also wenn du die Grafik so hinkriegst wie bei deinem JFalcon, dann wär das ja schon total ausreichend. Spielt ja auch keine Rolle ob Eigenarbeit oder Royalty Free.

Der Vorschlag mit Erfahrung klingt interessant. Ich find wir müssen nur aufpassen dass die Regeln nicht so kompliziert werden, dass man erstmal Stundenlang braucht um sich ins Spiel einzuarbeiten. Bei solchen Spielen spring ich persönlich zB schnell ab. Civilization 4 zB ist angeblich ein Hammer-Spiel, aber als ich es mal kurz gespielt habe, hab ich schnell die Lust verloren weil es einfach zu vollgeklatscht war von Features und Regeln.


----------



## Quaxli (7. Jan 2009)

Wie gesagt: Erst mal einfach anfangen  - und platz für Modifikationen einplanen.


----------



## hdi (7. Jan 2009)

Okay ich bin grad dabei eine ausführliche Spezifikation zu schreiben, wie die finale Version aussehen soll, mit
allen Features etc. Sowohl inhaltlich als auch grafisch.

Und da werd ich mir auch mal einen erste Milestone überlegen, also eine Version des Spiels, auf's Wesentliche beschränkt und so gecodet, dass man es erweitern kann (zB erstmal keine Gebäude, nur 1 Typ von Einheit, grafisch primitiv, nur 1 PC-Gegner, usw.)

Ich denk mal heute abend oder morgen werd ich damit fertig, und dann verlink ich das mal.

Wenn wir uns dann über die erste Version einig sind, kann's losgehen. Es bringt auch nichts wenn man 12 Monate plant und noch keine Zeile code hat, das kommt dann wie es kommt, lassen wir uns überraschen 

Ich meld mich dann..


----------



## manuche (7. Jan 2009)

Ich denke auch, dass bei solch "kleinen" Projekten immer besser kommt wenn man die Ideen direkt einfliessen lässt da sie noch recht einfach zu implementieren sind...
Leg am bestem mal das Konzept vor! Im Prinzip ist es ja dein Spiel 
Wer kümmert sich eigentlich im SVN?


----------



## homer65 (7. Jan 2009)

hdi hat gesagt.:
			
		

> Okay ich bin grad dabei eine ausführliche Spezifikation zu schreiben, wie die finale Version aussehen soll, mit
> allen Features etc. Sowohl inhaltlich als auch grafisch.


Ok, dann warten wir mal mit Spannung. Ich denke die erste Spezifikation muß gar nicht perfekt sein. Wird sich hoffentlich im Laufe der Zeit verbessern. Ist vielleicht praktisch erst mal einen Startpunkt zu haben und sich dann so nach und nach zu verbessern.


----------



## hdi (7. Jan 2009)

*Vorläufige Spezifikation der Spielregeln*

DOWNLOAD (Word 97 kompatibles Dokument, Rechtsklick -> Speichern unter...)

Wem was nicht passt, bitte Bescheid geben. Bitte beachten, dass diese Dinge hier nicht alle genauso realisiert
werden müssen, und erst Recht werden wir das nicht gleich alles umsetzen in den ersten Versionen des Spiels!
Es geht nur darum, in etwa das Finale Produkt abzuschätzen. Wenn also jemand eine Idee für Regeln oder so hat,
die sich komplett mit der bisherigen Struktur in die Haare kriegen würde, können wir das jetzt noch behandeln.
Ansonsten machen wir dann weiter, und zwar:

*Nächste Schritte:*

- die genaue Spezifikation davon, wie das Spiel aussehen soll, und wie der User interagieren kann.
Also Menüs, Grafiken, welche Informationen wir dem Spieler geben wollen, und wie (zB Übersicht
über die einheiten auf einem Feld, Ablauf eines Kampfes, etc)

- Wenn wir das Spiel dann sowohl inhaltlich als auch optisch ausdokumentiert haben, werden wir uns einen
ersten Milestone überlegen und eine *primitive Grund-Fassung* des Spiels implementieren.

*PS: *SVN werd ich heute oder morgen einrichten.

*EDIT:*
Ich hatte noch eine Regel für den Kampf-Ablauf vergessen und noch eine andere Kleinigkeit.
Ich habe den obigen Download aktualisiert, sodass diese Dinge nun enthalten sind.


----------



## hdi (8. Jan 2009)

So Leute ich hab mir jetzt mal überlegt wir man die Grundstruktur aufziehen kann für eine simple Version
des Spiels. Genauere Infos wie zB alle Methoden usw fehlen, es geht erstmal nur um den Klassen-Zusammenhang.
Ich hoffe ihr könnt etwas UML:





Also ein paar Worte dazu: Den Mittelpunkt bildet die WorldMap, die die einzelnen Zellen beinhaltet, ein JPanel ist, und das ganze Spielgeschehen zeichnet. Sie hat MouseListener und so kann man auf dein einzelnen Zellen arbeiten (die Map besteht ja aus einem 2d-array von Zellen).
Da alle spielrelevante Infos eig. in einer Zelle stecken, sprich die Einheiten, kann die Map also Infos über eine Zelle (und darüber wiederum über ihre Einheiten) anzeigen, und kann auch ein Battle starten.

Da dachte ich mir machen wir mit Observer, d.h. die Methode "startBattle()" bei WorldMap sieht in der Implementation etwa so aus:


```
public void startBattle(Army a, Army b){
      Battle battle = new Battle(a,b);
      battle.addObserver(this);
      battle.startFight();
}
```


```
public void upate(Observable o){ 
      (Battle)o.getWürfelInformation();
      // blub blub blub
      this.repaint();
}
```

Und während nun der Kampf geschieht macht Battle immer wieder ein Update, wodurch sich die WorldMap entsprechend
neu zeichnet bzw. in einem Fenster Infos über den Ablauf anzeigt, zB was grad gewürfelt wurde usw.

Was halt hier noch fehlt ist der Gameloop. Das könnte man vllt auch irgendwie mit der WorldMap per Observer verlinken.. Und die AI muss man auch noch reinquetschen, wobei das ja eig. der Gameloop selbst ist.


----------



## Quaxli (8. Jan 2009)

Du bist schon wieder zu schnell . Bevor darüber nachgedacht wird, wie man ein Gefecht startet, sollte erst mal der ganze Rahmen stehen.

Was mir noch nicht ganz klar ist:
WorldMap ist der Mittelpunkt -> d. h. dort läuft der GameLoop?
Das finde ich nicht gut, wenn es so gedacht ist.

Die WorldMap sollte nichts weiter sein als ein "Container", der die Felder enthält und geeignete Methoden für den Informationsabruf bereit stellt, also "nur" eine Klasse, die man in das Spiel einbindet.

Die Klasse in welcher der GameLoop letzten Endes läuft sollte nichts weiter tun, als das Spielgeschehen zu administrieren mehr nicht und das ist auch schon genug.
Auch die AI hat da meines Erachtens da nichts verloren, sondern sollte eine eigenständige Klasse/Komponente sein.

Bei so einer komplexen Geschichte sollte man schon der Übersichtlichkeit halber, nicht zuviel in eine Klasse quetschen. Damit tut man sich keinen Gefallen - auch im Hinblick auf eine spätere Erweiterbarkeit bzw. Austauschbarkeit.

Nehmen wir mal die Klasse WorldMap: Nach meinem Verständnis wäre das eine eigenständige Klasse, mit Methoden, wie z.B. generateMap(), drawMap(), etc... . 
In einem ersten Schritt könnte generateMap() z. B. einen vorgefertigte Karte enthalten, was denn später ausgebaut wird und über bestimmte Logiken wirklich eine Zufallskarte generiert. Dies kann u. U. in relativ viel Code ausarten. Und das in eine Klasse quetschen, in der noch der GameLoop, etc. läuft? Nein, danke.


----------



## manuche (8. Jan 2009)

Ich denke auch, dass wir eine Klasse für das "administrative" brauchen!
Hat eigentlich schon wer über Multi-Threading nachgedacht? Also vllt einen Thread der nur zeichnet und einen anderen, der die Spiellogik bearbeitet...
Ich weiss nicht in wiefern man in Java die Threads Prozessoren zu teilen kann aber ich hab immer schon einen Grund gesucht mich in Synchronisation von Threads einzuarbeiten...
Und ja ich hab nen Performance fetisch 

Vllt sollten wir auch mal sinnvoll aufteilen, wer sich um welches Themengebiet kümmert bevor wie alle durcheinander blubbern. Tipps und Kniffe kann man sich immernoch untereinander geben!
Vor allem sollten wir uns über unsere Teamarbeit unterhalten... Bringt ja nichts wenn alle einfach drauf los arbeiten (auch wenn ich das grad liebensgern tun würden  )!


----------



## SlaterB (8. Jan 2009)

findet die gesamte private Projektkommunikation jetzt in diesem Forum hier statt?


----------



## hdi (8. Jan 2009)

@SlaterB

nich mehr lange  Wenn wir erstmal angefangen haben kommunizieren wir eh über SVN und Skype o.ä.

@Team

ich hatte ja die Spezifikation hochgeladen. Eigentlich warte ich nur drauf, dass ihr da ein Ok gebt bzw etwas dazu sagt. 
Wenn jeder einverstanden ist, dachte ich eig. überlegen wir uns die Darstellung vom Spiel, aber okay das muss
jetzt nicht genau ausgearbeitet sein eig. 

Wir können auch direkt mit einer ersten Version beginnen. Denke ein detaillierteres UML Diagramm wäre da
aber schon nötig. Und sowas wie ein Battle muss da finde ich schon rein, auch bevor man anfängt irgendwas zu
coden. Das muss schon alle Grundfeatures enthalten, zumindest ich brauche sowas bevor ich anfang weil so 
Design fällt mir noch nicht beim Programmieren in den Schoß.

PS: Nein die Worldmap ist nicht der Gameloop, so war das nicht gedacht. Der Gameloop fehlt im Diagramm


----------



## manuche (8. Jan 2009)

Von mir gibts schonmal ein OK  Sieht ja ganz nett aus bis jetzt!


----------



## homer65 (8. Jan 2009)

Ich könnte unserem Projekt ein eigenes Forum zur Verfügung stellen. Dann bräuchen wir nicht mehr über das java-forum zu kommunizieren. Besteht Interesse daran? Bitte teilt mir euere Meinung mit.


----------



## hdi (8. Jan 2009)

Ja klar das wär super! Ich versuch heut abend noch das SVN einzurichten


----------



## manuche (8. Jan 2009)

@homer65: nen ganzes Forum??? Aber auf jeden Fall eine gute Möglichkeit sich "ungestört" austauschen zu können..

@hdi: hast du denn nen SVN-Server?


----------



## hdi (8. Jan 2009)

ja ich hab einen von meiner uni, allerdings muss ich warten bis mein freund on ist, ich hab das selbst noch nie gemacht.


----------



## homer65 (8. Jan 2009)

Habe mal auf die Schnelle ein Forum eingerichtet. Ist natürlich noch nicht perfekt, aber hier ist die Adresse:
http://ehm.homelinux.org/jforum


----------



## frapo (8. Jan 2009)

SlaterB hat gesagt.:
			
		

> findet die gesamte private Projektkommunikation jetzt in diesem Forum hier statt?



Hast ja recht.. so ganz gehört das alles ja nicht mehr hier hin. Aber ich persönlich muss sagen, dass ich als Unbeteiligter, diesen Thread bisher regelmäßig verfolge und ihn sehr spannend finde. Es ist einfach interessant zu verfolgen wie so ein Projekt wächst, ja auch irgendwann dann wirklich umgesetzt wird. 

Vielleicht an euch lieben Projektteilnehmer , falls ihr nun bald woanders kommunizieren werdet: wäre es vielleicht möglich in Betracht zu ziehen, so etwas wie ein Projekt-Tagebuch zu führen? Das könnte man vielleicht auch prima als weiteres Tutorial hier einbinden? Ich bin mir sicher das solches nicht nur mich interessieren würde    

Ansonsten: Gutes Gelingen Euch, vor allem viel Spaß! 

Gruß
frapo


----------



## Illuvatar (8. Jan 2009)

Da kann ich frapo nur zustimmen


----------



## hdi (8. Jan 2009)

Ja den Gedanken hatte ich auch schon, dass es sicherlich den ein oder anderen interessiert, wie so ein Spiel von Null an zustande kommt.

So ein kleines Tagebuch könnten wir machen, natürlich. Wo wir quasi den Stand immer updaten, und auch immer
beschreiben was wir uns für den nächsten Milestone überlegen. 
Und noch besser: Leute können mitreden! D.h. wen so ein Spiel interessiert, der kann auch Vorschläge oder Kritik
einbringen während das Spiel entsteht, und wenns uns auch gefällt bauen wir es ein oder ändern es, wenn wir 
sehen dass eine gewisse Sache bei niemandem gut ankommt.

Der Source-Code wird am Ende eh im Spiel mit dabei sein.

Die Frage ist wie wir das machen. Vllt löscht dann ein Mod alle bisherigen Beiträge, ich weiss janicht ob es
den Mods hier gefällt wenn ich einfach einen neuen Thread aufmache, nur als Tagebuch für uns quasi.

Wär gut wenn einer der Verantwortlichen dazu was sagen könnte


----------



## manuche (8. Jan 2009)

Also ich muss sagen, ich bin erstaunt wie der Thread hier abläuft ^^
Also immer wenn ich sowas mal gesehen hab, dass ein Projekt in einem Forum gestartet werden sollte wurde es direkt in Grund und Boden geredet... 
Und nun haben wir sogar quaxli, den Gottvater der 2D-Tutorials, mit im Boot und die Community verlangt ein Projekttagebuch!
Ich glaub da sprech ich für das "Projektteam" wenn ich sage: "Danke für die Motivationsschübe"! xD

*edit: sorry zu langsam... bin natürlich kein Verantwortlicher vom Forum


----------



## frapo (8. Jan 2009)

hdi hat gesagt.:
			
		

> Und noch besser: Leute können mitreden! D.h. wen so ein Spiel interessiert, der kann auch Vorschläge oder Kritik
> einbringen während das Spiel entsteht, und wenns uns auch gefällt bauen wir es ein oder ändern es, wenn wir
> sehen dass eine gewisse Sache bei niemandem gut ankommt.
> 
> Der Source-Code wird am Ende eh im Spiel mit dabei sein.



Und nicht nur das, ihr hättet so auch gleich den ein oder anderen Beta-Tester  :wink: , möglicherweise auch noch jemanden der Spaß daran hätte, eine Doku zum Game zu schreiben etc.



			
				manuche hat gesagt.:
			
		

> Also ich muss sagen, ich bin erstaunt wie der Thread hier abläuft ^^
> Also immer wenn ich sowas mal gesehen hab, dass ein Projekt in einem Forum gestartet werden sollte wurde es direkt in Grund und Boden geredet... icon_biggrin.gif
> Und nun haben wir sogar quaxli, den Gottvater der 2D-Tutorials, mit im Boot und die Community verlangt ein Projekttagebuch!
> Ich glaub da sprech ich für das "Projektteam" wenn ich sage: "Danke für die Motivationsschübe"! xD



Nicht zu danken!  Oder anders gesagt: wohl auch Teile der Community haben euch zu danken! Natürlich ist es für Teile der Community unheimlich interessant oder sogar wichtig, die Entstehung und Realisierung eines Projekts quer durch alle Entwicklungsprozesse mit zu erleben. Gerade das ist doch das was Anfängern meist fehlt: umfangreichere Beispiele aus der Praxis.


----------



## Marco13 (8. Jan 2009)

Für's Kartengenerieren könnte man mal nach Begriffen wie "Perlin Noise" o.ä suchen. Btw: Wenn Wasserfelder nicht betreten werden dürfen, drfen da aber keine Inseln vorkommen - sonst pflanzt da jemand seine Einheit drauf, und ist dann unbesiegbar 8) :wink:


----------



## hdi (8. Jan 2009)

Nanana Marco da hat einer die Spezifikation nicht gelesen  hehe, mal ernsthaft daran wurde schon gedacht, es gibt in dem Fall eine Verbindung, also einen Wasserweg.


----------



## manuche (9. Jan 2009)

Ich glaub es geht ihm darum, dass keine männchen auf dem Wasser stehen dürfen, oder? Allerdings wäre die Idee mit der unbesiegbaren Einheit ein wenig dirty 
Da gibts andere und besere Lösungen


----------



## hdi (9. Jan 2009)

so also wenn quaxli und homer noch ihr ok geben, könnten wir uns mal zusammenskypen und n halbes stündchen oder so quatschen, wie wir das machen wollen


----------



## homer65 (9. Jan 2009)

hdi hat gesagt.:
			
		

> so also wenn quaxli und homer noch ihr ok geben, könnten wir uns mal zusammenskypen und n halbes stündchen oder so quatschen, wie wir das machen wollen


Von mir aus gerne. Wir müßten uns halt auf einen Termin einigen. 
Was mich angeht, so bin ich berufstätig und habe tagsüber keine Zeit. Am Wochenende paßt mir auch nicht so gut. Also am liebsten wäre mir mitten in der Woche ab 19Uhr.


----------



## andre111 (9. Jan 2009)

Falls ihr noch einen Mann zur Programmierung ( leider kein Grafiker *g* ) braucht hätte ich Lust mitzumachen. Das ganze Projekt hört sich vielversprechend an. Ich hätte hauptsächlich am Wochenende vormittags bzw abends Zeit und unter der Woche auch so ab 19 uhr. Kann natürlich auch mal abweichen wegen Schule, Sport usw. Ich programmiere seit ca 1 1/2 jahren mit java, habe eig jeden Tag mich damit beschäftigt (Multithreading bin ich allerdings nicht sehr fit). Das komplette Spielkonzept finde ich so weit sehr gut (nicht zu komplex, aber anspruchsvoll).

Gruß André


----------



## hdi (9. Jan 2009)

Hey,

Man muss halt aufpassen dass es auch nicht zu viele Leute werden, das kann u.U. 
mehr Nachteil als Vorteil sein. Aber da wir noch nicht angefangen haben, und im Moment 
noch dabei sind unser Forum zu gestalten, wäre jetz sicherlich noch ein guter Punkt zum 
Einsteigen. Mit dir wären wir 5, ich denke das is ne gute Zahl 

Also dann registrier dich mal in unserem Forum:

http://ehm.homelinux.org/jforum/forums/list.page

Und Homer65 wird dich dann zu einem internen User machen demnächst.

Willkommen im Team :toll:


----------



## andre111 (9. Jan 2009)

Gut hab ich gemacht


----------



## homer65 (9. Jan 2009)

Ich denke wir könnten sicher noch mehr Projektmitglieder aufnehmen, man muß leider auch damit rechnen, das der ein oder andere auch wieder abspringt  :? . Jeder kann ja zum Projekt beitragen was er will und kann, Hauptsache es macht Spaß.  :lol: Wir sind ja hier nicht auf der Arbeit, sondern machen alle freiwillig mit.


----------



## hdi (9. Jan 2009)

Ja schon klar, aber ich will echt nicht 25 Leute im Projekt, da weiss keiner mehr was der andere tut, die Kommunikation ist viel zu schwer und alles zieht sich. Ich meine wenn jemand abspringt, was soll's. Wir haben ja keine Deadline. 
Lieber ein kleines gemütliches Team, und es dauert länger, als irgendwann ein Chaos.


----------



## andre111 (9. Jan 2009)

Ich denke mal so 5 leute sind in ordnung, ein bis zwei dazu würden auch noch gehen, aber mehr nicht


----------



## manuche (10. Jan 2009)

Solange jeder sein eigenes Aufgabengebiet bekommt ist das Ok! Denke aber mit 5 Mann sind wir gut bestückt...
Vllt sollten wir mal intern aufstellen, wer sich um was kümmern kann! Dann sehen wir ja an welcher Ecke es haken könnte... 
Allerdings denke ich, das wir mit 5 Mann schon sehr gut dabei sind!


----------



## SegFault (10. Jan 2009)

Ich geb auch mal fix meinen Senf dazu. 
Es kommt eigentlich weniger darauf an wie viele Leute im Team arbeiten mehr darauf das es eine Teamarbeit ist. Es ist toll wenn man 5 Spitzenleute zusammen hat. Nicht so toll dagegen wenn dann jeder was vor sich hinprogrammiert. Gerade Softwareentwicklung im Team ist nicht ganz einfach ansonsten wartet jeder auf irgendwelchen Code von jemand anderen der dan hintereinandergereiht das Programm ergibt aber im grunde dann auch von einem alleine geschrieben werden hätte können. 
Ihr solltet euch also nicht nur im klaren werden was ihr Programmieren wollt sondern auch wie. Definiert genaue schnittstellen (UML) 
Leider sind viel zu viele gute Projekte genau an sowas schon gescheitert und das muss nicht sein.


----------



## andre111 (10. Jan 2009)

Kommt sonst noch jemand ins Forum?
ehm.homelinux.org/jforum/forums/list.page
Bei mir schlägt jedes mal die Verbindung fehl.


----------



## homer65 (10. Jan 2009)

andre111 hat gesagt.:
			
		

> Kommt sonst noch jemand ins Forum?
> ehm.homelinux.org/jforum/forums/list.page
> Bei mir schlägt jedes mal die Verbindung fehl.


Da hatt doch jemand den TOMCAT, unter dem das Forum läuft abgeschossen. Hab ihn neu gestartet.
Hmh, kaum ist der eigene Server bekannter, schon hatt man Hacker da  :wink:


----------



## hdi (10. Jan 2009)

Ich war's nich


----------



## hdi (12. Jan 2009)

@homer

ich hab ein problem ich hatte formatiert und weiss mein pw nicht mehr für das forum. 
wollte mir das pw an meine mail senden lassen aber scheinbar ist der server überlastet,
zumindest ist nix gekommen (auch nix im spam).

Hast du irgendwie eine möglichkeit mein pw zu resetten oder so?


----------



## Saxony (13. Jan 2009)

Hiho,

habe gerade folgendes in dem Forum zu MyRisiko gelesen:



			
				hdi hat gesagt.:
			
		

> Naja wie man formatiert ist eig. jedem selbst überlassen, denn jede GUI bietet eig. eine Tastenkombination für Quickformat an,
> und dann passt sich der code deinen eigenen einstellungen an.



So egal ist das aber nicht. Wenn ich code auschecke den um ihn besser lesen zu können auf meine Formatierungsregeln quickformatiere, dann ergibt sich das Problem, dass es sich um eine neue Version dieser Datei handelt und rein theoretisch wieder ausgecheckt werden müsste. 

Oder wollt ihr komplett ohne Versionierungssystem arbeiten und euch den Code als zips zumailen. 

bye Saoxny


----------



## hdi (13. Jan 2009)

Nein das ist kein Problem.
Es ist wurscht ob 2 Leute seit Wochen auf "unterschiedlcihen" Versionen arbeiten, sobald einer
Commitet ist das halt die neue Version, und wenn einer auscheckt ist die Datei identisch zu der eigenen Version,
weil man da nix mergen muss. Es geht nur um die Syntax, völlig egal wie der Code formatiert ist.


----------



## Saxony (13. Jan 2009)

Ja dann habe ich aber immer 3249873942 Java Files rumliegen, welche er jedes mal mit als auscheck würdig markiert, weil ich diese auf meine Formatierung umgestellt habe. Das würde mich nerven. Und dann muss ich anfangen jede von mir neu formatierte Datei aus dem auscheckvorgang auszuklammern bis ich sie nach einer "echten" Änderung wieder hinzufügen muss.

Viel Spass! 

bye Saxony


----------



## hdi (13. Jan 2009)

Hä? Du machst ein Checkout und checkst einfach alles aus.
Es wird keine Konflikte geben, auch wenn Datei X bei dir lokal anders formatiert ist als die Version
dieser Datei, die du grad auscheckst. Weil der Inhalt der gleiche ist.

Es wird einfach geupdatet, du musst höchstens nach jedem Checkout die Quickformatierung machen.
Du hast immer nur genau so viele Dateien, wie es im Repository gibt. Alles kein Problem


----------



## Guest (14. Jan 2009)

hdi hat gesagt.:
			
		

> Hä? Du machst ein Checkout und checkst einfach alles aus.
> Es wird keine Konflikte geben, auch wenn Datei X bei dir lokal anders formatiert ist als die Version
> dieser Datei, die du grad auscheckst. Weil der Inhalt der gleiche ist.



Das ist schon klar, aber es geht ja um folgendes:

Ich hole mir die Sourcen ausm CVS und formatiere die um sie besser lesen zu können. Nun gibt es zwei Varianten welche alle beide Mist sind:

1. Bei einem Checkout schicke ich die formatierten Dateien mit, da sie sich für das Versionierungssystem geändert haben. Das hat den Nachteil, dass zwei Entwickler welche ständig den Code mit underschiedlichen Formatierungen lesen, die Versionsnummer der Datei hochschrauben. Auch wenn der Inhalt immer der gleiche ist. Aber alleine die Tatsache ob die öffnende Klammer "{" nach der Methodensignatur steht oder darunter ist schon eine Änderung im CVS, welche "gepflegt" werden muss.

2. Ich lade mir Sourcen runter, welche ich lesen will und formatiere diese. Dann wird bei einem Checkout diese auch als geänderte Datei mit aufgeführt. Lese ich mich in ein Projekt ein und formatiere somit 100 Klassen arbeite selber aber nur an einer, dann muss ich beim nächsten checkout trotzdem 101 Klassen auschecken. Ich muss dann im diesem Fall um die Versionierung nicht hochzutreiben ohne Änderung diese 100 Dateien manuell aus dem checkout-Vorgang ausklammern. Ändere ich eine von 100 Dateien außer der Formatierung muss ich diese wieder manuell dem checkout-Prozess zuführen.

3. und beste Lösung -> Code Conventions

bye Saxony


----------



## Saxony (14. Jan 2009)

Noch eine Anmerkung zu Variante 1:

Ändere ich eine Datei um sie besser lesen zu können und checke diese dann aus. Dann ist nicht nur der Nachteil vorhanden, dass ich die Versionsnummer dieser Datei ohne Änderung um eins erhöht habe, sondern jeder andere Entwickler lädt bei einem sync die von mir formatierte Datei neu, da sie ja "geändert" wurde. Dieser Entwickler formtiert diese wieder um und das Spiel beginnt von vorne. Am Ende bin ich bei Version 34989443 für ein Interface, welches seit Projektbeginn eigentlich unverändert existiert.

So eine Fall hatte ich schon. Dann haben wir uns daruf geeinigt, dass jeder Entwickler in Eclipse ein ctrl+shift+f* und dann ctrl+s macht vorm einchecken und die Probleme waren beseitigt.

bye Saxony

*Voraussetzung: Jeder verwendet das gleiche Quickformat Template.


----------



## manuche (14. Jan 2009)

Da habt ihr durchaus Recht, dass die Versionsnummer unnötig hochgetrieben wird! 
Allerdings ist doch der SVN-Server für die Versionsnummern und deren Verwaltung zuständig oder sehe ich das falsch?
Meiner Meinung nach greift das Formatierungstemplate immer nur beim Build einer Source. Das heisst, bevor die Formattierung geändert wird, wurde eh was an der Source geändert.
Hinzu kommt, dass man bei Subclipse generell nur hinzugefügte oder geänderte Sourcen hochläd und zur Not auch auch noch welche abwählen kann!


----------



## Saxony (14. Jan 2009)

manuche hat gesagt.:
			
		

> Allerdings ist doch der SVN-Server für die Versionsnummern und deren Verwaltung zuständig oder sehe ich das falsch?



Richtig! Dadurch wird ja die Versionsnummer einer Datei permanent hochgetrieben, obwohl sich nur das Format ändert.



			
				manuche hat gesagt.:
			
		

> Meiner Meinung nach greift das Formatierungstemplate immer nur beim Build einer Source. Das heisst, bevor die Formattierung geändert wird, wurde eh was an der Source geändert.



Das ist falsch. Ein Build produziert .class Dateien, welche normalerweise nicht mit eingecheckt werden. Hat sich der Inhalt (dazu gehört auch das Format) der .java nicht geändert werden diese auch nicht mit eingecheckt. Wäre es so wie du schreibst, müsste man bei jedem einchecken alle Klassen transferieren - vor allem bei aktiviertem auto-build.



			
				manuche hat gesagt.:
			
		

> Hinzu kommt, dass man bei Subclipse generell nur hinzugefügte oder geänderte Sourcen hochläd und zur Not auch auch noch welche abwählen kann!



Ja und das ist das Problem, welches ich unter 2. ansprach, da Quickformat eine geänderte Source generiert.

bye Saxony


----------



## Saxony (14. Jan 2009)

Nochmal ich,

ich darf leider keine Beiträge in eurem Forum schreiben und Registrieren funzt auch net.



			
				manuche hat gesagt.:
			
		

> Mal ne Frage... Zwar wird das nicht viel mit unserem Projekt zu tun haben allerdings wäre es immer gut es zu wissen!
> Und zwar würde ich mir gerne mal die Implementationen der Klassen aus der Standardbibliothek von Sun ansehen...
> Wenn ich in eclipse mit gedrückter Strg-Taste auf einen Klassennamen klicke öffnet sich ja die dazugehörige Source.



In Eclipse gehst du einfach im Projektbaum auf die jar mit rechtsklick und dann hast du die Möglichkeit Java Source und Java Doc hierzu auszuwählen.

bye Saxony


----------



## homer65 (14. Jan 2009)

Saxony hat gesagt.:
			
		

> Nochmal ich,
> ich darf leider keine Beiträge in eurem Forum schreiben und Registrieren funzt auch net.


Sollte aber doch, kommen irgendwelche Fehlermeldungen? Oder was funktioniert genau nicht?


----------



## Saxony (14. Jan 2009)

Also wenn ich als Gast zu dem Thema Java Sourcen im Subforum Sonstiges auf Antwort erstellen klicke, dann kommt das Fenster zum einloggen. Das scheint aber nur dort der Fall zu sein, da ich bei Code Schnipsel beispielsweise sogar Themen eröffnen kann.

Möchte ich mich registrieren, dann klicke ich auf den "Ich bin mit den Bendingungen einverstanden"-Button und es lädt wieder die Seite mit den Registrierungsbedingungen, wo ich wieder den Button drücken kann usw. usf. 

bye Saxony


----------



## homer65 (14. Jan 2009)

Saxony hat gesagt.:
			
		

> Also wenn ich als Gast zu dem Thema Java Sourcen im Subforum Sonstiges auf Antwort erstellen klicke, dann kommt das Fenster zum einloggen. Das scheint aber nur dort der Fall zu sein, da ich bei Code Schnipsel beispielsweise sogar Themen eröffnen kann.


Es ist gewollt, das nur registrierte Benutzer Beiträge schreiben dürfen. Muß mal gucken, warum bei Code Schnipsel auch Gäste schreiben dürfen. Das ist nicht gewünscht.



			
				Saxony hat gesagt.:
			
		

> Möchte ich mich registrieren, dann klicke ich auf den "Ich bin mit den Bendingungen einverstanden"-Button und es lädt wieder die Seite mit den Registrierungsbedingungen, wo ich wieder den Button drücken kann usw. usf.
> 
> bye Saxony


Bei mir klappt das Registrieren problemlos. Ich vermute es liegt an deinen Browser Einstellungen. Sowas, wie man darf keine Cookies erstellen oder ähnliches.[/quote]


----------



## Saxony (14. Jan 2009)

Na Super nun bin ich registriert darf aber nur noch lesen!


----------



## manuche (14. Jan 2009)

Also nochmal zum SVN...
Bei mir ändert sich das Format NUR wenn ich auch was an der Quelle gemacht habe un diese abspeichere! 
Sprich die Versionsnummer müsste eh hochgezählt werden.
Da wir alle eine aktuelle Version von eclipse benutzen sollte es also ziemlich ähnlich vom Verhalten sein... Ist also kein Problem für uns bzw unser Repos! 

Und danke für die Hilfe bezüglich der Originalsourcen!


----------



## homer65 (14. Jan 2009)

Saxony hat gesagt.:
			
		

> Na Super nun bin ich registriert darf aber nur noch lesen!


Muß wohl noch ein wenig an den Einstellungen feilen. Als registrierter User solltest du schon schreiben dürfen. Sorry, werde versuchen das zu korrekieren.


----------



## Saxony (14. Jan 2009)

manuche hat gesagt.:
			
		

> Bei mir ändert sich das Format NUR wenn ich auch was an der Quelle gemacht habe un diese abspeichere!



Und wenn ich das Format ändere um besser lesen zu können ohne das ich etwas an dem Code selber ändern will?

Dann darf ich nicht speichern und muss bei jedem Lesen neu formatieren oder ich speicher und es wird bei jedem einchecken als Änderung erkannt.

bye Saxony

Forum: Ich darf nun als reg-user schreiben!


----------



## Developer_X (6. Jun 2009)

hi, also wenn ich dürfte
würd ich gern mitmachen, 
könnt ihr mir hier bescheid geben obs klappt?


----------



## LordLuzifer (7. Jun 2009)

Nichtmal mehr das Forum dazu existiert, der Sache ist dann recht schnell die Luft ausgegangen.


----------



## Developer_X (7. Jun 2009)

ah ok


----------

