Thursday, July 12, 2012

Notoriously Databased v0.24

The interface for submitting a turn is more or less complete, and I'm happy with the progress of MVC in this design. The next thing to work on is the turn resolution itself. Since I'd completed most of it in the Google Doc version, I was expecting it to flow fairly quickly...

Resolution Phases
For this version I'll be breaking down the turn resolution into 5 phases.
  1. Validate the turn: If there are any commands that will not be possible, drop to the maximum achievable number (Eg 5 minions available and request 6 to dig = 5 digging)
  2. Town Raids: Calculate all attacks on the town. Initially the attacks were to occur simultaneously and impact on the amount of guards for that turn, but for now a simple ratio of defenders to resources will suffice.
  3. Hero attacks on Dungeon: Process all incoming attacks from the village. 
  4. Attacks by other Characters: Any incoming attacks from other dungeon will occur after the hero attacks. This will allow for potentially easier attacks, but also potentially nothing if the heroes wipe it first. If there are multiple people attacking the same dungeon, only one will survive (or none)
  5. Returning trops: Any successful raids or ransoms or dungeon attacks come back. Any digging or fortification building is also completed if not wiped.

Validate the Turn
 The validation itself was pretty easy to set up as I'd already done the logic for it, but the main sticking point in this section was creating a function to update the story with any errors. The story table will mainly be used to tell the player what happened in a turn, but it will suffice to also be the error reporting section for validation. The function itself should be pretty easy, but where to put it?

After another chat with Andrew, I decided on using a StoryRepository in the Models. Even though it's not technically a Model, the utility function does in a way act as a conduit to the model, and will not be doing much else apart from formatting and saving the Story into a new record. I played around with null values to allow optional parameters and unknown IDs, but it was cleaner to simply force IDs by seeding the optional parameters.


Town Raids
Initially I was hoping for the amount of defenders to be proportional to the amount of attackers as they would be pulled in different directions to defend all the resources (or go only one way if only one attacker). In the Google Doc version I'd dropped it in favour of a simple ratio of defenders per resource becuase of difficulties calulating all town attacks at once, but now that I can process them any way I like, I'll still use the ratio for now because it turned out to be simpler to calculate whether your attack will workor not by analysing the village state from the previous turn. It seems a little too controleld at the moment and I'd like a little more randomness, but for this large scale test it should be fine.

Once the raid has been calculated, the successful minions will return in phase 5. I could possibly merge this phase down to there, or merge up into validation, but I'm really unsure whether the town raid will need a different calculation method in testing, so it should be better in a self-contained section. Doing this means that I need a way to hold all raid data until phase 5. With my new-found love of Models, I made up a new class to act as a memory storage unit for raid data. This way I can create them into lists and process in much the same way as if it were table data.