05-23-2013, 06:05 PM
High-level code structure
We're finally nearing the actual code-writing. Now it'd be nice to just sum up the thoughts and decide on what groups of functionality there is, split the project into modules:
- Obviously, we need hook handlers for the interface with MCServer and for doing the actual protection. We also need command handlers that would handle commands from players accordingly. A simple Handlers module will do.
- We need to remember a few things about the current "state of things" for each VIP - what commands they're running, what coords they selected etc. Let's make a module CommandState for remembering this. Also, this module will implement the most logic behind the commands
- For each player we need to keep track of the protected areas around them. This will be the PlayerAreas module.
- To isolate all the modules from the underlying storage technology, we'll have a Storage module that will provide high-level functions, such as AddArea, AddUserToArea etc. and it will do the actual DB access.
Database structure
We decided to use SQLite for the storage, which means we need to structure our data in a database-like manner. In order to do that, we need to identify the "objects" that we will be using.
Protection areas are one such object. Each area will have a list of users; that can be represented in several ways. We could store a concatenated list of users for each area, but that doesn't work well with finding and removing users. It'll be much better to have another DB table, Users, pairing usernames with area IDs. Also, for administrative review, it might be beneficial to know who created each area.
So let's recap the structure:
- ProtectionAreas: ID, Coords, CreatorUserName
- AllowedUsers: AreaID, Username
We're finally nearing the actual code-writing. Now it'd be nice to just sum up the thoughts and decide on what groups of functionality there is, split the project into modules:
- Obviously, we need hook handlers for the interface with MCServer and for doing the actual protection. We also need command handlers that would handle commands from players accordingly. A simple Handlers module will do.
- We need to remember a few things about the current "state of things" for each VIP - what commands they're running, what coords they selected etc. Let's make a module CommandState for remembering this. Also, this module will implement the most logic behind the commands
- For each player we need to keep track of the protected areas around them. This will be the PlayerAreas module.
- To isolate all the modules from the underlying storage technology, we'll have a Storage module that will provide high-level functions, such as AddArea, AddUserToArea etc. and it will do the actual DB access.
Database structure
We decided to use SQLite for the storage, which means we need to structure our data in a database-like manner. In order to do that, we need to identify the "objects" that we will be using.
Protection areas are one such object. Each area will have a list of users; that can be represented in several ways. We could store a concatenated list of users for each area, but that doesn't work well with finding and removing users. It'll be much better to have another DB table, Users, pairing usernames with area IDs. Also, for administrative review, it might be beneficial to know who created each area.
So let's recap the structure:
- ProtectionAreas: ID, Coords, CreatorUserName
- AllowedUsers: AreaID, Username