Даниил

Причесаться :)

Человек не может эффективно управлять множеством обьектов. Максимальное количество обьектов (людей, вещей), которыми эффективно управляет один человек, равно шести. При большем количестве начинается "сортировка по приоритетам", в результате которой одними обьектами управляешь чаще, чем другими - при их одинаковой начальной эффективности.

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

Десять проектов, в каждом их которых сделано по два коммиту - это хуже, чем два, в каждом из которых по десять коммитов :)

Почему нет формы жалобы "Автор в неадеквате"?)

1. Студия используется как стандартная ide для unity
2. Хотите все с нуля и якобы без движков, пишите и свой графический движок, а если нет, то можно директX, но студия предлагает этот вариант как c++. Но вы конечно можете подключить порт под шарп.
3. Не хотите полностью с нуля, но не используя юнити, пишите на ксамарин, аспнет, ксенко и тд.
4. Если язык не важен, то полно других движков.
5. Игры наподобие NES/SNES использовали тайлсеты
6. К пунктам 2,3,4, если вы решите портировать куда то еще кроме пк, скорее всего у вас будут крупные проблемы.
7. И да, юнити полностью бесплатный. Платная версия нужна для отключение сплешскрина и некоторых облачных бонусов (которые вы конечно же можете и сами воссоздать)

Edit:
В свете дополнительных комментариев от автора и моей предложенной правки вопроса:

Вы можете использовать следующую библиотеку для реализации вашей игры средствами только символов
https://github.com/derrickcreamer/SunshineConsole
Она создает окно и выводит туда символы) Саму игру программируете сами)

Предсказать невозможно.
В лучшем случае - пара дней. В худшем - перенос не состоится вообще.
Начинайте сразу.

Mono - это кросс-платформенная реализация, включающая runtime CLR и подмножество .NET platform. Включает и поддержку настольных приложений.
Замарин (Xamarin) - это набор инструментов для разработки мобильных приложений. Работает поверх Mono runtime. Xamarin.forms позволяет писать меньше платформно-зависимого кода чем просто Xamarin.

.NET Core - это кросс-платформенная реализация подмножества .NET platform для разработки бэкэнд сервисов, без необходимости в Mono.

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

Есть такая «секретная» ссылка: www.youtube.com/get_video_info?video_id=XXXXXX
Вместо XXXXXX подставьте хэш видео, который в ссылке на ролик, типа youtu.be/BWCiWZtrWXU после слеша.

По этой (первой) ссылке вернутся URL-encoded данные. Распакуйте их и возьмите параметр url_encoded_fmt_stream_map. Его значение опять надо распаковать как URL-параметры. И из результата вытащить параметр url – это ссылка на единый скачивабельный видеофайл.

Например, в консоли браузера:

function getUrlParams(search) {
    let hashes = search.slice(search.indexOf('?') + 1).split('&')
    let params = {}
    hashes.map(hash => {
        let [key, val] = hash.split('=')
        params[key] = decodeURIComponent(val)
    })

    return params
}
var s = '------'; // здесь длиннющая строка из ответа /get_video_info
var a = getUrlParams(s);
var b = getUrlParams(a.url_encoded_fmt_stream_map);
console.log(b.url); // эту ссылку открываем в браузере - это скачиваемый видеофайл

Очень надеюсь, что вы покопаетесь в этих данных более подробно, разберётесь, как получать прямые ссылки на скачиваемые файлы во всех форматах и размерах, которые предлагает YouTube, и напишете короткий материал на Хабр по результатам, а также опубликуете gist с рабочим кодом для консоли браузера.

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

Мне кажется тут вопрос не столько в "плюсах и минусах" сколько в здравом смысле. Мне не совсем понятно, что в конечном счёте означает "бекенд на python, фронтэнд на angular". Это два независимых проекта, способных работать автономно друг от друга и "общаться", например, через API, разработка которых происходит параллельно и независимо друг от друга, при этом какие-либо части проектов не пересекаются между собой (например, куски HTML/CSS/JS/etc кода не копируются в бекенд-часть)? Если так - то крайне логично разделить это на два отдельных репозитория, т.к. это по сути два разных проекта, связанных между собой весьма косвенно. Если же у Вас проекты имеют более прочную связь между собой или степень контаминации исходного кода выше той, что я описал ранее - то это один проект и дробить его на множество репозиториев, лично я смысла не вижу никакого (а то мы так дойдём до "давайте хранить HTML-код в одном репозитории, CSS в дургом, JS в третьем и т.д.).

P.S. Обычно, такие вещи разъясняет штатный тимлид, а не коллеги по форуму :)

В Telegram строится API аналогичным образом, вопрос только в том подойдёт ли оно вам. Может вам нужны серьёзные вещи вроде GraphQL, или базовый RESTFull. Но в подражании нет ничего плохого, если ваш сервис например будут использовать люди знакомые уже с ВКонтакте API.

1. Работа над личным брендом: Высокая репутация в профессиональных сообществах повышает привлекательность для нанимателей.
   
2. Улучшение существующих знаний: Хочешь что-то понять, объясни другому.
   
3. Приобретение новых знаний: Специализация замыкает в узком спектре задач и проблем, а Q&A-сервисы - это источник задач и проблем из самых разных областей и иногда под самыми неожиданными углами.
   
4. Альтруизм: Большинству из нас кто-то помогал в начале пути, пришло время возвращать долг и делать свой скромный вклад в рост кадров.
   

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

Для чего просиживаете на тостере по 5-6 часов в день?

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