| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Для новичков > Шахматы |
| Автор: VanHelsing 16.10.2009, 11:21 | ||
| Все привет! Получил задание в институте по предмету "Технологии программирования" написание программы "ШАХМАТЫ". Программа предназначена для игры двух людей (т.е. изначально никакого ИИ не предусмотрено, хотя возможно его реализация). Почему решил создать данную тему, потому что хотелось чтобы указали на мои ошибки, возможно предложили бы наиболее оптимальные методы реализации. Надеюсь никто сильно ругать не будет. Итак начну! Преподаватель сказать, что прежде чем приступать к описанию классов фигур необходимо создать шахматную доску без фигур естественно. Возможно несколько методов реализации: - рисование на форме(Canvas) - самый простой вариант я его пока и выбрал - с использование компонентов TShape - с использование компонентов TPanel Вот реализация рисования доски на форме:
P.S. в следующий раз приведу описание классов |
| Автор: Данкинг 16.10.2009, 13:14 |
Так можно динамически создать и разместить. |
| Автор: VanHelsing 16.10.2009, 13:21 | ||
Насчет TShape и TPanel - преподаватель сказал рассмотреть все варианты, они отличаются в плане реализации. Фигуры будут в виде картинок (TImage), которые будут размещены в файле ресурсов.
Да вся программа должна быть реализована динамически - это одно из главных условий. Просто забыл об этом написать. P.S. вечером постараюсь выложить доску с фигурами. Спасибо что откликнулись! |
| Автор: TheVoid 16.10.2009, 13:27 |
| Моя старая реализация шахмат на двоих (так и не доделал, лень было). Может быть чего полезного найдете для себя. |
| Автор: VanHelsing 16.10.2009, 18:47 | ||||
| Теперь хотелось бы рассмотреть классы фигур. Будет один базовый класс фигур, а его потом будут содержать только один переопределяемый метод. Но обо всем по порядку. Что нам необходимо в классе фигуры: во-первых конечно это хранение цвета фигуры и ее позиции(хранение позиции будет в качестве свойства - у позиции фигуры два параметра), конструктор, процедура хода которая будет виртуальной и переопределяться у наследников класса т.к. каждая фигура ходит по-разному. Наверное что-то забыл, но пока я считаю что этого достаточно. Базовый класс:
Наследники:
Выбрал в качестве родительского класса TImage, потому что фигура на доске будет представлять картинкой. P.S. если есть другие предложения с радостью рассмотрю. |
| Автор: THandle 17.10.2009, 00:13 |
| VanHelsing, а теперь подумай как ты с этими картинками, TColor'ами и всем таким прочим реализовывать саму логику. Поле у тебя, к примеру, будет представленно каким нибудь массивом. Тебе нужны максимально простые структуры данных, именно для легкого управления, перемещения их по доске. А отрисовку графики следует произвоть отдельно от логики и в последнюю очередь. ИМХО. От этого лишней памяти они меньше занимать не станут |
| Автор: VanHelsing 17.10.2009, 06:50 |
| THandle для начала программу надо реализовать как требует преподаватель, а вот можно представлять какие угодно варианты. В данной реализации нет никакой сложно логики: размещаем картинки фигур, далее отслеживаем клик(проверяем не выходит ли он за границы доски) и делаем соответствующий расчет и получаем позицию на доске, допустим [ 1, 1 ]. А вот с другой с другим вариантом логики у меня пока проблемы. Можно рассмотреть шахматную доску в качестве матрицы 8*8, а каждая фигура имеет свой индивидуальный номер(пустая - 0, пешка белого цвета - 1 и т.д.). Вот это пока единственный вариант. P.S. хотелось бы услышать другие предложения. |
| Автор: THandle 17.10.2009, 08:54 | ||
Вот что то подобное будет как мне кажется лучше, чем вариант с двиганьем картинок. Хотя если преподаватель сказал так делать - никуда не денешься... Они такие... :( Я бы взял такую вот матрицу, наполнил её фигурами, нарисовал бы изначальную доску, и при каждом ходе изменял сначал данные матрицы, а потом перерисовывал бы ту часть доски где произошли какие-то изменения. Единственное чем сложнее такой вариант, чем варианты типа, когда используешь панельки - тебе будет немного сложнее отследить клик. Пок оду выше. Это как так получилось что у тебя все находится в private секции? Поля вообще лучше именовать с F, плюс свойства I, J -это не красиво. Давай нормальные названия, такие должны быть у переменных счетчиков, ИМХО. Плюс классы фигур конечно лучше проименовать по-английски, а то как-то дико читать |
| Автор: VanHelsing 17.10.2009, 09:04 | ||
Насчет private - преподаватель сказал, что шаг в сторону любой другой секции приравнивается к незачету. Поля и свойства переименую(X и Y думаю будут красивее смотреться). Насчет другой реализации. Хорошо представить доску в виде матрице я давно хотел, но пока не вижу альтернативы картинкам. Хотя возможно она и есть. P.S. конечно можно фигуры тоже на "канве" рисовать, но мне кажется что это сложнее. |
| Автор: Beltar 17.10.2009, 10:10 | ||||||
| Я бы доску, как компонент оформил, как я полагаю это д/б даже не контрол, а просто невизуальный компонент с битмепом доски внутри, по которому можно рисовать фигуры, а потом бросать это на PaintBox и в нее же можно запихнуть сам массив полей и ссылки на экземпляры фигур. Кстати, у PaintBox'а есть свойство DoubleBuffered (как я понимаю, оно позволяет строить изображение в памяти и потом выводить разом, так что контрол при перерисовке не мерцает) или это прирогатива TWinControl'а? При отрисовке координат определяй сначала длину и ширину текста, иначе их положение непредсказуемо даже на компьютерах с одинаковой схемой оформления.
На мой взгляд бессмысленно, т. к. 1) фигура может и тоскаться игроком, хотя для простоты можно и поля выделять. 2) Доска все равно будет перерисовываться полностью при переключении на программу. Т. е. полня отрисовка в идеале все равно д/б быстрее 50 мс.
Честно говоря, препод, похоже, маленько того, если по хорошему, то возможен такой вариант (извини, но слова роде tura мне слух режут, так что использую общепринятые англ. названия):
Правда, возможно, стоит забить на такую классовую иерархию и обойтись числовым индексом фигуры, тем более что ЕМНИП с оператором is, который понадобиться для анализа, конкретных фигур есть засада с определением типа конкретного экземпляра. Поправьте, если ошибаюсь. Есть в шахматах еще один сложный для реализации пунктик, называется взятие на проходе, для него надо анализировать последний ход, только препод про него может и не знать. PS я бы не отказался от хорошей реализации шахмат для игры по LAN'у в нете мне ничего стоящего найти не удалось. |
| Автор: VanHelsing 18.10.2009, 07:21 |
| Beltar спасибо за идею. Сейчас пока обдумываю логику программы, если представить доску в виде матрицы. Надо ведь связать фигуры на доске с матрицей. При клике на фигуре надо рассчитывать ее координаты. Да а в программе, которую требует преподаватель надо использовать DragandDrop. |
| Автор: Beltar 18.10.2009, 12:54 | ||
| Так описываешь доску как: TBoard=array[1..8,1..8] of TPiece, или как ты хотел через числа, тогда Integer (я бы юзал 0 для пустой клетки и отр. значения для черных фигур, так легче и нач. позицию заполнить и что-то подсчитывать и даже определять возможность хода, если поле=0 или отличается по знаку, и даже превращение пешки, если ее код плюс\минус 1 реализуется простым умножением на код белой фигуры); Вообще можно сделать так:
|
| Автор: VanHelsing 18.10.2009, 18:28 | ||
Так накидывал код программы(пока некрасивый и неокончательный) и столкнулся с такой проблемой: т.к. я рисую на форме, а в качестве фигур использую TImage, то для перемещения фигур использую
Ну бывает что одна фигура рубит другую, т.е. одну фигуру надо уничтожить, а вторую поставить на ее место. Я не знаю в каком обработчике и как ее реализовать. P.S. думаю....... |
| Автор: VanHelsing 20.10.2009, 17:00 | ||
Сделал создание фигур и их расстановка на доске:
P.S. проблема которая описана выше пока не решена. |
| Автор: amsoft 20.10.2009, 19:31 | ||
На мой взгляд намного удобнее реализовать поле в виде массива:
|
| Автор: VanHelsing 20.10.2009, 19:55 |
| amsoft можно подумать. Но на мой взгляд это сложнее реализовать и сложнее модифицировать. Еще у некоторых фигур есть дополнительные обработки кода, например обработка шаха. |
| Автор: Beltar 21.10.2009, 17:32 |
| Я пока писал тебе пред. ответы пришел к выводу, что простые цифровые коды все-таки лучше и проще, уже хотя бы при определении что за фигура, особенно с пешками, если они равны плюс\минус один изящно получается. |
| Автор: Hexel 21.10.2009, 21:43 |
| по поводу кода рисования: не обязательно рисовать сразу 2 цвета. достаточно применить FloodFill (нафлудить для зарубывания фигур примени события. то есть, когда фигура ходит (метод Move), возникает событие OnMove. его обработчик будет снимать фигуру с доски и помещать в "мертвяк". может быть, включить в базовый класс TFigure генерацию сего события. я так думаю, что это событие еще пригодится для решения исхода игры, когда какбе шах или мат |
| Автор: Beltar 22.10.2009, 07:35 | ||
С точки зрения удобства лучше всего красить поля так, как на деревянных досках, а вообще чем больше настроек, тем лучше, это и впечатление о софтине должно заметно улучшать.
Тогда надо доску, как компонент оформлять, что впрочем я считаю оптимальным вариантом. Да и в принципе вышедшие из игры фигуры может опять же хранить доска. Здесь есть один момент, как учитывать взятые превращенные фигуры. Я бы так сделал: Captured:array[-9..9{ну нравится мне использовать коды равные ценности фигур в пешках, жалко только, что конь и слон оба по 3 стоят}]:of Integer и при взятии, или превращении просто увеличивать соотв. индекс, если он получается больше нач. количества фигур, то рисуем максимум. Блин, я бы сам охотно попробовал реализовать шахматы для LAN'а, но юзебельность сильно зависит от качества арта, а с этим траблы. |
| Автор: Hexel 22.10.2009, 11:34 | ||
| кстати, VanHelsing , раз уж речь идет об серъезной разработке с обсуждением, начинай осваивать ER-диаграммы (графическое моделлирование классов). сам использую PowerDesigner. там, как по мне, есть все, что нужно. особенно, если тебе улыбается карьера программиста в PowerDesigner также есть куча других диаграмм, вообщем тебе должно понравиться и обсуждать это все будет легче, глядя на диаграммы, и тебе сразу станет понятнее структура твоей же программы ЗЫ:
это то, что я не осмеливался сказать вслух еще: это свойство-массив в public лучше вывесить как рид-онли, а перестановку фигур выполнять только из кода процедуры Move (или как она там у тебя называется) |
| Автор: Beltar 22.10.2009, 12:01 | ||||
Ну я выше приводил каркас такого класса, наследника TCustomControl, который сам же будет и Drag and Drop вместе с прочими мышиными событиями обрабатывать в перекрытых процедурах диспетчеризации.
А произвольную расстановку как делать? Очевидно у нас д/б еще "коробка" с фигурами (возможно подойдет TDrawGrid, сам этот контрол ни разу не юзал) из которой хватаем фигуру, тащим на доску и уже в MouseUp (как я понимаю при появлении MouseDown мышь перейдет в монопольное использование "коробки" и MouseUp возникнет у нее же) определяем где юзер ее отпустил, а там присваиваем полю нужную фигуру, ес-но в этом случае никаких проверок корректности позиции происходить не должно. Хотя вопрос, как у автора со временем все это делать. |
| Автор: VanHelsing 22.10.2009, 19:30 | ||||
Beltar если я правильно понял, то при таком варианте фигуры придется рисовать на этом компоненте?
Я задавался этим вопросом, но пока отложил, самое главное это понять какой вариант более правильный и оптимальный и позволяет расширять приложение. |
| Автор: Beltar 22.10.2009, 20:26 | ||
Ну да, в простейшем случае рисуешь доску, потом на ней фигуры. Плюс тут в том, что может батонов и побольше потоптать придется, но весь код разделится на 2 части более понятные, чем вся каша, которая неизбежно получится в файле главной формы размеров в 3000 строк. Практически я бы разбил задачу на следующие этапы: 1) Отрисовка пустой доски. 2) Отрисовка фигур, так что ты сможешь написать что-то вроде Board.Fields[1,1]:=BKnight; и на поле a1 у тебя появится черный конь. Считай режим произвольной расстановки и прокрутки партии готов, на первое время с доской можно даже простейшее контекстное меню в котором будешь выбирать фигуру связать, и он тебе еще ОЧЕНЬ понадобиться при тестировании. 3) Можно заняться ходами. В принципе мат или пат предполагают, что ходов согласно правилам нет, так что возможно, имеет смысл строить массив, всех возможных перемещений (это примерно 30-40, т. е. задаешь размер, например, в 128 и не паришься) проверяя после каких из них противник может взять короля и их не включать. 4) Реализовать собственно ходы, на таскание пока забить, хватит и выделения щелчком мыши. |
| Автор: VanHelsing 26.10.2009, 19:38 |
| При реализации столкнулся еще с одной проблемой: это проверка того, что на пути моей фигуры нет другой. То есть, чтобы одна фигура не могла перепрыгнуть другую (ну конечно за исключением коня). Вот такая проблема. |
| Автор: Hexel 26.10.2009, 20:32 |
| Значится, какие еще мысли пришли в голову 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 нужной фигуры. все ходы искать не обязательно, достаточно найти хотя бы один. ну считай, вот тебе готовое решение) с тебя только логика) |
| Автор: Beltar 26.10.2009, 20:51 | ||||||||
У вин-контролов вроде возможностей больше.
Так перебирай просто по возможным направлениям пока не упрешься в край или в фигуру.
А зачем двигать по доске TImage когда его можно просто скопировать на канвас?
А вот это как раз стоит отдельно от доски делать. По сути можно управлять уже списком ходов, а для доски команда отката, например, будет выглядеть как переместить фигуру с одного поля на другое без проверок, если нужно восстановить сбитую. |
| Автор: VanHelsing 11.11.2009, 20:53 |
| Beltar, Hexel спасибо за предложения. Вот все таки решил задуматься на логикой. Наверное лучше будет если доска будет представлена матрицей 8х8. Каждой фигуре будет соответствовать определенное числовое значение (возможно воспользуюсь предложение от -9..9). Проблема в другом. Если мы смотрим на доску, то левый нижний угол имеет координаты [1, 1], а матрице он имеет координаты [8, 1]. Наверное все просто, но я не понимаю как мне это соединить между собой. |
| Автор: Beltar 12.11.2009, 08:25 |
| Проблема на самом деле не в этом (Какая разница как ты представляешь себе массив, с [1,1] внизу, или, что более привычно вверху? Он просто в твоем воображении зеркально отразится.), а в том, что, экранные координаты считаются от левого верхнего угла и при нормальном положении доски (белые внизу) Y-координата поля a1 больше таковой у a8, впрочем по хорошему доска должна поворачиваться, т. е. нужно 2 способа рассчета Y координат. Несложно, но можно запутаться. А с X там все элементарно, как ни крути X-координаты поля [i,j] будут LeftBorder+(j-1)*FieldWidth и LeftBorder+j*FieldWidth. |
| Автор: VanHelsing 12.11.2009, 15:46 | ||
Вот в этом то и проблема, тем более на мой взгляд код из=за этого будет запутанным. Хочу найти другие варианты. |
| Автор: Beltar 13.11.2009, 08:24 |
| Там кода код наплакал, всего-лишь найти координаты прямоугольника поля, зная отступ от края и размер поля. Одна ф-ия в полтора десятка строк. |