Можу дати раду по розвитку:
1. Як вже казали раніше — вивчи хоча б базу git — на сьогодні це must have для всіх напрямків.

2. Якщо поглядаєш на embedded, треба попрактикуватися із реальним залізом:
2.1. Візьми мікроконтролер, підійде майже будь-який (e.g. я починав з STM32), і починай писати під нього програми поступово ускладнюючи собі задачі.
2.2. Ознайомся* з базовою периферією обраного МК, там UART, I2C, SPI, таймери, DMA, щось іще.
*Ознайомся означає напиши хоча б простенький проектик рівня університетської лаби на частину цієї периферії.
2.3. Ознайомся* з RTOS. Можеш обрати будь-яку.
2.4. Напиши пет-проект із цим МК. Це має бути щось більш-менш складне. Приклади бачив в інших коментарях.
2.5. Багато кому важливо, аби embedded-програмер хоч трохи розумівся на схемотехніці.
2.6. Програмування під МК має певну свою специфіку:
2.6.1. Часто (не завжди) є сильні обмеження на динамічне виділення пам’яті, аж до повної заборони, або використання для цього специфічних ліб замість звичного malloc+free з stdlib.
2.6.2. Переривання (interrupt) мають значення.
2.6.3. Особливості багатопотоковості: дарована RTOS ілюзія паралельного виконання дуже крихка, тим часом DMA є реальним другим мастером на шині даних, а процес у сусідній мікросхемі як ніщо прикрасить досвід покрокового виконання програми.

3. Якщо не до смаку мікроконтролери, але embedded все ж хочеться, є опція мікропроцесори.
3.1. Розберись, чим вони відрізняються від мікроконтролерів.
3.2. Попрактикуйся із реальним залізом.
3.3. Багато не підкажу, бо підходи тут і з МК багато в чому відрізняються, просто знайди в мережі туторіал як з ними працювати, але основа та сама — він має певні можливості по взаємодії із зовнішнім світом — з ними варто ознайомитися*. І написати більш-менш складний пет-проект.

4. Навіть якщо відходити від embedded, все зведеться до аналогічних порад. Обери одну-дві затребувані на ринку технології (фреймворк, ліба, etc.), ознайомся* з їхніми можливостями, потім напиши більш-менш складний пет-проект.

Проаналізувати більше зв’язків. Наприклад: жанр — рушій, платформа — рушій, жанр — платформа.

GNU Autogen (не плутати з MS-Autogen’ом). Її ніша вузька, проте в ній тулза працює чудово.

Гадаю, в опитування було варто додавати і відкриті питання. Щодо механік гри: важливо, аби гра не кидала з ходу в пекло з мільйону механік, а вводила в них поступово. Можливо, має сенс зробити окрему додаткову навчальну кампанію.

Примус до ризику життям — так само злочин як і замах на життя. І воно залишається злочином незалежно від того, хто і з якою метою його робить.

Спочатку треба зрозуміти конкретно Ваші потреби — без цього підібрати неможливо.
Навчання в якому напрямку?
Які предмети? Яке ПЗ буде для них встановлюватись?
Якщо Word + Excel + zoom, то підійде майже що завгодно.
Якщо багато роботи з 3D графікою, чи моделюванням — варто приділити увагу відеокарті.
Потрібно підключати якусь периферію (USB, HDMI, Ethernet, etc) — переконайтесь, що потрібний роз’єм є.
Загалом — нехай студент ознайомиться з переліком необхідного для навчання програмного забезпечення, потім ознайомиться з його (ПЗ) вимогами до заліза. Тоді запитання буде сформульоване не загальне, яке апріорі не матиме відповіді, а конкретно по Вашому випадку, і можна буде щось радити.

Файно, що DOU цікавиться нашою галуззю. Сподіваюсь, одного дня ми тут отримаємо окремий піддомен, як це сталося з gamedev. Бажаю успіху в пошуку авторів

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