Алексей Елецкий

- Хранить NPC имеет смысл в сущности «текущий бой», а вот где её хранить уже есть разница.
- Если под сохранением в сессию подразумевается сохранение в cookies, то это плохая идея, т.к., в случае двух одновременных запросов от пользователя, будут конфликты.
- Если под сохранением в сессию подразумевается сохранение на стороне сервера, то это скорее всего и есть сохранение в БД.
- «Если рассчитывать на 20 тыс игроков в онлайне, не нагнется ли…» — вопрос не корректен, т.к. не описана логика игры и железо на сервере. Если расчёт хода раз в сутки, то не нагнётся, если раз в секунду, то может и нагнуться.
- Число онлайна, кстати, дико оптимистично.

Варианта два:

1. Хранить в БД.
2. Хранить в фоновом процессе в памяти, который и делает обсчет логики, не обращаясь к БД.

Во втором случае, общаться с таким процессом можно, например, через отправку сообщений amqp. Результаты вычислений процесс может как ложить в кэш (который много быстрее БД), так и слать сразу клиенту (websockets).

Если это коммерческий проект ОБЪЕКТИВНО имеющий возможность получить 20к онлайна, заморочайтись 2-ым вариантом. Если это хобби, прототип или просто изучение новой технологии — не заморачивайтесь и начните с 1-ого, когда игра разовьётся, всё станет более очевидным.

Работать в консоли и писать для консоли — это разные вещи. Работать в консоли, безусловно, полезнее — это позволяет понять некоторые «подкапотные» вещи. Знающий консоль, гуи освоит, обратное не всегда верно. А вот писать под консоль, на мой взгляд, детей учить не обязательно.

Графика и дорогие роботы — это же всегда «круто», на них куда проще объяснять свои достижения сторонним людям. Вот небольшой пример, пусть мы учим алгоритмы на графах, делаем простой поиск пути по заранее заданной карте. Его можно сделать в виде:

- консольного рогалика где буковка @ бегает по клеточному полю.
- графического 2д, где картинка героя бегает по тайлам травки.
- графического 3д, с трёхмерным персонажем и т.д.
- программы для крутого робота, который ходит по квартире (с заранее заданным планом).

Алгоритм поиска пути будет почти одинаковый (везде может быть двухмерное клеточное поле). Сил и времени от ребёнка каждый вариант тоже требует примерно одинаковое количество. Пара вопросов:

1. Какой из вариантов будет выглядеть круче для мамы/друга/девушки?
2. Какой из вариантов ребёнок (да и взрослый) захочет дорабатывать?
3. Какой из вариантов даёт больший простор для оригинальной доработки и изучения технологий/алгоритмов?

Я бы сказал, что вариант с роботом (и далее в обратном порядке). Я учился программировать именно на консольных примерах, поэтому по своему опыту скажу, что даже если ты понимаешь «крутость» проделанной работы, другим это проще объяснить на роботах и графике.

По поводу программирования непосредственно GUI… Это то, чем занимается большая часть программистов, поэтому для среднего программиста эти навыки потребуются с бОльшей вероятность. Вопрос в том, готовите ли Вы средних программистов.

1. Единственного правильно ответа нет.
2. Сразу грамотно ещё никто никогда ничего не писал, не нужно надеяться и/или переживать. Если проект учебный, то просто пишите.
3. Если «экран» — это то, что отвечает за отрисовку игры, то он точно не должен управлять логикой.
4. Если возникают проблемы с определением того как управлять набором объектов, проще всего ввести дополнительную абстракцию (как Ваш вариант 2), только назовите не Engine (слишком уж обще), а, например, UnitsManager — все команды, касающиеся юнитов шлите ему, а он внутри уже пусть сам разберётся. Это позволит разделить всю логику на две независимые части (одна делает всё с юнитами, другая с ними ничего не делает), что упростит восприятие архитектуры.

Это, конечно, примерно.

1. Конкретная реализация зависит от проекта, предметной области, того, что делает код, когда выполняется и прочих вещей.
2. Переменная не обязана быть глобальной.
3. Советую почитать про MVC, правда не уверен, что в данном случае оно нужно.

Пользуясь своими экстрасенсорными способностями пришёл к выводу, что всё-таки через базу.