Currently, terrain has little affect on battles once the pirates land. It might be interesting to allow the terrain to be a bit more important. Three ideas: 1. Make swimming significantly slower than walking (say 30%). A pirate could create mini-moats throughout an island by spacing things out. A base could even be an archipelago (bunch of islands). 2. Tie walls into adjacent rock features. A creative pirate could build his/her defense using the local outcroppings instead of just clearing everything. 3. Allow the user to create (or move) outcroppings (limited in number) to, for example, make a portion of an island's periphery unsuitable for landing.
The idea with moats is a lot of work because now pirates can be dropped in every little puddle there is, so that entire script must be rewritten then. Don't know if that is even possible right now. Combining walls and rocks would be a nice feature, but in combination with idea number 3 I disagree. Because it then would replace the entire use of a wall.
As users, let us not speculate about how difficult something is to develop, let us express requirements (well, desirements), and leave the cost benefit analysis to the developer. That said, I'm experienced enough in software development to not ask for something computationally infeasible. In the puddle case, calculating the hull (we have to allow concave and convex hulls) of an object in a grid is easy - the solution is probably on the web. The puddle problem is resolved by disallowing dropping inside hulls. I'd limit the number of rock features that could be created (let's say 5) and make them expensive to prevent the obvious problems. I'll retract the notion of moving them; that's better handled as a removal project followed by a build project.
While I'm waiting for pirates to recruit, here's a simpler algorithm than hull calculation for determining puddles: 1. Put a water cell on the grid's periphery on a list (w-list). 2. Until w-list is empty: a. Remove a cell (c) from w-list, b. Put c on droppable list (d-list), c. Put water cells adjacent to c and not on d-list on w-list. At completion, d-list contains all the water cells usable as drop points (puddles don't appear on d-list). This algorithm is Order (n-squared) where n is the number of cells in the grid. There you go: simple and feasible. One could make this Order (n) by marking each cell as visited in step c and eliminating d-list; but I don't know if the underlying grid data structure allows such marking.
