Making a flowchart for a sudoku game?

I'm not even sure where to begin.

What's the flowchart for? Playing Sudoku? Generating Sudoku games? Automatically solving them?

Regardless of the answer, the first thing to do is most likely to identify the information you need. What are the properties of Sudoku, for example the size of the grid and the rules. Identifying what information needs to go into the flowchart is a good way to identify where to start.

It's for playing sudoku. I've tried that and I'm still struggling :/

Okay so start with a list of the rules of Sudoku. These are the things you need to test for in your flowchart.

There are many different ways to play Sudoku, but let's just assume you're going to start in the top left square and work along (a brute force approach of trying every square). Start with a flowchart on how to fill in that square. Then adapt that to the whole board.

Your final flowchart might look broadly like:
Start at top left square
Does square contain a number? If so move to next square.
If not, can we place any numbers (i.e. check rules). If so, put that number in the square
Move to next square
Repeat until all squares are filled

You'd need to flesh that out depending on the level of detail required, but that would give you a very rough brute force approach to solving the Sudoku.

start
=
go to left top square (process)
=
does square contain a number? (decision) = no can we place any numbers? (decision)
= yes = yes
move to next square = --- put that number into square (process
= end

Sorry to format it like this, i cant paste the flow chart the '=' sign is an arrow lol.

No worries on the formatting, I get what you're going for.

Conceptually this is along the right lines. I don't know how much detail you require for this, so between the "can we place any numbers" and "put that number into square" you may need all the checks to find which number you can put in. You may want a check to see if all squares are filled, and if not go back to the start. Keep going though because you're heading in the right direction.

Honestly, I kind of dislike these sorts of questions because it's never clear how much detail is expected. Typically it's a flowchart for something basic like making a cup of tea, but some people get petty when you write "turn the kettle on" without adding a "do I own a kettle" check, or "does my house have electricity". You can get super pedantic about these things, and at some point every flowchart just begins with "invent the universe".

Same here. This is part of my nea a level project. I need to give some kind of algorithm (like a flowchart) to show how my solution would work. It's quite difficult as you said, very vague. My teachers don't help so I'm a bit stuck at this point. Also, thank you for taking the time to help me! I really appreciate it

No problem. If you have an idea for how the solution will work, but you're struggling to do the flowchart then you may want to think about doing it a bit backwards. Identify all the parts in your solution and then slot them into the flowchart formula.

While this won't be good practice in the real world, this isn't a real world project. From an academic perspective what matters is ticking the box to get the marks. If you find it easier to just start building the solution and updating the documentation as you go that'd be a valid approach providing you can meet the grading criteria.

True. In the specification it says: to break down the solution into smaller parts justifying the decisions made. Not sure if a flowchart will be adequate though.

I can't really comment on what you'd get the marks for, as I'm not familiar with mark schemes nor am I a marker.

But IMO if you're developing some code to solve a Sudoku (the solution) and can describe it as a collection of smaller parts, that sounds like it'd be sufficient. A flowchart is one way of describing the logic, although it's not abundantly clear what the smaller parts could be. To achieve that, you might just want to write about each smaller part (e.g. checking if a square is empty, checking if the Sudoku is complete, checking if a number can be used, etc.).

Meaning like pseudo code? Wouldn't that take quite long

Could do, if that's how you want to do it. Or you could have sections in the report describing how you've broken the project down. Or you could make a list of how you've broken it down, plan when you'll do each feature and then talk about why one could be more time consuming than another.

To give a little example, maybe one of your sections is the "check what number can go in the current box" feature. You could talk about how this feature will be used many times during the program execution, and how you'll develop it first then scale up to check each square in sequence.

The point here is that there isn't a right or wrong way to do this. If all you've been asked to do is break the solution down and justify why, then do whatever works best for you.

I see, so when I make my design section I should talk about how the player has to play my game? Or how my code works? I'll do it the way of breaking down each feature.

If you think it's important to have then yes. General rule is you can't have too much documentation, but you can have too little. Talk about anything you think is important, but remember to talk about why it's important.

One thing to note, make sure your design stage flows. "How your code works" comes from other parts of the design, such as the rules. It makes sense to order the section based on how one design choice impacts another. So if you decided to do something like a diagram or a flowchart of the entire solution, that probably comes near the end of your design section because all the other design stuff influenced that final design. And something like an initial mind map to get initial ideas would be near the start.

On a somewhat similar note, "how your code works" is more of an implementation point, rather than design. If you're talking about how your code works, you've moved beyond the design stage and have started building stuff. In the design stage you might say "based on the rules of the game my code needs to do X, Y and Z. The X feature needs to happen many times, so I will put it in a reusable function". You could write the same thing in the implementation stage, saying something like "when developing feature X I realised it would be needed many times, so I put it in a reusable function". You don't necessarily need to write both as you'd be repeating yourself, but the point is to be aware of the language you are using.

Oh I see, so the design section states what I'll need to add into my code. Not what I've already done. As in the future. Or else it'll sound like the development sction right? At the moment rather than making an algorithm I'm thinking of just stating what I can do. Or it may sound too vague right? I can see where you're coming from haha.

Correct. The design section should discuss all the elements you've designed, while the development section covers actually implementing the design. Ideally if you gave the design section to someone else, they should have everything they need to build whatever you're building. You might decide to prototype ideas as part of the design stage to see what works, but you shouldn't actually be talking about the built solution because as you say that's the development section.

Don't worry if stuff sounds vague, you can flesh it out as you go. The design stage is typically something that develops as you go along. You might list all the parts you need to build, do some other part of the design and realise you missed something earlier. Or you may change your plans and need to redesign some elements. Starting off with vague ideas is fine to get an idea of where you're going. Sometimes academics are really picky about "doing the entire design stage before moving on", but in the real world what often happens is you design something, build it and then tweak the design as you go.

IDK how much it matters at A Level, but you may want to avoid using multiple tenses when writing your report. Although the design section is focused on "I'm planning how to do X" (future tense) whereas the development section is "This is how I did X" (past tense), good academic writing won't use first person and will stick to one tense. So something like "This diagram describes how the components fit together" rather than "I created this diagram which describes how the components fit together". Or "During development this problem arose and was fixed by doing Y", rather than "I ran into this problem so I did this thing to fix it". But that could be beyond the scope of an A Level mark criteria, so don't worry about it too much. Seek clarification from your teachers regarding the writing style.

Thank you so much! I've started it off, I deleted my flowchart and instead tried to list the ideas that I could implement in my code and how it affects the solution. However, when I looked at the Ocr exemplar papers they had nothing remotely close to writing out the design section. They all used some kind of flowchart or top down design. Also, I've tried emailing my teachers and none of them got back to me haha so I'm kind of relying on TSR to help me out. :/

Ideally it'd be good to stick to something that's similar to the example material, but unless the mark scheme actually says you need to use a certain method you shouldn't be penalised for it. IMO the best approach is usually a mix of words and diagrams, so maybe start with listing ideas and later try to turn some of it into diagrams to support the report. Hopefully your teachers get back to you, it was a bank holiday yesterday and I assume they're running around trying to get things ready for the new year.

Word of advice, never delete anything. You never know when you might want something later on, so take any files you don't need for now and just dump them in a folder out of the way. If later on you do find you need to do a flowchart you'll need to start again.

After completing this I was thinking of doing a top down design on the solution and then explaining reasons as to why I've decomposed each step.