| Сегодня 9 мая, четверг |
      |
  
|
  
Какой рейтинг вас больше интересует?
|
Главная /
Каталог блоговCтраница блогера Software Design/Записи в блоге |
 |
|
Архитектура клиентского приложения (механизмы структуризации)
2017-05-19 10:56:00 (читать в оригинале)История первая
Некоторое время назад я работал в одной игровой компании, которой руководил немец. Создание игр не было основным бизнесом этого немца. Основные доходы он получал от продажи косметики и от сдачи коммерческой недвижимости в аренду. Наличие игровой компании было способом выделиться среди своих знакомых бизнесменов.
Игровая компания немца разрабатывала 3 вида игр:
- Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
- Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
- Игры для платформы Nintendo Wii.
В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.
С самого начала была понятна только общая канва игры. Маленькая фея ходит по саду, встречает своих подруг (других фей), разговаривает с ними и приглашает на вечеринку. Подготовка к этой вечеринке занимает значительную часть игры: фея украшает сад, собирает яблоки, готовит из них праздничный пирог. Вечеринка проходит весело: фея и ее подруги играют на музыкальных инструментах, а затем — танцуют.
Предполагалось, что игра будет представлять собой последовательность мини-игр. Каждая мини-игра посвящена определенной теме: украшению сада, сбору яблок, приготовлению праздничного пирога, исполнению музыки и танцам. Не смотря на то, что были понятны темы мини-игр, не были понятны их детали. Геймдизайнера в команде не было.
Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.
На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.
На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.
Далее
О “легком” процессе замолвите слово: процесс разработки в отделе инструментария Larian Studios
2016-11-21 11:04:00 (читать в оригинале)
Проходя собеседование на должность руководителя разработки в некоторых компаниях, автору в ходе разговора приходилось выслушивать одну и ту же историю:
«Есть у нас 3 — 4 программиста, которые вот уже полгода (или год — период времени зависел от компании) “пилят” один проект. Тем не менее, несмотря на усилия, работоспособной “демки”, которую можно запустить и продемонстрировать Заказчику, все еще нет. Мы ищем руководителя, который смог бы организовать работу».
Странность ситуации заключается в том, что вроде бы умные и опытные руководители компаний задумываются об организации процесса разработки не в начале работы над проектом, а лишь только тогда, когда набранная команда терпит неудачу. Между тем, над процессом следует задумываться в самом начале.
В данной статье автор делится успешным опытом организации процесса разработки в отделе инструментария Larian Studios.
Дальше
История семинаров и Мастер-классов
2016-10-04 22:48:00 (читать в оригинале)Зацепила фраза, что, мол, если бы во времена СССР должным образом бы уделяли внимание применению ТРИЗ, то это помогло бы избежать дальнейшей экономической катастрофы.
На мой взгляд, если в этой точке зрения и есть зерно истины, то лишь отчасти. ТРИЗ позволяет решать творческие задачи в области техники, если быть точным, то только в некотором подмножестве. Например, классический ТРИЗ не решает задачи в области электроники.
Вторая проблема - умение решать творческие задачи - это лишь маленькая толика из того, что надо для того, чтобы разработать технически и технологически сложный продукт. Помимо творчества нужны еще и инженерные усилия. ТРИЗ никак не затрагивает этого аспекта. Более того, в своей книге "Найти идею" Генрих Саулович отвергает идею создать информационную систему для проектирования ювелирных изделий. С момента написания книги уже прошло ~35 лет. И мы можем сказать, что информационные системы, помогающие спроектировать техническую систему, получили широкое распространение (это разнообразные САПР), а вот экспертные системы, помогающие сделать изобретение, хоть и существуют, но, увы, не так широко. Реальная практика оказалась против прогноза. И помощь в конструировании (проектировании) оказалась важнее креатива.
Постановка процесса разработки в отделе инструментария игровой студии
2016-08-03 00:32:00 (читать в оригинале)Выкладываю видеозапись моего выступления на IT Global Meetup, который проходил 23 июля 2016 года в Санкт-Петербурге. Тема выступления - процесс разработки, который мы используем.
Грубая оценка проекта
2016-06-30 11:11:00 (читать в оригинале)Выкладываю свою презентацию с апрельского митапа руководителей проектов о том, как делать грубую оценку проекта.
Речь пойдет о мультимодельности - для того, чтобы получить как можно более точную оценку, лучше всего использовать несколько моделей.
Речь пойдет о мультимодельности - для того, чтобы получить как можно более точную оценку, лучше всего использовать несколько моделей.
Категория «Обзоры интернет ресурсов»
Взлеты Топ 5
 | ||
|
+910 |
933 |
Ruslan_Terentiev |
|
+875 |
934 |
Накукрыскин |
|
+864 |
953 |
Yurenzo |
|
+774 |
849 |
~ tatarnikoff ~ |
|
+749 |
969 |
pogovorim |
Падения Топ 5
 | ||
|
-1 |
460 |
Рисунок, живопись, дизайн |
|
-1 |
2 |
Интернетные штучки |
|
-2 |
29 |
Бросить пить |
|
-2 |
455 |
Компания Альпари |
|
-2 |
215 |
Авторский блог о ВебОС |
Популярные за сутки
Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.
взяты из открытых общедоступных источников и являются собственностью их авторов.