meta data for this page
This is an old revision of the document!
STATUS: PRELIMINARY, NOT READY YET
- topics assigned, check groups page
- additions will come to project requirements part
- Project work trains skills to create communication systems in practice.
- Project work divides into two phases
- Design and specification of communication, result ⇒ Specification document
- 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
- Is written in english.
- Is a specifications for a topic.
- Is one .pdf file.
- 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.
- 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.
- 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.
Project work topics
Assignment for topics is on groups page.
Game is Reversi
- wikipedia Reversi description
Game is Pentago
- wikipedia Pentago description
Game is freedom
- wikipedia Freedom (board game) description