Assignment U1#

Applies to:COMP1110
Released by:Monday, 24 February 2025, 09:00
Base assignment deadline:Friday, 07 March 2025, 15:00
Code Walk registration deadline:Friday, 07 March 2025, 18:00
Code Walk registration link:CWAC
Code Walks:
Thursday, 13 March 2025
Friday, 14 March 2025
GitLab template repository:(link)
GitLab CI file:.gitlab-ci.yml
Minimum Library Version:2025S1-3
Last Updated:Thursday, 27 February 2025, 12:00

This assignment is restricted to using the Functional Java libraries. Please note the required minimal library version above! In everything you do, you must follow the Design Recipe. To see roughly how this assignment will be marked, check out the Skeleton Rubric.

You really really need to stick to the restrictions of Functional Java. Don’t just write Java code simply because you already know Java. The penalties in the rubric for doing so are quite harsh.

Formalities#

This assignment is submitted via GitLab.

Access to Your Repository#

In order for us to be able to collect and mark it, you need to satisfy the following conditions:

  • Your repository’s name must be comp1110-2025s1-u1 (exactly), placed directly in your user namespace (the default). That is, if your uid is u1234567, the address of your GitLab project should read as https://gitlab.cecs.anu.edu.au/u1234567/comp1110-2025s1-u1.
  • Your repository must have our marker bot (comp1110-2025-s1-marker) added as a Maintainer.

You can achieve both these points by creating your project through forking our template repository and not changing the name, or by just using the correct name when creating the project and then manually adding the bot.

Notebooks and Push Requirement#

You need to keep a notebook file as explained on the Git and Notebooks page. You need to commit and push the current state of your files:

  • at the end of every session where you work on the assignment
  • at least once per hour (our checks implement this that no two pushes during sessions recorded in the notebook are more than 70 minutes apart).
  • at least once per major part of the assignment (i.e. for this assignment, at least four times). You are absolutely free to commit and/or push more often than that.

You need to write informative commit messages, and informative notes for each session in your notebook, which describe what it is that you did for this particular commit or session, respectively.

Statement of Originality#

Your submission (and therefore your git repository) needs to include a signed statement of originality. This must be a text file named soo.txt. That file must contain the following text, with the placeholders [your name here] and [your UID here] replaced with your name and UID, respectively:

I declare that this work upholds the principles of academic
integrity, as defined in the University Academic Misconduct
Rule; is entirely my own work; is produced for the purposes
of this assessment task and has not been submitted for
assessment in any other context, except where authorised in
writing by the course convener; gives appropriate
acknowledgement of the ideas, scholarship and intellectual
property of others insofar as these have been used; in no part
involves copying, cheating, collusion, fabrication, plagiarism
or recycling.

I declare that I have not used any form of generative AI in
preparing this work.

I declare that I have the rights to use and submit any assets
included in this work.

[your name here]
[your UID here]

Files Summary#

Your repository must be accessible to us and must contain the following files in its root directory:

  • notebook.yml - your Notebook
  • soo.txt - your signed Statement of Originality

Code-Walk Registration#

Our goal is to eventually move to CWAC for Code-Walk Registration and Schedule Preferences. As of the release of this assignment, that system is not yet ready. In the meantime, you can use this form to indicate that you want to be scheduled for a code walk for this assignment. We recommend that you wait until the start of week 2 to do so.

The deadline for registering to participate in code walks is Friday, 07 March 2025, 18:00. You need to do this in order for your assignment submission to get marked!

Tasks#

Part 1#

In a file called Baskets.java

We’ll model baskets of apples and oranges. Specifically, a basket contains either some number of oranges, or some number of apples. If a basket contains apples, we are also interested in the colour of the apples: typically, red, green, or yellow - but who knows what the geneticists have come up with?

Write a function that compares two baskets. If there is only one type of fruit involved in the comparison, then whichever basket has more pieces of fruit in it is better (and the other one is worse). If one basket contains apples and the other basket contains oranges, the baskets are incomparable.

Model the relevant data types and design the following function:

// [R] should be replaced with whatever type you use to model
//     results of the comparison
// [B] should be replaced with whatever type you use to model
//     baskets
// model colours as strings

/** Tries to compare two baskets. Returns whether the first
 * basket is better or worse than, or equal or incomparable
 * to the second basket */
[R] Compare([B], [B])

Follow the Design Recipe!

In addition, provide the following testing interface:

// To indicate what kind of result an [R] represents
boolean isBetter([R])
boolean isWorse([R])
boolean isEqual([R])
boolean isIncomparable([R])

// To indicate what kind of basket a [B] represents
boolean isAppleBasket([B])
boolean isOrangeBasket([B])

// To access one of the fields of your basket representation
int numberOfFruit([B])

// To construct values of your basket representation
[B] makeAppleBasket(int, String)
[B] makeOrangeBasket(int)

Follow the Design Recipe!

Part 2#

In a file called Baskets.java

A small town in the countryside celebrates Halloween every year, with kids going from house to house in their neighborhood to obtain sweet snacks, but with an interesting twist: the parents are all really obsessed with healthy eating, and so the kids only get fruit baskets instead of candy. Each kid can only carry one basket, so if they get one, they have to give away their current one.

Each kid has their very own peculiar set of preferences that they will use to judge how they value one basket compared to another. For example, one kid might always prefer any basket with more fruit of any kind. Another might always want apples, and the more of them, the better, but might also trade oranges for more oranges in the hopes of getting more bargaining power for apples later. Yet another kid might always trade for any number of non-zero golden apples, but otherwise prefer any basket with a prime number of fruit of whatever kind, unable to really decide between them, over all the other boring possible baskets (all equal). We model these preferences using BiFunctions, following the model of our Compare function above.

We model two scenarios for kids going around swapping baskets on Halloween. The first is when they go to someone’s house, where they will be offered some basket, and will have to decide whether to swap it against their current one.

If they value the basket they were offered more, the kid will swap their current basket for the new one. If they value their current basket more, the kid will refuse the basket they were offered. If they value the baskets equally in principle, then they prefer the one that they are offered (it’s new and shiny!). If they can’t decide between the baskets, then their parents will throw a coin to decide for them.

The second scenario is when two kids meet each other. They may decide to swap baskets, but such an exchange will only happen if none of the two kids is opposed to it. The special case that arises here is if both kids are undecided. In that case, both kids’ parents throw a single coin together to decide whether the exchange will happen or not, instead of each family doing this separately.

Design the following two functions:

// [K] should be replaced with whatever type you use to represent
//     a kid

/** Computes the result of a kid visiting a house and being offered
 *  a basket.
 *  The result value is a pair of the kid after making its decision 
 *  (possibly holding a new basket) and the basket that was left 
 *  over, either by the kid giving it away, or by the kid refusing
 *  to accept it.
 */
Pair<[K], [B]> visitHouse([K] kid, [B] offeredBasket)
/** Computes the results of two kids meeting each other and
 *  potentially swapping baskets.
 *  The result value is a pair of kids, corresponding to the order
 *  of the arguments of the function, but possibly holding
 *  different baskets than before.
 */
Pair<[K], [K]> meetFriend([K] kid1, [K] kid2)

Follow the Design Recipe!

Additionally, provide the following testing interface:

// To construct values of your kid representation
[K] makeKid(String name, BiFunction<[B], [B], [R]> basketValuation, [B] initialBasket)

// To access properties of your kid representation
[B] getBasket([K])
String getName([K])
BiFunction<[B], [B], [R]> getValuation([K])

Part 3#

In a file called Baskets.java

Write a main function for this program that allows for comparing baskets. It asks for exactly one line input, of the form:

[n] {[c] apples | oranges} =? [n] {[c] apples | oranges}

In the above string, [n] is replaced by some non-negative integer, [c] by some colour name that does not contain any spaces, and { ... | ... } means either the left or the right case.

Example inputs are:

"5 oranges =? 7 green apples"
"2 red apples =? 2 red apples"
"13 oranges =? 4 oranges"

The program should convert these strings into inputs for the Compare function you defined in part 1, and then run that function. Based on the result of that function call, the program should then print one of “Better”, “Worse”, “Equal”, or “Incomparable”.

Follow the Design Recipe!

Provide the following testing interface:

// parses a String of the form "[n] {[c] apples | oranges}" into
// the corresponding basket representation
[B] parseBasket(String s);

Part 4#

This part depends on content we’ll discuss in Workshop 3A. You can read through it, but should probably not attempt it until then.

In a file called Balloons.java

Design a game where the goal is to pop as many balloons as possible in a short amount of time. The game runs in an 800 pixels wide and 500 pixels high world. It starts in a main menu, displaying the text “Click to Start Game”. On a click, the game starts, and runs for 20 seconds.

Balloons are drawn as either an ellipse that is 30 pixels wide and 40 pixels high, or a suitable image drawn into the same bounding box. They start from below the bottom of the world, and float upwards at a suitable, constant speed (all balloons should move at the same speed). Every 5 ticks, a new balloon is spawned at a random X position. The X position may be such that the balloon is partially outside of the world, but a bit of it needs to be visible once it reaches some height.

When the player clicks a balloon, it pops and thus disappears, increasing the player’s score by one. The top left of the screen should display some text that shows the current score and remaining time in seconds.

When the game time has elapsed, the games witches back to the menu, displaying the “Click to Start Game” message, but also the score of the last game, and the highest score achieved so far (which may be the same). Another click then starts a new game.

Follow the Design Recipe!

Provide the following testing interface:

// [W] should be replaced with whatever type you use to represent
//     the world state
// [L] should be replaced with whatever type you use to represent
//     a balloon

/** whether the given world represents a main menu */
boolean inMainMenu([W]);

/** your mouse event handling function */
[W] mouseEvent([W], MouseEvent)

/** your stepping function */
[W] step([W])

/** your drawing function */
Image draw([W])

/** returns the initial state of your world */
[W] getInitialState();

// coordinates of the center of a balloon
int getX([L]);
int getY([L]);

//only available if inMainMenu(world) is false:
int currentScore([W] world);
ConsList<[L]> getBalloons([W] world);

Updates#

Monday, 24 February 2025, 11:00Fixed code walk registration link to go to form for U1 instead of P1.
Monday, 24 February 2025, 17:00Updated standard library version to 2025S1-3. This addresses a problem we discovered with key descriptions, which are different on MacOS from Windows and Linux by default. They are all the same now, but MacOS users will have to adjust any hardcoded key names that they have already used.
Thursday, 27 February 2025, 12:00Added note that Part 4 depends on content of Workshop 3A
bars search caret-down plus minus arrow-right times