Introduction

Check the Assignment 3 grade on the ZINC Online Submission System.

There are 99 GTest test cases in total, with each test case having its own grade. The grade stated by ZINC will be 1 if you passed the test case, 0 if you failed, and is NOT indicative of your actual grade. Please calculate your actual grade by checking the Grading Scheme section. No partial credit is possible within a single test case, as they are not worth more than 2% each.
The two Standard I/O Tests check for Memory and Undefined Behavior errors, and are worth 7% and 3% respectively, also with no partial credit possible.

For grade appeals, please follow the listed procedure below. Appeals with incomplete information and/or not following the listed procedure will not be processed:

1. Read the list of common errors and appeal cases, and follow their sub-instructions (if applicable).
2. Check the GTest code in the section below for more details of what each test case is doing.
3. Send an email to the TA in-charge, CHANG Bing Yen, bychang@connect.ust.hk, with the subject header "COMP2012H PA3 Grade Appeal".
4. State which test case(s) you wish to appeal (refer to the list in the section below). Clearly state your reasoning for why your code should have passed those test case(s).
5. You may propose changes to your source code. Attach your code snippet with the proposed changes in your email. However, such changes are subject to a grade deduction at the discretion of the TA in-charge, proportional to the magnitude, complexity, and hindsight of the changes.
6. The TA in-charge reserves the right to reject any and all source code changes, as the solution has already been released.
7. DO NOT attach any .exe/executable file(s) in your email.
8. Appeal deadline is 30 November 2020 Monday 23:59 HKT. No late appeals will be processed.
9. Finalized scores will be uploaded to Canvas after all appeals are processed.

Common Errors and Appeal Cases:

1. Uninitialized variables will have garbage (random) values in C++. Sometimes it will be 0, sometimes it will not. In that case, your program may generate different results on different machines or different runs if your logic depend on an uninitialized value. If you have assumed them to be 0 or something specific (e.g. a very large value), your code is faulty and will get random results.
2. If your function doesn't have a return statement for some cases, the returned value is undefined (can be random) for those cases.
3. Retrieving values from deleted/unallocated dynamic memory, or index out-of-bounds, may not always crash your program but may give random values.
4. Compilation errors will result in however many marks ZINC states for your submission. This should not occur as a revealed test case were already provided to test your code on ZINC. Your appeal email should include the code snippet(s) that fix the cause(s) of the compilation error. The corresponding test case(s) where the compilation error occured will still be considered as originally failed and will receive 0 marks, but you can recover your marks for the rest of the test cases.
5. Runtime errors and crashes due to incorrect memory access / memory allocation / memory deallocation / missing variable initialization / missing return values / out-of-bound array access / etc, may not occur all the time on all machines. However, even though you may not encounter the error/crash when you test your program, if your program crashes during any of the test cases on ZINC, the corresponding test cases will be considered as failed and will receive 0 marks.
6. Runtime crashes due to point 5 above, or due to timeouts (infinite loop / infinite recursion / runtime taking too long) of the whole GTest, will only be regraded if you can debug, fix, and report it in your email appeal with attached code snippet. The corresponding test case(s) where the runtime crash occured will still be considered as originally failed and will receive 0 marks, but you can recover your marks for the rest of the test cases.

Grading Scheme

No partial credit within a test case.

GameEngineTest	Grade
IsGameOverTwoPlayers	2%
IsGameOverOnePlayer	2%
IsGameOverZeroPlayers	1%
Subtotal	5%

GameMapTest	Grade
UpdateTerrainMapEmptyToOccupied	1%
UpdateTerrainMapOccupiedToEmpty	1%
IsValidPath	1%
IsValidPathOutOfBounds	1%
IsValidPathTerrainBlocked	1%
IsValidPathTerrainOccupied	1%
IsValidPathOutOfMovementRange	1%
Subtotal	7%

PlayerTest	Grade
GetUnitById	2%
HasUnitsAlive	1%
HasNoUnitsAlive	1%
HasUnitsReady	1%
HasNoUnitsReady	1%
ReadyAllUnits	2%
GetName	1%
GetNumUnits	1%
GetUnits	1%
Subtotal	11%

UnitTest	Grade
BeginTurn	1%
EndTurn	1%
MoveDeltaPositiveRowPositiveCol	0.5%
MoveDeltaNegativeRowNegativeCol	0.5%
MoveDeltaPositiveRowNegativeCol	0.5%
MoveDeltaNegativeRowPositiveCol	0.5%
HealRate	1%
HealMaxHealth	1%
GetId	1%
GetUnitType	1%
GetAttackRange	1%
GetMovementRange	1%
GetPositionRow	1%
GetPositionCol	1%
IsReadyTrue	0.5%
IsReadyFalse	0.5%
IsAliveNonzeroHealth	0.5%
IsAliveZeroHealth	0.5%
Subtotal	14%

DerivedUnitTest (Duplicated for all 4 Derived Unit Classes)	Grade
ConstructorId	0.5%
ConstructorUnitType	0.5%
ConstructorHealth	0.5%
ConstructorAttack	0.5%
ConstructorDefense	0.5%
ConstructorAttackRange	0.5%
ConstructorMovementRange	0.5%
ConstructorPositionRow	0.5%
ConstructorPositionCol	0.5%
ToString	1%
AttackSwordsman	1.5%
AttackPikeman	1.5%
AttackKnight	1.5%
AttackArcher	1.5%
SimultaneousCounterattack	1.5%
Subtotal	13% x4

ArcherTest	Grade
RangedAttackAgainstMelee	0.5%
RangedAttackAgainstArcher	0.5%
Subtotal	1%

Standard I/O Test	Grade
Test #1 (Memory & Address)	7%
Test #2 (Undefined Behavior)	3%
Subtotal	10%

Solution & Test Cases

• Solution: PA3_solution.zip
• GTest Code: pa3_gtest_code.zip
• GTest Library for Windows: pa3_gtest_windows.zip

Refer to the GTest usage and coding documentation.

GTest compilation instructions (Windows only) (similar to PA1):

1. Extract pa3_gtest_windows.zip into any convenient folder.
2. Place your submission header and source files into that convenient folder.
3. You should now have these files and subdirectories inside that convenient folder:
   • (PA3 header and source files, also textfiles for loading GameMap, Players, and Units)
   • UnitDerivedGTest.h
   • PA3_GTest.cpp
   • .\include\gtest\ (various subdirectories and files)
   • .\lib\libgtest.a
   • .\lib\libgtest_main.a
4. In a terminal, navigate to that convenient folder, and run the following g++ commands:
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c GameEngine.cpp -o GameEngine.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c GameMap.cpp -o GameMap.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Player.cpp -o Player.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Unit.cpp -o Unit.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Swordsman.cpp -o Swordsman.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Pikeman.cpp -o Pikeman.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Knight.cpp -o Knight.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 -c Archer.cpp -o Archer.o
   • g++ -std=c++11 -pedantic -Wall -Wextra -g -O0 "-I.\\include" -c PA3_GTest.cpp -o PA3_GTest.o
   • g++ "-L.\\lib" -o PA3_GTest.exe GameEngine.o GameMap.o Player.o Unit.o Swordsman.o Pikeman.o Knight.o Archer.o PA3_GTest.o -lgtest -lgtest_main
5. Things to try if you get compilation errors:
   • Replace with full directory pathnames ("-IC:\\Desktop\\convenient_folder\\include" , "-LC:\\Desktop\\convenient_folder\\lib") if relative pathnames fail to parse.
   • If you get "declaration not found in scope" errors related to gtest-*.h during Step 3, try replacing -std=c++11 with -std=c++0x, -std=gnu++0x, or -std=gnu++11.
   • If you are still having compilation errors, it might be a version difference with the MinGW compiler. Please try reinstalling according to the VS Code setup in Lab1.
6. Run PA3_GTest.exe. Note that there is no pause after output, so the terminal may close automatically.

To configure googletest for other platforms, please refer to the googletest make documentation. You'll need to compile the googletest library files libgtest.a and libgtest_main.a specifically for your platform.

The Memory and Undefined Behavior checks are performed with the compiler itself by adding the "-fsanitize=address" and "-fsanitize=undefined" compiler flags with GNU g++ on Linux. However, these flags are not available for MinGW on Windows. Nevertheless, the memory management code that you need to complete is just only in the Player Destructor - call delete on each Unit* in units array, and call delete[] on units.

Statistics

• Total: 100
• Average: 97.93
• Standard Deviation: 5.15
• Median: 100
• Minimum: 63
• Maximum: 100

Normalized to 8:

• Total: 8
• Average: 7.83
• Standard Deviation: 0.41
• Median: 8
• Minimum: 5.04
• Maximum: 8