Always at 23.59 on the same day as your TA session (Except Monday classes).
Consult the deadline for your class on the delivery plan.
In this iteration, the learning goal is the compositional design principles, especially its ability to support multi-dimensional variance, and contrast it to corresponding parametric and polymorphic designs. A secondary goal is generalizing your HotCiv framework for new unit types.
Solve and document exercises:
Develop (much of) ThetaCiv using TDD and by generalizing/extending your HotCiv production code.
ThetaCiv is identical to GammaCiv, except for the following additions:
- A new unit type, B52 bomber airplane, is introduced identified by the type string "b52". A bomber costs 60, travels a distance 2 (also over oceans and mountains), defense strength 8, attack strength 1.
- Cities can, of course, produce B52s if the Game's method "changeProduc...." is called with the B52 type string.
- A B52 can overfly an enemy city without conquering it, if there are no units on the city. If there is an enemy unit on the enemy city tile, it is considered a normal attack and conquest.
- B52 action. When a B52 is told to perform its action, it bombs the city below it, which have its population decreased by 1; if it reaches 0, then the city is removed. If there is no city, then if the tile's terrain is of type 'Forests' the bombing causes the terrain type to change to 'Plains'. All other terrain types are not affected by bombing.
And release them using the tag/branch name "Release6".
The main learning goals of this iteration is SemiCiv and the compositional design principles. Thus, if you find yourself pressed for time, focus on SemiCiv and put some ThetaCiv features on the backlog.
ThetaCiv is a way to force you into considering what/what not to generalize in your HotCiv framework code using a new unit type. So for each new feature, consider if it is the framework ("StandardGame, StandardCity, ...") code that should handle it, or if it is the delegate code that should. For instance, the ability to reduce city population seems pretty 'B52' specific, whereas its characteristics as a flying unit and terrain type engineering seems something that other HotCiv variants may benefit from having provided by the framework.
Regarding 'travel distance 2', interpret this as "allowed to make two successful calls to 'moveUnit(f,t)' each moving the unit one tile". This is much easier than developing path finding algorithms.
Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 6 Grade sheet to evaluate your submission. The score counts towards your final grade.
|Learning Goal||Assessment parameters|
|Submission||Git repository can be pulled using "Release6". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artefacts (report following the template) are present.|
|Composition||The compositional design principles are correctly applied in the code base to support all variants and in particular support the multi-variance SemiCiv. There are no source-code-copy, parametric, or polymorphic based variant handling code. The 'variant to use' code is localized in the ConcreteFactory for each variant.|
|Variability Analysis||The report clearly and concisely describes the SemiCiv configuration table and configuration code; and describes correct solutions to the parametric 'getWinner()' and polymorphic ZetaCiv through correct UML and (pseudo) code fragments.|
|ThetaCiv Behaviour||The ThetaCiv implementation is behaviourally correct, and general behaviour, that makes sense for other variants, is provided by Game framework code.|
|TDD and Clean Code||TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations, including adhering to Clean Code properties for newly developed code (1). Missing features are noted in the backlog (ThetaCiv features allowed there).|
Ad (1) Test code should also adhere to Clean Code
properties with the exception of "Arguments in Argument
Lists". It is common and correct that private helper
methods in test code express "hardcoded arguments as part of
the method name", like
because it is just a way to group this fixture code into a
helper method. It does not make sense to make a general method
moveUnitToCity(Unit u, City c) in the test code
as this would involve complex algorithms (requirering TDD to
develop) and time wasted for no gain.