Skip to content

TP 1

Partial Skyjo model implementation.

Meta

  • Deadline: Feb 15th, 11:59 PM
  • Submission: GitLab
  • Teams: Triplets of students, as announced in class
  • Late submission: Not possible. You will be graded by whatever contents is on your main branch at the deadline

It is your responsibility to submit code in a timely manner. Do not wait until the last minute, GitLab may fail.

Learning goals

In this TP you will gain practical experience with using a provided maven build system configuration, a third party maven repository, provided interfaces, and provided tests. You will practice brownfield development (creating a solution that integrates with existing software), by implementing solution classes that implement the provided interfaces and pass the provided tests.

Context

Skyjo as a card game is a perfect fit for the MVC pattern, i.e. a corresponding implementation consists of three packages: Model, View and Controller.

  • Model: represents state, but offers no protection, i.e. whoever has access to the model can manipulate the state in any direction, including changes that violate the game rules.
  • Controller: serves as proxy to modify model state in a controlled manner, that is, respecting the game rules.
  • View: displays model state and player options, forwards player actions to the controller.

The view has limited model access

The very point of MVC is to protect model state from illegal modifications. This includes the view. The view must never have direct write access to the model, and instead pass through the controller. To enforce this principle, the view only knows the model by its read-only interface.

  • Throughout the semester you are going to implement the Model and the Controller component for the Skyjo card game. The view is entirely provided.
  • In this TP you are requested to realize "default model" creation, and model read access.
  • You will notice the provided artifacts contain two model interfaces:
    • One for read access
    • One for write access
  • In this TP we're only interested in methods from the read-only interfaces. You can leave all write methods empty or stubs - they will not be tested.

Default model refers to an initial test model state that does not represent any randomness, that is:

  • Player names are hard coded to:
    1. "Max"
    2. "Ryan"
    3. "Maram"
    4. "Quentin"
  • Initially all cards are placed on the stack, from lowest to highest:
    • The lowest cards in the stack are the -2s.
    • The topmost cards in the stack are the 12s.
  • Afterwards cards are dealt to players:
    • One player at a time.
    • From top-left to bottom-right, line by line.
  • Finally, a single card is revealed from the fresh card stack and places on the discard card pile.

The default model construction is deterministic, that is, regardless how you implement model creation, once you display your model with the provided view, you must see this:

Round:            1
Deck   (101):  [??]
Discard ( 1):  [ 8]
Cache:         [--]

MAX  (23)             Ryan  (21)            Maram  (19)           Quentin  (17)         
[12] [??] [??] [??]   [11] [??] [??] [??]   [10] [??] [??] [??]   [ 9] [??] [??] [??]   
[??] [??] [??] [??]   [??] [??] [??] [??]   [??] [??] [??] [??]   [??] [??] [??] [??]   
[??] [??] [??] [11]   [??] [??] [??] [10]   [??] [??] [??] [ 9]   [??] [??] [??] [ 8]

Don't reinvent the wheel

The purpose of this TP is less to develop lots of new code, and more to integrate with the provided artifacts. Those contain more than just interfaces, e.g. also a Stack implementation that can be used as is. Don't reinvent the wheel - familiarize yourself with the provided artifacts and how they work by reading their documentation, before you start coding.

Project setup

  • Do not create a new project - accept the GitLab invitation (issued to you by email), as soon as you receive it.
  • Use the command git clone https://gitlab.info.uqam.ca/inf2050/2026-hiver/skyjoXX.git, to download a copy, where XX is your team number.

Do not tamper the project layout

Do not remove, rename, or modify any of the provided structure. You should only add new files. If you tamper with the project layout or modify provided files this almost certainly means your project cannot be evaluated, and you can not receive feedback.

Implementation

  • Use may use IntelliJ to develop your code, but your code will be tested on command line, using the maven command.
    • Other IDEs can be used, but are not recommended. Later in this course you will need IntelliJ-specific features.
    • It is highly recommended to test your code using the command line before submission, as this is how your solution will be assessed.
  • Double-check your java and maven version. If they do not match, it is likely your program will not behave correctly when assessed.

Dependencies

The project must be configured to use provided java interfaces, util classes and tests as maven dependencies.

  • Third party repo definition:
<repositories>
    <repository>
        <id>Max's third party repo on a UQAM GitLab file server</id>
        <url>https://max.pages.info.uqam.ca/inf2050repo/</url>
    </repository>
</repositories>

This is not a link to a webpage. It is normal to see an empty page or an error if you copy-paste it into your browser.

  • Interfaces and provided util classes:
<dependency>
    <groupId>ca.uqam.info.max</groupId>
    <artifactId>skyjo-interfaces</artifactId>
    <version>tp1-01</version>
</dependency>

Source code and documentation provided for your convenience.

  • Provided abstract tests:
<dependency>
    <groupId>ca.uqam.info.max</groupId>
    <artifactId>skyjo-tests</artifactId>
    <version>tp1-01</version>
    <scope>test</scope>
</dependency>

Source code provided for your convenience.

Reminder

Apart from the two authorized dependencies, and the third party repo, do not make any changes to the pom.xml. For this TP, tour submission will not be evaluated if you add additional libraries, plugins, etc.

Implementation classes

You must provide an implementation of the following classes for your new source model package. Your classes must implement the provided interfaces.

Build a solution for the provided requirements, not the other way round

Your code must respect the provided interfaces. You are not allowed to modify, ignore or replace interfaces.

Interface overview:

What about the factory

You'll also notice one controller interface provided: a factory for creating model objects. Why is it included ? Essentially by implementing this interface you can reduce the amount of code you Model class. The idea is to keep the model constructor free of too much logic, and let the factory do the heavy-lifting. The factory will play are more important role in the follow-up TPs, so it is a strategic choice to place as much model-creation-logic as you can into the factory class.

Test classes

  • You are for now not required to write your own tests.
  • However, your solution will be tested with a series of predefined tests, which also are meant to guide you as you implement your solution.
  • To activate these tests you only need to extend them:
    • All your tests go into the src/test/... subdirectories (not to be mixed with your production code)
    • The provided tests are all abstraction, that is, they don't test anything until you extend them
    • Extending the tests is as simple as creating a new class in your src/test/.../model directory, using the class YourTest extends AbstractProvidedTest syntax.
    • You will only need to define a single method, which provides an instance of what's to be tested to the abstract class.
  • Your solution cannot be tested if you do not extend the provided tests.
    • Intuitively this might sound good: after all, no tests means nothing goes wrong
    • In reality avoiding tests is a gigantic engineering no-go: Not tested == author cannot take liability for their code == client will not pay.
    • Submissions that do not implement all the provided abstract test classes are considered below what is acceptable, i.e. they receive no feedback beyond "0 points".
That seems overly complicated, why do I have to extend an abstract class again ?

The provided test classes tests against the provided interfaces, i.e. the assess if whatever you implemented complies to the expected behaviour. Interfaces unfortunately cannot define constructor methods, therefore we need an additional mechanism to get access to whatever-is-to-be-tested. This is the method imposed by the abstract class.

Launcher configuration

  • The initialized project contains a launcher.
  • It will neither compile, nor run. That's normal it calls the part that you still have to develop.
  • Don't modify the launcher, it is fine the way it is. Build your solution to work with the provided launcher.
  • The project is configured to only run once all tests pass:
    • Run your code with: mvn clean package exec:java
    • Alternatively, build a self-contained jar and launch it with: mvn clean package; java -jar target skyjo.jar
package ca.uqam.info.max.skyjo.view;

import ca.uqam.info.student.skyjo.controller.ModelFactoryImpl;
import ca.uqam.info.max.skyjo.controller.ModelPreset;
import ca.uqam.info.max.skyjo.model.SkyjoModelReadOnly;

/**
 * Launcher for TP1. You may edit SkyjoModelImpl constructor, but the rest should not be touched,
 * to ensure compatibility with upcoming TPs.
 *
 * @author Maximilian Schiedermeier
 */
public class LauncherTp1 {

  /**
   * Default constructor, as imposed by javadoc.
   */
  public LauncherTp1() {
  }

  /**
   * Main method, starting up TP1 code.
   *
   * @param args not used.
   */
  public static void main(String[] args) {

    // Create a model, using your model constructor.
    // Make sure your model implements the provided model readonly interface
    String[] playerNames = new String[] {"Max", "Ryan", "Maram", "Quentin"};

    /*
     This next line requires YOUR implementation of a ModelFactory to work.
     Make sure the returned model implements the SkyjoModelReadOnly interface and is a default
     model. See handout for definition of what a default model is.
     */
    SkyjoModelReadOnly model =
        new ModelFactoryImpl().createModel(ModelPreset.DEFAULT, playerNames, null);

    // Test model printing (you do not need to implement anything for this part to work, all view
    // concerns are provided).
    // If you're on windows, please set ttyColours to false, because
    // windows does not support them reliably:
    boolean useTtyColours = true;
    TextualVisualizer visualizer = new TextualVisualizer(model, useTtyColours);
    visualizer.refresh();
  }
}

Team programming

  • For future TPs you'll develop on multiple machines in parallel and merge your code using git.
  • For now, I recommend team-programming:
    • Develop together in front of one machine or using virtual team programming. One person codes, the other two help but do not grab the keyboard.
    • Change seats every 15 minutes.
  • If you cannot meet physically: Use IntelliJs code-with-me function
    • This feature is only included in the ultimate version. (See install instructions in first lecture.)
  • If you really want to alternate machines:
    • Push everything on the first machine (git add .; git commit -m "..."; git push)
    • Pull everything on the second machine (git pull)

MISC

Clutter

  • Keep your repository clutter-free. (See TP0)
  • Do not commit binary or generated files (.class files, target folder, generated javadoc)
  • Do not include any System.out.println statements in your code, this will break functionality in future TP milestones, and render the view's output less pretty.
  • Do not include any third party libraries / there must be no additional dependencies in your project, beyond what is requested.

Cheating and help

Getting legit help:

  • If you've thoroughly read the handout, participated in the TP presentation in class, and something still is not clear:
    • Ask on mattermost.
  • If you suspect something is broken, e.g. a provided test, a documentation, etc.
    • Ask on mattermost.

If you're stuck programming:

  • You can query the internet to find inspiration or help your understanding, but I recommend to never copy-paste code without fully understanding and citing the original source. I also recomment to always provide a reference / comment to the original source:
    • Copy past is rarely your friend if you're held responsible for your code.
    • Use a Java-comment // ... to provide the source, e.g. the exact stackoverflow post
  • Please do not share code with other teams, it is detrimental to their learning.
    • You can discuss ideas, you can draw concepts on a piece of paper, but never pass code.

Cheating:

  • This TP is your exam preparation.
  • The feedback I return tells you how well you understood exam-relevant concepts.
  • The more you got yourself invested, the higher you will score in the exam.
  • Using generative AI for code generation is almost certainly detrimental to your understanding.
  • I recommend you do not cheat yourself, but I also won't stop you.

Table

Item Criteria Max percentage
1 Provided tests pass 60%
2 3rd party repo and dependencies ok (pom) 15%
3 mvn clean package passes, jar working 15%
4 No clutter in repo 10%

Desk rejection

Here again the checklist of what to avoid if you want feedback on the quality of your work. If at least one item of the checklist applies, your submission will be desk rejected. There may be other criteria for desk rejection.

  • Solution not provided in dedicated GitLab directory.
  • Repository contains a zip file or other binary instead of code.
  • Code does not compile with provided maven command.
  • Provided classes do not implement provided interfaces.
  • Project structure not respected.
  • Implementation of abstract test classes is not provided in test package.
  • pom.xml has been modified, other than 3rd party repo and two provided dependencies.
  • Program attempts network communication at runtime.
  • Program attempts file system access.
  • Program stalls at runtime.