Available technology
There are several ways to do what the plugin needs to do. We need to choose the proper way.
The plugin needs to store the protection areas somewhere. There are multiple available storage schemas:
Lua source files are easy to write and super-easy to read (just do "require filename.lua"). However, they do not support partial reading and updating or deleting items either will be difficult, or the plugin will need to hold all the data in the RAM. Neither is a good solution. The files are human readable. The plugin would have to implement a (simple) writer, the reader is built in to Lua.
SQLite database is fast for reading and writing, is easily updated for new format, does support partial reads and writes and handles updates and deletions very well. The files aren't human-readable, but there's plenty of 3rd party editors out there. The API provides everything that the plugin needs for reading and writing.
XML file is fast enough for reading and writing, but difficult to partial-read, partial-write, update or delete. They are human-readable and quite legible. The API supports easy reading, the plugin would need to implement writing.
From this overview, it's quite obvious that the best choice here is to use the SQLite database for storage.
As for the actual protection, the plugin could either use hooks to forbid the interaction, or it could react to the interactions and try to undo them. The hooks approach is definitely better here.
Performance considerations
It is wise to do a little calculation on the plugin performance beforehand and thus see the benefit / penalty ratio. Let's consider a middle-sized server, with 80 people on it. There's a build-event currently on the server, so everyone is busy building and breaking blocks. From personal experience, builders can be as active as 5 placed blocks per second. This means that the plugin will need to perform 80 * 5 = 400 "checks" per second.
It is concievable, that on such a server there would be some 400 regular visitors, with an average 6 protected areas. That would make an estimated total of 400 * 6 = 2.400 protected areas on that server. If the plugin was to check each area with each check, it would mean doing 2.400 * 400 = 960.000 "IsInArea" comparisons per second. That's already a huge number, so we need a better strategy.
Note that we don't need to check the protected areas for players that are not currently present in the server. So instead of 2.400 areas that would mean checking 80 * 6 = 480 areas, or 480 * 400 = 192.000 "IsInArea" comparisons per second. A bit better.
Another optimization comes from the fact that we already know what player we need to check, so if we had only the list of areas for that player, we'd only need to check 6 areas, or 6 * 5 = 30 "IsInArea" comparisons. Compare that to the stunning 960.000 comparisons at the beginning!
In order to be able to optimize like this, we need to make some design choices. We need to be able to quickly retrieve the list of protected areas for a specified player. The easiest way to do that is to load the player's areas when they login (or when there is a change to the areas by the VIPs) and forget them when they log out. The areas will be stored in a table, and the table will be stored in a player->areas map table:
There are several ways to do what the plugin needs to do. We need to choose the proper way.
The plugin needs to store the protection areas somewhere. There are multiple available storage schemas:
- Binary flat file(s)
- Lua source file
- SQLite database
- XML file
Lua source files are easy to write and super-easy to read (just do "require filename.lua"). However, they do not support partial reading and updating or deleting items either will be difficult, or the plugin will need to hold all the data in the RAM. Neither is a good solution. The files are human readable. The plugin would have to implement a (simple) writer, the reader is built in to Lua.
SQLite database is fast for reading and writing, is easily updated for new format, does support partial reads and writes and handles updates and deletions very well. The files aren't human-readable, but there's plenty of 3rd party editors out there. The API provides everything that the plugin needs for reading and writing.
XML file is fast enough for reading and writing, but difficult to partial-read, partial-write, update or delete. They are human-readable and quite legible. The API supports easy reading, the plugin would need to implement writing.
From this overview, it's quite obvious that the best choice here is to use the SQLite database for storage.
As for the actual protection, the plugin could either use hooks to forbid the interaction, or it could react to the interactions and try to undo them. The hooks approach is definitely better here.
Performance considerations
It is wise to do a little calculation on the plugin performance beforehand and thus see the benefit / penalty ratio. Let's consider a middle-sized server, with 80 people on it. There's a build-event currently on the server, so everyone is busy building and breaking blocks. From personal experience, builders can be as active as 5 placed blocks per second. This means that the plugin will need to perform 80 * 5 = 400 "checks" per second.
It is concievable, that on such a server there would be some 400 regular visitors, with an average 6 protected areas. That would make an estimated total of 400 * 6 = 2.400 protected areas on that server. If the plugin was to check each area with each check, it would mean doing 2.400 * 400 = 960.000 "IsInArea" comparisons per second. That's already a huge number, so we need a better strategy.
Note that we don't need to check the protected areas for players that are not currently present in the server. So instead of 2.400 areas that would mean checking 80 * 6 = 480 areas, or 480 * 400 = 192.000 "IsInArea" comparisons per second. A bit better.
Another optimization comes from the fact that we already know what player we need to check, so if we had only the list of areas for that player, we'd only need to check 6 areas, or 6 * 5 = 30 "IsInArea" comparisons. Compare that to the stunning 960.000 comparisons at the beginning!
In order to be able to optimize like this, we need to make some design choices. We need to be able to quickly retrieve the list of protected areas for a specified player. The easiest way to do that is to load the player's areas when they login (or when there is a change to the areas by the VIPs) and forget them when they log out. The areas will be stored in a table, and the table will be stored in a player->areas map table:
-- globals:
PlayersToAreas = {}
-- in the hook:
local AreasForThisPlayer = PlayersToAreas[Player:GetName()];
for Area in pairs(AreasForThisPlayer) do
-- check Area
end