azShoo

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

А ещё есть отдельный геморрой с тем, что например при загрузке в АппСтор\ГуглПлей с вас, с высокой долей вероятности, спросят про права на трейдмарки и прочее.
Но это если говорить о мобильных приложениях.

"Оптимальный" путь зависит многих факторов.
Например, от архитектуры игр: предполагается постоянный коннект клиента с сервером, или можно жить в оффлайне?
Например, от UI и игровой логики: должен ли у пользователя быть постоянный real-time доступ к состоянию таймера восстановления, или оно просто должно тикать где-то в фоне?
Может ли он взаимодействовать с этим таймером (напр. дебаффать других игроков, что бы замедлить восстановление, или задонатить что бы сократить время)

В целом детерминированная по определенным правильнам, регулярно случающаяся активность идеально попадает под Scheduled Job \ Timer внутри игровой логики.
У вас есть момент инициализации таймера, в который вы рассчитываете с какой скоростью и в каком объеме у вас должен происходить "тик" восстановления энергии.
У вас есть момент окончания таймера - объект из буффера кидается в очередь на передачу клиента, обрабатывается клиентом, происходит так.
У вас есть критерии его окончания - пользователь ушел в оффлайн? Грохнули все таймеры для него, например. Или, наоборот, зафризили.

Самое сложное тут - правильно отслеживать состояние таймера и апдейтить его при необходимости.
Для этого надо правильно проработать условия возникновения, истечения и обработки таймеров и сложить их в прозрачное и пригодное для дебаггинга-тестирования хранилище.

Я правильно понимаю, что вы хотите запилить свой проект, а за это получать стабильную зарплату одной компании, и ещё и долю в другой?
Хорошая попытка.

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

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

1)Какие направления существуют в сфере игрового дизайна?
Их довольно много. Геймдизайнер - понятие совокупное, и в мелких командах это как правило парень, придумывающий и рассчитывающий как игровую логику, геймплей, так и монетизацию, создающий сеттинг и прочее.
В крупных компаниях эти "сферы" обычно дробят по разным людям.
И есть ещё куча других должностей: левел-дизайнер, концепт-дизайнер и дизайнер персонажей\сеттинга\етк.

Хотите рисовать? Вакансий художника\иллюстратора\концепт артиста и прочих - довольно много.
Поочередно вбиваете в поиске названия компаний, известных в гейм-дев сфере и смотрите вакансии, требования и прочее. Там все есть.
Пример: www.kefirgames.ru/ru/vacancy/hudozhnik_illyustrator

2)Какими навыками необходимо обладать, чтобы стать художником в играх?
3)Где можно обучиться?

1) Уметь рисовать.
2) Иметь портфолио.
3) Пройти собеседование.
В целом это все, что нужно. Дальше, в зависимости от специфики. Как бы все.

Вы определитесь сначала с платформой, с целевой аудиторией, а дальше уже с жанром.
Разница между предпочитаемыми жанрами есть даже внутри мобильной разработки, хотя больше конечно общих тенденций.
Браузерные игры - это другое.
Социальные игры - третье.
Десктопные - вообще отдельный мир.
В общем больше конкретики.

Берете книгу\видеокурс\статью а-ля "Создание игр для Android" (напр. на Udemy.com ) и начинаете.
В большинстве случаев в таких книгах\уроках в самом начале рассказывают про самые азы java, которые нужны для понимания.
Дальше - чувствуете, что чего-то не понимаете -> идете в гугл, ищете ответ, решаете проблему.
Вот и все.

Могу ошибаться, т.к. в целом на данный момент экспериментирую в том же направлении.
Для себя реализовал это примерно следующим образом:
1) GUI - видимо то, что вы понимали под "экранами". Графический интерфейс с отрисовкой и точками входа для действий пользователя (KeyListener и иже с ними). Никакой логики здесь нет, только соответствующая отрисовка.
2) Engine, грубо говоря - "движок": здесь содержится вся игровая логика. Карты, юниты, итемы, состояния и прочее. Все взаимодействия между объектами и экземплярами классов - описаны здесь.
3) Непосредственно Game - непосредственный "поток", включаемый по запуску приложения, который обуславливает взаимодействие GUI и Engine. Здесь инициализируется запуск Engine и GUI, а дальше по мере получения информации от движка и\или "экранов" - нужным образом обрабатывается взаимодействие.

Но, как я уже говорил, на правильность подобного деления не претендую.