Project, CSPA

Groups | Schedule | Specification

STATUS: PRELIMINARY, NOT READY YET

  • topics assigned, check groups page
  • additions will come to project requirements part

Project is a modeling, specification and programming work to create a communications system. Result is specifications document and implemented system.

  • Project work trains skills to create communication systems in practice.
  • Project work divides into two phases
    1. Design and specification of communication, result ⇒ Specification document
    2. Implementation of application with specified communication, result ⇒ working communicating software
  • Project work is done in two person groups
  • Assignments and deadlines will be given on schedule page.
  • The work topic will be assigned to your group. Check the groups list.

Phase1: Modeling and Specification

Result Document

  • Is written in english.
  • Is a specifications for a topic.
  • Is one .pdf file.

Phase2: Implementation

  • Implementation is fully functioning game system along given assignment topics and specification.
  • Implementation communications interoperability goes along specification
    • if in specification are definitions that are no able to implement you have to add point into review comments with a reason and deliver it to specification group
  • In addition to specification design you have to make implementation based design in practice (does not have to documented but implemented)
  • Implementation language is python
  • Update of the specification, if there is non-working definitions found from implementation. Independence to programming language and implementation environment should be remained.

Result Code

  • delivered in .zip package
  • no “trash” files (mostly no *.pyc)
  • Functionality demonstrated.
  • You have to be able describe code fully.

Project work requirements

(these are requirements for project work, you have to specify layer specific service requirements by yourself)

  • Resulted systems specifications have to present a consistent model for topic gaming system with working communication.
  • Specified system communication have to be able to implement in networked environment.
  • Game layer
  • Gaming system have to be communicate upper part entities. User Interface (UI) on client side and Control component on server side. Game layer is used by some kind of User Interface (UI) on GameClient side and some Control component on GameServer site. You do not need specify these (implementation thing) But on Game layer there have to be SAP interfaces for use.
  • There have to be at least three processes. 2 clients and 1 game server.
  • There should be able to run multiple games concurrently.
  • Byte Count coding with UDP transport.
  • Game rules, eg illegal moves detection, are implemented in server part.

Given Constraints for Project Work

(these are constraints for project work, you have to specify layer specific service constraints by yourself)

  • System role model is client – server
  • Assumed Transport layer: UDP. You have to reverse engineer UDP design to fit the project work design – UDP usage primitives.

Notes

  • You have to think and specify which service requirements goes to game topic specific layer and which go to general game support layer.
  • Games are assumed to be player between humans, so forget any game AI.
  • Game event calculations (actions) are not relevant in this level design (they are implementation level detail issues), but you have to design when game event is happening and what happens after the event. Game event is for example checking ending conditions in chess.
  • Game logic are rules are handled by game server and player (client) may not be trusted.
  • Used references have to be academic. Wikipedia is a good starting place, but very bad ending place as a reference.

Project work topics

Assignment for topics is on groups page.

reversi

Game is Reversi

pentago

Game is Pentago

freedom

Game is freedom