Post by Stefan Matthias AustDas erschien mir die einfachste Lösung als mir auffiel, dass ich sowohl
von einem Feld die Figur als auch von einer Figur ihr Feld wissen wollte.
Meine Klassendefinition möchte ich als eine Art textuelles UML
verstanden wissen und damit möchte ich einzig die Relationen zwischen
den Objekten bezeichnen.
ja, dann ist das ok, denn das bedeutet ja, daß du es nicht unbedingt auch
doppelt speichern willst, da man die eine oder andere Stelle gerne vergisst
upzudaten, wenn etwas redundant ist.
Post by Stefan Matthias AustEmpfinde ich als "over engineered". So böse ist Vererbung nun auch
nicht, dass man sie hier nicht für ein spezielles Feld - eben eines, bei
dem die Figuren eines bestimmten Spielers abzweigen und die anderen
Figuren vorbeilaufen - definieren könnte.
YAGNI
vielleicht hast du recht. Nach der reinen XP-Lehre müsste man sowieso erst
die JUnit-Testfälle schreiben und es käme dann mit Sicherheit noch eine
ganz andere Lösung dabei heraus :-)
Post by Stefan Matthias AustPost by Frank BussFürs GUI später wäre es wahrscheinlich noch sinnvoll, wenn man auch die
Depot-Felder, bei denen am Anfang die 4 Steine stehen, genauso behandelt
Hatte ich auch kurz drüber nachgedacht, fand aber keinen Grund dafür.
Im reinen Modell reicht es mir, wenn ein Spieler die Figuren kennt.
Figuren, die nicht auf dem Feld (dem "Ring") stehen, müssen offenbar im
Depot sein.
ich hatte überlegt, eine 1-1 Beziehung zwischen der logischen Field-Klasse
und der GUI-Field-Klasse aufzubauen, das würde das ganze wahrscheinlich
vereinheitlichen, da man dann keinen besonderen Code für die Figuren im
Depot zu schreiben braucht.
Post by Stefan Matthias AustPost by Frank Bussclass Field {
Player piece;
Du meinst hier "Piece piece", oder?
nö, mein Gedanke war dabei, daß überall dort, wo das piece-Feld den Wert
des jeweiligen Player-Objekts hat, auch ein Stein dieses Players implizit
steht :-)
Post by Stefan Matthias AustWarum hat jedes Feld einen Owner bei dir? Das Feld (ich meine, den
"member") ist doch dann fast immer "null", da fast alle - bis auf 4 -
Felder besitzerlos sind.
im allgemeinen gebe ich dir recht, aber mit dem Type-Konzept...
Post by Stefan Matthias AustPost by Frank Bussclass Type {
Field getNextField(Field parent, Player currentPlayer);
}
Und die Felder stehen - wenn ich noch weiter kritisieren darf - nicht in
einer parent-child-relation, sodass ich hier previous (als Gegenstück
zum "next") oder "predecessor" benutzen würde, auch wenn parent laut
dict.leo.org ebenfalls Vorgänger und nicht nur Elt (Singular von Eltern)
heißt.
... sieht das anders aus. Mit "parent" meinte ich hier den Container, der
das jeweilige Type-Objekt beinhaltet und dachte, mir analog zur
GUI-Programmierung, nenne ich das parent. Jedes Feld hat ein Type-Objekt,
wobei sich aber mehrere Felder dasselbe Type-Objekt teilen können. Wenn
dann z.B. getNextField vom Type-Objekt aufgerufen wird, dann kann das den
jeweils aktuellen Container nach Zusatzinformation befragen, daher die
Bezeichnung "parent". Je nach Typ muß aber auch der owner abgefragt werden.
Der JunctionType z.B. würde den parent nach dem owner und dem currentPlayer
befragen und entsprechend die eine oder andere Abzweigung wählen. Gerade
beim JunctionType lohnt sich das allerdings nicht, da man den Typ nur dort
zu speichern braucht, war also wieder mal YAGNI, für zukünftige Spiele :-)
Post by Stefan Matthias AustPost by Frank Bussclass Board {
LinkedList<Field> fieldGroups;
}
Wozu brauchst du dies? ich hatte da kurz drüber nachgedacht, dann aber
festgestellt, dass es reicht, die Spieler zu kennen, die ja dann die
Felder referenzieren. Eine extra Liste aller Felder sah ich nicht als
notwendig an.
wieder YAGNI, da es Spiele geben könnte, bei denen es auch andere isolierte
Gruppen gibt, zu denen man beamen kann und die sonst keine direkte
Verbindung zu den Spielern oder anderen Feldern haben.
Post by Stefan Matthias AustIst es nicht so, dass Sony eigentlich gar keine andere Software auf der
PSP haben will, und nur "dank" Fehlern in der Betriebssystemsoftware es
überhaupt möglich ist, da eigene Anwendungen einzuschummeln - gerade mal
so lange wie Sony braucht, eine neue Firmware-Version zu releasen, die
dann diese Lücke schließt?
Sony interessiert es nicht, wenn andere Software auf der PSP als die
offizielle läuft, solange es nicht den Umsatz mit Spielen schmälert (also
keine Programme, mit denen man illegal beschaffte UMD-Images vom Memory
Stick starten kann). Schon zu PS2- und PS1-Zeiten verkaufte Sony sogar ein,
im Vergleich zu dem professionellen Entwicklerpaket, recht preiswertes
Linux-Kit, um eigene Programme darauf zu entwickeln (um die 200 Euro).
Post by Stefan Matthias AustSollte das stimmen, würde ich ja auch nicht noch Sony indirekt
unterstützen, indem ich deren Hardware "cooler" mache, sondern ihnen
etwas sagen, das ich hier nicht aufschreiben möchte und mir ein Ziel
suchen, wo die Arbeit der Community auch honoriert wird.
ich entwickle auf der PSP nur hobbymäßig und weil es Spaß macht, da die
Hardware eben einfach cool ist. Was irgendeine Community daraus dann macht,
ist zwar schön, aber interessiert mich nicht hauptsächlich.
Post by Stefan Matthias AustAnsonsten aber viel Erfolg beim Vortrag :)
danke. Ist jetzt fast fertig, der andere Redner verschönert die Folien noch
etwas, da er den Hauptteil vorträgt. Ich werde in der 2. Hälfte des
Vortages eine Live-Demonstration geben und 4-Gewinnt implementieren, da
müssten meine Sprachkenntnisse auch noch ausreichen, da es dabei
hauptsächlich technisches Englisch ist.
Post by Stefan Matthias AustUnd warum eigentlich kein Java? Die PSP-Hardware ist doch im Bereich
der üblichen Handys, deren J2ME-Interpreter auch spieletauglich sind.
die Hardware ist bedeutent besser, als die üblichen Handys. Da ich gerade
die Folie offen habe: zwei MIPS 4K CPU Kerne (mit speziellen
Vectorprozessor-Erweiterungen, die zur Zeit noch in der Homebrew-Szene per
Reverse-Engineering erforscht werden) mit bis zu 333 MHz taktbar (220 MHz
Default), ein zusätzlicher grafischer Coprozessor, der 33 Millionen flat
shaded polygone pro Sekunde und 664 Millionen Pixel pro Sekunde auf das
gestochen scharfe 480x272 Pixel TFT bringt und NURBS, Morphing etc. per
Hardware unterstützt, das ganze mit 32 MB Hauptspeicher, 2 MB embedded VRAM
und bis zu mehreren GB großen Memory Sticks, Wi-Fi, USB und seriellem Port
(mit etwas basteln: http://www.luaplayer.org/sio/readme.html ). Da könnte
man vielleicht auch eine Standard Java Distribution drauf portieren (32 MB
RAM könnte etwas knapp werden).
--
Frank Buß, ***@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de