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

Вот моя диаграмма.
Выходит, что класс CMap. Отвечает и за саму карту и за ее отрисовку. Тут нужно создать новый класс, который будет рисовать. Вопрос такой, этот класс лучше сделать частью формы с отношением Композиция. Либо частью класса CMap тоже композицией. Или его еще куда можно засунуть?
Тут возникает следующий вопрос на моей диаграмма видно, что класса Enemy и Player так же через композицию относятся к классу CMap. Это как бы по своей сути верно, но у меня оно реализовано так, что функция которая проверяет может ли игрок походить в случае если может, то изменяет этот массив, который находится в классе CMap. Поэтому, как он мне сказал, туже композицию надо провести от Player к CMap и так же от Enemy. И выходит, что тут получается обратная связь, а он говорит, что нижние классы ничего не должны знать о верхних и ничего не должны менять.
Поэтому возвращаясь к новому классу Который должен рисовать карту, то он же тоже будет получать массив из СMap, чтобы что-то нарисовать, хотя он же ничего не изменяет поэтому тут будет просто Ассоциация?

Вот собственно и все, что хочу уточнить.
Спасибо.

я бы так сделал, наверное

Это все через Агрегацию?
Хорошо даже если и так, то Игрок должен ходить как-то, функции ходьбы у меня в классе Игрока, но для перехода ему нужно знать, где можно походить, потому я и посылаю из класса Карты ему массив с картой и тот его изменяет, а так нельзя сказали. В данном примере, я тоже не вижу возможности как таковой ходить игроку не зная куда.
К стати вот еще по этому поводу, поскольку игрок должен быть сам по себе и не зависеть от класса Карты, то выходит, что мне нужно будет переместить функции перехода в другой класс, а именно сказали, что каждый класс должен отвечать только за свои действия, то в класс Карты помещать не стоит и нужно будет еще сделать 1 класс Перехода, который будет отвечать только за переход. При этом выходит, что он тоже должен знать, массив с картой, чтобы проверять можно ли перейти... Тогда функции перехода все будут в этом классе, а в классе игрока ничего и не остается.   Вот вроде выходит, что должны быть классы CMap, Drawer, Player, Enemy, Walker.
Как бы теперь правильно связи расставить...
Игрок и Враг явно зависят от Карты через Композицию.
Дровер получает массив с картой из класса Карты т.к. ему нужно знать что рисовать.(Ассоциация?)
Волкер... даже не знаю куда его лучше всунуть, поскольку он вроде как зависит от Карты при этом ему нужно будет изменять координаты всех на карте...
Есть идеи?

Вся наша жисть - игра...
Мы в ней игроки. Действуем на поле Земля.
Отсюда - отношения:
1. Игра содержит землю и игроков, передавая ход
2. Игроки знают о Земле (карте), на которой идут действия
3. Игроки знают и о других игроках (возможно, посредством анализа карты)
4. Карта содержит текущее положение - что/кто где находится

Итак, Game агрегирует Map и Player, являясь связующим звеном в передаче информации и управляющая процессом
Player знает о Map (имеет ссылку)
Map независима, имеет методы, позволяющие изменить/получить текущее состояние

Так это по сути,то что у меня есть сейчас, за исключением обобщенного класса Гейм.
У меня сейчас так все и расставлено, Карта содержит Игроков, Игрок знает о карте(внутри указатель инициализирующийся через Конструктор).
Вот только, преподавателю необходима структура следующего вида.
Если посмотреть на мою диаграмму:
Форма - ничего не знает о том, кто ее вызывает, но знает, что содержит она.
Класс Карты - не важно ему, где он находится, важно только, то что он содержит.
Класс Игрок\Враг - им не важно куда они подключены, важно только, что ниже.

Вот и выходит, что не должно быть обратной связи от Игрока к Карте, потому, что Игрок в идее не знает, какой класс находится выше него. И поэтому действия нужно выполнять, где-то выше и потом какими либо методами, сообщать игроку, что у него что-то изменилось. А поскольку условие стоит так, что один класс отвечает только за себя, то класс Карты не может выполнять обработку Ходьбы. Как я написал придется добавлять еще 1 класс, который после обработки будет в низ(Игрокам) отправлять сообщение, что изменились координаты и т.п.
Хотя лично я, не вижу почему ему не подошел мой вариант, либо те что вы предложили.

неправильно это.



тут нет "выше/ниже", тут кооператив. для его организации и нужен Game. А карта лишь имеет состояние, умеет сообщать о нем, менять его и (возможно) рисовать себя.

Нет. Game имеет принципиальное значение.

Добавлено через 2 минуты и 52 секунды
вот тут основная ошибка:

не зависят.

Хорошо, вопрос, почему класс Гейм агрегирует Карту и Игрока? Это же значит, что Карта и Игрок должны быть созданы, где-то в другом месте и не зависеть от Гейма.
И вопрос остается, перемещение же тогда так и останется, Игроку нужно будет знать о карте. Тогда выходит, что я принесу тоже самое переделанное на 1 новый класс.

Это когда же на агрегацию такие ограничения наложили?


Игрок имеет ссылку на карту, но уже не является частью карты. Ты же знаешь о Земле, а ей плевать на тебя (образно говоря).

Ах да это верно, я продолжил думать, что Игрок остается частью Карты.

На счет агрегации, из Википедии

Ну вот я и предполагаю, что раз Гейм это контейнер и он агрегирует Карту и Игрока, то они должны существовать не зависимо от Гейма?

TGrey, нельзя так строго понимать утверждение из вики, в UML помимо агрегации есть только композиция, которая накладывает больше ограничений на ассоциацию. В общем, ничего страшного не будет, если Game создаст игроков.

Ну я так тоже и подумал, потому и писал везде Композицию, что раз, в моем случае, карта удаляется, то и Игроки тоже, а в этом случае Гейм удаляется, то и Карта с игроками тоже. Просто мне нужно указать точную связь и это же тогда Композиция выходит?

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

Хмм, а можно не большой примерчик их отличия, потому что на консультациях преподаватель лично мне сказала, что раз при удалении контейнера сносится все содержимое, то это Композиция, если нужно будет им объяснить, что тут агрегация, то что говорить то)

первое попавшееся, но вроде по сути :
http://cssblast.ru/articles/oop_concepts/

К сожалению, там на самом интересном, статья не дописана и кода не хватает))
Но суть я понял такую:

Далее код и теория не соответствуют друг другу поэтому я полез в гугл найти не хватающей части, наткнулся на ту же википедию, но с довольно хорошим объяснением.
http://en.wikipedia.org/wiki/Has-a


Вот.

Я не хочу утверждать, что я прав или эта статья, просто хочу разобраться, как же оно на самом деле. Вот получается, что Game has a Map, has a Player.
Игрок не меняется на протяжении всей жизни Гейма, Карта по сути изменятся только внутри, а сам объект тоже остается неизменным на протяжении всей жизни Гейма.

Кстати тогда Player получается и Агрегирует Map. Т.к. он ее не создает, а просто "имеет" ее.

Это сообщение отредактировал(а) TGrey - 30.12.2010, 16:04

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

букет цветов  - композиция.. 
ваза, в которой стоит букет цветов - агрегация..

Добавлено через 1 минуту и 28 секунд

игрок агрегирует не карту, а указатель на карту, а карта представляет собой композицию игроков и врагов..

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


Примерно такая структура классов получается. А куда тогда желательно впихнуть Класс, который буде рисовать карту?
Если его сделать независимым и создавать вместе с Game. И потом просто передавать ему массив с картой?

Ничего не корректного не будет?

"обычно" класс Гейм не предоставляет собой композицию врагов и плееров, так как без он не предоставляет их наружу.. а сам изменяет когда и что нужно.. Он может содержать в себе эту композицию..

Добавлено через 1 минуту и 58 секунд

форме (или его окну)..

Добавлено через 3 минуты и 23 секунды

у Вас плеер и енеми самодостаточные ? т.е логика их поведения обслуживается ими же ? сомневаюсь..  
если сомнения верны, то схема не правильна..

Ну так тогда же будет та же связь, что преподаватель забраковал, карта знает о игроке, а игрок знает о карте...

т.е возможны только два варианта ? и больше никак ?

Добавлено через 3 минуты и 24 секунды
кстати насчет Player.. тот Player, o котором идет речь, это всего лишь фишка на поле..
класс осуществляющий управление этой фишкой , это другая сущность.. 
мне кажется Вы пытаетесь сделать из них единое целое.. 

В том то и дело, что я не уверен, что ему надо сделать, он сказал, что это не верно, что карта знает о игроке, а игрок знает о карте. Не смотря на это я вот сижу обдумываю, как сделать эти классы независимыми, но не вижу смысла в том, что игрок есть, но он не знает ничего о карте, на которой должен ходить. Это не логично. Все что мне пришло в голову убрать все методы "Перехода" с класса Игрока и засунуть их в другой. А потом по средствам того если переход возможен, то вызывать некие методы, которые будут изменять уже значения полей Игрока. Вот собственно единственный вариант, который мне пришел в голову, чтобы сделать Игрока не зависимым от карты.
К этом как раз и подходит, то предложение, что Гейм является контейнером для всех, при этом Игрок знает о карте, но карта не знает о игроке. Это как бы даже логически подходит. Тогда же остается нужда в доп. классе который должен знать и о Карте и о Игроке, чтобы проверять возможность Ходьбы и изменять данные на карте и чтобы изменять поля Игрока.  

если игрок - эта фишка на поле, как уже было выше сказано, то согласен что неверно..

Добавлено через 56 секунд

не путайте игрока и фишку игрока..

Добавлено через 2 минуты и 29 секунд

является не контейнером.. а обслуживателем единой логики...

Добавлено через 4 минуты и 41 секунду

это и есть гейм ..


какого игрока ? фишку он меняет.. а состояние управляющего находится вне ведомости класса игры..

Добавлено через 5 минут и 10 секунд
опишите игру, которую Вы делаете, чтоб можно было подсказать точнее.. 

А какая разница между игрок\фишка игрока?


Игра Пак-Мен. В моем варианте:
CMap - загружает карту из файла(0 и 1), рисует карту.
Player - методы обработки ходьбы игрока(если может походить по карте и там есть монетка по значение в массиве меняется на 2)
Enemy - методы обработки ходьбы врага.

Структура такова

в том фишка лежит себе где нибудь и никого не трогает.. 
зато всем контроллерам видно где и что лежит и двигают что им можно, когда им нужно и можно.. 


Добавлено через 5 минут и 1 секунду




  







свой вариант напишу попозже..сейчас нет достаточно времени.. 

Что-то я вообще потерялся...
Хорошо выходит, что мой Класс Плеер - фишка. Значит он ничего сам делать не должен и ни о чем знать не должен тоже. В это же время, если учитывать новую структуру классов, то класс Гейм - это контроллер, который будет пытаться перейти в карте и если это возможно, тогда он двигает Игрока(он же Фишка).
Тогда игрок ничего не соображает вообще, методов в нем выходит вообще не будет, только поля для очков, жизней и другие параметры.
Значит Гейм - управляет переходами, содержит Карту, содержит Игроков.
Игрок вообще ничего не знает.
Карта тоже ничего не знает, содержит только массив с самой картой.

приступим...

нам нужно :
 карта местности 
 активные фишки (игрок, враги)
 пассивные фишки (подарки)

1. фишки могут быть расположены на карте местности, а могут просто хранить координату на поле, при том второе имеет предпочтение ввиду экономичности..
2. передвижение, разбор столкновений, и др подобное осуществляет контролер игры..
3. игрок может изменить направление принадлежащей ему фишки..(*тут пересечение с пунктом 2.)
4. игра может находиться в разных игровых состояниях (start, play, finish)
5. отрисовка должна осуществляться внешним объектом, на основании общей информации..

Добавлено через 1 минуту и 17 секунд
теперь надо подумать как это все состыковать..

Ну пассивных фишек нет) Без них обойдусь.
В данный момент есть только Игроки и Враги которые хранят в себе координаты на поле. Методе столкновений и переходов я уже написал, нужно только перенести их в Game(он же контроллер). Тогда выходит, что Гейм будет вызывать функции Перехода, в случае "съедания" монетки изменять данные в массиве Карты и изменять координаты Игроков\Врагов.

А вот на счет отрисовки, внешний объект будет создаваться на форме, как отдельный класс, который рисует карту из заданного массива. Тогда выходит что он должен будет получать класс Гейм и из него выбирать массив с Картой.

Как-то так?

отвлекли немного.. вот пока часть наброска.. 

Спасибо, но мне не столь важен код, как сама диаграмма) Я потом под нее свой код подгоню.

ну так монетки и подразумевались в роли пассивных фишек 

Добавлено через 1 минуту и 47 секунд

для отрисовки (в принципе) нужна не толька Карта, а вся информациядоступная через game..

Добавлено через 2 минуты и 47 секунд

мне просто легче кодом выражаться.. с uml я не сталкивался 

Добавлено через 5 минут и 29 секунд

метод формы вызывает render отрисовщика, передавая в него контекст для рисования и ссылку на игру.. 

что за связь на схеме между врагом и плеером ?

Это наследование. Игрок и Враг оба имеют общие поля такие как Х, У, Сдвиг Х, Сдвиг У, Ссылка на Карту. Потому я решил, что проще унаследовать Врага, чтобы не повторять класс. А для абстрактного класса я посчитал он тут будет нецелесообразным т.к. нет никакого полиморфизма.

Вот насчет Рисовальщика, будет получать, Канву для отрисовки и ссылку на Игру. Хорошо, а его тогда лучше сделать френдом для Игры? Потому что эти поля Игрок, Враг, Карта, явно будут в секции Приват, хотя можно сделать методы чтобы их получить, но, как и в прошлый раз я не придумал ничего умнее как засунуть массив с картой в Паблик, по тому что же некак возвращать из функции многомерный массив.

вопрос был не об этом 


да но игрок не является врагом.. поэтому если есть общий предок, определите для него свой тип..

Добавлено через 2 минуты и 3 секунды

классная причина    

Добавлено через 3 минуты и 39 секунд

зачем ?

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

Добавлено через 5 минут и 21 секунду

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

Ну так а там между ними больше и нет связей?) В чем тогда был вопрос?

Да, Игрок не является Врагом. Я так тут подумал, что по идее наследование это расширение одного класса за счет другого, а у меня тут сужение получилось) Во Врага переходят все Протектед поля, а Приват остаются у Плеера. Видимо, правильнее было бы наследовать Игрока от Врага) Общего предка нет. Не знаю, как вы, но я в нем просто смысла не вижу. Если он будет, тогда получиться, что класс Игрок от него наследуется и действительно расширяется, за счет своих характерных полей таких, как Жизни, Очки... А у Врага таких полей нет, выходит, что он просто будет дублировать поля. И смысл тогда от предка.

Причина классная)) У меня тут ничего не виртуалится зачем еще усложнять)

Ну я и спрашивал, Френдом, либо интерфейс дописать, чтобы получить поля)


На счет последнего, я верно понял? Засунуть массив с картой в структуру и через функцию возвращать ссылку на эту структуру?

тоже не верно.. 


ну смотря как представляете.. 


вот опять вернулись к началу..  на поле игрок и враг практически идеентичны.. а тот игрок который хранит нечто другое, он не на поле...

Ээээ, а где же он тогда? Видимо в том, что писал я, они все на поле.

1. никто не предлагал делать виртуал.. 
2. Наследование Вы сами зацепили, я не предлагал даже его..
3. выделить отдельный тип можно не только в предка, но в агрегируемый тип..

Добавлено через 1 минуту и 44 секунды

ну давайте еще раз повторим кто у нас на поле .. начинайте.. я буду подправлять.. 
(без кода, просто словами)

Как вы говорили - фишка. Лежит себе, где-то никого не трогает. Фишка содержит в себе координаты на поле. Вот так и у меня мои классы содержат свои координаты на поле. А класс игрока к этому у меня еще и содержит Очки и Жизни. Выходит, что фишка содержит Координаты + доп. данные. Я тогда не совсем понимаю, что подразумевается под игроком, который не на карте.

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

Так у меня таких нет) Выходит, что у меня все - Фишки)

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

враг - класс с АИ для управления фишкой.. 

Так, а что тогда получается Фишка? Если класс Игрок это игрок который не на поле? То фишка это даже не объект? Это просто определение того, что рисуется на канве по координатам полученным из класса Плеер?

и уже выше проскальзовало.. но еще раз заострю.. 
поле с фишками это не игра, а "ядро игры" - предполагаю playing, но тут надо подумать..

Добавлено через 4 минуты и 16 секунд

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

Добавлено через 7 минут и 20 секунд
фишка имеет два интерфейса управления.. один задающий направление, другой осуществляющий непосредственное перемещение.. 
первый это гуи или аи, в зависимости чья фишка своя или врага, а второй это контроллер игры..

Добавлено через 10 минут

рисуется это отдельный вопрос.. для "полноценного" рисования нужна вся информация.. но нас сейчас не интересует это..
ддостаточно утверждения что гейм будет предоставлять "константный" доступ к любой игровой характеристике.. 

Ну значит, так все и остается? Класс Гейм будет руководить всеми перемещениями, классы Игрок будет хранить координаты игрока на поле, класс Дравер будет рисовать карту и фишки на ней.
Так значит и остается?) На счет той диаграммы, что я привел, там получается, что Игрок\Враг ничего не знают о карте, это будет допустимо? Всеми будет заправлять Гейм, а те будут в бессознательном состоянии ничего не зная друг о друге.

Гейм (плайинг) только "прокручивает" к следующему кадру.. 
а управление ( в случае пакмана) это выбор направления движения.. , а не само движение, которое просто является выражением следующего кадра..

Добавлено @ 12:39

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

Добавлено через 5 минут и 25 секунд

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

Добавлено через 10 минут и 15 секунд
еще одно уточнение.. фишка это блок данных .. а плаер и враг это контролеры управления..

Это сообщение отредактировал(а) mes - 31.12.2010, 12:40

Хорошо, ну так сама суть, Диаграмма классов приведенная мною соответствует тому, что мы пытаемся сделать то?)

Кстати тогда выходит, что Игроку нет смысла знать о Карте, если всем будет заправлять Гейм.


Вообще моя задача, не геймдев) Это просто я выбрал такую тему, задача выполнить это все в ООП. А именно построить правильное взаимодействие между классами) Потому мне не важно, что можно дописывать и как было бы точнее с точно зрения Создания игр. Просто надо, эти классы, как-то упорядочить и сделать из них каркас.

Это сообщение отредактировал(а) TGrey - 31.12.2010, 13:35

TGrey
помоему вы занимаетесь не ОО Проектированием, а ОО Анализом(если строите взаимодействие м\у классами)

не всем, а только сменой кадров и расчетом вытекающих коллизий и т.п.

Ну да уже Анализом) Мое проектирование не прошло, приходится заново анализировать.

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

2 ТС: посмотрите в сторону MVC (Model/View/Controller) концепции. То, что у вас сейчас получается (стараниями mes) замечательно в эту концепцию укладывается. При этом сама концепция MVC налагает некоторые ограничения на функциональность и взаимодействие частей. Эти ограничения могут помочь и в вашем анализе   

Ой та мне бы уже хоть так сделать)) Чтобы было по велению преподавателя))

Да уж.
  
- Девушка, можно вас на 5 минут?
- А успеете, за 5 минут?
- Долго ли умеючи!
- Умеючи, как раз долго...
- Ну тогда хоть как нибудь ...
- А на 'как нибудь' и муж есть.

Наверное он не просто так повелел, видимо на то были основания   

Я не верно выразился, мне не все равно, как сделать. Просто та структура, что я сделал не подошла и сказали переделать с такими-то условиями. То, что мы общими усилиями тут вывели, как раз вроде подходит этим условиям) Поэтому я и говорю, что хоть так бы уже сделать, потому что вот сегодня Новый Год уже, а сдать надо на со следующей недели. Вот в этом и выражается "хоть так сделать".

Всех С Наступающим. Спасибо за помощь)  
Накуролесю по этой схеме классы и пойду сдавать) 

TGrey
Оливье нужно стряпать, а не думать что сдавать)))
с наступающим вас тоже =)

тут надо понимать, что под этим подразумевается.. да не должен два не связанных действия..
но есть к примеру координирующие классы, которые в принципе только и занимаются союзом "И" 


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

Добавлено через 3 минуты и 11 секунд
забудем для начала об управлении.. считаем что делаем не игру, а просто типо видеоролик 

Добавлено через 6 минут и 27 секунд
у нас есть игрок, враги, подарки, каждый из которых может быть в разных состояних..
фактически игрок враг и подарок ничем не отличается - назовем любого из них фишкой.. 
но фишки должны отличаться друг от друга... то есть должны отличаться характрером.. 
при этом игроку (как и всем остальным) может принадлежать несколько характеров (не одновременно)..

Добавлено через 7 минут и 17 секунд


Добавлено через 11 минут и 32 секунды
характер это некая полиморфная единица, от реального типа которого зависит поведение.. 

самый простой способ разгрузить через enum ..


Это сообщение отредактировал(а) mes - 31.12.2010, 16:29

Ну так тогда же я не вижу ничего плохого, что у меня класс Карты рисовал ее))
Видеоролик) Хорошо.
Класс Гейм будет дергать за ниточки. Тыкаю по клавиатуре, вызываются методы Гейма для смены направления, проверяется можно ли походить, скушать монетку, удариться в стену или попасть на врога, при необходимости изменяются данные на Карте если "съели" монетку, изменяются координаты Фишек.
А тут я так понял, можно либо посылать сообщение Драверу, что типа все уже изменили ходы окончены, нужна перерисовка. Либо через одно место, засунуть Перерисовку в Таймер и пусть себе рисуется каждые 30млсек)) Вот вроде и построение ролика)?

чуть посложней отразить тип на таблицу свойств..

так

или так :


Добавлено @ 16:47

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

Добавлено @ 16:49

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

Добавлено @ 16:53
итак у нас есть набор фишек с разным характером..
теперь надо их немножко расшевилить..
в плайинге перемещаем их (пока произвольно) .. назовем эту функцию produce_frame.. 
она будет вызываться извне, чтоб адаптировать скорость игры под компьютер..

Добавлено @ 16:55
сейчас фишки бегают по пустому  полю,для того, чтоб они бегали по дорожке,
добавим карту местности.. Пусть будет битовый (для простоты байтовый) массив где каждая ячейка показывает пусто или нет.. 
теперь в produce_frame мы должны учитывать возможность перемещения только по пустым ячейкам.. 


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

Да все бы хорошо, я не совсем понимаю, зачем описывать эти поведения для фишек? У меня всего-то 2 фишки)) А теже Монетки это не объекты и ничего такого, просто 1 в массиве с картой, при переходе на которую значение меняет на 2. Самый элементарный способ наверно)

теперь нужно добавить осмысленности.. заводим класс осуществляющие интеллект... 
пусть будут gui_player, player_auto, enemy_stupid, enemy_smart..

так же нам нужен не только управляющий, а производящий объекты.. допустим фабрика.. 
к этому вернемся чуть позже..

Добавлено через 3 минуты и 43 секунды

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

Добавлено через 4 минуты и 5 секунд
но это уже детали конкретного реализации..

Добавлено через 5 минут и 29 секунд

такой подход Вам будет мешать... Объект просто выражен некоторым значением..

Добавлено через 6 минут и 23 секунды
хм сбился.. сейчас перечитаю чего мы там написали.. 

Да уж)) Не думал, что так пустится тема)) Скоро можно будет собрать готовый код)))

Дело в том, что это все у меня уже написано, АИ, Коллизии, Смена направления, изменение данных)) Мне бы только правильно по полочкам разложить обязанности))

Ну почему же мешать) Мне же не надо мега продвинутую и супер запрограммированную игру) Обычная примитивная реализация подобия игры.
Были и другие работы которые вообще не имели отношения к игре. Вот мой однокурсник сдавал Фракталы. У него вышло полная чушь по сути) Просто бессвязные классы) Поэтому и приняли т.к. в диаграмме классов там просто не как было ошибиться)) В моем же случае немного не корректно распределены обязанности и их нужно исправить.

Это сообщение отредактировал(а) TGrey - 31.12.2010, 17:12

итак как бегают фишки и идет расчет столкновений вроде понятно.. покрайней мере отчего оталкиваться.. теперь перейдем к управлению (интеллекту)..  
для того чтоб решить куда идти, надо "видеть" состояние всей игры.. для человека, естественно, нарисованное, а для аи достаточно ссылки на плайинг.. 
как производиться управление ? можно пойти двумя способами.. 
1. в фишке выделить память под хранение импульса и предоставить плееру его изменять.. 
2. у плеера хранить желаемое направление, а контроллер игры будет опрашивать и на основании этого изменять фишку.. 
второй способ мне кажется предпочтительнее.. 
теперь как выразить это.. 
можно у плайинга сделать метод  для изъявления желания направления движения фишки.. и на него вешать объекты.. выглядит немножко неповоротливо..
сейчас..

Добавлено через 1 минуту и 34 секунды

"под подходом" имелось в виду нежелание признавать объектом то, что фактически является законченной полноценной сущностью из за того, что оно выражено числом 

Добавлено через 6 минут и 18 секунд
думаю самое простое будет так..
имеется плайер, тот кто управляет фишкой :


Добавлено через 9 минут и 37 секунд
итого получается что с каждой фишкой у нас происоциирован контролер игрока, который получая всю информацию о плайинге выражает свое желание.. и на основании этого идет пересчет положения.. 
подобный подход позволит прицепить любойконтролер на любую фишку.. т.е можно аи на фишку игрока , а гуи_плаыера на врага..

Добавлено через 11 минут и 16 секунд
P.S. везде писал аи - это калька с английского - подразумевалось ИИ..

Добавлено через 14 минут и 38 секунд
значит у нас будет набор игроков для игры, опрос их готовки и переход в режим игры.. 
итого получается что game хранит список игроков, а playing хранит фишки и т.п.. 
осталось согласовать пожелания плееров с поведением фишек..

мне сейчас нужно отойти.. позже продолжу (если сами не разберетесь к тому времени )..

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

Спасибо за помощь mes, но я уже тоже ухожу праздновать) На сегодня наверно можно закончить.

а что когда плеер скушает супер силу, он врагов не бьет ?

Добавлено @ 19:22
я тут выше говорил про кадр (frame)  - к рисованию (отображению) это не имеет никакого отношения.. 
фактически наш frame(подобрать более точный термин оставляю Вам) это аналог хода в играх с поочередным хождением.. 

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


Добавлено @ 19:24

Цитата(TGrey @  31.12.2010,  16:34 )

Спасибо за помощь mes, но я уже тоже ухожу праздновать)

пожалуйста  приятного времяпровождения  

Цитата(TGrey @  31.12.2010,  16:34 )

На сегодня наверно можно закончить.

ну теперь можно сказать, что закончили.. у меня вроде все уложилось в голове 


Это сообщение отредактировал(а) mes - 1.1.2011, 00:17

Да вы маниаки, господа!   
Всех с Новым Годом...

у меня на самом деле несколько иное время.. чем то, что показывает форум.. 

Добавлено через 2 минуты и 44 секунды

Взаимно 

Все, сдал на 5  

TGrey, ну если не секрет, нам тоже покажите  интересно все ж   

Да то, что и говорил)
Все классы не знают ничего друг о друге, Дравер рисует только то, что ему дает Гейм. Гейм управляет передвижениями.
Все как заказывали)

TGrey, таки Гейм?   

Что-то сервер с картинкой упал видимо... не показывает.
Ну да Гейм. Больше я не придумал ему заданий, поэтому сделал задачу ему обслуживать ходы)