Recent Question/Assignment

Assignment 02: Building a custom view to implement the game of Draughts
Barry Denby
October 14, 2019
1 Assignment Information
Course: MSCC
Stage / Year: 1
Module: Mobile Development
Semester: 1
Assignment: 2 of 3
Date of Issue: 2019-10-16
Assignment Deadline: 2019-11-24 @ 23:55 (End of week 9)
Assignment Submission: Upload to Moodle
Assignment Weighting: 16% of Module
2 Introduction
NOTE: read the whole assignment brief first before implementing it contains very important information
In this assignment you will be tasked with building an entire custom view for the game of Draughts. You will be responsible for all drawing, touch interaction, and the ability to customise it.
The game is a two player game played on an 8x8 checkerboard. Each player starts with 12 pieces that can only move and capture diagonally on the board. The objective is to eliminate all the other player’s pieces. Pieces can only move forward up the board until they get to the other side where they are kinged. Kinged pieces can move in all four diagonal directions from there on in.
if you are looking for a general rule set you will find one here https://en. wikipedia.org/wiki/English_draughts
Once the general custom view is finished you will then integrate it into a UI in the later brackets.
NOTE: This is an individual assignment. It is not a group assignment. You can discuss ideas/algorithms but you cannot share code
NOTE: that you are also required to show me a working example of your brackets in labs. I will only consider marking those brackets that I’ve seen in labs. If you have only shown me the first four brackets in a lab I will not consider the rest.
3 Submission and Penalties
You are required to submit two separate components to the Moodle
• An archive containing your complete Android Studio Project. The accepted archive formats are: zip, rar, 7z, tar.gz, tar.bz2, tar.xz. The use of any other archive format will incur a 10% penalty before grading.
• A PDF containing documentation of your code. If you do not provide documentation your code will not be marked. Copying and pasting code into a PDF does not count as documentation.
There are also a few penalties you should be aware of
• Code that fails to compile will incur a 30% penalty before grading. At this stage you have zero excuse to produce non compiling code. I should be able to open your project and be able to compile and run without having to fix syntax errors.
• The use of libraries outside the SDK will incur a 20% penalty before grading. You have all you need in the standard SDK. I shouldn’t have to figure out how to install and use an external library to get your app to work
• An omission of a git repository attached to your email address that is registered for GCD will result in your application and documentation not being graded.
• The standard late penalties will also apply
You are also required to submit as part of your archive a working Git repository.
• When I unpack your archive there should be a .git directory as part of it.
• This should be a fully working git archive.
• You are not permitted to upload your work to Github, Gitlab, or any other publicly visible git repository (assignment will be marked as a zero if it is)
• If you need a remote git repository the only permitted one is the college provided Gitlab which can be found at gitlab.griffith.ie
• There must be a minimum of seven commits in the git repository, one per completed bracket.
Very Important: Take note of the grade brackets listed below. These are meant to be completed in order. If you skip a bracket or do not complete a bracket following brackets will not be considered for marking. You should be well capable of producing strong and generally robust software by now. For example if there are six brackets and you fail the third one, then the fourth, fifth, and sixth brackets will not be marked. Documentation brackets will be treated separately from Coding brackets.
You should also be aware that I will remove marks for the presence of bugs anywhere in the code and this will incur a deduction of between 1% and 15% depending on the severity. If you have enough of these bugs it is entirely possible that you may not score very many marks overall. I want robust bug free code that also validates all user input to make sure it is sensible in nature.
Also note that the percentage listed after the bracket is the maximum mark you can obtain if you complete that many brackets without error. Everything in all brackets is mandatory.
4 Plagiarism
Be aware that we take plagiarism very seriously here. Plagiarism is where you take someone else’s work and submit it as if it was your own work. There are many different ways plagiarism can happen. I will list a few here (this is not exhaustive):
• Finding something similar online (full implementation or tutorial) that does the same job and submit that.
• Finding something similar online (full implementation or tutorial) and transcribing (i.e. copying it out by hand)
• Working together on an individual assignment and sharing code together such that all implementation look the same.
• Getting a copy of someone else’s code and submitting/transcribing that
• Doing any of the above and attempting to conceal it by moving functionality around and renaming functions and variables.
• Paying someone to do your assignment
I’ve had to deal with many cases of plagiarism over the last six years so I can spot it and diagnose it easily, so don’t do it. To prevent plagiarism include but not limited to the following:
• Do all your code by yourself
• Don’t share your code with anyone, particularly if anyone looks for a copy of your code for reference.
• If you need to find information online only query about very specific problems you have don’t look for a full assignment or howto.
Be aware that if you submit your assignment you accept that you understand what plagiarism is and that your assignment is not plagiarised in any way.
5 Coding Brackets (70%)
1. Bracket 1 (10%)
• Create the basic shell of an application.
• Create the basic shell of a custom view.
• Force the custom view to be square in size (Bracket failure if not forced).
2. Bracket 2 (20%)
• Get the custom view to render an 8x8 grid that is adaptable in size (bracket failure if fixed sizing used).
• Get the custom view to render the initial state of the game (bracket failure if fixed sizing used).
3. Bracket 3 (30%)
• Enable touch interaction to allow a user to select a piece then select a location for it to move to.
• Enable player1’s pieces to move diagonally up and right, or up and left provided the space is adjacent to where the piece is and there is nothing occupying it.
• Enable player2’s pieces to move diagonally down and right, or down and left with similar restrictions.
4. Bracket 4 (40%)
• Modify touch interaction to enable the player to make a simple capture, captures follow similar logic to movement except there must be an empty square behind the captured piece.
• Modify the logic of the game to keep a player’s move if there is the possibility of chaining multiple captures together.
5. Bracket 5 (50%)
• When a player’s piece has made it to the other side of the board king it (including showing a visible difference).
• Add in logic for the king pieces to move both forward and back in all diagonal directions.
6. Bracket 6 (60%)
• Modify the logic of captures to allow kings to capture backwards.
• Modify the logic of chaining to allow kings to chain a capture in any direction.
7. Bracket 7 (70%)
• Add in UI elements to keep track of the current player, how many pieces each has, and a button to reset the game.
• Add in a settings activity that permits the user to theme the board by defining the colours of the squares and of the pieces, the custom view should reflect these changes.
6 Documentation Brackets (30%)
NOTE: Documentation should be around 2,000 words in length total
8. Bracket 8 (0 to 10%): Document every method in your code from a highlevel perspective. i.e. give an overview of what the method does. Do not copy and paste code you will be penalised for this.
9. Bracket 9 (10 to 20%): Document every datastructure and database designyou have used in your code and why you chose them. You do not need to provide an E-R diagram for database designs.
10. Bracket 10 (20% to 30%): Detail any design decisions you made that youconsider to have improved the ease of use of your UI or you consider innovative. If you have made custom views detail their design and mathematics here

Looking for answers ?