Архитектура движка.Форум

Методика проектирования, итеративность + ОО. (полуночная лекция) (комментарии) (3 стр)

Страницы: 1 2 3
#30
23:24, 28 янв 2006

Zeux
>Как связаны во второй фазе
>> Структура файлов/каталогов начинает фиксироваться более формально - в "движковом" коде.

>> За чтение битмапа путём LoadBitmap("blabla.jpg") бьют по рукам.
>?

Во второй фазе процесс разработки игры становится более формальным: он начинает проявлять себя в коде.
LoadBitmap("blabla.jpg") в игровом коде означает, что игровой программист захотел прочесть этот конкретный битмап.
Зачем он этого мог захотеть - вопрос третьей фазы.
Вопрос второй фазы - почему именно blabla.jpg?

Где именно LoadBitmap() должен искать blabla.jpg?
Скажем, может быть (динамический) контекст.
Типа как мы задаём пути include для компилятора, или пути поиска текстур в 3D-пакете.
И при компиляции .cpp #include foo.hpp может начинать искаться сначала там, где .cpp - и дальше по списку.
Что образует контекст?
К какому другому объекту может быть привязан blabla.jpg?
Почему игровой программист может хотеть явно указывать контексты, а не доверять эту работу низкоуровневым push-подсистемам?

Что будет, когда структура каталогов изменится?  Что, если она вообще фиксируется низкоуровневой виртуальной файловой системой?
Что, если она тэгированная, а не иерархическая?

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

Исключения из правил - редки, поэтому вменяемый игровой программист согласится использовать более длинную и тяжёлую запись.
Согласится явно проинклудить специальный хидер, использовать deprecated функцию, вынести строку в static.

Даже такая простая мера, как

  #include "bitmapio/explicit_bitmap_loader.hpp"

  const bitmapio::explicit::bitmap_loading_intent  blabla_jpg_loading_intent(vfs::explicit_path("blabla.jpg")...);

  ...
  {
     //const bitmapio::pbitmap p = bitmapio::load_bitmap( "blabla.jpg" );
     const bitmapio::pbitmap p = blabla_jpg_loading_intent(...);
  }

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

Такая мера даёт дополнительный уровень хуков: мы заменяем чистую pull-модель на близкую к push-модели.

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

Это и есть первые ростки третьей фазы.

#31
17:32, 31 янв 2006

aruslan
>классические проблемы C++: асинхронные потоки управления, машины состояний/параллельные CSP
А под этим что имеется ввиду?

#32
15:14, 1 фев 2006

>bitmapio::explicit::bitmap_loading_intent
Бугага, ключевые слова жгут.

#33
20:14, 1 фев 2006

cppguru
Уел, да.

#34
21:06, 1 фев 2006

aruslan

почитал... топик - интересный!
поясни поподробней, что, на твой взгляд происходит после четвертой фазы?
интересует именно вот эта фраза:

>На этой фазе начинается новый виток спирали.
>Если вынесенная вовне модель страдает аналогичной C++ ригидностью - всё неминуемо начнётся с начала.
>Скажем, внутренний порок трёхлетней давности статических спецификаций напрямую связан с ригидностью описаний.

#35
18:45, 6 фев 2006

aruslan
Спасибо, очень доходчиво и понятно. Только что дошёл до пониманимания этих вещей. Ещё бы с примерами о третьем и четвёртом уровне:) А проблемы баз данных мне понятны, сам несколько раз перестраивал.

#36
23:44, 3 мар 2006

да, aruslan, третий и четвертый этап определенно интересуют.

#37
15:13, 9 мар 2006

Прочитал, про фазы познавательно, искал себя там.
Как оказалось, изначально двигаюсь к четвертой фазе, сейчас нахожусь на границе 2-й и 3-й.

>На этой фазе начинается новый виток спирали.

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

#38
20:09, 11 мар 2006

Resolver
> отрыжками твоего мозга в процессе обработки мыслей, происходящему по односложному конвейеру наподобие спирали
Хорошо сказано.

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

Всё как в жизни ;)

Прошло более 8 месяцев
#39
11:27, 18 ноя 2006

Неужели тема закрыта? ;)

было бы замечательно примеры в UML поглядеть 3-й и 4-й "фаз".
если шибко отличаются - то по паре, хотя бы, на фазу. если, конечно, не трудоемко и не времязатратно.

#40
4:34, 22 янв 2007

aruslan


Не совсем понял как может DDS убивать ОО модель.
Давайте вернёмся к Вашему же примеру:

-----------------

Попробуем сделать окошко для моего простого приложения.  Без ОС.
С нуля.  Как игру.  Как велосипед.

Моё главное окошко состоит из рамочки, текста и одной кнопочки.

Тупой прямолинейный ОО дизайн сделает мне класс окошка, агрегирующий рамочку, текст и кнопочку.
Внимание: дизайн - верный (хотя и тупой) - мы программируем то, что нужно и ничего лишнего.
main_window  text      set_text("blabla").
main_window  frame  set_thickness(25).
main_window  button  set_text("Ok")

Но... кнопочка некрасивая получилась.  Опять set_text.  Да и реализация - сплошной copy-paste будет.
Немножко подумав, ОО дизайн попытается отразить кнопочку как немножко почти то же самое окошко.
Только без встроенной кнопочки.

Немножко ОО рефакторинга и - вуаля! - применяется паттерн Composite.

Появляется классическое "контрольный элемент".
Одной из разновидностей которого является "окошко" - набор "контрольных элементов".
Плюс "контрольный элемент" "кнопочка" (в глубине - тоже "окошко").
Плюс "текст" (не будем двигаться дальше :) ).

> -- прошло три года, успешный рост продаж, уже восьмая версия...

И вот теперь смотрим на код.
Где моё любимое (и - единственное на прикладном уровне!) окошко?!
Где моя кнопулечка?!

Почему я должен писать вот такой вот код:
main_window
  find_control  "ok_button"
    cast_to_button
        find_control  "button_text"
          cast_to_text
              set_text "Ok"

------------------

А вот если так:


...

Control window = new PopupWindow();
window.setText("blabla");

Control button = new Button();
button.setText("Ok");

window.addChild(button);

...


Или эквивалентным XML Файлом (который в рантайме производит аналогичные окошки):


<PopupWindow text="blabla">
<Button text="Ok" />
</PopupWindow>

Мы уже можем подключать дизайнеров к редактированию этих простейших файлов (уже DataDriven клепание форм на лету,  - "орхетектура") для составления интерфейса окошек, все ещё оставаясь в рамках простой для понимания ОО модели...

Вот еще - Вы пишите посыл - см выше - происходит рефакторинг 3 года и он  почему-то деструктивен для ОО модели - ухудшается читабельность\понимание программы. Зачем тогда его такой страшный-то делать? Он наоборот должен служить обратному - упрощать понимание, чтобы код из каши превращался в нечто стройное и понятное.

P.S. Очень интересная тема! Большое спасибо Вам и xmvlad и всем кто принимал участие.

#41
19:25, 12 фев 2007

Filim
Вот еще - Вы пишите посыл - см выше - происходит рефакторинг 3 года и он  почему-то деструктивен для ОО модели - ухудшается читабельность\понимание программы. Зачем тогда его такой страшный-то делать? Он наоборот должен служить обратному - упрощать понимание, чтобы код из каши превращался в нечто стройное и понятное.


Потому что в жизни получается примерно так:

main_window_object = GetObject("main_window ");
if ( main_window_object == NULL) ....;
main_window = super_cast<AbstructWindowContainer*>(main_window_object);
if ( main_window == NULL) ....;
main_window_implementation = main_window->GetImplementationServer("FramedMainWindow"); // get platform realization
okButton_child = main_window_implementation->GetChildren("OkButton");
okButton = okButton_child->GetViewImplementation();
for (ViewControllerIterator ii=okButton->GetControllerFirst(),ee=okButton->GetControllerEnd(); ii!=ee; ++ii)
{
  if (ii->GetClassID==ClassID("666-666-666")
{
    static_cast<WindowTitleController*>(&*ii)->SetText(WStringBuilder.CreateString(str2wstr(STR_OK))); //lang support
}
}


------------------

Страницы: 1 2 3
Архитектура движка.Форум

Тема в архиве.