Strange Wood

Закрытые или заброшенные проекты, не состоявшие в Клубе, но имевшие ветку на форуме.

Модератор: Jolly Roger

Аватара пользователя
BreakMT
WANDER Team
Сообщения: 933
Зарегистрирован: 27 ноя 2006, 12:16

Сообщение BreakMT » 22 ноя 2007, 10:11

что-то с отрисвкой вещей - видно что топор мигает
и кстати подобрать не работает хотя в ридми есть!

Dmiry
Сообщения: 168
Зарегистрирован: 14 июн 2007, 10:32

Сообщение Dmiry » 24 янв 2008, 09:31

Пока меня не отправили в отстойник, ой, то есть в Lost Dream, рапортую - работа замедлилась, но продолжается.

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

Dmiry
Сообщения: 168
Зарегистрирован: 14 июн 2007, 10:32

Сообщение Dmiry » 26 фев 2008, 03:31

25/01/08
Потихоньку выполняю рефакторинг. Сейчас выделяю класс MapWindow.

Еще одна идея - выделить все, что касается SDL, в отдельный класс. Тогда иерархия классов окон будет использовать один класс для отображения на экране.

Закончил выделение класса MapWindow. Ошибок компиляции нет, но при запуске выдает Access Violation.

28/01/08
Выделил из Паинтера класс MessageWindow.

Проект компилируется, запускается, но на экран ничего не выводит. Уже хорошо. Вывод отсутствует, потому что не делается явный вызов для отрисовки на экране. Этот вызов по идее должен происходить автоматически после изменений в данных программы. То есть при перемещении героя паинтер должен самостоятельно определять необходимость перерисовки экрана и соответственно вызывать метод Draw нужного окна.

Пришел к еще одной мысли: если я выношу рисование карты полностью в отдельный класс, мне потребуется этому классу предоставить карту, героя, монстров, предметы и т.д. То есть все то, что может находиться на карте. Вопрос: надо ли тогда включить в карту все перечисленные объекты? Или просто ссылку на соответствующие объекты?
Первая заповедь фотолюбителя: Проявил себя - закрепи!

Dmiry
Сообщения: 168
Зарегистрирован: 14 июн 2007, 10:32

Сообщение Dmiry » 26 фев 2008, 03:34

30/01/08
Сейчас мне кажется, что все, касающееся SDL, надо вынести в отдельный класс. В том числе и вывод спрайтов на поверхность. Смысл в том, что классы игры или даже паинтера не должны выполнять вызовы SDL. Это должен делать только специализированный класс-оболочка. Тогда должно выглядеть следующим образом: класс MapWindow при рисовании предметов на карте вызывает свой метод DrawItem, который в свою очередь вызывает SDLSystem.DrawGameGlyph. Глифы также хранятся в SDLSystem? Пока я в этом не уверен. Потому что глифы карты нужны только для рисования карты. Хотя глифы символов могут понадобиться не только для окна сообщений. Выделить отдельный класс GlyphList?

06/02/08
Размышлял над структурой проекта. Особенно после чтения книги "Совершенный код". Глава про итеративный процесс проектирования.

Пришел к следующему разделению ролей: Паинтер отвечает за формирование внешнего облика игры, SDLSystem - за любой вывод на экран. Если надо изменить оформление игрового экрана (добавить/убрать элементы, изменить рамки, размещение и размер игровых окон) - за это отвечает паинтер (или у него теперь должно быть другое название?). Непосредственно за вывод на экран отвечает сейчас SDLSystem (хотя более правильно было бы назвать как-то вроде LowLevel).

По-прежнему остается вопрос, в какой части надо хранить глифы. По идее - все-таки в паинтере. SDL отвечает только за их отображение. Простой вопрос: если я захочу сменить средство вывода картинки на экран - должно это затронуть глифы? При таком подходе можно четко провести стратификацию - один слой отвечает на формирование изображения из составных элементов (Painter), другой слой - за низкоуровневый вывод на экран (Screen), еще один инкапсулирует игровую логику (Game).

С другой стороны, SDLSystem должен знать про тип TGlyph, описанный в паинтере. Или SDLSystem должен экспортировать функцию/процедуру для вывода глифа на экран. Тогда в каком виде этот глиф должен подаваться на вход функции?
Первая заповедь фотолюбителя: Проявил себя - закрепи!

Dmiry
Сообщения: 168
Зарегистрирован: 14 июн 2007, 10:32

Сообщение Dmiry » 26 фев 2008, 03:35

14/02/08
Читал книгу "Совершенный код" Макконнела. Много думал. Надо сделать некоторое проектирование для игры. В частности, выделить подсистемы, и определить интерфейс каждой из подсистем. Пока присутствуют следующие подсистемы: низкоуровневый вывод на экран - SDLSystem; подсистема организации игрового экрана - Painter; подсистема, реализующая игровую логику - Game; подсистема сохранения игры и загрузки - сейчас в методах LoadGame и SaveGame класса TGame.

Больше всего вопросов касается Game. По моим предположениям, этот класс объединяет в себе все составные элементы - героя, карту, предметы, а также взаимодействия между ними. Если организовывать сохранение и загрузку в виде отдельной подсистемы - то будет похоже на паинтер - то есть каждый заинтересованный класс вызывает Storage.SaveXXX(self).

Есть еще мысль оформить координаты клетки карты в виде отдельного класса. Тогда можно упростить вызовы "поднять предмет"/"бросить предмет", передавая координаты в виде экземпляра класса.
Первая заповедь фотолюбителя: Проявил себя - закрепи!

Аватара пользователя
BreakMT
WANDER Team
Сообщения: 933
Зарегистрирован: 27 ноя 2006, 12:16

Re:

Сообщение BreakMT » 17 ноя 2011, 13:45

Dmiry писал(а):Читал книгу "Совершенный код" Макконнела. Много думал.
Еще одна причина для темы viewtopic.php?f=9&t=668

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 4 гостя