Погонял немного нашу программку.
На данный момент есть следующие недочеты:
1. Точка закрашивается при щелчке в клетку справа-внизу от нее. Пришла пора править screen2field():


2. Точка перекрашивается даже если она уже занята другим игроком. Чтобы этого не происходило, нужно добавить проверку в setNewColor()

3. Ход все равно передается следующему игроку, даже если предыдущий щелкнул в занятую точку. Мы используем значение, возвращаемое setNewColor(), чтобы определить, удалось ли игроку поставить точку или нет, и передадим ход только если удалось:



4. При закрытии окна появляется диалог "Would you like to stop the game  ?", но окно закрывается независимо от того would я like или нет. Может оставить одну кнопку Yes?  

Точки которые созданы заранее и хранятся в массиве у меня на решётке не видны .А точки создаваемые при щелчке мышкой рисуются там где мышкой щёлкнули..даже  друг на друге .
Я попробовала изменить screen2field но пока поведение точек не изменилось.Может быть надо поправить и field2screen  что бы был эффект попадания в углы решётки ? 
После введения проверки в setNewColor() точки перестали перекрашивать друг друга но при неполном перекрывании новая точка того же цвета всё-таки рисуется. Если щёлкать мышкой и чуть чуть смещать курсор можно нарисовать линию из частично перекрывающихся точек одного цвета.  

В mouseWasClicked мне пришлось оставить points[pointX][pointY].paint(x,y,this.getGraphics()); потому что без него  точки не рисуются .

видимых изменений это не принесло потому что мы не смогли привязать координаты новых точек к координатам точек в массиве. Наши точки пока гуляют сами по себе 
mouseClicked скомпелировался нормально .
Кнопочку я попыталась убрать изменив ту часть кода где она мне встретилась  всё скомпелировалось но и кнопочка тоже осталась..Странно однако .
Хотя это пустяк по сравнению с точками "гуляющими" по решётке .

ТАМ они и не должны рисоваться. У вас есть метод paintComponent() в котором происходит(ну, должна происходить) отрисовка.

paintComponent() происходит отрисовка точек которые заранее созданы в  массиве и самой решётки .Мы не определяем их цвет .
 если поменять на  points[x][y].paint(field2screen(x), field2screen(y), g);   то решётка выйдет без прорисовки заранее созданных  точек так что смысла в этом нет.
Оба метода для рисования точек на данный момент :

В методе  mouseWasClicked происходит рисование точек цветами игроков при щелчке мышкой.Они то у нас и гуляют сами по себе .
Нам нужна валидация их координат на предмет совпадения с координатами заранее созданных точек которые ещё не имеют хозяина. Может быть просто перебирать координаты заранее созданных точек на предмет совпадения с координатами щелчка мышкой  плюс минус 5 пикселей ? Если такая точка существует - мы её закрасим , а если нет пускай пробуют ещё раз щёлкнуть 

Смысл есть - для чего мы использовали setNewColor()? Когда игрок тыкает в точку, меняется хранимый в ней цвет, и она рисуется этим цветом.
paintComponent() вызывается всякий раз, когда щелкается мышка (проверьте, в mouseClicked() должна быть строчка repaint();), поэтому всякий раз перерисовывается все поле - если точка получила цвет, она появится на экране.

Ах да мой косяк. Запостил mouseClicked() без repaint'а  Должен быть repaint()!!, в самом конце метода - он вызывает paintComponent(), без него изменения на поле видно не будет.

А я  вчера пыталась найти кто же вызывает paintComponent()  ..... 
Мне это было жутко интересно  
Потом я смирилась и решила что это какой-то особый метод который и вызывать то не надо - работает автоматом . 
Теперь у нас точки ставятся по углам решётки      
Но  мы ещё не применяли метод 
  мы будем его использовать для замыкания контура  ?

Будут ли  нарисованные точки   храниться в отдельном массиве  или можно  использовать  массив  который уже есть с заранее созданными точками ?


 

paintComponent() на самом деле вызывается на усмотрение Явы, например когда окно разворачивается из свернутого состояния. repaint() мы используем чтобы сообщить Яве что мы изменили поле и его надо перерисовать.

А field2screen() уже используется здесь для перевода координат точки на поле в экранные координаты:


Работать мы будем с теми точками которые у нас есть.

______________________________________
Собственно прежде чем идти дальше предлагаю внести пару штрихов в код.

1. Сейчас у нас если пощелкать у самого правого края экрана (или внизу) происходит исключение ArrayIndexOutOfBoundsException, потому что в результате пересчета экранных координат щелчка в "полевые" получается что x или y за пределами массива

Чтобы этого не происходило мы добавим проверку координат.
Сначала вспомогательный метод для проверки координат:

Сама проверка:

2. Рисование точек начинается с координат [1,1], т.е. не видно целый столбец и целую строку точек, хотя они все равно обрабатываются программой:

Меняем на 


Теперь рисуются все точки, но слева и сверху они прилипли к краю окна.
Нам придется сдвинуть всю сетку вместе с точками вправо-вниз, и заодно увеличить окно, чтобы точки не выезжали там за его край.

Сначала увеличим размер окна на одну клетку.
Было:

Стало:


Теперь места достаточно чтобы подвинуть сетку. Дорабатываем paintComponent():

    translate(x, y) используется чтобы сместить пространство отрисовки. Здесь мы смещаем его вправо-вниз на размер клетки
    так что все рисуемые объекты тоже смещаются на это расстояние.
    translate(-x, -y) в конце используется чтобы вернуть все как было (после отрисовки). Без него поле будет смещаться дальше и дальше
    при каждом вызове paintComponent() и уедет с экрана.

Ну и, раз уж мы сдвинули сетку, придется поправить и screen2field(), чтобы точки попадали в мышку как и раньше.



Это сообщение отредактировал(а) Rpahut - 27.1.2009, 22:56

Вчера у меня отключился интернет ( ливнем  повредило телефонный кабель ). 
Сейчас пишу с чужого компьютера  .Компилятора под рукой нет но я надеюсь к вечеру интернет будет и я смогу описать  результат проделанной работы. Пока занималась проблемой с лишней кнопкой при закрытии программы .Не знаю как её убрать . Если только весь public void windowClosing(WindowEvent e) убрать и сделать JPaneOption диалог . Мы его использовали когда ещё не пользовались GUI поэтому ещё не факт что с  GUI это будет правильным решением .  
Сегодня  нам  рассказали какую документацию к программе  от нас хотят ... Сказали  написать срочно 50-100 страниц используя используя глаголы в будущем времени потому что мы сначала  должны были  писали эту документацию  а потом уже  программу разрабатывать   .. 
Надо  описать как всё работает  ,  куда что передаётся  , как  и где  принципы обьектно-ориентированного программирования себя проявляют . К алгоритмам надо приложить  диаграммы или псевдо-коде .  Я бы конечно предпочла что-бы мне  заранее  это сказали делать . Но у препода своя  железная логика . Он считает что декабре мы ещё не могли знать что реально мы   напишем и каким путём пойдём . 
У всех студентов сейчас  разные версии .  А тех у кого версии  будут одинаковые будут  "пытать "  в разных кабинетах . Преподаватели  наделают им  ошибок в коде их же собственных  програм  и заставят  их исправить что-бы выяснить кто у кого списал   ..

У меня всё скомпелировалось . Я думаю как можно сделать что-бы последняя поставленная точка мигала привлекая к себе внимание игроков. Надо вызывать paintComponent , но как ..такое впечатление что  нужно установить не просто loop а loop c таймером  для прорисовки через определённый интервал.


Это сообщение отредактировал(а) Qawra - 28.1.2009, 20:42

Там нужно сделать две вещи.
Во-первых, указать чтобы окно не закрывалось автоматически:
setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
Во-вторых - вручную закрыть окно, если пользователь выберет Yes.


__________________________
Вам показывали что BlueJ умеет генерировать документацию? 

Вобщем, он умеет, нужно только составить описание классов и методов.

Потом в BlueJ выбираем Tools->Project Documentation и получаем документацию. Вряд ли там получится 100 страниц, но...
How to write Doc Comments for the Javadoc tool

С окошком наконец-то получилось .Я пробовала раньше setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE); но это приводило к невозможности закрыть программу вообще . Теперь она закрылась     

То что BlueJ делает документацию от нас естественно держат в секрете .
Хотя не думаю что это может помочь . То что они хотят это скорее реферат чем документация.
====================================================
Часть 1 : 
Описание проблемы , Use-Case Diagrams ( ещё не знаю что это такое , может быть это из UML ), причины по которым написание программы необходимо и возможные пути решения поставленной задачи.

Часть 2:
Описание использованных алгоритмов и их детальный дизайн ( псевдо-код или flow chart )

Часть 3 :
Описание применённых в программе принципов Обьектно-Ориентированного программирования и диаграммы классов .

Часть 4 :
Applications of Java APIs

Часть 5 :
Процедуры тестирования 

Часть 6 :
Solution Evaluation ,User Manual , Screenshoots

Приложение :
Исходный коде программы
==================================================

Приступаю к обдумываю первой части с использованием глаголов в будущем времени .Зачем писали программу ...в целях экономии бумаги школьниками 

Хотелось мне как-то выделить   точку  которая была поставленна последней.
Пока самое простое что пришло в голову это нарисовать у этой точки чёрный ободок. При небольшом дополнении к методу drawCircle
 такие ободки рисуются у всех точек . А надо что бы ободок изчезал как только поставлена следующая точка. Может быть вынести это в отдельный метод drawCircleNew  и вызывать только когда рисуется новая точка а затем перерисовывать с помощью :

Насчет ободка предлагаю такое решение: добавим ещё одно поле а классе GridsCanvas и назовем его LastPoint. К классу DrawablePoint добавим метод "нарисовать ободок" и После перерисовки всех точек вызовем для последней точки рисование ободка.

У нас получается что поле характеризуется массивом точек, состояние которых описывается в поле color: 1)null - не точки: 2)Цвет 1го игрока - первый игрок, 3) 2го - второй. Мне не кажется это очень хорошим решением. Положим мы дошли до того некоторого места в написании проекта, и теперь нам предстоит заниматься замыканием контура. На сколько я помню игру "точки" замыкать контур можно, если замыканием отрезается область, содержащая хотя бы одну точку противника; при проведении границы мы не должны пересекать уже проведенных вражеских ребер. На текущем этапе проектирования нам придется вводить массив на ребра, находящиеся на поле (читайте хранить несвязный граф) и хранить, участвовала ли каждая точка в замыкании пути. ИМХО, мне это не нравится. Я бы оставил просто массив int равный размеру поля. Обходя его я бы рисовал каждую точку. (Возможно, после замыкания контура мы захотим наводить контур более жирной линией: тут начнутся проблемы. Мелочь типа наведения ободка на данном этапе легко добавляется, как добавить жирный контур мне пока не очевидно). Классы это, конечно грамотно, но... В принципе я с массивом погорячился: можно добавить в класс DrawablePoint атрибут, принадлежит ли она какому-нить замыканию.

Что будем делать, когда игрок делает ход? Тут надо привести нетривиальный алгоритм поиска замыкания. Как известно из курса мат. анализа, положительным направлением обхода контура будет такое направление при котором внешняя нормаль в данной точке границы контура при повороте по часовой стрелке (читайте при умножении на матрицу 2х2: (0 -1 1 0) ) совпадает с направлением касательной, т.е. с направлением движения. 

Итак, мы имеем точку, в которую только что кликнули. окрестные 8 точек можно воспринимать как циклически замкнутую строку (в принципе это даже не так важно). 
Нада какой-нить пример:
вот наши 9 точек, в центр только что нажали. окружность разобьется на две группы точек: {(2,0)} и {(0,0),(0,1),(1,2)}. Проверять, что центральная точка вместе с верхними тремя замкнет контур не нужно, так как мы это уже делали, когда добавляли эти три точки (некая индукция, если рассуждать в терминах математики). значит мы должны проверить не замкнет ли центральная верхние три с нижней. далее мы выберем одно из 4х стартовых направлений (т.к. суммарное кол-во точек в обеих группах=4) и будем так же выбирать направление со следующими точками. При этом  надо маркировать (где-то хранить точки пути)

Кажется я начинаю запутываться.
Извините за этот бред, надеюсь я никого не напугал нашими перспективами.
Сам я Java не изучал (настала пора начинать!), но морской бой в Дельфях написать  могу. Постараюсь помочь в написании этой дикой вещи.

Kakadu дело говорит; только я бы сделал выделение двух последних точек, по одной на игрока, иначе зачем это не совсем понятно.

Kakadu, на правила мы забили. Точки можно соединять если они рядом, принадлежат одному игроку и если новое соединение не пересекает уже существующее. Счет ведется по захваченной площади.

По поводу нетривиального алгоритма поиска - не совсем понятно как найти внешнюю нормаль, если имеется только взаимно равноправное соединение между точками и где внешняя сторона еще не известно.
Предполагается добавление в DrawablePoint массива для хранения точек, с которыми соединена данная точка, и через него все остальные действия.

Поиск контура и захваченных точек задумывался при помощи рекурсии, поскольку рекурсия мне роднее матана  
Используются следующие идеи:
1. Если из всех соединенных друг с другом точек выкинуть тупиковые (т.е. имеющие максимум одно нетупиковое соединение) точки, то что останется и будет замкнутым контуром.
2. Построив после этого прямоугольную границу вокруг контурных точек и расширив ее на одну клетку в каждую сторону, можно из внешней части запустить поиск, который, теоретически, найдет все точки вне контура. Сейчас я, кажется, вижу в этом пункте одну серьезную дырку... Также, кажется, я вижу как ее заделать  

Самое лучшее описание алгоритма я видела здесь 
http://pointsxt.logicsworld.net/forum/index.php?showtopic=69
К сожалению регистрация на форуме не работает ( как видимо и сам форум ).