The Fury of Dracula

Assignment 2
The View

introductionthe rulesthe datafaq [the view]the hunt
courtesy Richard Buckland, John Shepherd, and many tutors

Marks: 100 (worth 7/15 towards assignment)
Due: 23:59 on Fri 31 July
Submissions not accepted after solution released at 23:59 on Sat 1 August
Submit: give cs2521 ass2view SubmissionFiles (see below)



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 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/
    If you're working from home, download the 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


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.


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:

a set of dependencies used to control compilation
definitions of game constants; interface to game engine
interface to the GameView ADT
skeleton implementation of the GameView ADT
main program containing a few tests for the GameView ADT
interface to the DraculaView ADT
skeleton implementation of the DraculaView ADT
main program containing a few tests for the DraculaView ADT
interface to the HunterView ADT
skeleton implementation of the HunterView ADT
main program containing a few tests for the HunterView ADT
interface to common test utilities
implementation of common test utilities
interface to the Places ADT
implementation of the Places ADT
interface to the Map ADT
implementation of the Map ADT
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.


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


You have two tasks for this part of the exercise:

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:

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:

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:

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.

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


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.


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 ADTi's could be Map.


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/ files-to-be-submitted...

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


Details coming soon...



Click here to download the new version.


Click here to download the new version.