Открывая книгу по «новомодной технике проектирования», такой как инверсия зависимостей ожидаешь увидеть описание очередной серебряной пули. Дескать, вот, до этого все мы жили неправильно, а теперь, вооружившись ломом контейнером и какой-то матерью мы сможем писать новые приложения за 10 минут.
Поскольку сам я к подобным новомодным инструментам отношусь с некоторой осторожностью, то я был приятно удивлен тем, что в книге Марк делает акцент на общепринятых практиках проектирования, роли стандартных паттернов проектирования, да и вообще, рассматривает принципы управления зависимостями в отрыве от конкретных инструментов.

Автоматический подсчет ссылок (Automatic Reference Counting, ARC) для языка Objective-C был представлен компанией Apple еще в 2011 году для iOS 4.0 и выше, Mac OS X 10.6 и выше, с использованием xCode 4.2 и выше. И, хотя всё больше библиотек, фреймворков и проектов сегодня используют ARC, до сих пор среди программистов встречается либо неприятие этой технологии, либо eё неполное понимание. Опытные программисты, привыкшие к retain/release, иногда считают, что они лучше и эффективней справяться с подсчетом ссылок, чем это за них сделает компилятор, а новички, начищающие сразу использовать ARC, полагают, что им не надо вообще думать об управлении памятью, и всё сделается магическим образом само.

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.

---

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.


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

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

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

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

До чего бывает неприятно: есть 32-битная библиотека на C++, которую вы уже много лет лицензируете клиентам, а теперь все больше и больше клиентов хочет использовать ее из 64-битных программ. Вы развиваете библиотеку, исправляете ошибки, дорабатываете, холите и лелеете ее, она прекрасно работает, а клиентам это не так и важно – они просто хотят 64 бита. Им даже не важно, будет ли она вся 64-битной, они просто хотят ее использовать.
 
Что делать? Очевидно – переписать код так, чтобы он компилировался и на 32 бита, и на 64:
— читаем много статей – например, вот эту и те, что появятся в «похожих публикациях» при ее прочтении;
— быстренько правим код (за неделю должны управиться, правда?);
— ???
— PROFIT
 
А теперь добро пожаловать в реальный мир.

В массовом сознании давно укоренилось, что программирование — это работа для молодых. Честно говоря, я сам так считал до совсем недавнего времени. Исходил я, при этом, из предположения, что молодые люди легче учатся, быстрее и лучше думают и, поэтому, в большей степени подходят для решения алгоритмических задач. Мне казалось, что с возрастом мозг работает хуже, память ухудшается, нейроны вроде не восстанавливаются, а способность к быстрому обучению падает. Правда, меня смущало то, что на своем собственном опыте я убеждался как раз в обратном: сейчас, в 42 года, я определенно думаю лучше, чем в 20 лет.

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

Сегодня мы поговорим о распределенных, гетерогенных и местами довольно серьезно и разнообразно нагруженных интернет приложениях на примере портала http://www.abbyyonline.com. Я постараюсь не углубляться в технические подробности, имеющие отношение к конкретной платформе, и, хотя основная часть описанного приложения реализована на ASP.Net MVC, возможно, данный материал заинтересует всех, имеющих отношение к веб-разработке, вне зависимости от используемого инструментария.

В нашем блоге мы уже немного рассказывали о старых версиях ABBYY Lingvo, но всё время за рамками постов оставалось главное в истории словаря – как же он создавался. Было это больше двадцати лет назад – срок немалый, но в ABBYY люди работаю долго, и Александр Москалёв, который спроектировал первую версию Lingvo в 1989 году, до сих пор в компании. Мы попросили рассказать его о том, как всё начиналось, – и вот что из этого получилось.

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

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

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

var opened = false;

Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:

var opened = false;
var animating = false;

function onClick(event) {
  if (animating) return;
  if (opened) close();
  else open();
}

Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

Знакомьтесь, это Вася.

Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств.

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

Итак, в ноябре прошлого года наша команда начала делать клиентскую сессионную ммошечку — катайся на машинах, стреляй врагов. Надо сказать, что у команды уже был опыт не успешного проекта на юнити, это были 3д гонки для вконтакта. Так что тема машинок в юнити была уже знакома и на этом планировалось сэкономить. Cамое первое с чего было решено начать, это максимально быстро сделать пруф оф концепт — демку игры максимально точно показывающую геймплей. Цель данного мероприятия понятна — как можно раньше отсечь все то, что не впишется в игру. Кроме того, предстояло также выбрать серверный движок. С клиентом все было понятно сразу, Unity3d наше все, но что выбрать в качестве серверного движка? Вот в чем вопрос. Остановлюсь на этом по подробнее.

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

Для самых нетерпеливых по ссылкам ниже находится готовый прототип.
Онлайн версия
Скомпилированная версия для Windows [Зеркало] ~7.5 МБ

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

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

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

Добрый день, уважаемые коллеги!

Так получилось, что к моменту начала работы с Unity3D, у меня был четырехлетний опыт разработки на .NET. Три года из этих четырех я успешно применял dependency injection в нескольких крупных промышленных проектах. Этот опыт оказался для меня настолько позитивен, что я постарался привнести его и в геймдев.
Сейчас уже могу сказать, что затеял это не зря. Дочитав до конца, вы увидите пример того, как dependency injection позволяет сделать код читабельнее и проще, но в то же время гибче, а заодно еще и более пригодным для юнит-тестирования. Даже если вы впервые слышите словосочетание dependency injection — ничего страшного. Не проходите мимо! Эта статья задумана как ознакомительная, без погружения в тонкие материи.

Разработка игр в целом – очень увлекательный и интересный процесс. Особенно он интересен тогда, когда ты занимаешься этим один, независимо ни от кого, имея за плечами небольшой опыт во всем, что позволит создать полноценный продукт для индустрии развлечений. Казалось бы, если для этого есть время и возможности, то почему бы не переодеться в шкуру инди-разработчика и создать нечто интересное, что сможет понравиться людям и принесет прибыль? Конечно да, но только помимо множества явных подводных камней существуют и едва заметные грабли, которые лежат на последней ступени процесса создания игры и больно лупят по голове. После чего остается мысль — «Ведь я же старался, потратил много времени, но ничего не получил взамен», а следом — «Ничего, в следующий раз я сделаю лучше!». Под катом история о том, как на эти грабли мне пришлось наступить трижды.

При разработке нам понадобился простой конечный автомат, желательно уже реализованный. Из списка реализаций, который предложил гугл, выбрали этот, за простоту и компактность. Используем у себя, в целом FSM неплох. Далее под катом перевод оригинальной статьи автора из Греции Tasos Giannakopoulos. Я не переводчик, поэтому я старался передать смысл, иногда объясняя суть своими словами, за что извиняюсь перед перфекционистами.