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

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.

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