Read all of your requirements (the entire assignment, project, etc.) and on a piece of paper or whiteboard, write down all of the parts/pieces.
When deciding the overall structure of your program, there are really only four types of tool you will be using most of the time. Those are: 1. Classes, 2. Methods, 3. Variables, 4. Modules. Modules are not needed at all to write a Ruby program, but they are a good tool to use to organize your code better, and something to get familiar with once you have the basics down (Class, Method, Variable). For now, focus on the first three types, and worry only about methods that don't have self in the name, and variables of the "instance", and "local" variety. Plenty of time to learn about the others once you get some context and familiarity.
To recap: When looking at one of your lego pieces, ask yourself, "Should this be a class, a method, or a variable?" QUICK AND DIRTY RULES:
- If it needs to hold multiple values, and change or use those values, it's a class.
- If it does something to a value (i.e. if it's a behavior), then it's a method.
- If it needs to maintain it's value over multiple methods (this is known as maintaining a STATE), then it's an instance variable.
- If it is just a temporary holder for a value inside of a method, then it's a local variable.
TIPS FOR DECIPHERING THE ASSIGNMENT REQUIREMENTS:
If in the requirements, you see something like "when you do this: Mastermind.something, you should get this #=> [cool, array]", the .something part tells you instantly that should be a method.
Almost any time you need a counter, or a timer, or an object you are using more than once during your program, it will be an instance variable. (@timer = Timer.new, @counter = 0, @game_map = MapGenerator.new)
If you see requirements that say something like "when you do this: Timer.new", the .new part tells you that needs to be a class.
Go through your list of parts/pieces and decide which parts should be what tools (Class, Method, Instance Variable, Local Variable) Usually you won't have many local variable pieces to start, because they come later when you need to make something happen to a value, but you need to transform it temporarily first. The reason I suggested paper or whiteboard, and not computer, is because this process will proabaly involve some shifting, erasing, and moving around of parts until you have something you think will work as an outline for your program.
IMPORTANT: What you are making is only a rough guide, and you shouldn't try to make the assignment specs fit the program model you created, rather the model should mold and conform to the assignment specs as you go. This is why it is NOT a good idea to create all of your classes once you get your model set up. Instead, keep the overall structure in mind while following the project specs. That way you should have an easier time actually putting the pieces together. Later when you are in the real world, you will get the chance to actually build everything the way you think it should be done.
Many of the early assignments, and some of the later ones, will lead you by the nose if you let them. You may need to stop and do some research to understand what an example given to you in the project specs is doing, but if you carefully follow the breadcrumb trail the instructors are leaving, you should be able to get out of the woods safely. BUT, you need to take it slow, and you need to read everything very carefully. Programming is not like normal life, where you infer, and you skip over the punctuation in your mind, and you speed read to "get the gist". Programming is about reading every single character, to make sure you don't miss anything, because missing one tiny detail early can literally result in project failure at the end.