Differences

This shows you the differences between two versions of the page.

--- invbat [2014/01/28 13:24]
icmu20132 [Communication Architecture]
+++ invbat [2017/07/21 03:08]
@@ Line 1: / Line 1: @@
-====== Invisible Battlefields ======
-Invisible Battlefields is a work-in-progress, collaborative, positioning-sensitive mobile game in which players battle against each other for the glory of their clan.
-The battles always occurs in a pre-determined regions in specific time-frames. If the player physically crosses the region, he is eligible to participate in the next battle on this region, receiving a notification of such in his mobile device. Then, he has until the time of the battle to confirm his participation and choose which other clan he will attack. This information goes to the Core SDDL, and then is forwarded to the Game Service, which calculates the battle results for each player on the closing time of the Battle. After that, these results are stored so that the player can request them whenever they want.
-A player has three attributes, Strength, Agility and Intelligence, in which the highest one (randomly choosed when the character is created) will be used in the battle outcome calculation. The battle itself works like a weighted rock-paper-scissor, in which the weight is the value of the attributes. In term of attributes, Strength beats Agility, Agility beats Intelligence, Intelligence beats Strength. The attribute in advantage receives a 2x multiplicand.
-ex.
-Player 1 and 2 are battling. Player 1 attacks with 5 STR and Player 2 attacks with 8 AGI. STR beats AGI, so Player 1 has 2x5 = 10 of attack power and player 2 has 8 of attack power. Player 1 wins this battle.
-The player can choose which clan he wants to belong during his registration. We use his email as primary key for his registration. We also store his Character Data, which contains his level, attributes and such.
-As of writing, the Core SDDL itself checks the positions of each client sharing their lat-long localization data (upon request of the client) and then tries to match it with battle regions, but we intend to change this strategy on future updates so that the client will be the one handling it's one region matching (more details in the presentation linked below, available only in Portuguese).
-===== Communication Architecture =====
-The Android Client and the Core SDDL communicate in a simple Request <-> Response paradigm. The clients can send data to the Core whenever they want (Requests), but the Core can only send data upon a previous data request from the client (Responses). That means the Core isn't capable, neither is it's responsibility, to hold specific client information (such as his UUID) or to send data to a specific player without a previous Request.
-{{ :ubi_t2_arquitetura_final_1.png?400 |}}
-{{ :ubi_t2_arquitetura_final_2.png?400 |}}
-===== Service API (if exists) =====
-Service API (if exists)
-  * ''getService()'' Returns Service
-  * ''myMethod()'' Returns Service
-===== Service Usage =====
-How to use the service.
-<file java Hello.java>
-public class Hello {
-   public static void main(String args[]) {
-        // Teste
-        double x = 2;
-   }
-}
-</file>
-==== Contact ====
-  * André Mac Dowell: adowell@inf.puc-rio.br
-  * Ivan Xavier Araújo de Lima: ilima@inf.puc-rio.br
-  * Rogério Carvalho Schneider: rschneider@inf.puc-rio.br