Symbi0t

Ищите в гугле более широкие темы. Например, узнайте про "12 принципов анимации", или более наглядно тут (советую взглянуть всем, даже если тема не интересует, для общего образования). И применяйте их уже к вашей задаче, ничего сложного нет.
Для вдохновения можете погуглить "motion design", и посмотреть на каком уровне 2D анимация там.

Изучите это Material-Animations

Прогресс персонажа:

Вариант 1. Постоянный рейт — т.е. всегда 1000 XP на уровень
Вариант 2. Арифметическая прогрессия — 1000 XP + 100 * N на уровень
Вариант 3. Геометрическая прогрессия — 1000XP * (1.1)^N

Прогресс XP, получаемый за выполнение игровых задач
1. Постоянный — время, затраченное на достижение нового уровня, всегда одинаковое
2. Уменьшающийся — чем выше уровень, тем больше требуется опыта.
Пример: пусть кол-во опыта на уровень постоянно: 1000 XP.
XP _{убийство моба} = 100 * (10 + LVL _моба — LVL _игрока)/(10 + LVL _игрока). На первом уровне нужно убить 10 мобов своего уровня, на десятом — двадцать.

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

Но согласно общей концепции, у обычного сотрудника не может быть подчиненных. Значит метод getListEmployee() не нужен родительскому классу Person.

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

Так, например, можно добавить метод getListEmployee(), возвращающий список подчинённых (кстати, опять плохое название метода, не отражает сути), а реализация этого метода в классе Employee может возвращать пустой список.
Или можно добавить метод getSubordinateEnumerator(), возвращающий интерфейс перечисления подчинённых, а в классе Employee возвращать из этого метода NULL.

Если же вы не собираетесь использовать единый интерфейс Person, а, например, будете пытаться привести Person* к типу Employee* или Manager* с помощью dynamic_cast, то метод в Person не нужен.

открыть с помошью>дополнительные программы > найти другую программу на этом компе > C:\Users\USER\AppData\Local\atom\app-1.7.2\atom.exe
Только не забыть "использовать по-умолчанию" поставить

Symbi0t:

Скорее классический сайт, чем полноценное SPA. Но именно клиентсайд хотелось бы сделать модульным, используя ES6.

Вот это плохой подход. Инструменты нужны, чтобы решать проблему. А у вас подход - "Проблемы нужны, чтобы использовать инструменты".
Тем более получить поверхностные знания одно, а использовать - другое. С большой вероятностью проект будет настолько медленно развиваться, что вы забьете на дизморали.
выберите одно, на нем сконцентрируйтесь, сделайте прототип рабочий, потом постепенно переписывая допиливая с использованием новых технологий (CommonJs/AMD, к примеру, в небольшом проекте вполне нормально заменить на анонимные самовызывающиеся функции). Поймите зачем вам вообще этот проект, если это что-то большее чем песочница для обучения, то сконцентрируйтесь на этом большем (контенте).
Попробуйте реализовать какой-нибудь типовой архитектурный шаблон на нативном js, чтобы лучше видеть +/- фреймворков(библиотек), какие проблемы решают, да и вообще понимать, что там происходит.

Думаю, что лучше взять ES6 + Babel + Webpack. Может я ошибаюсь и лучше взять что-то другое?

Нормально.

Использовать сервер только для получения каких-либо данных, а бизнес-логику поручить клиентсайду? SPA или классический сайт?

Так вы задайте себе вопрос, у вас SPA или классический сайт? Приложение или газета? Gmail нет смысла делать классическим сайтом, визитку нет смысла делать SPA.

Переведенная документация. Не знаю, только в какой объёме её перевели.

Рисуйте фигуры с помощью svg ( например raphaeljs.com )
И вешайте обработчик как на обычный dom элемент.

На событие mousemove для родительского элемента прямоугольного) вешать обработчик, который будет проверять нахождение курсора внутри требуемой фигуры (как решать задачу о принадлежности точки фигуре, решать вам) и на основании этого выполнять или не выполнять какие-то действия (имитировать hover).

Попробуйте для начала Удовольствие от ИКС

Go - язык общего назначения. Перспективы у языка хорошие, и для WEB он подходит более чем. Основное назначение GO, как по мне, распределенные приложения и приложение ориентированные на массовый паралелизм. На нем удобно писать разного рода демоны, REST апишки (можно реализовывать узкие места к примеру), обработка I/O. Как примеры использования, самые популярные, можно привести Docker, skydns и т.д.

Не согласен.

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

GUI имеет смысл преподавать уже после консольки, при чем объясняя такие вещи как отзывчивость интерфейсов, как не допускать подвисаний интерфейсов. асинхронная работа с IO и т.д. Тогда толк есть.

Что до робототехники, контроллеры типа arduino, можно, но когда человек разберется что такое микроконтроллер, научится эффективно их использовать и все такое прочее. Все же разрабатывать коммерческие проекты на базе ардуино не очень то выгодно, обычно это просто хобби, побаловаться. Есть кучи более дешевых аналогов, от тех же Texas Instruments которые позволяют и разобраться, и не иметь дела со скучным ассемблером а писать уже на Си и делать прикольные штуки. Так же есть DSP процессоры и кучи других прикольных вещей.

На хабрахабр делились опытом использования данного языка habrahabr.ru/post/195464

Скорее всего вам подойдет теория расписаний.