Итоги 2013 года

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

Слова любимым

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

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

Сейчас приложение участвует в конкурсе «Лучшее приложение года» и имеет не плохие шансы, не забудьте проголосовать, если еще этого не сделали! ;-)

За год, бесплатную версию приложения, скачали 270 000 пользователей, а суммарное количество пользователей перевалило за 325 000, это очень хорошие показатели, а платную 3 250.

За 2013 год рост посещаемости составил более чем в 2.5 раза, но на самом деле он намного больше, тк счетчик посещаемости появился в октябре 2012 года, пока пользователи обновились, да и сравнивать праздничные месяцы в начале года с концом, не очень правильно, тк приложение ориентировано на праздники, но даже так. 

Web – название самого первого счетчика в приложение

Paid и paid buy – платная версия приложения не купленная и купленная соответственно

Free – бесплатная версия приложения

AlienStorm

AlienStorm – игра и игровой движок для 2д игр, вид сбоку с физикой и другими интересными вещами.

Разработка игры началась зимой 2012 года, в 2013 году она была полностью переосмыслена и стал разрабатываться игровой движок под эту игру. Работа над ним была проделана не малая, а если учесть, что он писался в свободное от основной работы время то для меня он вообще золотой. К концу года движок уже практически был готов и первой игрой на нем планировала выйти, как раз AlienStorm. За время его написания, я уже довольно сильно оброс знаниями, чтобы понять, что начинать стоит с чего-то по проще, ведь по мимо того чтобы сделать игру есть много других вопросов, о юзабилити, о монетизации, о раскрутке. Проект AlienStorm задумывался изначально довольно масштабным, после небольших размышлений и оценки текущего рынка игр, осенью этого года, родился еще один проект, о котом я пока не чего не говорил, Trucking mania это небольшая игра в лучших традиция эластомания.

Именно она будет первой игрой на движке AlienStorm. Изначально она планировалась к самому концу 2013 года, но к сожаление сроки пришлось немного изменить и планируется выпустить её в начале 2014 года. Более подробно о не я расскажу в цикле статьей «Записки программиста».

Вот собственно и все что произошло за 2013 год и ожидается в начале 2014, я считаю, что в целом неплохо для хобби, ведь есть еще основная работа и девушка :-)

Поздравляю всех с наступающим Новым 2014 годом! Желаю творческих успехов! Чтобы все Ваши зарождающиеся проекты доживали до дедлайна и приносили не только удовольствие, но и деньги! Пусть Год Лошади заберет всю лень и дарует максимальную производительность :-D
С НАСТУПАЮЩИМ!!

Записки программиста #6. Что мы знаем о монетизации?!

Недавно я задался вопросом, что я вообще знаю о монетизации мобильного приложения.

Я думаю стоит выделить три группы:

• Реклама в приложении
• Продажа приложения
• Покупки внутри приложения

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

Реклама в приложении

Я бы ее разделил на две большие категории:

1. Реклама внутри приложения, как баннер как правило 480*80Это один из самых простых способов рекламы. Вы выбираете рекламного провайдера по региону в котором у него есть реклама, а лучше выбирать как можно больше и оставлять за собой возможность регулировать выбор без обновления приложения. Это необходимо делать для того, чтобы если у одного из провайдеров будут низкие цены на клики можно было переключиться на остальных.В плане получения денег, тут все просто, количество прибыли зависит от времени одной сессии и количества пользователей, ну и от цены за клик у конкретного провайдера.
2. Большой фул скрин баннер.На текущий момент, я не видел провайдера для российского рынка которые торгуют такими баннерами. Как правило их вставляют в момент старта приложения, в момент выхода или после игровой сессии в играх. Цены за показ такого баннера как правило намного выше, но и недовольство пользователя тоже возрастает.

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

И так, что по поводу денег, этот вопрос наверное интересует всех. Тут как я и говорил, все просто - 10 000 сессий в день * (10 минут на одну сессию / 30 сек показ баннера) = 200 000 показов баннера в день. Цена за 1000 показов в районе 6-10 рублей (это в переводе на клики, в текущих реалиях среди российских провайдеров рекламы на Windows Phone). 

200 000 / 1000 * (6-10)=1200-2000 рублей в день. Откуда брать статистику? Вы все еще не прикрутили не google analytics или flurry, ну вы даете…

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

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

Продажа приложения

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

За все время существование платной версии, а это 8 месяцев было 183 покупки по 33 руб

– 30% магазину = 4183,20 руб. Бешенные деньги =)

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

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

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

Покупки внутри приложения

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

Почему вкусный кусок пирога? Да потому, что переход игры с pay-to-play на free-to-play приносит довольно серьезный доход, а если привнести в реалии мобильной разработки то и продвигать бесплатные/условно бесплатные игры намного проще.

Исходя из этого, свою новую игру я буду монетизировать по схеме f2p.

Давайте попробуем разобраться, что это за зверь и что и как следует делать…

Про различные способы монетизации хорошо написано в статье на хабре «Мошеннические методымонетизации в free-to-play играх» и «Игры free-to-play: как сделать их успешными». Есть еще куча других статьей, но я считаю, что это наиболее полезные.

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

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

Вывод:

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

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

MD5Core старый баг...

Недавно на работе, работая над мобильным xmpp клиентом, столкнулся с такой забавной вещью при авторизации, никак не получалось авторизоваться на рабочем сервере, с корректными данными, используя md5. Unit tests с тестовыми данными проходят, путем долго дебага и сравнивания нашли проблему в либе MD5Core.

Оказывается - эта либа считает неправильно хеш, если длина равна 56, 120, 184, 248 и тд…

На это наткнулся после 2 лет успешного использования, мда, жизнь меня к такому не готовила…

Ошибка оказывается это известная от 5 июль 2011…

Лечиться путем изменения

if (cbSize <= 56) на  if (cbSize < 56)

Забавно до слез!

Записки программиста #5. Концепт документ, да или нет?

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

И так, что это вообще такое «Концепт документ» и с чем его едят.

Концепт-документ (концепт) — это краткое и ёмкое описание концепции (идеи) игры, то есть, максимально сжатый документ, в котором рассказывается о том, какой будет игра, чем она будет интересна и как она должна выглядеть после разработки.

Такой документ составляется игровым дизайнером, но в моем проекта я и дизайнер и программист, и спонсор и кем я только не являюсь =))) Но трудности ведь закаляют;-)

Концепт-документ может строиться по следующей схеме:

1. Введение
2. Жанр и аудитория
3. Основные особенности игры
4. Описание игры
5. Сравнение и предпосылки создания игры
6. Платформа
7. Контакты

Во первых определитесь, для чего Вы его пишете вообще, а если не можете ответить на этот вопрос, то зачем Вы его пишете?! Что бы было? Я думаю не стоит…

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

После того как вы это сделайте, стоит взяться за «Дизайн-документ».

Типовой дизайн-документ может иметь следующую структуру:

1. Введение

2. Концепция

2.1. Введение

2.2. Жанр и аудитория

2.3. Основные особенности игры

2.4. Описание игры

2.5. Предпосылки создания

2.6. Платформа

3. Функциональная спецификация

3.1. Принципы игры

3.1.1. Суть игрового процесса

3.1.2. Ход игры и сюжет

3.2. Физическая модель

3.3. Персонаж игрока

3.4. Элементы игры

3.5. "Искусственный интеллект"

3.6. Многопользовательский режим

3.7. Интерфейс пользователя

3.7.1. Блок-схема

3.7.2. Функциональное описание и управление

3.7.3. Объекты интерфейса пользователя

3.8. Графика и видео

3.8.1. Общее описание

3.8.2. Двумерная графика и анимация

3.8.3. Трехмерная графика и анимация

3.8.4. Анимационные вставки

3.9. Звуки и музыка

3.9.1. Общее описание

3.9.2. Звук и звуковые эффекты

3.9.3. Музыка

3.10. Описание уровней

3.10.1. Общее описание дизайна уровней

3.10.2. Диаграмма взаимного расположения уровней

3.10.3. График введения новых объектов

Контакты

Примеров «Дизайн-документ» в интернете ходит много.

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

Выводы:

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

Когда его стоит писать? Насчет того, что начинать стоит с него, если Вы инди разработчик, я не согласился, я его написал перед привлечение новых людей в проект, после редактора физики, к тому моменту идея окончательно созрела в голове;-)

Удачи в разработке;-) 

Записки программиста #4. С чего начать…

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

Изначально для редактора физики я собирался использовать связку Windows Forms + XNA.

• Используем Windows Forms контролы
• Рисуем XNA на панели
• Один изпримеров реализации

Для редактора мне больше всего нравился метод, где XNA это панель, а остальная гуя это Windows Forms контролы. Но тк решил писать на Monogame, возникли проблемы, может конечно руки кривые, но не срослось. Нашел презабавную вещицу - OpenTK.GLControl.

Но чем больше я использовал подобные решения, тем больше у я убеждался, что нужны свои контролы, тк изобретать велосипед совсем не хотелось. Решил глянуть что появилось новенького в плане GUI for XNA, их довольно-таки много:

• Ruminate XNA 4.0 GUI
• XNA Tool GUI
• Neoforce Controls XNA
• XNA Simple GUI 2.0 
• MoControls 
• XAMLite UI Library for XNA 

Также у меня были первые версии библиотеки general’a GPF:

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

Из всего этого многообразия мне понравилось два проекта GPF и XAMLite, правда оба они не дописаны и не обновляются в открытом доступе, что очень прискорбно.

Решено было остановиться на GPF и допиливать его по мере необходимости.

После того как я определился с GUI я взялся за сам движок и редактор физики.

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

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

Пора браться за саму игру =)

Правда, по поводу игры возник небольшой нюанс…Но это сюрприз, напишу о нем в следующей статье :-)

Промо от Nokia

Сегодня попал в промо от Nokia.

Россия, Украина, обладатели Nokia на борту с WP8

Установить на главный экран "Делись лучшим", зайти туда, подожди чтобы загрузилась, выйти и зайти снова: я в разделе "Рекомендуемые сегодня" :-)

Windows Camp 2013 моими глазами.

12 сентября прошла уже третья конференция Windows Camp посвященная Windows 8.1, Visual Studio 2013, Windows Azure и Windows Phone.

Большинство докладов было посвящено выходу новой операционной системы, а точнее, обновлению Windows 8.1, которое назначено на 18 октября 2013 года. Обновление доступно всем пользователям Windows 8.0. Приложения, написанные для Windows 8.0, будут работать в режиме совместимости, но всем разработчикам следует обновить свои приложения, чтобы поддерживать новый функционал и корректно работать: режим работы с разными разрешениями экрана, большие и маленькие тайлы, новый сценарий поиска в приложении.

В Windows 8.1 существенно расширился API

Синим, показано, что добавлено нового в Windows 8.1. Windows Phone имеет общее ядро, что и большая Windows, к сожалению появиться ли этот функционал на Windows Phone пока не известно, об этом станет известно в первом квартале 2014 года.

Также был существенно улучшен парсинг XAML и отображение длинных списков.

Разработка под Windows 8.1 возможно только в Visual Studio 2013. В 2013 студии появился ряд нововведений, улучшен редактор XAML и HTML. В XAML редактор добавлена поддержка функции перехода по определению “Go To Definition” для ресурсов, связей данных, свойств и элементов XAML. Более глубокая интеграция с Azure.  Одним из самых интересных нововведений Visual Studio 2013 является технология динамических индикаторов в коде. CodeLens для языка C# позволяет разработчикам получать самую актуальную контекстную информацию прямо в редакторе, например такую как количество ссылок, последние изменения в базе исходного кода. Более подробно описано на сайте microsoft. В студию включена поддержка технологии мгновенных сообщений Lync в виде индикатора доступности. Эта технология позволяет связаться с автором изменений в коде прямо из редактора. Так же добавлен ряд новых индикаторов, например, такие как баги, связи с рабочими элементами, задачи, требования, рецензирование.

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

Помимо нововведений вошедших в VS 2013 RC так же было исправлено большое количество ошибок и внесены изменения на основе пользовательских запросов. 

Записки программиста #3. XNA vs Mono vs Silverlight vs Engine

Изначально свою будущую игру «AlienStorm» предполагалось делать по средствам XNA.

Wiki: Microsoft XNA — набор инструментов с управляемой средой времени выполнения (.NET), созданный Microsoft, облегчающий разработку и управление компьютерными играми. XNA стремится освободить разработку игр от написания «повторяющегося шаблонного кода» и объединить различные аспекты разработки игр в одной системе. Набор инструментов XNA был анонсирован 24 марта 2004 на Game Developers Conference в Сан-Хосе, Калифорния. Первый Community Technology Preview XNA Build был выпущен 14 марта 2006.

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

И тут как гром среди ясного неба, по правде слухи ходили, но никто не верил… Microsoft от 31 января 2013 заявило, что новые версии XNA более не будут разрабатываться и XNA не будет доступен в новом Metro интерфейсе Windows 8, а также на Windows 8 RT. А также на Windows Phone 8 будет поддержка XNA приложений в режиме совместимости…

Печали не было границ…

Разрабатывать в дальнейшем, я собирался на C#, и для XNA требовалась замена.

Несколько мучительных запросов к поисковикам показали, что для .NET существуют два враппера над DirectX: SlimDX и SharpDX.

При этом SlimDX и SharpDX поддерживают DirectX 11, a XNA – нет.

Сравнив код примеров, и погоняв простенькие тесты, убедился, что SharpDX в части взаимодействия с Unmanaged кодом проработано глубже. Кроме того, SharpDX собирается под Any CPU, что позволяет делать один билд как для x86 так и для x64 архитектур. Фактически этот выбор на код почти не влияет — это не более чем врапперы, пишем мы по-прежнему под голый DirectX, разница разве что в именовании — по-другому названы пространства имен, и где-то другой регистр, где-то чуть по-другому именуются классы. Судя по заявлениям авторов обоих врапперов, функционал Direct3D 11 покрыт полностью и работает практически идеально. Поверим им на слово. Но все равно это было немного не то.

Решил поискать дальше про аналоги XNA, ведь уже не раз слышал о том, что есть open-source реализации:

• MonoGame
• MonoXNA судя по старым комитам забросили.

Обе представляют собой кроссплатформенные open-source реализации Microsoft XNA для Mono.

Также уже были найдены готовые движки:

• Unity3D
• Cocos2d
• Ogre3D

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

И так из всего этого многообразия приходится выбирать.

Решил с того, что нужно сперва подвести итоги, что же у меня есть:

• Работающий прототип со своими минусами
• Примеры физики для 2д
• Большая часть графики 2д
• Опыт работы с XNA

Платформы, под которые должно работать: Windows Phone 7/8, Windows 8, Windows 7+, не плохо бы иметь возможность портирование на IOS и Android, но это на будущее.

Из готовых движков очень понравился Unity3D, но мои умения и наработки касаются 2д, но за него я в будущем еще возьмусь =)

Physicshelperxaml – ну очень понравился, и реализация, и возможность в плане редактора использовать студию, но к сожалению, по моим расчетам сделать на этом, что-то большое и красивое будет проблематично. К примеру все реализации части, которые я нашел, довольно сильно тормозят, возможно я не умею готовить, да и возможность даже в будущем сделать версию на ней для IOS и Android очень призрачна…

Выбор мой пал на MonoGame. У него конечно много своих минусов, но он постоянно развивается и это радует. Да и на текущий момент, он уже довольно-таки неплох.

Записки программиста #2. Портативные библиотеки классов или совместное использование кода в различных проектах.

Разрабатывая приложения для Windows Phone 8 и Windows 8 часто встает вопрос, как сделать так, чтобы написанный один раз код, работал везде, хоть они и основаны на одном и том же ядре Windows 8 и Microsoft пытается всячески сократить разрыв между ними, но различий довольно много. А если встает вопрос о поддержке проекта на IOS и Android по средствам Mono, то порой хочется плакать… Ведь в самом худшем сценарии, придется поддерживать как минимум 4 проекта и изменение в одном, несут большое количество изменений в другом, те большое количество ручного труда. Именно такой и встал у меня вопрос в начале разработке, ведь об этом стоит подумать заранее. До этого я с этим сталкивался только вскользь.

В целом, для решения этого рода задач, существует два метода:

Портативный библиотек классов

Совместное использование кода

Портативный библиотек классов

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

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

Что же такое PCL, хорошо показано на рисунке:

А если добавит Xbox получите что-то вроде этого:

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

В таблице ниже дается обзор того, что поддерживается в PCL:

Feature	.NET Framework	Windows Store	Silverlight	Windows Phone	Xbox 360
Core BCL	Да	Да	Да	Да	Да
Core XML	Да	Да	Да	Да	Да
Core WCF	Да	Да	Да	Да
Core networking	Да	Да	Да	Да
XML Serialization	Да	Да	Да	Да
JSON serialization	Да	Да	Да	Да
Datacontract serialization	Да	Да	Да	Да
IQueryable	Да	Да	Да	7.5  и выше
dynamic keyword	4.5	Да	Да
View Models	4.5	Да	Да	Да
Data Annotations	4.03 и выше	Да	Да	Да
LINQ	Да	Да	Да	Да
XLINQ	4.0.3  и выше	Да	Да	Да	Да
MEF	Да	Да	Да
System.Numerics	Да	Да	Да

Совместное использование кода

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

Используя данный подход Вы все еще ограниченны общим API библиотек. Так как исходный файл должен работать в нескольких проектах.  Однако, существует еще один метод, который можно использовать, чтобы обойти это: директивы препроцессора.

Когда использовать первый способ, а когда второй?

Я бы рекомендовал использовать PCL в небольших проектах, где идет большое количество одинакового кода минимально привязанного к платформе. Как правило это бизнес приложения для Windows 8 и Windows Phone7/8 где интерфейсами заменяются критические части и реализовываются для каждой платформы отдельно, как я писал выше.

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

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