Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
invbat [2014/01/28 13:14] icmu20132 [Service Architecture] |
invbat [2017/07/21 03:08] (current) |
||
---|---|---|---|
Line 11: | Line 11: | ||
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. | 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 | + | 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 power point presentation, |
===== Communication Architecture ===== | ===== 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, | 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, | ||
+ | {{ : | ||
- | ===== Service API (if exists) | + | {{ : |
- | Service API (if exists) | + | ===== Playing the Game ===== |
- | * '' | + | To try and play the game, you'll need a Android device with GPS enabled. |
- | * '' | + | Download the Core Server project and the Android Client project. |
+ | git clone https:// | ||
- | ===== Service Usage ===== | + | First you need to start the gateway and Core Server. You should change this local IP address to your own IP Address. |
- | How to use the service. | + | gateway 127.0.0.1 5500 |
- | <file java Hello.java> | + | Now you only need to open the InvisibleBattlefieldsSDDLCore project and run the Java Application on Eclipse, BattleCoreServer.java. |
- | public class Hello { | + | |
- | public | + | Since the actual Android Client wasn't entirely properly tested, we suggest you to run our Test Client, BattleCoreClient.java, |
- | // Teste | + | |
- | | + | You just need to update you IP address onto the client file: |
+ | |||
+ | <file java HelloCoreClient.java> | ||
+ | public class BattleCoreClient implements NodeConnectionListener | ||
+ | private | ||
+ | //....... | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Finally, if you want to try the Android Client, you need to open the InvisibleBattlefieldsClient project and generate a " | ||
+ | |||
+ | Again, you have to update the IP Address that you'll be using on this specific file: | ||
+ | |||
+ | <file java CommunicationTask.java> | ||
+ | public class CommunicationTask extends AsyncTask< | ||
+ | private String ipAddress = " | ||
+ | | ||
} | } | ||
} | } | ||
</ | </ | ||
+ | And that's it, you should be able to run the game and communicate with the Core Server now. Since it's a work-in-progress, | ||
==== Contact ==== | ==== Contact ==== | ||