Все привет! Получил задание в институте по предмету "Технологии программирования" написание программы "ШАХМАТЫ". Программа предназначена для игры двух людей (т.е. изначально никакого ИИ не предусмотрено, хотя возможно его реализация). 
Почему решил создать данную тему, потому что хотелось чтобы указали на мои ошибки, возможно предложили бы наиболее оптимальные методы реализации. Надеюсь никто сильно ругать не будет.  
  Итак начну!
  Преподаватель сказать, что прежде чем приступать к описанию классов фигур необходимо создать шахматную доску без фигур естественно. 
  Возможно несколько методов реализации: 
- рисование на форме(Canvas) - самый простой вариант я его пока и выбрал
- с использование компонентов TShape
- с использование компонентов TPanel
  Вот реализация рисования доски на форме:

P.S. в следующий раз приведу описание классов

ИМХО, эти варианты намного хуже выбранного тобой. Создавать столько контролов на форме, размещать их... Я думаю не стоит эти варианты переделывать.

Замечание по коду основное:

VanHelsing, вообще представь себе, как часто окно перерисовывается(выполняется событие OnPain). Зачем тебе это? Ты рисуй один раз доску, и перерисовывай это только при изменеении положения фигур.

Как ты собираешься реализовывать доску с фигурами(не графически)? В виде каких структур?

Так можно динамически создать и разместить.  

Насчет TShape и TPanel - преподаватель сказал рассмотреть все варианты, они отличаются в плане реализации. Фигуры будут в виде картинок (TImage), которые будут размещены в файле ресурсов.

Да вся программа должна быть реализована динамически - это одно из главных условий. Просто забыл об этом написать.
P.S. вечером постараюсь выложить доску с фигурами. Спасибо что откликнулись!  

Это сообщение отредактировал(а) VanHelsing - 16.10.2009, 13:23

Моя старая реализация шахмат на двоих (так и не доделал, лень было). Может быть чего полезного найдете для себя.

Присоединённый файл ( Кол-во скачиваний: 68 )
 MiniChess.zip 22,77 Kb

Теперь хотелось бы рассмотреть классы фигур. Будет один базовый класс фигур, а его потом будут содержать только один переопределяемый метод. Но обо всем по порядку.
Что нам необходимо в классе фигуры:  во-первых конечно это хранение цвета фигуры и ее позиции(хранение позиции будет в качестве свойства - у позиции фигуры два параметра), конструктор, процедура хода которая будет виртуальной и переопределяться у наследников класса т.к. каждая фигура ходит по-разному.
Наверное что-то забыл, но пока я считаю что этого достаточно.
Базовый класс:

Наследники:

Выбрал в качестве родительского класса TImage, потому что фигура на доске будет представлять картинкой.
P.S. если есть другие предложения с радостью рассмотрю.   

Это сообщение отредактировал(а) VanHelsing - 16.10.2009, 18:50

VanHelsing, а теперь подумай как ты с этими картинками, TColor'ами и всем таким прочим реализовывать саму логику.
Поле у тебя, к примеру, будет представленно каким нибудь массивом. Тебе нужны максимально простые структуры данных, именно для легкого управления, перемещения их по доске. А отрисовку графики следует произвоть отдельно от логики и в последнюю очередь. ИМХО.



От этого лишней памяти они меньше занимать не станут 

THandle для начала программу надо реализовать как требует преподаватель, а вот можно представлять какие угодно варианты.
В данной реализации нет никакой сложно логики: размещаем картинки фигур, далее отслеживаем клик(проверяем не выходит ли он за границы доски) и делаем соответствующий расчет и получаем позицию на доске, допустим [ 1, 1 ].
А вот с другой с другим вариантом логики у меня пока проблемы. Можно рассмотреть шахматную доску в качестве матрицы 8*8, а каждая фигура имеет свой индивидуальный номер(пустая - 0, пешка белого цвета - 1 и т.д.). Вот это пока единственный вариант.
P.S. хотелось бы услышать другие предложения.

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

Я бы взял такую вот матрицу, наполнил её фигурами, нарисовал бы изначальную доску, и при каждом ходе изменял сначал данные матрицы, а потом перерисовывал бы ту часть доски где произошли какие-то изменения.
Единственное чем сложнее такой вариант, чем варианты типа, когда используешь панельки - тебе будет немного сложнее отследить клик.

Пок оду выше. Это как так получилось что у тебя все находится в private секции? Поля вообще лучше именовать с F, плюс свойства I, J -это не красиво. Давай нормальные названия, такие должны быть у переменных счетчиков, ИМХО. Плюс классы фигур конечно лучше проименовать по-английски, а то как-то дико читать  

Насчет private - преподаватель сказал, что шаг в сторону любой другой секции приравнивается к незачету. Поля и свойства переименую(X и Y думаю будут красивее смотреться). 
Насчет другой реализации. Хорошо представить доску в виде матрице я давно хотел, но пока не вижу альтернативы картинкам. Хотя возможно она и есть.   
P.S. конечно можно фигуры тоже на "канве" рисовать, но мне кажется что это сложнее.

Это сообщение отредактировал(а) VanHelsing - 17.10.2009, 09:05

Я бы доску, как компонент оформил, как я полагаю это д/б даже не контрол, а просто невизуальный компонент с битмепом доски внутри, по которому можно рисовать фигуры, а потом бросать это на PaintBox и в нее же можно запихнуть сам массив полей и ссылки на экземпляры фигур. Кстати, у PaintBox'а есть свойство DoubleBuffered (как я понимаю, оно позволяет строить изображение в памяти и потом выводить разом, так что контрол при перерисовке не мерцает) или это прирогатива TWinControl'а?
При отрисовке координат определяй сначала длину и ширину текста, иначе их положение непредсказуемо даже на компьютерах с одинаковой схемой оформления.



На мой взгляд бессмысленно, т. к.
1) фигура может и тоскаться игроком, хотя для простоты можно и поля выделять.
2) Доска все равно будет перерисовываться полностью при переключении на программу. Т. е. полня отрисовка в идеале все равно д/б быстрее 50 мс.



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



Правда, возможно, стоит забить на такую классовую иерархию и обойтись числовым индексом фигуры, тем более что ЕМНИП с оператором is, который понадобиться для анализа, конкретных фигур есть засада с определением типа конкретного экземпляра. Поправьте, если ошибаюсь.

Есть в шахматах еще один сложный для реализации пунктик, называется взятие на проходе, для него надо анализировать последний ход, только препод про него может и не знать.

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

Это сообщение отредактировал(а) Beltar - 17.10.2009, 11:04

Beltar спасибо за идею.
Сейчас пока обдумываю логику программы, если представить доску в виде матрицы. Надо ведь связать фигуры на доске с матрицей. При клике на фигуре надо рассчитывать ее координаты.
Да а в программе, которую требует преподаватель надо использовать DragandDrop.

Так описываешь доску как: TBoard=array[1..8,1..8] of TPiece, или как ты хотел через числа, тогда Integer (я бы юзал 0 для пустой клетки и отр. значения для черных фигур, так легче и нач. позицию заполнить и что-то подсчитывать и даже определять возможность хода, если поле=0 или отличается по знаку, и даже превращение пешки, если ее код плюс\минус 1 реализуется простым умножением на код белой фигуры);

Вообще можно сделать так:





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

Так накидывал код программы(пока некрасивый и неокончательный) и столкнулся с такой проблемой: т.к. я рисую на форме, а в качестве фигур использую TImage, то для перемещения фигур использую 

Ну бывает что одна фигура рубит другую, т.е. одну фигуру надо уничтожить, а вторую поставить на ее место. Я не знаю в каком обработчике и как ее реализовать.
P.S. думаю.......

Сделал создание фигур и их расстановка на доске:

P.S. проблема которая описана выше пока не решена.

Это сообщение отредактировал(а) VanHelsing - 20.10.2009, 17:49