KI-Pool

Moderator: Digitale Spiele

Soll es einen KI-Pool geben?

Umfrage endete am 3. Jun 2007 17:43

Ja, open source & für alle
3
50%
Ja, open source & nur für die die beitragen
2
33%
Ja, closed source & für alle
0
Keine Stimmen
Ja, cloesd source & nur für die die beitragen
1
17%
nein
0
Keine Stimmen
 
Abstimmungen insgesamt: 6

Nando
Erstie
Erstie
Beiträge: 11
Registriert: 6. Apr 2005 16:35

KI-Pool

Beitrag von Nando » 20. Mai 2007 17:43

Hallo!

Nachdem auch andere die idee KI's für jostle auszutauschen hatten mache ich hier mal die umfrage.

Unsere Gruppe hat sich für Java entschieden. Ich vermute mal die meißten werden auch java benutzen, der code sollte sich ja mit geringem aufwand für C/C++ abändern lassen. Und damit wären wohl die wichtigsten sprachen abgedeckt.

Unser Design (plan) sieht ein KI-modul vor das vom spiel aufgerufen wird (pro zug) und sich aus der "spiel-logik" diverser informationen bedient. Dieses Interface soll definiert werden, aber die spiellogik bei jeder gruppe selbst verbleiben. Die methoden die für hochewertige ki's benötigt werden müsste dann jede gruppe selbst programmieren (z.b. eine methode die angibt um wieviel felder einen ein gewisser zug nach vorne bringt).

ich hoffe mal wir kommen da soweit überein das viele gruppen teilnehmen können. eine genauere spezifikation unseres interface-vorschlags kommt wenn wir sehen das unser ansatz praktikabel ist.

nando

Nando
Erstie
Erstie
Beiträge: 11
Registriert: 6. Apr 2005 16:35

Beitrag von Nando » 22. Mai 2007 01:33

Also, manche haben sich gefragt ob dem herrn prof das so recht ist, all diese zusammenarbeit. ich hab ihn gefragt:

> Hallo!
> >
> >Wir und ein paar andere gruppen hatten die idee (ganz im sinne der
> >forschung :) ki's auszutauschen. Ich habe dazu einen foreneintrag im
> >fachschaftsforum gemacht. Wenn ihnen die zusammenarbeit auf diese weise
> >zu weit geht sagen sie bitte bescheid.
> >
> >http://www.fachschaft.informatik.tu-dar ... php?t=8859
> >
> > nando fuchs


Den Smiley kriegen Sie zurueck ... :) ... Wenn meine Lehrveranstaltung
bewirkt, dass Studierende an der TU Darmstadt miteinander diskutieren,
wenn das sogar noch interdisziplinaer, mit Studis unterschiedlicher
Studiengaenge, passiert, und wenn am Ende Ergebnisse rauskommen,
die davon profitieren, ... ;-) ... dann werde ich behaupten,
dass das von Anfang an so geplant war und nur im Ergebnis
genialer didaktischer Tricks meinerseits funktionieren
konnte.


Also los ...!


j.

Benutzeravatar
Robert
Ehemalige Fachschaftler
Beiträge: 511
Registriert: 6. Okt 2004 17:38
Wohnort: DA

Beitrag von Robert » 22. Mai 2007 15:45

Hi,

ich finde die Idee gut, würde da auch gerne mitmachen.

Wichtig wäre schnell ein Interface dafür zu haben, damit man nicht zuviel in unterschiedliche Richtungen arbeitet.

Des weiteren bin ich für den Punkt 2 der Abstimmung ... wer mitmacht sollte auch ruhig die KIs der anderen sehen können ... da ich Prof. Jantke eh so verstanden habe da es ihm mehr um ein Tool geht das analysen erlaubt ... somit wären die KIs kein Kernelement des Progs.

Der Vorteil deines Vorschlages liegt auf der Hand .. wenn nur 3 Gruppen mitmachen und jede Schreibt 3 KIs hat man schon 10 KIs zum rumspielen ... und bei OpenSource KIs wird wohl jede Gruppe sich Anregungen von den Anderen holen und diese verändern (und potenziell auch verbessern)

Nando
Erstie
Erstie
Beiträge: 11
Registriert: 6. Apr 2005 16:35

Beitrag von Nando » 22. Mai 2007 19:31

das interface für die ki steht kurz vor einem verbindlichen vorschlag
nachtrag: ich stell vielleicht heute noch nen ersten vorschlag rein

Nando
Erstie
Erstie
Beiträge: 11
Registriert: 6. Apr 2005 16:35

hier die erste version

Beitrag von Nando » 28. Mai 2007 18:45

Wo wir was implementiert haben was nicht unbedingt freigegeben werden sollte steht "// querty:".
Sorry das die einrückungen verschwunden sind, das liegt am forum.

Die Klassen:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Stone:

public class Stone {
private int field, stoneNr;
private Player parent;

public Stone(Player parent, int nr) {
this.parent = parent;
stoneNr = nr;
field = -1;
}

public int getNr() {
return stoneNr;
}

public int getPlayerNr() {
return parent.getNr();
}

public int getField() {
return field;
}

public void setField(int f) {
field = f;
}
}


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Player:

public abstract class Player {
private int playerNr;
private String name;
private Stone s1, s2, s3;

public Player(String name, int nr) {
playerNr = nr;
this.name = name;
s1 = new Stone(this, 1);
s2 = new Stone(this, 2);
s3 = new Stone(this, 3);
}

abstract void makeMove(int wurf);

public int getNr() {
return playerNr;
}

public String getName() {
return name;
}

public Stone getStone(int nr) {
if(nr == 1) return s1;
if(nr == 2) return s2;
if(nr == 3) return s3;

return null;
}

public int getField(int stoneNr) {
if(stoneNr == 1) {
return s1.getField();
}
if(stoneNr == 2) {
return s2.getField();
}
if(stoneNr == 3) {
return s3.getField();
}
return -1;
}

public void setField(int fieldNr, int stoneNr) {
if(stoneNr == 1) {
s1.setField(fieldNr);
}
if(stoneNr == 2) {
s2.setField(fieldNr);
}
if(stoneNr == 3) {
s3.setField(fieldNr);
}
}

public int getScore() {
int score = 0;
// querty: punktezahlen berechnen
return score;
}
}

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
KI:

public class KI extends Player {
private Logik myLogik;
private int aktWurf;

public KI(Jostle myGame, Logik myLogik, String name, int nr) {
super(name, nr);
this.myLogik = myLogik;
aktWurf = -1;
}

public int randomStone() {
// querty: return zahl zwischen 1 und 3, kommt vielleicht noch raus -> logik
}

public void makeMove(int wurf) { // ob dieser int wirklich übergeben wird steht noch nciht fest, vielleicht eher mit nem getter von der logik bei bedarf holen
// querty: hier überlegen welcher Stein gezogen wird
/* beispiel: if(myLogik.moveStone(this, stone) == -1) {
Fehler, dieser stein kann nicht gezogen werden!
}*/
}

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Logik:

public class Logik {
private Stone[] felder;
private int aktWurf;
private KI dummy;

public Logik(Jostle myGame) {
felder = new Stone[32];
aktWurf = -1;
dummy = new KI(myGame, this, "dummy", 4);

for(int i = 0; i < 32; i++) {
felder = null;
}
}

public void setWurf(int wurf) {
aktWurf = wurf;
}

public int moveStone(Player player, int stoneNr) {
// querty: hier werden die stones bewegt die in einem zug verschoben werden
// 0 bedeutet, keine Probleme
return 0;
}

public void jostling(int jostleField) {
// querty: bei uns ausgelagert von moveStone, braucht ihr aber nicht
}

public int event(int neuesFeld) {
// querty: die eventfelder. wie oben: braucht ihr nicht so zu machen
return neuesFeld;
}

public boolean checkEnd() {
if(felder[31] != null && felder[30] != null &&
felder[29] != null && felder[28] != null &&
felder[27] != null) { return true; }
return false;
}
}

Benutzeravatar
Robert
Ehemalige Fachschaftler
Beiträge: 511
Registriert: 6. Okt 2004 17:38
Wohnort: DA

Beitrag von Robert » 29. Mai 2007 12:06

find ich nicht so toll den Vorschlag .. da fehlen klare Interfaces und vorallem ist die Spiellogik komisch über die einzelnen Klassen verteilt.

Ich arbeite grad an einem Gegenvorschlag ausgehend von eueren Ideen.

Nexus
Windoof-User
Windoof-User
Beiträge: 26
Registriert: 19. Jan 2005 13:10

Beitrag von Nexus » 3. Jun 2007 08:54

Bin in der Gruppe vom Threadersteller. Unsere Spiellogik ist nicht über viele Klassen verteilt wie du vll denkst.

Essentiell ist unser Ansatz folgendermaßen:

Klasse Jostle:
- initialisiert das Spiel
- steuert den Spielfluss (nächsten Zug starten, auf Spielende prüfen etc.)

Klasse Player (im Beispiel KI extends Player)
- überlegt anhand von Informationen die ausschließlich den ersten Wurf beinhalten (Wenn eine 6 gewürfelt wird darf man nochmal würfeln. Die KI muss die Entscheidung über den Spielstein aber vor dem zweiten Wurf treffen und hat nach der Entscheidung keinen Einfluss mehr auf den weiteren Zugverlauf) welcher Stein gezogen werden soll und teilt dies der Logik mit

Klasse Logik
- berechnet den Zustand des Spielbretts wenn ein Zug getätigt wird.
- meldet Jostle wenn der aktuelle Spieler seinen Zug beendet hat
- bietet Methoden an, um Informationen über das Spielbrett zu gewinnen (nötig für bessere KI Überlegungen)



Mit diesen 3 Grundlegenden Klassen haben wir nun einen Kreislauf, indem Informationen und Aufgaben strikt getrennt sind. Beispiel:

Jostle initialisiert Spiel -> Jostle meldet Spieler 1, dass er am Zug ist -> Spieler 1 (KI) meldet Logik, dass Stein 2 gezogen werden soll -> Logik berechnet den aktuellen Zug und aktualisiert das Spielbrett -> Logik meldet Jostle, dass der Zug beendet ist -> Jostle meldet Spieler 2, dass er am Zug ist -> [...]

Tillmann
BASIC-Programmierer
BASIC-Programmierer
Beiträge: 131
Registriert: 5. Dez 2003 21:27
Wohnort: Frankfurt

Re: hier die erste version

Beitrag von Tillmann » 3. Jun 2007 13:37

arschmeister hat geschrieben:Sorry das die einrückungen verschwunden sind, das liegt am forum.
Benutze BBCode.

Benutzeravatar
Robert
Ehemalige Fachschaftler
Beiträge: 511
Registriert: 6. Okt 2004 17:38
Wohnort: DA

Beitrag von Robert » 9. Jun 2007 17:48

Also unser Vorschlag zum ganzen sieht so aus:

Interface für die Spielsteine. Darauf bauen viele Sachen auf. Funktionen die es erlauben den Spielstein zu verändern sind absichtlich nicht teil des Interfaces, da ein Spieler einen Spielstein nicht ändern sollte.

Code: Alles auswählen

package jostle;

/**
 * Representiert einen Spielstein.
 * 
 * @author Robert
 * 
 */
public interface IPiece {
	/**
	 * @return den Besitzer des Spielsteins.
	 */
	IPlayer player();

	/**
	 * Liefert die Position des Spielsteins. Hierbei sind werte zwischen
	 * (inklusive) 0 und 32 möglich. Ein Spielstein mit der Position 0 befindet
	 * sich noch nicht auf dem Spielbrett.
	 * 
	 * @return die Position des Spielsteins.
	 */
	int position();

	/**
	 * Liefert eine für jeden Spielstein eindeutige id. Es wird nicht verlangt
	 * das die ids der Spielsteine irgend eine Ordnung besitzen.
	 * 
	 * @return id des Spielsteins.
	 */
	int id();
}

Interfaces welches von jedem Spieler implementiert werden muss. Hat die nötigsten Funktionen die so gebraucht werden um einen Spieler zu erstellen und Ihn in das Spiel einzubinden.

Code: Alles auswählen

package jostle;

import java.util.List;

/**
 * Stellt einen Spieler dar.
 * 
 * @author Robert
 */
public interface IPlayer {
	/**
	 * Funktion welche vom Spiel aufgerufen wird und dem Spieler mitteilt das er
	 * an der Reihe ist und er einen Spielzug machen soll.
	 * 
	 * @param dice
	 *            Die Augenzahel des Würfels um welche der Spieler ziehen muss.
	 */
	void makeMove(int dice);

	/**
	 * Der Name des Spielers. Bei Menschlichen Spielern wird der Name wohl über
	 * den Konstruktor oder ähnliches gesetzt. KIs sollten am besten von Haus
	 * aus einen Namen tragen welcher sie repräsentiert. (z.B. "RandomKI").
	 * 
	 * @return Name des Spielers.
	 */
	String name();

	/**
	 * Die id wird mit Hilfe der <i>setId</i> Funktion gesetzt. Der Spieler
	 * bestimmt also nicht selbst was seine Id ist und darf diese auch nicht
	 * ändern. Es ist auch nicht Aufgabe des Spielers dafür zu sorgen das seine
	 * Id eindeutig ist.
	 * 
	 * @return eine Id welche jeden Spieler eindeutig identifiziert.
	 */
	int id();

	/**
	 * Erlaubt das Setzen der Spieler Id.
	 * 
	 * @param id
	 *            die neue Id dieses Spielers.
	 */
	void setId(int id);

	/**
	 * Teilt dem Spier das Spiel mit an dem er teilnimmt. So kann er alle
	 * Informationen über das Spiel erhalten.
	 * 
	 * @param game
	 *            das Spiel an dem der Spieler teilnimmt.
	 */
	void setGame(IJostleGame game);

	/**
	 * @param piece
	 *            Fügt dem Spieler einen weiteren Spielstein hinzu. Dies dient
	 *            dazu das der Spieler seine Spielsteine kennt. Er kann dann
	 *            auch einfach direkt über die <i>position</i> Funktion der
	 *            Spielsteine deren Position feststellen.
	 */
	void addPiece(IPiece piece);

	/**
	 * @return Eine Liste der Steine welche diesem Spieler gehören.
	 */
	List<IPiece> pieces();

}
Das Interface repräsentiert das Spiel und liefert alle Informationen die man braucht um den aktuellen Status des Spieles festzustellen und anhand dessen eine Entscheidung zu treffen über den nächsten Zug.

Code: Alles auswählen

package jostle;

import java.util.List;
import java.util.Map;

import jostle.exceptions.DuplicatePlayerException;
import jostle.exceptions.NotEnoughPlayersException;
import jostle.exceptions.TooManyPlayersException;
import jostle.exceptions.WrongMoveException;
import jostle.exceptions.WrongPhaseException;
import jostle.exceptions.WrongPieceCountException;

/**
 * Das Interface zur Spiellogik von Jostle. Das Interface unterteilt sich in
 * vier Gruppen von Funktionen welche sich logisch an dem Grundaufbau des
 * Spieles orientieren. <br>
 * <li> Pre-game - Funktionen welche vor Begin des Spiels benutzt werden können
 * und sollen. Hierzu zählt auch die beginGame() Funktion. <br>
 * <li> In-game - Funktionen welche während des Spiels benutzt werden. <br>
 * <li> Post-same - Funktionen welche ausschließlich nach dem Ende des Spieles
 * zur verfügung stehen. <br>
 * Wird während einer Phase des Spiels eine Funktion verwendet welche nicht
 * dieser Phase angehört führt dies zu einer Exception.
 * <li> Außerdem gibt es Funktionen welche immer aufgerufen werden dürfen, da
 * diese in keinem Konflikt mit der aktuellen Phase des Spiels stehen. Ein
 * Beispiel für eine solche Funktion ist die <i>piecesPerPlayer</i> Funktion.
 * 
 * 
 * @author Robert
 * 
 */
public interface IJostleGame {
	// ///////////////////////////////////////////////////////////////
	// Pre-game //////////////////////////////////////////////////////
	// ///////////////////////////////////////////////////////////////

	/**
	 * <i>pre-game Funktion</i><br>
	 * Fügt einen weiteren Spieler zum Spiel hinzu.
	 * 
	 * @param player
	 *            Instanz eines Spielers welcher am Spiel teilnehmen soll.
	 * @throws TooManyPlayersException
	 *             Falls schon soviele Spieler am Spiel teilnehmen das ein
	 *             weiterer Spieler nicht aufgenommen werden kann.
	 * @throws DuplicatePlayerException
	 *             wird geworfen falls versucht wird ein und den selben Spieler
	 *             mehrmals in das Spiel einzufügen.
	 * @throws WrongPhaseException
	 *             wird geworfen falls die Funktion in der falschen Phase
	 *             verwendet wird.
	 */
	void addPlayer(IPlayer player) throws TooManyPlayersException,
			DuplicatePlayerException, WrongPhaseException;

	/**
	 * Legt die Anzahl der Spielsteine pro Spieler Fest.
	 * 
	 * @param count
	 *            Anzahl der Spielsteine pro Spieler.
	 * @throws WrongPieceCountException
	 *             Falls ein Wert kleiner 1 eingegeben wird oder ein zu großer
	 *             Wert (hängt von der Anzahl der Spieler ab)
	 * @throws WrongPhaseException
	 *             wird geworfen falls die Funktion in der falschen Phase
	 *             verwendet wird.
	 */
	void setPiecesPerPlayer(int count) throws WrongPieceCountException,
			WrongPhaseException;;

	/**
	 * Startet das Spiel und beendet somit die Pre-game Phase.
	 * 
	 * @throws NotEnoughPlayersException
	 *             Es nehmen nicht genügend Spieler am Spiel teil. Ein Begin des
	 *             Spiels ist noch nicht möglich.
	 * 
	 * @throws WrongPhaseException
	 *             wird geworfen falls die Funktion in der falschen Phase
	 *             verwendet wird.
	 */
	void beginGame() throws NotEnoughPlayersException, WrongPhaseException;;

	// ///////////////////////////////////////////////////////////////
	// In-game ///////////////////////////////////////////////////////
	// ///////////////////////////////////////////////////////////////

	/**
	 * Gibt alle Spieler zurück. Die Reihenfolge der Liste stimmt dabei mit der
	 * Zug-Reihenfolge der Spieler überein.
	 * 
	 * @return Liste der Spieler.
	 */
	List<IPlayer> playerList();

	/**
	 * Listet alle Spielsteine auf. Die Reihenfolge der Spielsteine in der Liste
	 * ist nicht festgelegt.
	 * 
	 * @return Liste der Spielsteine.
	 */
	List<IPiece> piecesList();

	/**
	 * Gibt den aktuellen Stand des Spielbretts. Dabei werden die Arrayfelder
	 * von 1 bis 32 benutzt. Das 0 Feld des Arrays wird nicht genutzt - das ist
	 * ein wenig Verschwendung aber es vereinfacht die Sache. Es kann vorkommen
	 * das sich ein Spielstein im 0 Feld befindet, dies ist erlaubt und sollte
	 * ignoriert werden.
	 * 
	 * @return Array welches das Spielfeld repräsentiert.
	 */
	IPiece[] boardStatus();

	/**
	 * bewegt die Spielfigur um die aktuelle Augenzahl des würfels nach vorne.
	 * 
	 * @param piece
	 *            der Spielstein welcher bewegt werden soll.
	 * 
	 * @throws WrongMoveException
	 *             falls die Figur einem anderen Spieler gehört oder aus anderen
	 *             Gründen nicht gezogen werden kann/darf.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	void movePiece(IPiece piece) throws WrongMoveException, WrongPhaseException;

	/**
	 * gibt an welcher spieler gerade an der Reihe ist.
	 * 
	 * @return den Spieler welcher am zug ist.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	IPlayer playerToTurn() throws WrongPhaseException;

	/**
	 * @return die aktuelle Augenzahl des Würfels.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	int diceResult() throws WrongPhaseException;

	/**
	 * @return Die Anzahl der Spieler welche am Spiel Teilnehmen.
	 */
	int numPlayer();

	/**
	 * @return die Anzahl der Steine pro Spieler.
	 */
	int piecesPerPlayer();

	/**
	 * @return ob die Letzte Runde erreicht wurde.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	boolean finalRoundReached() throws WrongPhaseException;

	/**
	 * @return die Liste der Spieler welche noch drankommen bevor das Spiel
	 *         endet. Die Liste enthält nicht den Spieler welcher Aktuell an der
	 *         Reihe ist.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	List<IPlayer> finalRoundRemainingPlayers() throws WrongPhaseException;

	// ///////////////////////////////////////////////////////////////
	// Post-game /////////////////////////////////////////////////////
	// ///////////////////////////////////////////////////////////////

	/**
	 * Liefert das Ergebnis des Spiels. Dabei wird mit jedem Key der Map ein
	 * Integer Objekt assoziiert welches das Ergebnis für den jeweiligen Spieler
	 * darstellt. <br>
	 * Es wird ein Ergebnis für alle am Spiel Teilnehmenden Spieler ausgegeben,
	 * auch wenn das Ergebnis 0 lautet.
	 * 
	 * @return Tabelle der Spieler und ihrer erreichten Punktzahlen.
	 * @throws WrongPhaseException
	 *             die Funktion wurde in der falschen Phase aufgerufen.
	 */
	Map<IPlayer, Integer> scoreTable() throws WrongPhaseException;

}
Hier mal ein kleines Beispiel wie das Starten eines Spieles aussehen könnte:

Code: Alles auswählen

		IJostleGame spiel = new JostleSpiel();
		
		spiel.setPiecesPerPlayer(3);
		
		IPlayer p1 = new RandomKI();
		p1.setId(1);
		IPlayer p2 = new RandomKI();
		p2.setId(2);
		IPlayer p3 = new RandomKI();
		p3.setId(3);
		
		spiel.addPlayer(p1);
		spiel.addPlayer(p2);
		spiel.addPlayer(p3);

		spiel.beginGame();
		
		System.out.println(spiel.scoreTable());
während des Spieles wird dann jeweils die makeMove(...) Funktion der Spieler aufgerufen. Diese entscheiden dann welche Figur sie ziehen möchten und rufen ihrerseits die movePiece(...) Funktion des Spieles auf.

Dies geht so lange bis das Spiel zu ende ist. Sollte ein Spieler nicht ziehen können so wird er auch nicht dazu aufgefordert. Sollte eine 6 gewürfelt werden wird nach dem movePiece(...) Aufruf durch den Spieler automatisch nochmals gewürfelt und die gleiche Figur (falls möglich) nochmals gezogen.


Will man noch eine GUI um das ganze basteln, nutzt man am besten das Observer-Pattern für die Klasse welche IJostleGame implementiert. Ein (oder mehrere) menschlicher Spieler fügt sich auch sehr einfach in das ganze ein. in seiner makeMove(...) Funktion muss er nur auf eine Eingabe durch den Menschen warten und diese dann weiterleiten.
(wie man ein solches Warten realisieren könnte (gibt viele Möglichkeiten) findet sich z.B. hier: http://www.galileocomputing.de/openbook ... Xxx1000058 )


Wir haben außerdem vor den Spielern noch eine abstrakte Klasse geschaltet welche sich um die Verwaltung der Spielsteine usw kümmert, so das unsere eigentlichen Spieler (egal ob KI oder Mensch-Interface) nur noch makeMove(...) und name(...) selbst implementieren müssen.

Es empfiehlt sich außerdem (besonders fürs debuggen) bei allen (Piece, Player, etc) die toString() Funktion zu überschreiben und mit was sinnvollem (wie z.B. der id) zu füllen.


---
Für Vorschläge sind wir offen. Insbesondere bei den Namen der Funktionen sind wir sehr flexibel (dank Eclipse das alles automatisch umbenennen kann)

FlorianB1982
Neuling
Neuling
Beiträge: 1
Registriert: 4. Mär 2005 15:31

Beitrag von FlorianB1982 » 25. Jun 2007 16:16

hey leute....

da sich hier nun ne weile nix mehr getan hat, wollte ich mal nachfragen, wer sich denn jetzt an obige interfaces hält.

ich beginne jetzt auch mit der implementierung von jostle, und währe sehr an nem ki-pool interessiert. wenn ich mich aber an obige interfaces halte, wärs schon gut, wenn das andere auch noch tun und dann auch willens sind, ein wenig ki-tausch zu betreiben....=)
sonst mach ich mir nur arbeit und hab am ende nix davon....;)

also leute, wie siehts aus?

ciao, *flo*!

Nexus
Windoof-User
Windoof-User
Beiträge: 26
Registriert: 19. Jan 2005 13:10

Beitrag von Nexus » 25. Jun 2007 17:32

Ich persönlich denke dass da nichtmehr viel draus wird. Wir sind zumindest mit unserer Implementierung zu weit fortgeschritten. Ich denke nicht dass wir das auf die oben genannten Interfaces so einfach umstellen können. Dafür sollte sich das aber nochmal jmd aus meiner Gruppe anschaun der sich besser mit Interfaces auskennt wie ich ^^

Antworten

Zurück zu „Digitale Spiele / Digital Games“