Зачем Писать Собственный Игровой Движок?

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

Единство перед лицом разнообразия игровых движков

В следующем году ситуация, как вы понимаете, изменится.

Нас интересует, какой 41% здесь выделен, то есть двигатели собственной разработки.

Если посмотреть на 5 крупнейших компаний, представленных на конференции, то у каждой из них будет свой движок.

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

Это не всегда самое разумное решение в мире, но это так.

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

Армия семи наций

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

Сверху находятся аддоны над движками, готовые инструменты, которые идут в комплекте с играми, например, инструменты Neverwinter Nights. Что бы ты ни делал, ты каким-то образом оказываешься внутри этой штуки.

Допустим, я хочу оказаться на втором уровне этой пирамиды снизу.

Однако все пути в конечном итоге ведут к вершине пирамиды.

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

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

Вернуться к основам

В идеальном мире при разработке игры вы могли бы убрать этот синий сектор и поместить туда красный, желтый или зеленый.

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

На самом деле это не так, но мы должны к этому стремиться.

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

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

При этом деньги, время и все остальное распределяются именно так.

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

Он не меняется от двигателя к двигателю.

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

Однако если кто-то в компании заговорит о разработке собственного двигателя, он, скорее всего, столкнётся с определённым набором возражений.

Давайте посмотрим на них.

Мифический человеко-месяц

В ответ вы услышите примерно то же, что видите на слайде: «Вы будете это делать долго, это очень рискованно, это нерационально, это не поможет нам достичь наших целей».

Что вы можете на это ответить? Дело здесь в том, что все эти возражения, кроме последнего, не выдерживают критики.

Долгая разработка двигателя? Но если разработка на собственном движке идет быстрее, то это не аргумент. Возможно, никто даже не знает, что такое «рациональное».

Поэтому все эти возражения очень субъективны.

Последний пункт относительно того, способствует ли ваш двигатель достижению ваших целей, очень важен.

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

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

Но не всегда можно эффективно использовать готовые двигатели.

Зачем, в конце концов, писать свой собственный движок?

13 причин почему

• Время выхода на рынок — время вывода продукта на рынок.

  Это действительно серьезно.

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

На сайте одной компании было задание для программистов, которое выглядело примерно так: «Ребята, если вы хотите у нас работать, напишите, пожалуйста, «Астероиды», которые должны работать на платформе Android без использования внешних библиотек.

Мы считаем, что 8 часов вам достаточно.

Время шло».

Потом время увеличили до 12 часов.

Может, это выглядит забавно.

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

Это значит, что если вы вдруг захотите издать «Астероиды» для Android, есть как минимум 200 человек, которые смогут. сделать это за 8 часов.

Я не говорю, что его можно продать.

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

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

• Лорд платформы - Лорд платформы.

  Есть платформы, для которых нет готовых инструментов.

  Например, STB, set-top box (приемник цифрового телевидения) – это приставка для кабельного телевидения, которая есть на столе у каждого третьего американца.

Если вы там пишете софт, включая игры, то у вас есть доллар за коробку.

Это 120 миллионов долларов в год. При этом никто кроме вас не может написать за эту вещь.

Потому что нет DirectX, там вообще ничего нет. Если ты умеешь писать программы для СТБ, то ты хозяин платформы, у тебя есть эти сто двадцать миллионов долларов в год. Почему бы не написать свой собственный движок? Понятно, что речь сейчас идет скорее о чем-то вроде консольных игрушек, но, тем не менее, в некоторых ситуациях это может быть необходимо.

Например, игровые автоматы.

Конечно, сейчас в основном компьютеры.

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

Можно сказать, что нас интересуют телефоны, но речь идет о миллионах долларов.

Почему бы не написать для других устройств? В результате есть совершенно ясные причины это сделать.

Или, например, у нас есть новейшие умные часы.

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

.

Если два миллиона из них будут проданы, то вы получите два миллиона долларов.

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

• Слабые, но гордые устройства – маленькие, но гордые устройства.

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

В то же время в случае с iPhone можно сделать хоть какую-то ставку на прогресс.

Например, ожидается, что Unreal будет работать на iPhone 10, хотя к тому времени, когда все это будет реализовано, уже будет какой-нибудь iPhone 12, 15 или 17. Но в случае с миром в целом, труднее делать ставку на прогресс в краткосрочной перспективе.

Потому что обновления устройств происходят очень медленно.

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

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

Если не хотите конкурентной картинки, то, соответственно, учитывайте возможности слабых телефонов.

Поэтому, если вы попали в ситуацию, когда вас не интересуют самые быстрые устройства, например, вы единственный дистрибьютор где-нибудь в Португалии или Бразилии, то вам придется об этом задуматься.

• Свой язык для своих идей – собственные языки для своих идей.

  Когда вы делаете двигатель самостоятельно, вы можете использовать эту концепцию.

  Дело в том, что главная проблема нашей индустрии в том, что сфера деятельности гейм-дизайнера — филология.

  Он думает на обычном языке.

  Он не может сделать ничего другого.

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

  В результате определенная итерация, которую приходится повторять постоянно, стоит, например, два доллара.

  И вы постоянно тратите эти деньги.

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

Но для всех.

И у вас есть свои идеи, и вы можете реализовать их непосредственно, создав собственный набор инструментов.

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

• Уникальная механика = Уникальные двигатели – уникальная механика = уникальные двигатели.

  Мои друзья написали Minecraft в 1915 году, используя Unity. Был ли вообще смысл все это делать – вопрос открытый.

  Но они выбрали двигатель и приступили к работе.

  Однако двигатель явно их сильно беспокоил.

  Им было тяжело.

  У них были очень длинные итерации.

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

  При этом весь остальной код, отвечающий, скажем, за построение мира, естественно, никуда не делся.

  Просто все это перестало быть в C#, перестало быть в Unity. И работа закипела.

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

Поэтому, если завтра вы придумаете что-то особенное, какие-то сложные воксельные механизмы, то вам будет неудобно работать со стандартными движками.

То есть есть механики, для которых стандартные двигатели не подходят, и которые достаточно легко реализовать самостоятельно.

• Игра не рендер - игра все остальное - игра не рендер, игра все остальное.

  Мы уже говорили об этом.

  Если ваша задача — только что-то нарисовать или, скажем, использовать звук при создании мультиплатформенной игры, то в рассмотренной ранее пирамиде вы могли увидеть похожие истории.

  Если вы скажете: «Я хочу воспроизводить аудио на трёх платформах», то вам для этого не нужна большая «У» — достаточно маленькой «С».

Остановимся теперь на том, какие преимущества дает компании разработка собственного двигателя.

Преимущества разработки собственного движка

• Покупка зачастую выгоднее ипотеки – покупка зачастую предпочтительнее ипотеки.

  Разработка игр — это, так или иначе, деньги.

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

Если на коробке двигателя написано «роялти 10 процентов», то это категорически недопустимо, столько вы не заработаете.

У тебя может быть стопроцентная прибыль, но ты работаешь от 2. То есть если у тебя есть роялти, то это чисто экономическая причина отказа от движка.

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

То есть эта опция сразу отпадает.

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

  Очевидно, что дженерики всегда медленнее, менее производительны и менее специфичны, чем специализированные вещи.

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

• Инструменты и пайплайны разрабатываются внутри — пайплайны и инструменты разработки, созданные внутри компании.

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

  Во-первых, это лучшие практики.

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

  Вполне возможно, что ваши художники рисуют иначе.

  У них есть свой собственный конвейер, и они преуспевают.

Есть простые примеры.

Допустим, вы говорите: «Мы импортируем 3D-модели».

Вы не знаете, что находится на другой стороне.

Итак, вам нужен промежуточный формат. Пусть промежуточным форматом будет FBX. Каждый, кто это делает, знает недостатки FBX. И вам некуда идти, потому что вы не знаете, что там будет делать, вы не будете писать плагины для 450 инструментов 3D-моделирования.

Когда вы работаете в своей компании, вы можете внедрить тот же конвейер, который у вас уже есть, и положить на него то, что вы делаете.

На самом деле это очень важно.

Дело в том, что все это связано со временем разработки и, как следствие, стоимостью.

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

В противном случае ваш документ, который называется «Правила загрузки 3D-моделей и создания материалов для художников», будет больше дизайнерского документа, а это неправильно.

• Время реакции - время реакции.

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

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

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

Исследование новых технологий также упрощается при использовании собственных двигателей.

Допустим, ваш программист пошёл на конференцию и послушал лекцию о чём-то новом.

Он сразу попробовал, получил представление об этой обновке и знаешь, нужна она тебе или нет. Вы действительно можете реактивно попробовать что-то интересное из мира науки.

А это, кстати, означает, что в компании может появиться человек, которого назовут «исследователем».

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

• Спектакль - спектакль.

  Игровая индустрия ориентирована на производительность.

  Первый подход к достижению высокой производительности – использование специальных решений.

  Чем конкретнее решения, тем они продуктивнее.

  Второй подход, тоже кстати уважаемый, — это оптимизация готовых двигателей.

  То, как он будет выглядеть, во многом зависит от этих двигателей.

Это тоже риски.

Давайте посмотрим на них.

Риски, связанные с разработкой собственного движка

• Время разработки - время разработки.

  Эта концепция пересекается с тем, о чем мы говорили о времени выхода на рынок.

  Разработка двигателя может быть как очень долгой, так и довольно быстрой.

  Но время разработки двигателя в любом случае влияет на общее время разработки проекта.

  Поэтому это тоже риск.

  Например, я знаю команды, у которых время разработки движка стремится к бесконечности.

• Терминальные шкафы вендор-лока - терминальные шкафы вендор-лока.

  Это касается не только крупных компаний, но и мелких.

  Допустим, вы наняли Васю, он написал движок, потом влюбился, бросил вас, и никто не понимает, что он написал.

  В результате ваша вендор-локировка хуже, чем у Google. Потому что еще можно написать письмо в Гугл, хоть они и не ответят, но тут с уходом программиста все закончилось.

  Результат — напрасная трата времени на разработку и другие неприятные последствия.

  Мы должны быть в состоянии избежать этих рисков.

• Reinvent the Wheel – изобретение колеса.

  Дело в том, что мы живем в мире, в котором все еще изобретают велосипеды.

  При разработке двигателя оказывается, что завод велосипедов переносится из кода игры в код двигателя, хотя им там нет места.

• Закрытая экосистема – закрытая экосистема.

  Все, что делается внутри компании, принадлежит этой компании.

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

  Это может быть какой-нибудь XScript, который работает только в рамках их решения.

Это можно считать одним из факторов, помогающих удерживать сотрудников.

Поэтому ответ на вопрос, является ли использование собственной технологии хорошим или плохим риском, зависит от конкретной ситуации.

Например, мы стараемся не использовать концепции собственного изобретения.

Например, я знаю одну компанию, которая имеет строго типизированный Lua с синтаксисом Pascal. Этим можно овладеть, но эти знания мертвы, как и греческий язык.

Мы стараемся этого не делать.

Главный вопрос жизни, Вселенной и всего остального

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

Ответ на него, конечно, не 42. Вопрос в том, что вообще нужно, чтобы просто хотя бы иметь возможность сказать: «Да у нас хоть что-то есть, мы можем начать что-то делать».

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

Программисты

Если не знаете, погуглите разницу между словами «разработчик» (разработчик) и «программист» (программист).

Это очень важно.

Разработчики — основная группа.

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

Извините, но они разработчики.

Разработчики не умеют грамотно сделать движок.

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

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

С одной стороны, мир сейчас очень открыт. Я, например, знаю код Unreal 4 и CryEngine, он открытый.

Любой, кто хочет знать, может поискать код Unity, там доступно огромное количество соответствующего материала.

Это означает, что это может сделать тот, кто является программистом и читает по-английски.

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

Поэтому вы должны знать, где они водятся, вы должны уметь их вербовать, использовать и поощрять.

Если вы умеете это делать, то уже можете задуматься о собственном движке.

Если у вас нет таких людей, то у вас все равно ничего не получится.

Примером этого является тьма.

Дело не в том, что есть хорошие и плохие решения.

Просто есть вещи, которые изначально не могут работать.

Программистов нужно иметь возможность нанимать.

Если вы умеете нанимать, вы можете построить двигатель.

Если не знаете, как нанимать, то нужно брать что-то готовое.

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

Если для разработки движка нужны программисты, то сразу возникает несколько вопросов.

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

Технологическая эпидемия

В таких компаниях существует несколько подходов к подбору персонала.

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

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

Во-вторых, есть подход, который мы в принципе исповедуем.

Как действует кефир? Он превращает все вокруг в себя.

Берешь молоко, бросаешь туда кефир — а молока нет, все превратилось в кефир.

Для нас это выглядит так: «Ребята, давайте наймем 5 сильных программистов, это будет внутренний технологический центр».

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

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

Теперь рассмотрим подход, который предполагает организацию в компании команды, которая делает двигатель или еще какие-то интересные вещи.

Это работа на будущее.

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

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

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

То есть физика заказывается, и вместо того, чтобы вырезать какие-то свои вещи, мы говорим: «Давайте сделаем вот так.

Мы просто придумываем общие интерфейсы, несколько обобщенные, и вы это сделаете».

И для типовых задач это очень хорошо.

То есть в принципе хорошо распределять технологии внутри компании.

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

Поэтому, если можете, то попробуйте.

Выглядеть это может как угодно — скажем, мы делаем свою ветку Unreal и там обрабатываем все так, как вы хотите.

Например, в одной из компаний я сделал браузер, умещающийся в 2,5 мегабайта памяти.

И это сработало.

Почему – не знаю, но было бесконечно интересно.

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

Давайте рассмотрим эту проблему более подробно.

Два мира

Это реальная картина.

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

В игровой индустрии сосуществуют два мира.

Люди либо ориентированы на технологические проблемы, либо ориентированы на повествование.

А посередине какая-то поделка.

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

На слайде вы можете увидеть дерево поведения.

В принципе, это вещь просто взятая из Википедии, но до нас Unreal взял ее оттуда.

В этом нет ничего плохого.

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

Это значит, что я облегчил себе жизнь, я не пишу документацию.

И таких вещей здесь очень много.

В примере со слайда что-то происходит, краб бегает, кого-то ловит, в общем, не важно.

Внутри программист решает задачи типа «подойти к.

», «выстрелить в.

», «вычислить расстояние» — и все.

Все остальное поведение пишет в этом редакторе человек, не имеющий абсолютно никакого отношения к программированию.

И это работает, в отличие от перевода текста в код. Тем более, если говорить, скажем, о балансе.

Что такое баланс? Это 15 коэффициентов, которые можно менять.

И здесь описано поведение, а не коэффициенты.

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

В проектной документации просто пишут: «патрули».

И программист может перевести это 50 разными способами.

Что вообще такое патрулирование? И здесь геймдизайнер пишет именно то, что имеет в виду.

И это победа, друзья мои.

Вот почему вам нужны свои собственные инструменты.

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

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

Полученные результаты

Мы говорили о причинах написать свой собственный движок.

Скажем, если вы оглянетесь на устаревшие устройства, это не хорошо и не плохо.

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

В то же время вы хотите выглядеть современно.

Как этого добиться? Напишите свой собственный.

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

В то же время, чтобы сделать свой движок, нужны ресурсы.

А ресурсы — это программисты.

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

Вопросы и ответы

Вопрос

→ Ответить

А если говорить о трудозатратах, то это девять месяцев для коллектива из шести человек.

Но надо понимать, что это наша новейшая разработка, и здесь мы стремимся достаточно высоко.

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

Наш предыдущий двигатель делали два человека за четыре месяца.

Это тоже 3D, но более простой телефон.

Можно сделать и быстрее, я уже рассказывал, как «Астероиды» пишутся за 8 часов, но это, конечно, далеко от реальности.

Вопрос

Отвечать

Два человека делали это в течение месяца.

Но проблема здесь шире, чем создание дерева поведения.

Дело в том, что наши действия написаны на Lua, это занимает, наверное, четыре дня, а вот написание редактора на Qt занимает месяц.

Вопрос

Отвечать

• Ничто Не Бесплатно: Будьте Осторожны С Уловом

  19 Oct, 24

• Андроид Вьюпейджер. Как Заменить Один Фрагмент Другим

  19 Oct, 24

• Coca-Cola Выпустила Бутылки С Возможностью Записи Голосовых Сообщений

  19 Oct, 24

• Неделя Безопасности 46: Слежка За Паролями В Телеконференциях

  19 Oct, 24

• Ourgrid — Бесплатная Двунаправленная Распределенная Вычислительная Система P2P.

  19 Oct, 24

• Ускорение Openmp В Visual C++ 2010

  19 Oct, 24

• Вам Его Значок Ничего Не Напоминает?

  19 Oct, 24

• А Что Насчет Www. Домены Профилей Не Работают?

  19 Oct, 24

• Сеть В Законе

  19 Oct, 24

• Статистика Продаж Приложений В Магазине Windows

  19 Oct, 24