Two players compete to get a line of noughts or crosses in a 3x3 grid. Players take turns to place a piece and the game ends when either player has three in a row, column, or diagonal. A draw occurs if no player has got a line of 3.
A player faces off against the computer choosing rock, paper or scissors as their move. Paper beats rock, rock beats scissors, and scissors beats paper.
In a grid of tiles, a player flips tiles until they find two that match. Once all tiles have been flipped and matched, the game ends.
Before building the feature, you might like to spend some time planning exactly what it it should do. You might like to draw out the user interface on paper or create some wireframes.
Break your feature down into it’s constituent parts, don’t try to code it all as one monolith. You might like to use separate functions for each large part of the feature. You might use comments in your code to remind yourself what each part is doing.
Focus on building one part at a time, and test it as you go. You might use tutorials for different parts, if you are - we recommend trying to write all the code yourself and refactoring it until it makes sense to you.
If you’re offered an interview with Founders and Coders, we’ll usually ask you to talk through some of your code. Being able to explain what the code does in conversational English is an important skill for any developer.
Copy and pasting or following a tutorial without thinking about what the code is doing will limit what you learn. When you’re finding help elsewhere, aim to build within your own skillset and in a way that makes sense to you.
You will face errors, challenges and bugs as you build a feature. This all part of being a developer. Knowing what to do when you face a problem is what makes a good developer. Focus on following a path through your code, understanding what is happening at each step, and checking whether you’re getting expected results by logging values.
Rubber Ducking is explaining code aloud to debug and gain a fuller understanding of what is happening.
You’ll likely use
console.log() often as you work through the project to check what is happening in your code.
Using Google, resources, articles, and asking for help on Discord will all help you when you’re in a pickle. Even taking a walk around the block, or sleeping on something can be all you need to resolve a tricky bug.
We’d like to hear about what you created, and how you created it. For this project, you’re required to include a
README.md file. These are written in Markdown and give an overview of the project. You might like to include sections which follow the three headings above: planning; building; and debugging.
The above examples give you a sense of the kind of feature we’re looking for. It’s up to you to build something that you find challenging, and engaging.
We’re looking for creative features that you have built yourself. Is there something you’ve always wanted to see on a website? A type of game you enjoy? Something that would add additional functionality to your site? And most importantly, find something you enjoy building!