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

На мой взгляд намного удобнее реализовать поле в виде массива:

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

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

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

по поводу кода рисования: не обязательно рисовать сразу 2 цвета. достаточно применить FloodFill (нафлудить или Bar одним цветом, потом рисовать квадратики другого.

для зарубывания фигур примени события. то есть, когда фигура ходит (метод Move), возникает событие OnMove. его обработчик будет снимать фигуру с доски и помещать в "мертвяк". может быть, включить в базовый класс TFigure генерацию сего события. я так думаю, что это событие еще пригодится для решения исхода игры, когда какбе шах или мат

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



Тогда надо доску, как компонент оформлять, что впрочем я считаю оптимальным вариантом. Да и в принципе вышедшие из игры фигуры может опять же хранить доска. Здесь есть один момент, как учитывать взятые превращенные фигуры. Я бы так сделал:
Captured:array[-9..9{ну нравится мне использовать коды равные ценности фигур в пешках, жалко только, что конь и слон оба по 3 стоят}]:of Integer и при взятии, или превращении просто увеличивать соотв. индекс, если он получается больше нач. количества фигур, то рисуем максимум.

Блин, я бы сам охотно попробовал реализовать шахматы для LAN'а, но юзебельность сильно зависит от качества арта, а с этим траблы.

кстати, VanHelsing , раз уж речь идет об серъезной разработке с обсуждением, начинай осваивать ER-диаграммы (графическое моделлирование классов). сам использую PowerDesigner. там, как по мне, есть все, что нужно. особенно, если тебе улыбается карьера программиста 
в PowerDesigner также есть куча других диаграмм, вообщем тебе должно понравиться  .
и обсуждать это все будет легче, глядя на диаграммы, и тебе сразу станет понятнее структура твоей же программы

ЗЫ: 



это то, что я не осмеливался сказать вслух . меня тоже какбе смущает массив объектов. хотя самое простое решение - самое лучшее. с другой стороны, никто не запрещает поместить массив в класс типа "ТДоска"
еще: это свойство-массив в public лучше вывесить как рид-онли, а перестановку фигур выполнять только из кода процедуры Move (или как она там у тебя называется)

Ну я выше приводил каркас такого класса, наследника TCustomControl, который сам же будет и Drag and Drop вместе с прочими мышиными событиями обрабатывать в перекрытых процедурах диспетчеризации.



А произвольную расстановку как делать? Очевидно у нас д/б еще "коробка" с фигурами (возможно подойдет TDrawGrid, сам этот контрол ни разу не юзал) из которой хватаем фигуру, тащим на доску и уже в MouseUp (как я понимаю при появлении MouseDown мышь перейдет в монопольное использование "коробки" и MouseUp возникнет у нее же) определяем где юзер ее отпустил, а там присваиваем полю нужную фигуру, ес-но в этом случае никаких проверок корректности позиции происходить не должно. Хотя вопрос, как у автора со временем все это делать.

Beltar если я правильно понял, то при таком варианте фигуры придется рисовать на этом компоненте?

Я задавался этим вопросом, но пока отложил, самое главное это понять какой вариант более правильный и оптимальный и позволяет расширять приложение.

Это сообщение отредактировал(а) VanHelsing - 22.10.2009, 19:31

Ну да, в простейшем случае рисуешь доску, потом на ней фигуры. Плюс тут в том, что может батонов и побольше потоптать придется, но весь код разделится на 2 части более понятные, чем вся каша, которая неизбежно получится в файле главной формы размеров в 3000 строк.

Практически я бы разбил задачу на следующие этапы:
1) Отрисовка пустой доски.
2) Отрисовка фигур, так что ты сможешь написать что-то вроде Board.Fields[1,1]:=BKnight; и на поле a1 у тебя появится черный конь. Считай режим произвольной расстановки и прокрутки партии готов, на первое время с доской можно даже простейшее контекстное меню в котором будешь выбирать фигуру связать, и он тебе еще ОЧЕНЬ понадобиться при тестировании.
3) Можно заняться ходами. В принципе мат или пат предполагают, что ходов согласно правилам нет, так что возможно, имеет смысл строить массив, всех возможных перемещений (это примерно 30-40, т. е. задаешь размер, например, в 128 и не паришься) проверяя после каких из них противник может взять короля и их не включать.
4) Реализовать собственно ходы, на таскание пока забить, хватит и выделения щелчком мыши.

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

Значится, какие еще мысли пришли в голову
TTable сделать потомком PaintBox - хорошая идея, там будет удобно обращаться к таким вещам, как Canvas  и выполнять перерисовку OnPaint.
Доступ к массиву обеспечить через Property Figures(i, j): TFigure. Это позволит при присваивании "по горячему" перерисовать новую фигуру, зная, что она изменила положение (и до присваивания массиву ты можешь найти ее на доске и стереть на прежнем месте). Здесь же можно обрабатывать событие Capture (захват фигуры). То есть, когда присваиваем ячейке фигуру другого цвета, чем того, который уже здесь есть, происходит захват. Более того, нельзя захватывать короля.
В этот же класс включить процедуру Drag, которая будет отрисовывать временное положение фигуры при таскании ее мышью (OnMouseDouwn, OnMouseMove, OnMouseUp). В таком случае процедура Move в суперклассе TFigure не нужна (можно объявить как абстракную), а определять ее уже у потомков.
Для начальной расстановки просто напиши процедуру InitTable, которая просто очистит доску и присвоит массиву нужные фигуры.
То есть получается такой себе компонент) Добавь в него свойство "мертвяк" CapturedFigures(Side: Integer - игрок): array of TFigure и новое событие OnCapture, чтобы при появлении новых фигур в мертвяке обновлять внешние компоненты, которые этот список выводят.
Кстати, умные игры в шахматы хранят историю ходов (ее можно сохранять в обработке свойства Figures(i, j): TFigure).

TFigure лучше наследовать от TObject, добавив свойство Image типа TBitmap. Это выгоднее тем, что ты можешь напрямую обрабатывать OnMouseMove класса TTable (эти события не перекроются с событиями TImage, которые находятся на доске). при начале драга делаешь снимок доски в буфер TBitmap, и по мере таскания рисуешь сначала этот фон, а сверху в координатах х, у дорисовываешь Image нужной фигуры.

все ходы искать не обязательно, достаточно найти хотя бы один.

ну считай, вот тебе готовое решение) с тебя только логика)

У вин-контролов вроде возможностей больше.



Так перебирай просто по возможным направлениям пока не упрешься в край или в фигуру.



А зачем двигать по доске TImage когда его можно просто скопировать на канвас?



А вот это как раз стоит отдельно от доски делать. По сути можно управлять уже списком ходов, а для доски команда отката, например, будет выглядеть как переместить фигуру с одного поля на другое без проверок, если нужно восстановить сбитую.

Это сообщение отредактировал(а) Beltar - 26.10.2009, 21:00

Beltar, Hexel спасибо за предложения.
Вот все таки решил задуматься на логикой. Наверное лучше будет если доска будет представлена матрицей 8х8. Каждой фигуре будет соответствовать определенное числовое значение (возможно воспользуюсь предложение от -9..9).
Проблема в другом. Если мы смотрим на доску, то левый нижний угол имеет координаты [1, 1], а матрице он имеет координаты [8, 1]. Наверное все просто, но я не понимаю как мне это соединить между собой.

Проблема на самом деле не в этом (Какая разница как ты представляешь себе массив, с [1,1] внизу, или, что более привычно вверху? Он просто в твоем воображении зеркально отразится.), а в том, что, экранные координаты считаются от левого верхнего угла и при нормальном положении доски (белые внизу) Y-координата поля a1 больше таковой у a8, впрочем по хорошему доска должна поворачиваться, т. е. нужно 2 способа рассчета Y координат. Несложно, но можно запутаться. А с X там все элементарно, как ни крути X-координаты поля [i,j] будут LeftBorder+(j-1)*FieldWidth и LeftBorder+j*FieldWidth.

Вот в этом то и проблема, тем более на мой взгляд код из=за этого будет запутанным. Хочу найти другие варианты.

Там кода код наплакал, всего-лишь найти координаты прямоугольника поля, зная отступ от края и размер поля. Одна ф-ия в полтора десятка строк.