Developed by Stefan Freund, Claudia Ruch, Daniel Wolf
The problem with creating a multiplayer puzzle as a standard table-top-like puzzle is that interaction between multiple users is helpful but not really necessary. A puzzle can easily be solved alone. In addition, a table-top-like puzzle shows no need for new ways of interaction. Of course it would be helpful to have a way to move pieces over great distance, but when doing a normal puzzle you have time to walk around and move the pieces.
So we decided to create a szenario where you would have to interact with other users in order to solve the puzzle. The pieces should also depend on their absolut position on the wall and the user should not have unlimited time to arrange them. With these limitations the user would have to use the new forms of interactions provided to solve the puzzle.
The Tetris game meets all these requirements. This is why we decided to invent "Jedi Tetris". The idea is that the whole wall is one big Tetris field and pieces are raining down at random. Because the playing field is so big, the two players have to split up to cover the whole area. Two players will have to arrange the dropping pieces or exchange them quickly between each other in order to win the game.
There will be three ways of user interaction with the tetris pieces.
- The pieces can be dragged by touching into them and moving them sideways and downwards.
- The pieces can be rotated by making a rotation movement around the center of a tetris piece.
- If a piece is not close to the user, he can use the "force" to move it towards or away from him. By drawing a diagonal line towards a tetris piece, the piece will be selected from the user. Than he could perform the same gestures as mentioned in 1 and 2. Depending on the distance between the gesture and the piece, the tetris pieces will move with different speeds. This way they can be passed between players, too.
Timeline and Current Development
|| (Start) Analysis (Idea generation, project definition)
|| Start on the separate tasks for the chat client homework
|| Hand in chat client parts
|| Chat client debugging, test and submit
|| Motivation presentation
|| (End) Analysis
|| (Start) Planning (graphical layout, system design)
|| (End) Planning
|| (Start) Implementation (game logic, graphic, gestures, misc)
|| (Start) Testing (unit test)
|| (Start) Integration (model - view - controler)
|| (End) Integration
|| (End) Testing (unit test)
|| (End) Implementation
|| (Start) Testing (system test) and solving problems
|| (End) Testing
|| Final project presentation
The first version of the game will have the following features:
- restart/exit game
- manipulate pieces by
- pointing and moving them sideways
- rotating them
- moving them sideways using the "force"
The end version has additional features:
- levels and scores
- using the force in other directions than sideways (rotate pieces, moving them down)
- graphical effects when using gestures
- rows vanishing
- by range (full rows in one Display vanish)
- by number of blocks (number of n blocks in one row vanish)
- by a number of blocks in one range
- hide unvisible areas at the display wall
- sounds to give the user feedback
User Interface Design
As soon as the program is started, a new game begins. By clicking on the screen after a few seconds after game over the program can be restarted.
User interface draft for the first version:
- One piece consists of four blocks.
- The origin of the game coordinate system is in the lower-left corner of the game area. The positive x-axis extends to the right, the positive y-axis points upwards.
The system operates in time-fixed cycles. For each cycle, the following steps are performed:
- move all pieces in mid-air one level lower
- check if pieces touch the ground / lying pieces -> attach them
- check if one or more full rows are present -> mark them as filled
- if at least one row is marked as filled: remove the bottom-most one, move all others
- check if the game is over
This clock-cycle approach allows for easy collision checking using integer coordinates. To hide this simplicity, the graphics engine can apply temporal interpolation.
Communication Model - View
The view subscribes for model events. The model sends update events to its receivers whenever there are changes, like:
- game starts
- piece is added to the game field
- piece falls down
- piece rotates, shifts left, shifts right, shifts down
- piece connects to pieces lying on the ground
- row is full and vanishes
- score is updated
- game is over
Communication View - Controller
The view sends finger or mouse events to controller who interprets them and calls methods in model. Following events must be sended:
- mouse down / display wall is touched
- mouse draged / move finger at the wall
- mouse released / display wall is released