Home

DOCUMENTATION

Welcome to our game wiki.

Table of content:

About The Game
1. Rules
2. Manual
Development info
Additional information and links
1. Stack
2. Helpful links

About The Game

Rules

Game is split into rounds. A single round consists of each player's turn, which is divided into two phases. First phase is a trading phase, in which a player can make one exchange with another player or the bank. Exchange is restricted to global rules. Second phase is a breeding phase, in which the player throws two different, 12 edge dice and is able to breed animals, that have been shown on the dice. For each pair of the same animals on the dice, or a single animal from the dice which could pair with one from your herd, a player receives a new animal of this kind from bank. However, if dice will show fox, a player has to discard all the rabbits from his herd, and if it will show wolf, all animals are discarded except for the horse. These losses can be prevented, if a player has a dog in the herd. Small dogs prevent from fox effect, big dogs prevent from wolf effect.

Manual

Game will be available here. Shortcut of all windows.

Development info

Installation

To install this application, you have to install Git and Node.js on your machine. After that use git clone https://github.com/Front-znad-zatoki/super-farmer.git, enter downloaded directory and use npm i to install application.

Running application

After you have installed the application, call start script or simply use npm start in your command line in super-farmer directory. Application will be available on 127.0.0.1:8765

Code rules

Write your code in a clear and understandable way. Remember about Clean Code, SOLID, DRY and KISS rules. Keep each component in a separate file. When you add new method, add defining comment, so IDE can assist with method description. I.e.:

   /**
   * Gets an offer from player and returns true or false if transaction can be made processed and process it if possible
   * @param offer accepts tuple with offer containing animal name and quantity to be sold
   * @param player accepts instance of Player class, which wants to sell his animals
   * @param target accepts tuple with desired animal(s) containing desired animal name and quantity to buy
   * @param bank accepts instance of Bank class, to whom will be animals sold
   * @returns true if transaction will be processed, and false otherwise
   */

To demonstrate new functionality, add functionality demo file in manuals directory and don't modify App.ts, if it's not necessary.

Don’t style by tags or ID, use classes. When you write CSS remember about right order:

Positioning: I - position, II - z-index, III - top, IV - right, V - bottom, VI - left
Display and box model: I - display, II - overflow, III - box-sizing, IV - width, V - height, VI - padding, VII - border, VIII - margin
Other: I - background, II - color, III - font-family, IV - font-size, V - text-align

And remember to write a test before you start writing a method. While writing a test keep FIRST rules.

Push changes at least at the end of day, commit changes after you have finished some part of your task.

Naming convention

Use pascal case in reusable components and class names (i.e. MenuButton), and camel case in typescript filenames and method/variable names (i.e. getRandomAnswer). Keep interfaces in separate files, add Interface at the end of class (i.e. PlayerInterface). To import from file use import statements, i.e. import App from './app/App'. All enums will be written in uppercase and saved in enums directory.

Testing

We are using jest as our main testing tool. For E2E testing we will use cypress. To run all tests run script from IDE or type npm test in console. To run tests from single file call npm test test/<filename>. Also you can check coverage of our code by typing npm run test:cov. Do not test plain objects, get/set methods and methods with unpredictable results (random/current time). Name file with tests like <filename of tested class>.spec.ts i.e. calculator.spec.ts. Run tests to your method every time you change something in it, and once you have done, run all tests to ensure, that everything works well.

As we are using TDD, make sure that tests for method will be added in first commit.

Pull Requests

Don’t commit to develop or main branches. Create an individual branch for every bug/feature. Follow that naming convention:

<type of issue>/#<number of issue>-<name referring to issue title>

Create branch from up-to-date develop branch. Before creating pull request merge your branch with develop and resolve eventual conflicts. Remember to format your code with format script (npm run format) and push changes to origin. In every PR there should be at least two reviewers, where one of them should be Techlead or someone indicated by him. In pull request description write closes #.

Comments

Write // FIX: and // TODO: with short description, if you have to wait for other part to be finished or you have to solve some problems, it will help to understand problem and allow other member of team to help you solve it. Try to write your code clearly, so there will be no need of more comments (unless you have to name variable or method with 100 character name).