Assignment 2
The View

Objectives

• to give you experience in implementing Graph-based ADTs
• to give you practice in implementing a well-defined interface

Background

The ultimate goal for this assignment is to write AIs that can play The Fury of Dracula. The interface for the AIs is very simple: the game engine invokes the AI, waits for a certain amount of time while the AI thinks about its move (possibly suggesting several moves), and then takes the last move suggested by the AI. The AIs clearly need to know about the game state in order to decide on a move. Their access to the game state is via an appropriate View ADT: hunters use the HunterView ADT, while Dracula uses the DraculaView ADT. Both of these ADTs are layered on top of a generic GameView ADT. Your task in this phase of the assignment is to implement a version of these ADTs that your AIs can use.

Setting Up

Create a GitHub repository

Since you are working in teams, and there are many files involved, it is important that you properly manage your source code. Thus, we require you to use GitHub for this assignment (plus it's an opportunity for you to create a GitHub account if you don't already have one).

If you don't have a GitHub account yet, create one here (every team member must do this). Then, get one member of your team to create a private repository To create a repository:

1. Go to this page.
2. Enter an appropriate name for the repository, like fury-of-dracula.
3. Select Private to make the repository private. Make sure you do this, or other teams will be able to find and copy your code!
4. Check the box next to Initialize this repository with a README.
5. Select C in the Add .gitignore dropdown. This will ensure that object files (.o files) get ignored by Git when you push your files to the repository.
6. Click Create repository.

Invite your teammates

Now, invite the other team members to the repository as collaborators. There are instructions for how to do this here.

Add COMP2521UNSW as a collaborator

In order to check whether team members are contributing to the assignment, we will need to have access to your repository. Invite the COMP2521UNSW user to the repository, in the same way as you invited your teammates in the previous step.

Clone the repository

Now you're ready to clone the repository.

1. On the main page of the repository, click on the green button which says Code. Then copy the URL in the box that appears.
2. In the terminal, run the command git clone url, where url is the URL that you copied in the previous step. If this is your first time using GitHub, you will likely be asked to enter your GitHub username and password. (There are ways for you to avoid entering your username and password every time you interface with GitHub, but we will tolerate this for now.)

Congratulations! You now have a local version of the repository, which you can push your code to and pull your teammates' code from.

Configure your commit email address

In order to ensure that your contributions are linked to your GitHub account, configure your commit email address by running the command:

git config --global user.email email

where email is the email address you used when signing up to GitHub. If you already had a GitHub account but forgot what email address you used, you can find out by going to your Settings page on GitHub, and opening the Emails tab.

Add the starter code

Now you need to add the starter code to the repository. Note: Only one team member should do this.

1. In the terminal, change into your repository directory (this is the directory that was created when you ran git clone).
2. Create a directory for the view phase of the assignment. Then change into that directory.
3. If you're on the CSE system, run the command:

   unzip /web/cs2521/20T2/ass/ass2/view/view.zip

   If you're working from home, download the view.zip file and unzip the files into the directory that you created in the previous step.
4. Now we want to push (i.e., upload) these initial files to the remote repository on GitHub. Before we do this, we need to make a snapshot (i.e., commit) of the local repository that contains these initial files. Git keeps track of snapshots of your repository so that you can keep track of changes. Making a snapshot is a two step process: first, you must add (i.e., stage) the changes, and then you must make the snapshot. To stage the changes, run the command:

   git add -A

   This stages changes to all the files in the repository (other than the files specified in the .gitignore file, which includes the .o files we mentioned earlier). Later, if you want to stage changes to only a specific group of files to the repository, you should specify the individual files rather than using -A, for example:

   git add file1 file2

   Now, to make the snapshot, run the command:

   git commit -m "initial view files"

   This takes a snapshot of the current state of your repository. Finally, push (i.e., upload) your files to GitHub using the git push command.

   git push

   Now, when your teammates clone the repository, they will receive the files (and changes) that you pushed.

Well done! You've now uploaded the starter code to your repository and can now begin working on it.

Pulling changes

While working on the assignment, you'll need to sync your local repository with the changes that your teammates have made. To pull changes from the repository that your teammates have pushed, change into the repository directory, and then run the command:

git pull

NOTE

You should run git pull every time you sit down and start working on the assignment, since your teammates might have made some changes to the code.

Pushing changes

After you have finished a session of coding, you should stage your changes and push them to GitHub. That way, your teammates can obtain your code and review it. To do this, follow step 4 in the Add the starter code section above.

NOTE

You should do this every time you stop working on the assignment. However, make sure that your code compiles before pushing. Your teammates should not need to deal with compile errors that you have caused (unless they agreed to help you with it).

The files

When you downloaded the starter code, you received these files:

Makefile

a set of dependencies used to control compilation

Game.h

definitions of game constants; interface to game engine

GameView.h

interface to the GameView ADT

GameView.c

skeleton implementation of the GameView ADT

testGameView.c

main program containing a few tests for the GameView ADT

DraculaView.h

interface to the DraculaView ADT

DraculaView.c

skeleton implementation of the DraculaView ADT

testDraculaView.c

main program containing a few tests for the DraculaView ADT

HunterView.h

interface to the HunterView ADT

HunterView.c

skeleton implementation of the HunterView ADT

testHunterView.c

main program containing a few tests for the HunterView ADT

testUtils.h

interface to common test utilities

testUtils.c

implementation of common test utilities

Places.h

interface to the Places ADT

Places.c

implementation of the Places ADT

Map.h

interface to the Map ADT

Map.c

implementation of the Map ADT

pastPlays.txt

some sample pastPlays strings

Make sure you read the Places and Map ADTs carefully before using them. You are not required to use the Map ADT, but it will probably save you some time. You are allowed to modify it (both Map.h and Map.c files) if you wish.

IMPORTANT NOTE

You must not modify any of the provided function signatures in the GameView, HunterView and DraculaView ADT interfaces (otherwise you'll fail auto-testing). However, you may augment these ADTs with as many other functions as you like.

What to do

GameView

You have two tasks for this part of the exercise:

• design and build an implementation of the GameView ADT,
• write a comprehensive test suite to ensure that the ADT is working correctly

The first task requires you to complete the GameView.c file. You should not modify the provided function signatures in the GameView.h file.

If you decide to use other ADTs, these should be #include‘d in the GameView.c file. Read GameView.h carefully to ensure that you understand what each function is supposed to do. Then, design data structures to support this, then implement the functions on top of these data structures. You are free to use the supplied Map ADT, and you are free to use any other ADTs that you think will help. Note that if you use other ADTs:

• you will need to add them to the Makefile, and
• you will need to submit them.

If you modify the Map ADT, you will also need to submit the modified version.

The second task requires you to think about all of the cases that your GameView ADT needs to handle and come up with as many tests as you can think of to ensure that all cases are checked.

The supplied testGameView.c file provides some tests, to give an idea of what’s required, but they are by no means comprehensive. You should add as many as you think are needed to check that your ADT is working properly. This is in your own best interests, since, if you submit a buggy ADT to the Hunt to support your AI, then your AI will (by making enough invalid moves) eventually be disqualified for that game, and you will miss out on performance marks.

HunterView and DraculaView

You have two tasks for this part of the exercise:

• design and build an implementation of the HunterView and DraculaView ADTs
• write a comprehensive test suite to ensure that both ADTs are working correctly

The HunterView and DraculaView provide views of the game state appropriate to either a hunter player or the Dracula player. They provide much the same functionality as the GameView ADT, but with some specialisations towards the needs and/or capabilities of the relevant players.

Some assumptions in the design of these ADTs:

• they will be used by the AIs in their decidePlayerMove function
• no AI will use the GameView ADT directly
• the HunterView and DraculaView ADTs should use the GameView ADT in their implementation
• the DraculaView ADT will only be used by the Dracula AI, and only when it’s Dracula’s turn
• the HunterView ADT will be used by the hunter AI, and will be used for all of the hunter players
• a Hunter AI can work out which hunter player it’s currently running as by using the HvGetPlayer() function

You should use the same strategy for the design, implementation and testing of your HunterView and DraculaView ADTs, as you used in developing your GameView ADT, i.e.

• read the PlayerView.h file to understand what each function is supposed to do
• design a data structure that can support the required operations (will include a GameView value)
• implement each of the functions specified in the PlayerView.h interface, using the skeleton PlayerView.c file provided
• you may use other ADTs in implementing either or both of the PlayerView ADTs
• these ADTs may not require much code of their own, since they rely on most of the work being done by the GameView ADT
• once implemented, design a comprehensive set of tests, and add them to the appropriate testPlayerView.c file
• test, re-code, repeat … maybe with the occasional stop for eat and sleep

Once you have implemented and thoroughly tested all three ADTs, move on to the submission step.

Submission

The submission command is:

give cs2521 ass2view files...

You should submit all your views and tests (and any additional ADTs) at the same time. Only one member of each group needs to submit. If there are multiple submissions from the same group, only the last submission will be marked. You must submit from a CSE server (VLAB or SSH).

What to Submit

Here are the steps for determining what you must submit.

1. Your submission must include the following files:
   • GameView.c
   • HunterView.c
   • DraculaView.c
   • testGameView.c
   • testHunterView.c
   • testDraculaView.c
   • Makefile
   
   

   If you didn't modify the Makefile, you still need to submit it.

2. If you added more interface functions to the GameView ADT, then you must also submit GameView.h. Ditto for the HunterView and DraculaView ADTs.
3. If you updated the provided Map ADT then you must also submit Map.c and Map.h.
4. If you added more test utilities to testUtils.c then you must also submit testUtils.c and testUtils.h.
5. If you used any other ADTs then you must also submit that ADT's corresponding .c and .h file. For example, if you used a Queue ADT, then you submit Queue.c and Queue.h.
6. You are not allowed to submit Game.h, Places.c or Places.h, as you were not allowed to modify these files.

Examples

A minimal submission would look like:

give cs2521 ass2view GameView.c testGameView.c HunterView.c testHunterView.c DraculaView.c testDraculaView.c Makefile

If you change the Map ADT, then your submission would look like:

give cs2521 ass2view GameView.c testGameView.c HunterView.c testHunterView.c DraculaView.c testDraculaView.c Map.h Map.c Makefile

If you add new ADTs, then your submission would be like:

give cs2521 ass2view GameView.c testGameView.c HunterView.c testHunterView.c DraculaView.c testDraculaView.c Makefile ADT1.h ADT1.c ADT2.h ADT2.c ...

Note that one of the ADT_i's could be Map.

Dryrun

When you submit, a dryrun test is run to check that you've submitted sufficient files to at least compile the tests. It does the following:

1. Checks that you've submitted all the compulsory files
2. Checks that you haven't submitted any files you shouldn't have submitted
3. Brings in these files from our end: Game.h, Places.c, Places.h
4. Brings in these files from our end if you haven't submitted them: GameView.h, HunterView.h, DraculaView.h, Map.c, Map.h, testUtils.c, testUtils.h
5. Tries to compile your program and produce testGameView, testHunterView, and testDraculaView
6. Replaces your testGameView.c, testHunterView.c, and testDraculaView.c with our stub versions, and tries to compile again

If any of these steps fail, the dryrun fails and you will be asked to fix your code or check that you are submitting the right files.

The dryrun tests will delay your submission by a couple of seconds (or minutes if you have errors in your files and need to fix them). It is your responsibility to ensure that your submission occurs on time.

You are also able to run the dryrun tests independently. To do this, run the following command:

sh /web/cs2521/20T2/ass/ass2/view/dryrun/dryrun.sh files-to-be-submitted...

Note that running the dryrun itself does not submit your files. You still need to submit them via give cs2521.

Assessment

Corrections

testGameView.c

Click here to download the new version.

• Line ~185

  char *trail =
    "GGE.... SGE.... HGE.... MGE.... DEC.... "
    "GST.... SST.... HST.... MST.... DD1.... "
    "GFR.... SFR.... HFR.... MFR....";
  
  - Message messages[] = {
  + Message messages[14] = {
    "Hello", "Rubbish", "Stuff", "", "Mwahahah",
    "Aha!", "", "", "", "Back I go"};
  

• Line ~213

  Message messages[6] = {};
  GameView gv = GvNew(trail, messages);
  
  - assert(GvGetHealth(gv, GAME_START_HUNTER_LIFE_POINTS));
  + assert(GvGetHealth(gv, PLAYER_LORD_GODALMING) == GAME_START_HUNTER_LIFE_POINTS);
  

• Line ~273

  char *trail =
    "GVI.... SGE.... HGE.... MGE.... DCD.V.. "
    "GBD.... SGE.... HGE.... MGE.... DKLT... "
    "GSZ.... SGE.... HGE.... MGE.... DGAT... "
    "GSZ.... SGE.... HGE.... MGE....";
  
  - Message messages[15] = {};
  + Message messages[19] = {};
  

• Line ~363

  assert(GvGetPlayerLocation(gv, PLAYER_DRACULA) == CITY_UNKNOWN);
  - assert(GvGetVampireLocation(gv) == STRASBOURG);
  + assert(GvGetVampireLocation(gv) == NOWHERE);
  

• Line ~472

  assert(locs[0] == BORDEAUX);
  - assert(locs[1] == BUCHAREST);
  + assert(locs[1] == BRUSSELS);
  assert(locs[2] == COLOGNE);
  

testHunterView.c

Click here to download the new version.

• Line ~078

  assert(HvGetRound(hv) == 0);
  - assert(HvGetPlayer(hv) == PLAYER_DRACULA);
  + assert(HvGetPlayer(hv) == PLAYER_MINA_HARKER);
  assert(HvGetScore(hv) == GAME_START_SCORE);
  

• Line ~084

  assert(HvGetPlayerLocation(hv, PLAYER_DRACULA) == NOWHERE);
  + 
  + HvFree(hv);
  + printf("Test passed!\n");
  

• Line ~228

  char *trail =
    "GVI.... SGE.... HGE.... MGE.... DCD.V.. "
    "GBD.... SGE.... HGE.... MGE.... DC?T... "
    "GSZ.... SGE.... HGE.... MGE.... DC?T... "
    "GSZ.... SGE.... HGE....";
  
  - Message messages[15] = {};
  + Message messages[18] = {};
  HunterView hv = HvNew(trail, messages);
  

• Line ~231

  - assert(HvGetPlayerLocation(hv, PLAYER_DRACULA) == GALATZ);
  + assert(HvGetPlayerLocation(hv, PLAYER_DRACULA) == CITY_UNKNOWN);
  assert(HvGetVampireLocation(hv) == CASTLE_DRACULA);
  

• Line ~281

  assert(round == 1);
  + 
  + HvFree(hv);
  + printf("Test passed!\n");
  

• Line ~341

  PlaceId *path = HvGetShortestPathTo(hv, PLAYER_MINA_HARKER,
                                      CONSTANTA, &pathLength);
  assert(pathLength == 4);
  - assert(path[0] == GENOA);
  + assert(path[0] == GENOA || path[0] == MILAN);
  assert(path[1] == VENICE);
  assert(path[2] == BUDAPEST);
  assert(path[3] == CONSTANTA);
  

• Line ~356

  assert(pathLength == 7);
  assert(path[0] == SARAGOSSA);
  assert(path[1] == MARSEILLES);
  - assert(path[2] == GENOA);
  + assert(path[2] == GENOA || path[2] == MILAN);
  assert(path[3] == VENICE);
  assert(path[4] == BUDAPEST);
  - assert(path[5] == GALATZ);
  + assert(path[5] == GALATZ || path[5] == KLAUSENBURG);
  assert(path[6] == CASTLE_DRACULA);
  free(path);
  

• Line ~404

  assert(locs[0] == BORDEAUX);
  - assert(locs[1] == BUCHAREST);
  + assert(locs[1] == BRUSSELS);
  assert(locs[2] == LE_HAVRE);
  

• Line ~427

  - assert(numLocs == 3);
  + assert(numLocs == 4);
  sortPlaces(locs, numLocs);
  assert(locs[0] == ADRIATIC_SEA);
  assert(locs[1] == BARI);
  - assert(locs[2] == VENICE);
  + assert(locs[2] == IONIAN_SEA);
  + assert(locs[3] == VENICE);
  

• Line ~452

  - assert(numLocs == 4);
  + assert(numLocs == 5);
  sortPlaces(locs, numLocs);
  assert(locs[0] == BELGRADE);
  assert(locs[1] == BUDAPEST);
  assert(locs[2] == KLAUSENBURG);
  assert(locs[3] == SZEGED);
  + assert(locs[4] == ZAGREB);