This program runs The Pickling Game, a game where people can learn to pickle things. It will influence people of the importance of preserving different foodstuffs, to use things that might be otherwise wasted, and to encourage them to experiment with pickling different kinds of foods. It is intended to target people with an interest for making or preparing food, people who value sustainability, and people who like pickles and/or text adventure games.

There is only one type of pickling involved in The Pickling Game so far, a version of Quick pickling. However, the option of slow pickling and other variations of pickling will be introduced.

Business Goals:

• Food Preservation
• Sustainability
• Teaching culinary skills
• Teaching self-sufficiency
• Preserving old skills

In the game, the user is able to create and store jars of pickles. Each jar will contain pickles of varying quality according to how well the user pickles their ingredients. The player will be able to challenge themselves to guess how to make pickles, or to view hints/instructions on how to make a successful jar of pickles.

At the pickling table, tha player makes their jars of pickles. At the fridge, the player stores their jars of pickles. The player may then taste samples from each jar, once the jar of pickles has been made and stored for a given period of time.

In this section, you should go over the different parts of your project, and describe each in a sentence or so. You will need to explain what value each of the features provides for the user, focusing on who this website is for, what it is that they want to achieve and how your project is the best way to help them achieve these things.

• XYZ

  • Navigation
  • This section will allow the user to ...


• XYZ

  • Navigation
  • This section will allow the user to ...


• XYZ

  • Navigation
  • This section will allow the user to ...


For some/all of your features, you may choose to reference the specific project files that implement them.

In addition, you may also use this section to discuss plans for additional features to be implemented in the future:

• Another feature idea

In this section, you need to convince the assessor that you have conducted enough testing to legitimately believe that the site works well. Essentially, in this part you will want to go over all of your project’s features and ensure that they all work as intended, with the project providing an easy and straightforward way for the users to achieve their goals.

In addition, you should mention in this section how your project looks and works on different browsers and screen sizes.

You should also mention in this section any interesting bugs or problems you discovered during your testing, even if you haven't addressed them yet.

If this section grows too long, you may want to split it off into a separate file and link to it from here.

• HTML
  • No errors were returned when passing through the official W3C validator
• CSS
  • No errors were found when passing through the official (Jigsaw) validator

You will need to mention unfixed bugs and why they were not fixed. This section should include shortcomings of the frameworks or technologies used. Although time can be a big variable to consider, paucity of time and difficulty understanding implementation is not a valid reason to leave bugs unfixed.

This section should describe the process you went through to deploy the project to a hosting platform (e.g. GitHub)

• The site was deployed to GitHub pages. The steps to deploy are as follows:
  • In the GitHub repository, navigate to the Settings tab
  • From the source section drop-down menu, select the Master Branch
  • Once the master branch has been selected, the page will be automatically refreshed with a detailed ribbon display to indicate the successful deployment.

The live link can be found here - https://code-institute-org.github.io/love-running-2.0/index.html

In this section you need to reference where you got your content, media and extra help from. It is common practice to use code from other repositories and tutorials, however, it is important to be very specific about these sources to avoid plagiarism.

You can break the credits section up into Content and Media, depending on what you have included in your project.

• The text for the Home page was taken from Wikipedia Article A
• Instructions on how to implement form validation on the Sign Up page was taken from Specific YouTube Tutorial
• The icons in the footer were taken from Font Awesome

• The photos used on the home and sign up page are from This Open Source site
• The images used for the gallery page were taken from this other open source site

Congratulations on completing your Readme, you have made another big stride in the direction of being a developer!

Below you will find a couple of extra tips that may be helpful when completing your project. Remember that each of these projects will become part of your final portfolio so it’s important to allow enough time to showcase your best work!

• One of the most basic elements of keeping a healthy commit history is with the commit message. When getting started with your project, read through this article by Chris Beams on How to Write a Git Commit Message

  • Make sure to keep the messages in the imperative mood

• When naming the files in your project directory, make sure to consider meaningful naming of files, point to specific names and sections of content.

  • For example, instead of naming an image used ‘image1.png’ consider naming it ‘landing_page_img.png’. This will ensure that there are clear file paths kept.

• Do some extra research on good and bad coding practices, there are a handful of useful articles to read, consider reviewing the following list when getting started:

  • Writing Your Best Code
  • HTML & CSS Coding Best Practices
  • Google HTML/CSS Style Guide

Getting started with your Portfolio Projects can be daunting, planning your project can make it a lot easier to tackle, take small steps to reach the final outcome and enjoy the process!