nicht angemeldet
Hallo Nick,
wir sind ne 7 köpfige Gruppe von Informatik-Studenten, 5tes Semester. Wir haben 7 Wochen Zeit um ein Spiel zu programmieren.
Also zu viele Leute für zu wenig Zeit, das bedeutet weniger eine Herausforderung an Eure Programmierfähigkeiten (vorausgesetzt ihr könnt hinlänglich gut programmieren) als an Eure Organisationsfähigkeiten ;-)
Also erstmal eine minimale Zeitplanung vielleicht:
1 Woche "Spezifikation" bzw. Selbstfindungsphase, was wollt Ihr überhaupt, wie viel könnt Ihr in dieser Zeit umsetzen. Beschränkt Euch auf eine sinnvolle Basisfunktionalität. Diese Woche ist mittlerweile vermutlich sowieso schon fast rum.
2 Woche "Entwurf". Überlegt welche Komponenten ihr braucht, welche Technologien ihr nehmt, versucht den Kram so zu verstehen, dass ihr damit auch arbeiten könnt. (Zu viel neues Zeug wird also nicht gehen, ihr habt ja kaum Zeit zu lernen, wie man damit umgeht.)
3-4/5 Woche Implementierung, überlegt euch, wie ihr dabei vorgeht. Zentrale Teile zuerst, möglichst bald etwas erreichen, was rudimentär tut. (Also nicht einfach mal die guten Leute an der tollen KI tüfteln lassen und die schlechten am Layout und dann gucken, was noch fehlt ;-)
4/5-7 Woche, Testen, Fehler beheben, retten was zu retten ist ;-), Pufferzeit falls ihr Euch irgendwo verschätzt habt.
Das scheint ein großer Teil der Zeit zu sein, aber in nur einer Woche kann man verdammt wenig reparieren, wenn irgendwie alles doch noch nicht so funktioniert, wie man das wollte.
Ein Teil muss auf nem Windows 2003 Server laufen (der Spieleserver) und ein Teil auf dem Client (das Spiel).
Das müsst Ihr genauer klären, wenn es Anforderungen sind. Wenn es keine sind, müsst Ihr es auch klären, aber indem Ihr Euch überlegt, was für euch da am sinnvollsten ist. (Also eher im 2. Schritt)
Es soll möglich sein, später weitere Spiele hinzu zu programmieren.
Welche Arten von Spielen, ihr müsst für einen Entwurf wissen, welche Art von Datenaustausch Ihr zwischen Clients und Server ermöglichen müsst. Dazu braucht Ihr wahrscheinlich eine gewisse vorstellung davon, was ein Spiel so ist.
- Datenbank, speichert aktuelle Spielstände, Benutzerdaten...
Hier ist auch wieder wichtig, wie Spielstände aussehen und welche Informationen man über Spiele sonst noch speichern muss. Je mehr man hier abdecken will, desto flexibler muss dann auch das Design werden.
- Spiele-Server (läuft auf Windows 2003 Server), greift als einzige Anwendung auf die Datenbank zu, nimmt Anfragen von Clients entgegen beispielsweise "geb mir die nächste Karte", bestimmt die Anwort aus der Datenbank und antwortet dem Client
- Spiel 1, kommuniziert mit dem Spiele-Server.
- KI 1, simuliert einen Menschen. Die KI wird nur dann ausgeführt, falls ein Mensch gegen den Computer spielen möchte. Für jedes Spiel das wir programmieren, müssen wir einen separate KI programmieren. Die KI wird auf dem Server ausgeführt. Sie enthält Methoden wie z. B. MakeNextMove()
Das Konzept muss noch genauer werden, vor allem dahin, wie Ihr einzelne Spiel-Sitzungen verwaltet und wie Ihr vom konkreten Spiel und der konkreten KI so abstrahiert, dass das alles ausreichend erweiterbar ist.
Wichtig sind denke ich folgende Punkte:
- versteht Eure Technologie hinreichend gut.
- macht darauf aufbauend ein robustes Konzept für die zentralen Anforderungen.
- implementiert das so schnell wie möglich, damit Ihr seht, ob es tut.
Dass die KI gut funktioniert, man im Client wirklich schön spielen
und der Server was weiß ich noch tun kann, ist erst danach wichtig. Das kann man dann auch sehr gut auf mehre Leute verteilen und zusammenarbeiten, wenn eine robuste Basis steht.
Grüße
Daniel