Hi
Im new to java and im curently building a sudoku game.
At the minute i have a gui class which builds my gui with 81 text fields and a few jbuttons to load save etc.
im planning on using a 2d array. i want to be able to load a puzzle into a 2d array and then for the puzzle to be displayed in my 81 textfields.
Hope this makes sense?
any help appreciated.
Thanks.
> Hi
>
> Im new to java and im curently building a sudoku
> game.
>
> At the minute i have a gui class which builds my gui
> with 81 text fields and a few jbuttons to load save
> etc.
>
> im planning on using a 2d array. i want to be able to
> load a puzzle into a 2d array and then for the puzzle
> to be displayed in my 81 textfields.
>
> Hope this makes sense?
It does. If your array is 9x9 ^_^
>
> any help appreciated.
You didn't ask for anything in particular
> whats the best way then? i want to keep it as simple
> as possible.
"simple" is not a simple concept ;-)
If by "simple" you mean "the smalles amount of files to handle" then your approach would be the simplest, but that's usually not a usefull definition.
If by simple you mean "easy to understand" then producing seperate classes to handle seperate tasks is usually the better approach.
The problem is that some of those seperations are very simple if you've got your head around them but can be confusing if you're very new. But you should really work at climbing that barrier, as it allows you to handle much larger problems without getting confused.
I've not yet implemented a Sudoko, so I might be way of, but the parts that come to my mind would be the following:
Model:
- Board (holds the 81 Fields)
- Field (holds the current value, if it's preset or user-set and possibly hints)
View:
- FieldViewer (displays a single field)
- BoardViewer (displays the field)
- SudokoFrame (displays the Board and the menu and whatnot)
Add classes as needed.
> "simple" is not a simple concept ;-)
>
> If by "simple" you mean "the smalles amount of files
> to handle" then your approach would be the simplest,
> but that's usually not a usefull definition.
>
> If by simple you mean "easy to understand" then
> producing seperate classes to handle seperate tasks
> is usually the better approach.
>
> The problem is that some of those seperations are
> very simple if you've got your head around them but
> can be confusing if you're very new. But you should
> really work at climbing that barrier, as it allows
> you to handle much larger problems without getting
> confused.
Well said, Joachim!
