diff --git a/Element-Paquets d'erreur.odg b/Element-Paquets d'erreur.odg new file mode 100644 index 0000000000000000000000000000000000000000..dd11c33d4ae6fa893eea1ea85662ec1600a48082 Binary files /dev/null and b/Element-Paquets d'erreur.odg differ diff --git "a/Element-Paquets de donn\303\251es.odg" "b/Element-Paquets de donn\303\251es.odg" new file mode 100644 index 0000000000000000000000000000000000000000..df38d52e2b345a77c829f1382a84f4126cabdc2c Binary files /dev/null and "b/Element-Paquets de donn\303\251es.odg" differ diff --git a/Element-Paquets de routage.odg b/Element-Paquets de routage.odg new file mode 100644 index 0000000000000000000000000000000000000000..3f3cdeee91e8e49c2a6b54147b0134ff57d0b7b0 Binary files /dev/null and b/Element-Paquets de routage.odg differ diff --git a/Element-Pelleteuse.odg b/Element-Pelleteuse.odg new file mode 100644 index 0000000000000000000000000000000000000000..f61aca2e32e11969d432d599001c3f6cc6a5c512 Binary files /dev/null and b/Element-Pelleteuse.odg differ diff --git a/Element-Plateau de jeu.odg b/Element-Plateau de jeu.odg new file mode 100644 index 0000000000000000000000000000000000000000..73a7b83d866ab7f7c929250d9c2bedbfe1cede7e Binary files /dev/null and b/Element-Plateau de jeu.odg differ diff --git a/Element-Tables de routage 1 (blanc).odg b/Element-Tables de routage 1 (blanc).odg new file mode 100644 index 0000000000000000000000000000000000000000..289853d62515101e63f3ea6590530042a72e8281 Binary files /dev/null and b/Element-Tables de routage 1 (blanc).odg differ diff --git a/Element-Tables de routage vierge.odg b/Element-Tables de routage vierge.odg new file mode 100644 index 0000000000000000000000000000000000000000..789de552f20a87a2300bb9681faa00923553c6fa Binary files /dev/null and b/Element-Tables de routage vierge.odg differ diff --git a/Jeu du routage.odt b/Jeu du routage.odt new file mode 100644 index 0000000000000000000000000000000000000000..535cee70e452e7695675e4df00097d8aba99a1d3 Binary files /dev/null and b/Jeu du routage.odt differ diff --git a/README.md b/README.md index eebf7e2110b3e6998e5fdb30e05687031be38720..42e3b638c19e0d2cdff41c09ceb8a2b3a55e4c02 100644 --- a/README.md +++ b/README.md @@ -1,93 +1,21 @@ # Jeu serieux sur le routage +## Licences -## Getting started +L’ensemble des documents sont sous licence « CC BY-SA 3.0 René Chalon » sauf : +* Image de la pelleteuse : CC BY 3.0 Made by Made (http://www.madexmade.com) -To make it easy for you to get started with GitLab, here's a list of recommended next steps. +## Documentation -Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)! +Voir le fichier : "Jeu du routage.odt" -## Add your files +TODO : +* ajouter des explications supplémentaires +* proposer un scénario d'utilisation complet -- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files -- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command: +## Éléments de jeu -``` -cd existing_repo -git remote add origin https://gitlab.ec-lyon.fr/chalon/jeu-routage.git -git branch -M main -git push -uf origin main -``` +Tous les éléments de jeux sont à imprimer sur du papier A4 80g blanc ou de couleur (voir dcoumentation) -## Integrate with your tools -- [ ] [Set up project integrations](https://gitlab.ec-lyon.fr/chalon/jeu-routage/-/settings/integrations) - -## Collaborate with your team - -- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/) -- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) -- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically) -- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) -- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/) - -## Test and Deploy - -Use the built-in continuous integration in GitLab. - -- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/) -- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) -- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html) -- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/) -- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) - -*** - -# Editing this README - -When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template. - -## Suggestions for a good README - -Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information. - -## Name -Choose a self-explaining name for your project. - -## Description -Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors. - -## Badges -On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge. - -## Visuals -Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method. - -## Installation -Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection. - -## Usage -Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README. - -## Support -Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc. - -## Roadmap -If you have ideas for releases in the future, it is a good idea to list them in the README. - -## Contributing -State if you are open to contributions and what your requirements are for accepting them. - -For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self. - -You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser. - -## Authors and acknowledgment -Show your appreciation to those who have contributed to the project. - -## License -For open source projects, say how it is licensed. - -## Project status -If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers. diff --git a/pelleteuse.png b/pelleteuse.png new file mode 100644 index 0000000000000000000000000000000000000000..cd186b5036b051a66e43b88d52879ac2a7c3cd29 Binary files /dev/null and b/pelleteuse.png differ