1. Threading
A considerable amount of time was spent trying to get threading to work properly. Initial designs included a thread called Turn, which would call a subsequent thread for performing communication actions with the LAMP server. Unable to get a working solution, the nested thread design was abandoned and the team focused on simply trying to get the Turn thread to work (it would have been easier yet to run the turn interactions in the main thread, however, this was seen to be extremely poor Android application design).
After considerable frustration, it was found that problems with wait() and notify() methods vanished by using "extends Thread" instead of "implements Runnable" for the Turn class.
2 Project Reevaluation
Despite considerable setbacks, the team generally stayed the course.
The decision to create an Android app, despite the lack of experience, made for a challenging project, but the difficulties encountered provided substantial learning opportunities. The large scope was initially intimidating, but after overcoming the many roadblocks, the team is satisfied that the project is of appropriate scope for the class.
The only notable decision the team chose not to pursue was the use of Bluetooth for Android communication. Though the use of Bluetooth was abandoned due to apparent time constraints, the use of a stable central database alleviated concerns about the host quitting, as the LAMP server provides consistent, accessible data. Additionally, PHP provided powerful tools that simplified coding in several cases.
3. Phase 1 Functionality
Functionality Description
A. Overall Application Description (end goal for the project)
The Card Czar Android application is a spin-off of the popular card game Apples to Apples (drawing some inspiration from the similar card game, Cards Against Humanity).
The Card Czar is an android application multiplayer card game that can deliver hours of fun. It allows a user to create a new game room and invite friends to play with them. For a game to begin there must be at least 3 players. Once a game is started each player is dealt at random a hand of response responses that will be used to respond to the random bait that is chosen for the round. A bait card (text) is chosen and the Card Baron (this is the dealer-either the winner from the last round, or host if it's the first round) then waits for players to submit responses to that bait. The Card Baron (dealer) then selects from one of the responses and the player who submitted the winning response gains 1 point and becomes the Card Baron for the next round. The first player to get to 5 points wins and is crowned the Card Czar.
B. Phase 1 Functionality
This section describes the functionality being delivered as of Phase1. All of the application's activity layout screens have been coded and are working, except for GameplayActivity, which only handles gameplay while a player is a dealer (Card Baron). Note that the other completed Activity Java classes have only the levelof functionality necessary for bare minimum operation.Additionally, the LAMP server has been created and deployed to an AWS instance. This server hosts the middleware, PHP files, which the application will call to interact with the database. The PHP files have not all been completed-not all of the non-dealer actions have been coded. The delivered code for phase 1 can be compiled and run through an emulator to begin showing basic gameplay functionality and interaction with the LAMP server.
The gameplay functionality is not complete yet so a full game cannot be played without using PHP tools that were designed for testing. Full functionality should be completed in the next phase of development.Additionally, security, such as setting up HTTPS communication with the LAMP server, has not yet been implemented in this phase of development. A breakdown of a sample game follows.