Кому можно рекомендовать ББ - в текущем состоянии!

[ilovb]

Но ты то явно как-то связываешь прототипирование с архитектурой.

Ну тык самым прямым образом связываю...
А ты другого мнения на сей счет? 

[ilovb]

Вот нашел статью, которая примерно соответствует моим представлениям о прототипировании:
http://dtf.ru/articles/read.php?id=44070

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

Ответ прост: было бы неплохо иметь некий инструментарий, в котором была бы следующая функциональность:

Возможность проведения теоретических изысканий: балансировка игры, проверка работоспособности и функционирования механики игры, сбор статистических данных, вывод необходимой информации в виде графиков и диаграмм, проведение различных математических расчетов.
Возможность прототипирования игровых диалогов и связанных с ними геймплейных моментов.
Возможность быстрого создания прототипа без знания сложных языков программирования.
Возможность быстрого изменения параметров и функциональности прототипов.
Возможность легкого использования полученных в ходе прототипирования данных.
После анализа исходных данных, а также имеющегося временного отрезка, было решено в качестве средства создания подобного программного продукта использовать в качестве языка программирования C#, а в качестве среды - Visual Studio .NET 2005. Почему был выбран C#, можно пояснить очень коротко - это быстро, гибко и визуально.

[ilovb]

И насчет текстового редактора. Под архитектурой оного я подразумеваю то, что описано в книге "Проект Оберон" в главе 5.2. Управление текстом.

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

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

[Geniepro]

Если бы мы специализировались не на мобильно-облачном сегменте, а на чём-то более стационарном (скажем пульт для дежурной медсестры для наблюдения за состоянием пациентов), то я вполне могу себе представить ББ в качестве основной платформы для разработки и распространения. Ну, а поскольку мы все ж таки в том числе программисты-профессионалы, подтянуть ББ в случае нужды наверно было бы можно. :-) Хотя задача в общем то не шибко памятежоркая, так что 64бита не актуально было бы.

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

[valexey_u]

Но ты то явно как-то связываешь прототипирование с архитектурой.

Ну тык самым прямым образом связываю...
А ты другого мнения на сей счет? 

Да, конечно.

Прототипирование нужно для того, чтобы понять предметную область, рассмотреть идеи, возможно показать потенциальному заказчику/потребителю. Конечным результатом серии прототипов является составленое ТЗ на реализации задачи (если конечно в ходе прототипирования не выяснилось, что идея не жизнеспособная). Прототипы могут клепаться на чем угодно вообще, причем людьми любой квалификации. Тут главное - БЫСТРО. Прототипов лепится множество, смотрятся возможные вариации и так далее. Все они выбрасываются.

После того как тонна прототипов написана, выброшена и ТЗ составлено, начинают свою работу архитекторы. Создается архитектора будущего приложения. В ТЗ обозначено что должно быть, и примерно очерчено куда это все может расширяться. Архитектор читает все это, включает свою параною на максимум, и закладывает в архитектуру точки расширения с учетом своей паранои с одной стороны, и исходя из бюджета и наличных кадров с другой. Архитектор также проектирует протоколы взаимодействия, основные абстракции, масштабируемость (с учетом многопоточности всякой), портируемость и так далее. Он принимает основные решения. Естественно он это делает с учетом языка на котором все это будет реализовываться (кстати, также он может и язык выбирать). В процессе архитектор может в принципе строить свои, архитекторные, прототипы. Естественно они уже пишутся на языке реализации. И очень часто не только не работают, но даже и не собираются во что-то цельное :-) На выходе архитектора имеем документ с описанием всего этого + каркас (набор скажем спецификаций основных пакетов, если у нас Ада) на базе которого будет строиться конечное приложение.

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

Я видел приложение на С++ которые были спроектированы джавистами - это ужасно. Равно как и наоборот.

[ilovb]

Ну в общем понятна разница наших взглядов. 

По большому счету разница сконцентрирована в этом предложении:

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

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

Я видел приложение на С++ которые были спроектированы джавистами - это ужасно. Равно как и наоборот.

Да ладно, я видел приложение 1С написанное сиплюсплюсниками. Всем офисом ржали, а потом еще и материли его/их на чем свет стоит.   

[valexey_u]

Ну в общем понятна разница наших взглядов. 

По большому счету разница сконцентрирована в этом предложении:

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

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

А смысл?

Также как в статье, которую я привел, эту роль выполняет геймдизайнер (который в игрострое и есть архитектор)

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

А вот архитектор принимает уже конкретные инженерные решения.

[ilovb]

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

[valexey_u]

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

Нет. Архитектор не есть внутренний заказчик. Точнее, внутри конторы обычно же цепочка, точнее как минимум дерево (или вообще граф). Где родитель твой есть твой внутренний заказчик. Так вот, геймдиз - это тот, кто пишет сценарий к игре, тот кто отвечает за геймплей и так далее. Но он НЕ отвечает за геймплей, НЕ отвечает и не принимает решение по используемым технологиям. Он не решает какова будет архитектора кластера серверной части World Of Tanks, ибо он в этом ни в зуб ногой. Это все решает архитектор. Вплоть до основных абстракций. И да, архитектор он инженер. И он является внутренним заказчиком уже для тимлидов например. Которые руководят группами программистов лепящих конкретный кусок функционала, а также тимлиды являются основными программистами в группе.

Если говорить о прототипах.. До частенько действительно не имеет значения кто именно их лепит. Тот же геймдиз может иметь под собой 5 дешевых программистов-студентов которые будут быстро прототипировать его бред. 1 прототип - 1 студентодень. Затем геймдиз смотрит что из этого всего получилось, все выбрасывается и пошла новая итерация. Пока оно не приблизится к чему-то вменяемому.

Причем если в геймдеве это еще не столь ярко выражено, то в менее креативных областях софтостроениях, это выражено сильнее. Приходит кому-нибудь в голову идея - а давайте скрестим текстовый редактор и медиа плеер! Вдруг чо получится? Ну, ок. Давайте слепим прототип - берется студент и сажается на эту задачу. Он что-то там лепит на вижуалбейсике, абсолютно ужасное внутри, но как-то работающее и падающее всего то раз в полчаса. И вот он прототип. Можно оценивать жизнеспособность идеи. Зачем автору идеи самому воплощать эту хрень, или дергать архитектора от текущих архитекторских задач на такую фигню (которая в 99% случаев не выстрелит)?

[ilovb]

Он не решает какова будет архитектора кластера серверной части

Сильно сомневаюсь что в wargaming этим занимался главный архитектор.

[valexey_u]

Он не решает какова будет архитектора кластера серверной части

Сильно сомневаюсь что в wargaming этим занимался главный архитектор.

Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.

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

[ilovb]

Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.

Откуда такая инфа?
Можно ссылочку?

Я вот его нашел:

С 1997 года работает в сфере IT. В последнее время - ведущий разработчик проекта World of Tanks, заявленная должность - главный гейм-дизайнер проекта World of Tanks.

http://world-of-tank.livejournal.com/716.html

И как бэ он полностью соответствует моему представлению об архитекторе.

[valexey_u]

Абсолютно точно этим не занимался главный геймдиз :-) И да, архитектура кластера входит в круг задач для архитекторов.

Откуда такая инфа?
Можно ссылочку?

Я вот его нашел:

С 1997 года работает в сфере IT. В последнее время - ведущий разработчик проекта World of Tanks, заявленная должность - главный гейм-дизайнер проекта World of Tanks.

http://world-of-tank.livejournal.com/716.html

И как бэ он полностью соответствует моему представлению об архитекторе.

То есть по твоему архитектор это менеджер? :-D (да, менеджеры тоже работают в сфере IT, если работают в соответствующей компании).

Серб никогда не отвечает на технические вопросы. Он отвечает на окологеймплейные вопросы и общую политику компании в плане игроков. Он не архитектор, он геймдиз. Он ковыряется в истории танкостроения, лазает по архивам, пописывает рассказики. Но он не инженер, он не архитектор. И естественно он не архитектурил кластер. Максимум его технической компетенции и влияния на техническую часть - это сказать что, например, они не будут считать данные (попадания там и так далее) на стороне клиента (ибо очевидно что это открывает дорогу читерам). Ну и расставляет приоритеты типа - в следующем релизе физика, или поддержка многоядерности. Но это не архитекторные вопросы, это чисто менеджерско-маркетоидная работа.

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

[ilovb]

Э нет, valexey, вот он то как раз и есть архитектор. Ибо его ошибка будет самой дорогой.

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

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

то есть это пример из жизни а не выдумки

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

[ilovb]

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