I can see this page 10 being a pretty big thorn in my side. After stating fairly clearly<\/p>\n
\nmodels can move up to their move rate<\/p>\n<\/blockquote>\n
under the \u2018Moving\u2019 heading, it then says<\/p>\n
\nA running fighter can move at double speed: 8″ rather than 4″, for example.<\/p>\n<\/blockquote>\n
This is going to have a fairly large impact on the tests involved. The test for exceeding total movement (both in one and two moves) will only throw an exception if the total movement is double the model\u2019s Movement rate now. In addition, a new test is going to have to be added to ensure that moving over the Movement rate sets an ‘IsRunning\u2019 flag to true. The first test to add would be one that allows a model to move more than it\u2019s Movement rate, but sets the IsRunning flag.<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>MoveModel_MovesDistanceOverMovementRateAndSetsIsRunningFlag()\n{\nModel <\/span>testModel = new <\/span>Model<\/span>();\ntestModel.Movement = 4;\ntestModel.PositionX = 0;\ntestModel.PositionY = 0;\ntestModel.PositionZ = 0;\nfloat <\/span>newX = 5;\nfloat <\/span>newY = 4;\nfloat <\/span>newZ = 3;\ntestModel.MoveModel(newX, newY, newZ);\nAssert<\/span>.IsTrue(testModel.IsRunning);\n}<\/pre>\nEven with the correct code added to MoveModel –<\/p>\n
if <\/span>(this<\/span>.TotalDistanceMoved > this<\/span>.Movement)\n{\nthis<\/span>.IsRunning = true<\/span>;\n}<\/pre>\n– this doesn\u2019t work. Because ValidateMove is throwing an exception (as we designed in earlier). So ValidateMove has to allow up to twice the MovementRate.<\/p>\n
if <\/span>(GetDistanceFrom(positionX, positionY, positionZ) + this<\/span>.TotalDistanceMoved > this<\/span>.Movement * 2)\n{\nthrow new <\/span>ArgumentException<\/span>(\"The model cannot move further than it's Movement rate.\"<\/span>);\n}<\/pre>\nNow, all the tests pass. But should they be? Checking my working, the MoveModel_CannotMoveFurtherThanModelsMovement test is moving the model more than twice it\u2019s movement rate. So it is correct to throw an exception, and therefore pass the test. Anything testing to stay beneath the model\u2019s Movement rate is obviously going to be beneath it\u2019s doubled Movement rate, so they will continue to pass. MoveModel_TotalMovementInASingleTurn… that tests whether two movements that combined make more than the model\u2019s Movement is also working correctly. But I\u2019ve noticed I had an error in that test:<\/p>\n
[TestMethod<\/span>]\npublic void <\/span>MoveModel_TotalMovementInASingleTurnCannotExceedModelMovement_ThrowsArgumentException()\n{\nbool <\/span>correctExceptionThrown = false<\/span>;\ntry\n<\/span>{\nModel <\/span>testModel = new <\/span>Model<\/span>();\ntestModel.Movement = 4;\ntestModel.PositionX = 0;\ntestModel.PositionY = 0;\ntestModel.PositionZ = 0;\nfloat <\/span>newX = 5;\nfloat <\/span>newY = 4;\nfloat <\/span>newZ = 3;\ntestModel.MoveModel(newX, newY, newZ);\ntestModel.MoveModel(0, 0, 0);\n}\ncatch <\/span>(ArgumentException <\/span>ex)\n{\ncorrectExceptionThrown = true<\/span>;\n}\nAssert<\/span>.IsTrue(correctExceptionThrown);\n}<\/pre>\nThe try catch was working on both MoveModel calls \u2013 and those values (after the calculation fix a couple of posts back) would have sent it way over the Movement on the first move, not the second. Moving the try…catch so that it only covers the second call to MoveModel would check that it\u2019s failing in precisely the right place. By reversing my change to ValidateMove, I can confirm that the test would have failed before if the try…catch was in the right place. Putting it back in, and it throws an exception on the second MoveModel call, just as it should do. All the tests pass, and I\u2019m a little more comfortable about them testing the right thing.<\/p>\n
Lesson learned: Only test exactly the line you expect to break things.<\/p>\n
The rest of the \u2018Running\u2019 section mentions not being able to shoot \u2013 this is something that we can cover in the Shooting section (after Movement), and isn\u2019t important right now. The next bit that should matter is that a running model must stop 8 units away from an enemy model that he can see. This brings a number of things into play immediately:<\/p>\n
\n
- Can we identify models as being enemies?\n
- Can we identify which models can see others?\n
- How do we perform the sight checks all along it\u2019s movement to work out if it can see the enemy (they may not be in sight at the beginning of the move, only halfway along it)?\n
- What action should be taken if the model\u2019s movement is disrupted \u2013 should it still count as running? How can it be prevented from moving further? <\/li>\n<\/ol>\n
Before we write tests, we should explore the problem a bit further.<\/p>\n
Essentially, the enemy is at the centre of a circle 16 units in diameter (radius of 8). The active model\u2019s path may intersect the circle at some point. If it does so, the active model must stop at the point along that path nearest to his starting point, providing that he can draw a line of sight to the enemy model at the centre of the circle.<\/p>\n
So we only really need to work out if any point of the active model\u2019s path intersects the enemy \u2018disruption\u2019 circles, and check those sections of the path for line-of-sight to the centre of the circle.<\/p>\n","protected":false},"excerpt":{"rendered":"
I can see this page 10 being a pretty big thorn in my side. After stating fairly clearly models can move up to their move rate under the \u2018Moving\u2019 heading, it then says A running fighter can move at double speed: 8″ rather than 4″, for example. This is going to have a fairly large … <\/p>\n