25. september 2012 - 11:43Der er
4 kommentarer og 1 løsning
overordnet struktur af pokerprogram
Jeg har brug for råd/inspiration til strukturen af en pokerapplet. Det virker fint i sin nuværende form, men det er meget besværligt at fortsætte uden at have en mere fleksibel struktur på programmet. Håber i kan bære over med en lang post.
Som det ser ud nu har det følgende struktur.
hand klassen: Central klasse med et par hjælpeklasser tilknyttet. Holder al information omkring hånden og alle regler for spillet. holder også et spiller array, med spillerne der deltager i hånden.
spiller klassen: Nogle ting er udeligeret til spiller klassen. Den samlede "penge" beholdning for spileren. Om spilleren er menneske eller maskine. Hvilken strategi den følger, hvis den er maskine. etc.
unik klassen: Hjælper med odds og sammenligning af hænder ved showdown.
NewJFrame klassen: Den grafiske side af spillet (GUI). Har main metoden. public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() {//disse to er vel bare en ny tråd. new NewJFrame().setVisible(true); } }); } hoved AIkontrol k = new AIkontrol(); hand t = new hand();
Har tegne metoder som tegnKort(), tegnShowdown() etc (bruger ikke en samlet paint()). Har selvfølgelig også actionlisteners som betMousePressed(java.awt.event.MouseEvent evt), doubleJSlider1MouseDragged(java.awt.event.MouseEvent evt) etc. Den virker på hand hovedsageligt via feks t.nyhand() t.bet(doubleJSlider1.getDoubleValue()); Endelig har den nogle metoder der (ligesom main) muligvis ikke burde være i den grafiske del af programmet.
public void koer()//metode der fortløbende kalder hand() { if(t.getslut()==false&&t.getrace()==false)//hånden kør { if(t.gettilstand(t.getaktiv())==2||t.gettilstand(t.getaktiv())==3){//spiller er aktiv if(t.getspiller(t.getaktiv()).getstrategy()==1) t.grafikupdate();//spiller er menneske else//metoden udfoer() henter bud i AIkontrol udfoer(k.givhandling(t.getspiller(t.getaktiv()).getstrategy())); t.grafikupdate(); } else { t.skift(); koer(); } } }
Spørgsmålet:
Problemet er at den aktuelle hånd kun er tilgængelig i NewJFrame via t.divMetoder. Der findes mange tilstande og data i hand som AIkontrol har brug for når mere raffinerede strategier følges. Det er nærmest umuligt at sende alle disse videre fra NewJFrame til AIkontrol. Tænkte at lave en hel ny klasse til kontrol af GUI, der indeholder blandt andet koer() og udfoer() og som kalder GUI via NewJFrame n= new NewJFrame();
Hvad er en god angrebsvinkel. Hvordan skal den overordnede struktur være for at skabe mest klarhed og fleksibilitet?
Hvor ville man ligge main metoden i sådan en struktur, og skal der køre flere tråde. Har ikke arbejdet med tråde før, men tror det ville være oplagt her.
Hvor ville en "koer"-agtig metode ligge?
Jeg er stor tilhænger af gennemskuelighed og genbrug af kode, som jo er det hvad dette spørgsmål drejer sig om. Det bliver en stor mundfuld at lære brugen af alle de ting du nævner. Regner med at arbejde med interface og enum her i weekenden.
Har arbejdet med nedarvning før, selvom jeg aldrig rigtig forstod den store pointe i det. Et interface er skræddersyet til den klasse jeg kalder AIkontrol og som nogenlunde svarer til play i din struktur. Det må jeg lære.
Har også været på nettet og læse om enum. Det er ligeledes skræddersyet til at beskrive de tilstande (lidt over en håndfuld) som en spiller kan have. Tænkte hvad det gør for afviklingshastigheden.
Flavor har jeg heller aldrig brugt før. Virker lidt abstrakt. Så det bliver nok ikke det første jeg begynder på.
Mit nuværende program har få klasser der er vokset for store i kampens hede. Skal have lavet nogle pakker som du skriver. Blandt andet en til alle .gif filer. Er dog lidt i tvivl om hvordan man får programmet til at fungere i praksis. Altså med hensyn til hvordan man kalder på kryds og tværs(interface). Som det fungerer nu sker alt af betydning jo i hand() og kaldes fra NewJFrame gennem t.hand.
Med hensyn til conventions, kan jeg heldigvis rette dette let inde i netbeans. Så det bliver ikke noget problem. Undskylder det rodede indtryk.
Vil gemme din struktur og forsøge at arbejde hen mod den. Tak for din tid :)
jeg er ikke sikker paa at traade er noedvendige - der er vel altid kun en spiller som har mulighed for at goere noget
du behoever ikke vaere bekymret over enum og performance
der er ikke noget specielt ved at referere paa tvaers af pakker udover at du skal importere klassen
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.