Александр

+ и все что дальше него до @ — просто игнорируется. Это очень удобно, потому что позволяет иметь при одном ящике бесчисленное количество адресов.

Я например часто использую эту фичу когда регистрируюсь на каких-то сайтах, например для facebook e-mail myemail+fb@domain.net, для yandex — myemail+ya@domain.net, для какого — нибудь сомнительного сайта — myemail+hrenkakayato@domain.net и т.д.

Письма по всем этим адресам будут доставлены в myemail@domain.net

И если потом например в мой ящик начинает приходить спам на имя myemail+hrenkakayato, то сразу видно, где утечка. И легко сделать фильтр, чтобы просто банить такие письма…

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

Во всех остальных случаях нужен стационарный комп, потому что:
1) Проектировщику нужен нормальный монитор 24", а часто даже пара одинаковых (документация на одном, чертеж на втором). К ноутбуку конечно можно подключить второй большой монитор и нормальную клавиатуру - поставить ее перед большим монитором, но какой тогда смысл в ноутбуке?
2) Автокад одноядерный. Это его родовой дефект. И все "течения" в автокаде - на его "шасси" - тоже (Civil, Plant3D и пр). Основной процесс "упирается рогом" в производительность одного ядра, а все вспомогательные процессы - потребляют еще 0,5 ядра максимум. Т.е. работает он только в режиме "полтора землекопа". Поэтому нам нужен процессор упоротый по частоте в режиме нагрузки 2-х ядер. А это например линейка Интел с индексом К. А значит с ноутбуками - опять мимо.
2) Память - тут все сложно. Да, надо признать, что чистый Автокад прекрасно работает и на i5 второго поколения выпуска 2012 года с 8-ю оперативки, но второй родовой дефект Автокада - работа с кучей временных файлов. В результате при наличии в системе "свободной" памяти она используется как дисковый кэш и некоторые тяжелые кадовские операции могут ускоряться в десятки (!) раз при наличии запаса именно незанятой памяти. Плюс есть любители - кроме Автокада держать открытыми еще несколько пожирателей памяти: 30 вкладок в Хроме, Скайп, Вайбер, Word, Acrobat - тут смотрите по своим вредным привычкам и особенностям работы. Но 16 гигабайт обычно решает проблему.
Опять же ноутбуки с 16 - это топ и дорого.
3) Быстрый диск. Как я уже написал - автокад любит диск. Поэтому сегодня есть смысл собирать под него комп с NVMe диском, со скоростями ближе к 3000 мб/сек на чтение и запись. А ноутбук - как правило кот в мешке - не вы его собирали, и что там сунуто - обычно "сюрприз". Хотя уже пошли модели, где в этом плане все ОК, но опять же - информации ноль. Только опытным путем...
4) Видеокарта - встроенная. Дело в том, что у Красных, что у Зеленых - дискретные видеокарты разделены на игровой и профессиональный сегменты. И что у AMD, что у Nvidia - кадовские функции ускорения в игровых картах отключены. В то же время уже с 2012 года встроенная графика Intel этим не страдает, всё кадовское ускорение там разрешено и дискретным решениям - как минимум не проигрывает.
А теперь найдите хоть один ноутбук с вышеуказанными характеристиками и без дискретной видеокарты!
5) Дешевле. Комп с нужными характеристиками выйдет примерно в 2 раза дешевле аналогичного ноутбука :).

Ну вот - теперь признайте правду - игровых ноутбуков не бывает, ноутбуков под авткоад - тоже. Автокад работает на современном - чем угодно, но иногда скорость НЕКОТОРЫХ может операций может отличаться критично.

P.S. а если всё же для игр - то в стационарный поставить видеокарту намного проще.

Есть разные понятия джиттера, основное это резкое изменение фазы сигнала (например при последовательном воспроизведении двух музыкальных треков). Однако в сетях джиттером обычно называют просто "прыгающий пинг", т.е. разброс во времени прохождения сетевых пакетов. Т.е. если у вас все пакеты идут по 2 миллисекунды, то джиттера нет. Если все пакеты по 200 миллисекунд то джиттера тоже нет. Но если часть пакетов идет по 2 и часть по 200 - то это джиттер. Джиттер есть практически в любых броадкастных сетях, в т.ч. и в Ethernet, при высоких загрузках среды передачи. В WiFi выраженность джиттера будет зависеть от нескольких факторов, основной это загруженность используемого частного канала. В многоквартирном доме или офисном здании с кучей небольших компаний это может быть достаточно серьезной проблемой. Джиттер плох в основном для игр и реалтаймовых протоколов (голоса, видео).

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

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

Из общих советов могу порекомендовать избегать циклических связей, когда, например, вы в ui что-то отправляете и в сценарии ожидаете, что оттуда вас дёрнут в ответ, а если не дёрнут, то всё сломается. Для того, чтобы это не случалось, очень удобно использовать такую конструкцию:
public event Action OnSomething = () => {};
Так вы всегда сможете вызывать OnSomething и не беспокоиться о том, есть ли какие-либо подписчики у этого события, оно никогда не будет null и снаружи его никто вызвать не сможет. Когда вы начинаете думать в таком формате, то проектировать архитектуру становится проще.

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

Всё зависит от цели, задачи и пути исполнения. Для обучения программированию, выстраиванию архитектуры и основам gamedev libgdx отлично подходит, но он по сути только для 2D игр(и он ну очень хорош в этом) + мало инструментов разработки( editor, animator и т.д).
C# и Java конечно похожи, но не настолько что б сразу "перескочить". Но и C# в Unity это не совсем C#. Короче, если идет только обучение или желание создать небольшую 2D игру на мобилку, то libgdx. Если есть немного знаний + 3D или мало мальская серьезная 2D, то Unity. А если ПК + 3D или Пк + Мега 2D, то Unreal Engine 4.

Java и шарп действительно сильно похожи синтаксисом но внутренние отличия довольно большие. В общем перескочить можно с малой кровью.
Сравнивать libgdx и юнити очень некорректно.
Юнити это готовый и законченный движек с готовыми утилитами под него.
LibGDX это только фреймворк над базовыми вещами. Т.е. рендер\систему ресурсов\сеть\базовые классы игры, все придется писать самому. Утилиты,равно как и форматы хранения контента придется тоже писать самому. Редактор карт тоже придется писать самому. Другой вариант что многие описанные вещи можно найти уже написанные кем то и слепить все воедино.

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

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

1) Документация по юнити официальная частично переведена. Ну и - учите английский, чтобы проблем небыло.
2) Лучшая дока, которую я видел - официальная.
3) Лучший курс - опять таки официальный.

Официальные туторы, курсы, вот это все - https://unity3d.com/ru/learn - тут.

Если вы берёте ноутбук, значит вы так или иначе допускаете работу не в "домашних условиях" => FHD лишним не будет (хотя оно лишним не будет даже если вторым экраном монитор подключен). Я уже с десяток лет с ноутбуком как с основным домашним (т.е. для пет-проджектов) компьютером и поверьте на слово - разрешение 1366 на 768 (тем более если диагональ 15") это боль, страдание, унижение и ненависть к производителю. Встроенная графика сейчас конечно достаточно проворна, но лучше дискретную графику, хотя бы 950М. А вообще геймдев цель так и шепчет на ухо: "возьми стационарный ПК". Так или иначе всё сильно зависит от уровня ваших проектов. Два экрана не должны стать проблемой. Опять же, смотря что на них делать. Если на одной IDE, а на другой разворачивается простой 2Д проект, то почему бы и нет? А вообще абстрактного коня описываю. Сейчас прям цены на ноутбуки приличные настолько злы, что смотреть страшно - так что удачи в выборе )

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

• Если хорошо знаешь Java - выбирай его, не задумываясь
  
• Есть немалое количество туториалов на тему этого движка и готовых игр, а так документация на хорошем уровне
  
• Не требует высокого уровня программирования
  
• К сожалению, многие фреймворки, различные расширения для игр, анимационные стандарты, рекламные сервисы не поддерживают движок
  
• Это джава. Она всегда лагает. Её с плюсами даже сравнивать нельзя
  
• Частенько придется писать платформозависимый код, как на Java для Android, так и на Objective-C для iOS
  

Теперь о Cosos2d-x:

• Знаешь C++ - выбор сделан
  
• Очень производителен в 2д разработке. Обходит по скорости даже юнити, про libgdx даже молчу. Но нужна ли тебе такая производительность?
  
• Из-за того, что движок очень популярен, поддерживается большинством фреймворков, рекламных сетей, но ни так, как юнити. Это все же надо понимать.
  
• Полностью кроссплатформенный. Есть даже встроенные средства для добавление поддержки внутриигровых покупок для iOS и Android одновременно, без написание кода под каждую ОС.
  
• Открытый код. Постоянно развивается засчет этого движок.
  
• Отличная архитектура у движка
  
• Пи#здец, как мало туториалов и статей. А документация просто ужасная