Mercury13

Инструменты (В чем или на чем) зависят напрямую от:

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

В общем и целом, чаще используется векторная графика т.к. удобна для масштабирования при печати. Соответственно, создавать макеты надо в векторном редакторе (от самых известных платных Adobe Illustrator и CorelDRAW до менее известных, бесплатных и с менее широким функционалом). Конкретный инструмент должен выбирать дизайнер т.к. именно он будет работать над созданием.

Также используется растровая графика (чаще для более реалистичных и фото изображений). Здесь графических редакторов также много: Adobe Photoshop самый известный, но есть и немало продуктов от других производителей. Выбор конкретного также полагается на дизайнера т.к. вам (руководителю или заказчику) важен результат, а не формат файлов.

Хорошим тоном будет спросить требования к файлам в типографии (или на заводе) заранее. Это избавит от любых возможных проблем с форматами и техническими особенностями макетов для изготовления. 2016 год на дворе, но я до сих пор не понимаю почему никто так не делает. Если в типографии есть отдел допечатной подготовки (а в хороших и грамотных конторах он есть, сам в таком работал когда-то), то вопросы соответствия макетов требованиям уже не так актуален т.к. они сами все приведут к нужному виду.

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

Аллокатор умеет выделять и освобождать память в требуемых количествах определённым образом. std::allocator -- пример реализации аллокатора из стандартной библиотеки, просто использует new и delete, которые обычно обращаются к системным вызовам malloc и free.

Более сложный пример -- pool allocator. Раз системные вызовы дороги, почему бы на них не сэкономить? Выделим сразу 1 гигабайт памяти (к примеру), а дальше в аллокаторе будем выдавать память из этого пула и увеличивать указатель head (опять же, упрощенно). Реальное выделение памяти только одно, системных вызовов почти нет, ура-ура, программа ускорилась.

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

Неужели СТАНДАРТНАЯ БИБЛИОТЕКА (которая почти часть языка) это какой-то секрет?

Вовсе нет:
glibc: https://sourceware.org/git/?p=glibc.git;a=tree
musl: git.musl-libc.org/cgit/musl/tree
uclibc-ng: repo.or.cz/uclibc-ng.git/tree
newlib: https://sourceware.org/git/gitweb.cgi?p=newlib-cyg...

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

0. Написание дизайн-документа. Если не можете точно и детально написать, что из себя представляет игра, какие механики используются, сеттинг и т.п., то к разработке приступать не рекомендуется.
1. Пре-альфа/Прототип. Этап, на котором набивается "скелет" игры, с минимумом контента. На нём можно успешно закончить, если понимаете, что не можете реализовать те или иные идеи диздока или игра не соответствует вашим ожиданиям.
В UE4 - этап, состоящий из написания кода на 90% (даже если вы разрабатываете на блюпринтах - рано или поздно захочется уехать на чистый код, тем более что оттуда можно делать интерфейсы для них для удобства тестирования и гуманитариев).
2. Альфа. Играбельно-багованое нечто, в котором реализованы все основные механики. На этом этапе обычно основной упор в разработке на базовый баланс, заполнение контентом и БАГИ. Тут по-полной используются все возможности: от моделей и анимации до активной работы с дебаггером и логами.
3. Бета. Весь геймплей в наличии, контент готов на 95%. Баги - наше всё.
4. Релиз. Момент рождения продукта.
5. Пост-релиз. БАГИ, недовольные пользователи, призывы к бунтам. Возможно захочется делать допконтент.
Про мобильную разработку: преимущества ue4: полный контроль над кодом, лучший редактор во Вселенной, вариативная производительность и бОльшие технические возможности, недостатки: больший порог вхождения, дольше и сложнее разработка, нет поддержки "из коробки" многих удобных фич типа AdMob и ачивок на платформе.

Пакеты Джавы и сборки Дотнета - это про модули в терминах крупной структуры приложения, они тут не при чем.
Речь идет о модулях на уровне программного кода.
Хотите примерно понять как это будет выглядеть - посмотрите, например, на юниты в Паскале. Это примерно и есть то, что хотят получить в конечном счёте - возможность по-человечески, на уровне языка, объявлять интерфейсы модулей, подключать их друг к другу, следить за зависимостями между модулями (разве что модули C++ вроде как не привязываются к единице компиляции, в отличие от юнитов Паскаля).
Сейчас в C++ это достигается большим хаком на уровне препроцессора (а не компилятора языка), называющимся include-файлы. Этот механизм, основанный на правиле "много объявлений, одно определение", унаследован из Си, и по сути представляет собой замену отсутствующей возможности передавать метаданные от одной единицы компиляции к другой при сборке проекта. С помощью инклудов вы напихиваете в один файл ВСЕ, что может потребоваться компилятору. По факту выливается в то, что бОльшая часть единицы компиляции после обработки препроцессором - это содержимое инклуд-файлов. И всё это обрабатывается компилятором каждый раз заново (в каждой единице компиляции). В Си это еще куда ни шло, но в плюсах, где многие библиотеки содержат тяжелый шаблонный код, это становится совсем печальным. Помимо этого, сама работа с инклудами - это непростая практика, и если следовать ей неверно, особенно новичкам, они могут получить от компилятора удивительнейшие ошибки. За примером далеко ходить не надо - попробуйте в большом проекте не ставить защиту от множественного инклуда.
Вся эта препроцессорная магия красоты и прозрачности языку не добавляет. Пока в других языках пишут "package foobar" и "import foobar", мы пишем "#pragma once" или даже "#ifndef FOOBAR_H ...". Уже грустно как-то становится.

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

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

Вам нужна одна из следующих комбинаций:
1. Один роутер (тот что получает интернет, любой вообще) - две точки доступа, одна должна работать как клиент
2. Один роутер с вайфаем и одна точка доступа с режимом клиента
3. Два роутера - один с режимом работы клиента вайфая.

Можно.
У передающего роутера - съемная wi-fi антенна
У принимающего роутера - съемная wi-fi антенна, режим wi-fi client
+ пара направленных антенн, вместо второго роутера можно использовать точку доступа

PS: Какие точные условия передачи? В чем проблема кинуть на 50м UTP5 хоть по воздуху? или это между квартирами? Городить wi-fi мост целесообразно при длине кабельной линии >120м

Задача сводится к выяснению того, сколькими кубиками (не способами, а именно кубиками) может быть задана исходная сумма (нижних граней).
Например, 1 может быть задано только 1-м кубиком, ответ - 1
2 может быть задано как 1-м, так и 2-мя кубиками, ответ - 2
3 может быть задано 1-м, 2-мя или 3-мя кубиками, ответ - 3.
Рассмотрим 4. Может быть задано от 1-го до 4-х кубиками. Т.е. ответ - 4. Рассмотрим случай 2-х кубиков. Это могут быть комбинации 2 + 2 или 1 + 3, но оба они дадут одну и ту же сумму верхних граней: 6 + 6 - (2+2) или 6 + 6 - (1+3), что явно одно и то же.
У разных же количеств кубиков сумма разная, так как разное кол-во 6-к (самых больших чисел).

Итак, надо выяснить, сколькими кубиками можно задать сумму s. Понятно, что если s ≤ 6, то любым кол-вом от 1 до s. Но если s > 6, то одним кубиком уже не задать. Если s > 12 (6 * 2), то не задать уже и двумя.
Т.е. если s > 6, надо вычесть 1, если s > 12, надо вычесть 2, если s > 18, то вычесть 3.
Или, иначе говоря, если s > 6k, надо вычесть k. k можно посчитать как (s - 1) / 6 (целочисленное деление). Как только s становится больше 6k, то есть становится 6k + 1, получаем (6k + 1 - 1) / 6 = k. Если же s = 6k, то (6k - 1) / 6 = k - 1, что нам и надо.
Т.о. результат: s - (s - 1) / 6, что эквивалентно вашей формуле, так как
(s + 5) / 6 = (s - 1) / 6 - 1
(s + 5) / 6 - 1 = (s - 1) / 6