Gunn AP CS Settlers of Catan

1. Gunn AP CS Settlers of Catan Incremental Design Plan

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

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

4. 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?

5. 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

6. 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

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

8. 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)

9. 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

10. 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]

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

12. 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.

13. 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

14. Incremental Development • Two player game • Add synchronization • Add game loop

15. Incremental Development • Add Robber

16. Incremental Development • Add Development Cards

17. 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

18. Grid