Rock, paper, scissors, with the webcam

An image model starts with a name and no examples from your task. It works like the Level 2 image lab: a pretrained network, trained earlier on many other photos, turns each photo into numerical features, and your labelled photos teach a small classifier on top of them. Creating hands is not yet training it on your gestures.

Choose three definitions: closed fist is rock, open palm is paper, and two extended fingers is scissors. Consistent labels matter more than the particular word chosen for the model variable.

Add make an image model called hands from Images. Put a simple status message below it.

The capture statement asks for ten photos under one label. All ten must show rock according to your definition. Vary pose and distance a little while keeping the class correct. Ten adjacent nearly identical frames are less varied evidence than ten meaningfully different views.

This partial stage is for learning collection. It is not yet a two-or-more-class training task. Starting another Run clears this temporary collection, so the final program must include every group before training.

Connect add 10 webcam photos to hands labeled rock. Run only if you want to practise the capture interface; allow the camera when your browser requests it.

The second capture group uses the same camera and label rules, with an open palm for paper. Keep backgrounds and lighting shared across classes. If every rock photo has one background and every paper photo another, background becomes an easy shortcut.

Both groups belong to hands. A second make-image-model statement here would reset the collection instead of extending it.

Add the paper capture below rock without another make-image-model block. Inspect the two capture labels before running.

Scissors completes the label set the game rules will expect. The collection now describes a three-class recognition task. Inspect it before training; a confidently wrong label on a training photo can teach the opposite of what you intended.

Count is one check and content is another. Equal numbers do not guarantee useful diversity or correct labels. Make a note of which hand, angles, lighting, and backgrounds you used so later tests can explore something new.

Add scissors as the third capture group. Keep show photos after all three groups. Read the label shown by each capture prompt.

Train image model hands trains the classifier for your three classes, using the collected photos. The work happens in your browser. Initial model resources may need to load first, and training time depends on the device. Wait for status updates instead of repeatedly pressing Run.

Prediction comes next. Training sees the labels and adjusts the classifier. Prediction receives a new photo with no label and asks which class gets the strongest support.

Place train image model hands below the inspection. Run the whole collection-and-training stack when you are ready to capture all three classes.

Capture one test photo and store it as photo. Both image-label and confidence read that same value. If each socket contained a separate camera block, you could classify one gesture and display the score for another.

The result is measured, so this article cannot promise a particular number. Compare the label with the gesture you actually showed. A high score is evidence about this model's preferences, not a correctness guarantee.

Below training, set photo to a webcam photo. Set move and sure using the rounded photo variable. Put labelled output statements after those assignments.

The outer condition decides whether to use the recognition result in the game. A score below 60 makes the program say it is unsure. The other branch prints the label and score. This placement stops the game from treating an unsure label as a valid move.

An unfamiliar elbow or empty frame may still get a high score for one of the three classes. A threshold is not a reliable neither detector, so evaluate the rule instead of assuming it works on everything.

Put both accepted-result output blocks inside otherwise. Put only the unsure message in the below-60 branch.

The game is a separate system from the recogniser. Start with known moves so you can check the if/else logic without collecting photos. First handle equality as a draw, then the three combinations that make the player win. All other valid pairs make the computer win.

This is why each winning test uses AND: both the player's move and the opponent's move must match the specific pair. Checking rock alone would wrongly award a win against paper.

Build the nested decision using fixed move and computer assignments. Load this stage to isolate the rules, then inspect each condition and branch.

The list defines the allowed opponent choices. A random whole number from one to three supplies a valid item position for this block interface. Randomness changes the opponent, while the game rules always give the same result for the same pair of moves.

The list order is rock, paper, scissors. If you add a fourth class later, changing the random bound alone will not make the existing rules valid; the game definition must change too.

Create moves and append the three labels. Nest a random whole number in item-of-moves, then store that item under computer before the verdict.

The final stack keeps collection and training above the round loop. Each of five turns captures one new photo, reads its prediction and score, applies the gate, and plays a round only if the gate accepts the move. The learned image model is reused throughout that one run.

An unsure answer uses up an attempt in this version; the program does not retry forever until it is confident. That explicit rule prevents an unclear gesture from trapping the program in an endless loop. A fresh Run restarts collection, while another loop turn reuses the same trained model.

Build the final loop below training and the move list. Place photo capture, label, score, and gate inside repeat. Keep Five attempts complete below the loop.