Gunn AP CS Settlers of Catan Incremental Design Plan

Components Client/Server App SVN for version control – If we make a mistake, how to we revert to stable code? Incremental Development

Client/Server App Server – Game State – Game Loop – Logic/Control Client – GUI (Swing framework) Event handling Display code Both – Communication – Connection Monitoring

Server Game State – Whose turn is it? – What is on the grid? Resources Dice numbers Buildables (Roads, Settlements, Cities) Harbors Robber – What things does each player have?

Server Game Loop – Is the game over? – Advance to next player – Development cards playable at any time during turn – Turn sequence Roll dice Resource allocation If a 7 is rolled… – Forced discards – Robber movement – Steal resource Trading & Building End turn

Server Logic (Examples) – Calculate longest road/largest army – Management of Development Cards – Determine if an action ends turn or game – Allocate resources – Player data – Robber management – Harbor occupation

Client GUI: Event Handling – Roll dice – Placement of Pieces – Build – Trade – Development card play – End turn – Discards Transmission of event input to server

Client GUI: Display Code – Grid (and general artwork) – Objects on grid – Player data Including whose turn it is Development card panel, etc. – Build bar Including at setup time – Trading panels Current player Other players – Dice rolls (make obvious what is happening)

Both Client and Server Communication – String will be used to transfer game state – Message transmission – Message reception Connection Monitoring – Ping to verify presence of clients

Subversion (SVN) Used to track changes in code Google Code does this automatically for us Commit and update daily in class – Use stubs where appropriate Avoid situations where two groups are working on same class at same time – Need to be clear on each team’s role at start of each class period PEOPLE ARE COUNTING ON YOU. NO SLACKING. [Demo time]

Subversion (SVN) Demo – Get Google account – Set up project – Modify something – Revert to previous code Everyone needs to provide address – Code changing privileges – Communication with members of class

Incremental Development Writing the WHOLE GAME and then testing is both hard and criminally insane Writing small pieces that can be tested one at a time is a more efficient and effective way to produce a large program Some parts of the project will have dependencies – Without a grid, cannot place objects, e.g.

Incremental Development One player game – No Development Cards – No Robber – Only need: Grid – Roads, Settlements, Cities (can be created as classes but are unusable until grid exists) Dice Resources End of game check

Incremental Development Two player game – Add synchronization – Add game loop

Incremental Development Add Robber

Incremental Development Add Development Cards

Grid Coordinate system – Murky; this is why abstraction matters 2D array of Point (abstract class) Point – ResourcePoint – BuildablePoint Public interface will be defined by team leaders and must be adhered to strictly

Grid