Здравствуйте, уважаемые. 
На этот раз не буду выкладывать никаких программулек, потому что еще немного недоделано.

Встал такой вопрос, как гибко делать смену пользователей на хуманов и москов?
Варианты всевозможные H-AI AI-H AI-AI H-H

Я уверен, что люди уже разработали такой шаблон...

есть класс Main в нем
ChessBoard board - доска, хранит информацию о игровой ситуации
ChessBoardView boardView - естественно отображение этой ситуации на доске.

Как мне посредством класса Main сделать настройку игрового режима, чтоб можно было нацепить на boardView мышного слушателя, если это игрок, если это неигрок, то просто установить AI


На этом дело встало.

Если у тебя ChessControll  - интерфейс который реализует публичный интерфейс игрока, то тебе надо просто сделать два класса, которые реализуют этот интерфейс и выполняют функции AI и H. Тогда слушатель должен будет существовать в рамках класса H. А при добавлении будешь просто добавлять нужный класс.

Либо можно сделать абстракный класс Player у которого будут все необходимые методы а реализаци их будет отличаться в зависиости от того  AI это или H.

Короче - полиморфизм - это сила! 

Именно с этим прицелом у меня ChessControll и сделано, но вопрос сотается, как локанично сделать еще и навешивание слушателя на нужные панели в случае игрока?

Ну конкретно не подскажу, сам не делал. Но по идеи ты реализуешь интерфейс слушателя в классе Chess Controll.
Если это у тебя AI то он просто ничего не делает и передает управление дальше. Если это реализация H то как раз и делаешь то, что надо.

В методе регистрации игрока регистрируешь игрока как слушателя. Опять же тебе не важно, что это будет за игрок.

Добавлено через 2 минуты и 31 секунду
Метод регистрации игрока как слушателя даже лучше сделать членом класса самого игрока... Тогда даже и не надо интерфейс слушателя реализовывать в классе ChessControl.

Можно сделать внутренний класс слушателя... И каждому игроку можно передавать нужные панели, к которым он должен будет прицепиться.

Ладно, я сделал по тупому.
ChessControll.setEngine(Engine e);
а Engine предоставляет всем контроллам все данные: и игровую канву, и данные о игровой ситуации.

Сейчас еще 1 вопрос подводный возник. Я еще игру ниразу не запускал, но сразу вижу косяк. Если будут играть 2 моска в 1-м потоке, то когда-нибудь они достигнут переполнение стека. Ибо будет 1 поток, конечно есть мысли сделать 2 потока, по 1-му на моск, у Человека и так отделный поток в виде диспетчера событий, но может есть решение попроще?

А почему должно быть переполнение?
"Моски" ходят по очереди, так? То есть, если запус "хода" происходит в основном цикле, то после завершения хода мы снова попадаем в основной цикл. Так?
Так откуда же возьмётся переполнение?



Этим всё сказано. Твой же вариант установки "движка" имеет кучу неудобств. Когда начнёшь расписывать работу всего этого барахла - заметишь.

nornad, поясни пожалуйчта. Конечно, метод примитивный, но факторов, связывающих руки я не нашел.




и правда, что... Что-то я себя сам понапугал.

Смотри. Если делать по предложенному варианту, то каждый "плеер" имеет реализацию интерфейса осуществления хода. Плюс, возможно, ещё некоторое количество методов "для себя".
В твоём же варианте "движок" даёт доступ к внутрненним объектам игры. Это приводит к тому, что "плеер" должен сам получать и разбирать информацию, сам же производить некоторые действия. В итоге это приведёт к большому количеству перекрёстного кода, который будет неудобно поддерживать. Намного проще переписать сызнова, чем добавить что-то новое. А возможно и проще, чем изменить старое.

nornad,  возможно твои замечания правильны. Давай, когда я програмку допишу, посмотришь и скажешь как можно сделать лучше?

Я лучше не буду обещать, т.к. работы довольно много, а код маленьким явно не будет.  

Код явно небольшой ;) 15 файлов, из них 6 - специфическая фигура, остальные 9 по делу, не так уж и много, я думаю.

Конечно правильные. Ты нарушаешь принципы ООП Cohesion и Coupling (блин, не знаю даже как их на русский перевести )
Конечно это не смертельно, просто если ее соблюдать, то гораздо удобнее расширяться и поддерживаться.

Это сообщение отредактировал(а) Felan - 8.11.2007, 09:43

Felan, я думаю, ты имеешь ввиду стремление к слабой связности компонентов системы?

Добавлено через 5 минут и 32 секунды
Да, вы правы абсолютно, я пересмотрел свои позиции.
Теперь я подумал сделать так:
Как контроллу хумана, так и мозгу передается объект с информацией о игровой ситуации.
Но, для хумана будет еще 1 параметр: указатель на визуализацию игры.
Получается, что теперь контроллы с движком напрямую не работают, а только он их опрашивает, какой сделать ход. Такой подход лучше?

Это сообщение отредактировал(а) Platon - 11.11.2007, 19:30

Народ! Предлагаю состязание ИИ в рамках шахмат...

Пока мой АИ не готов, но вот-вот будет. Предлагаю вам тоже подключиться, составим спаринг AI.

Это сообщение отредактировал(а) Platon - 13.11.2007, 13:02

Присоединённый файл ( Кол-во скачиваний: 18 )
 Chess.rar 56,30 Kb

Я бы сделал так.
Есть движок. Есть интерфейс игрока. Есть слушатель хода. Есть слушатель передачи хода. Есть реализация игрока для человека и есть для машины.
В самом начале регистрируются слушатели. Оба игрока регистрируют в движке свои слушатели передачи хода, а движок регистрирует слушателей самих ходов. Далее ход передаётся "белым" и игра начинается.
Кроме указанных вещей, игроки должны иметь методы для определения ситуации на доске (человеку надо нарисовать поле, а машина должна иметь поле, чтобы можно было производить расчёты, на основе которых будет выбран следующий ход). Ну и, конечно, некий метод для информирования о состоянии (шах, мат, пат...; кстати, эту информацию вполне можно передать в слушатель передачи хода.


Ещё б я знал, как писать мозги для шахмат...