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

---

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


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

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

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



Это перевод поста с форума Оverclock.net. Пользователь Show4Pro решил вытащить все внутренности своего супер компа и повесить все на стену. Прекрасная идея прекрасно реализована. Кому интересно, как это собиралось и как это работает — велкам под кат.

Работаю в IT уже более 12 лет. Думал, что без проблем справляюсь с менеджментом задач, которые отдаем во фриланс. Но последний случай буквально выбил меня из колеи: получил весьма дорогой и негативный опыт. До сих пор обдумываем с коллегами что было сделано верно, а что нет. Предлагаю вашему вниманию 10 выводов-советов, которые мы сделали для себя. Надеюсь, они будут полезны и вам. Если у вас есть что еще посоветовать, то welcome в комментарии.

1. Всегда фиксируйте «правила игры» в договоре

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

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

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

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

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

Поехали?

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

Разработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»

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

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

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

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

Когда я* говорил, что нужно вкладывать в сообщество и User Groups, вы вкладывали в теннисные столы. Теперь у нас много средненьких теннисистов и нет коммюнити.

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

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