Алексей Павлов

ООП это не методология отрубающая руки, это способ строить сложные программы проще. Нужно объединить MovePlatform и PlatformSpeed в класс Platform, тут же все проблемы уйдут, пусть и работают с общим полем speed

Вы не уточнили, что понимается под словом "переставляя". Можно ли скажем, переставить первую и пятую строку местами? Или может быть можно, скажем, пятую строку поставить в начало...
А может быть под "переставляя" имеется в виду перестановку рядом стоящих строк местами?
В любом случае имеет смысл сперва найти самый ольшой элемент в матрице, а потом переставлять строки, чтобы он всплыл в угол.
В чем конкретно у вас проблема? Если вы хотите готовый алгоритм, то этот ресурс не для этого. а на конкретные вопросы тут с удовольствием ответят и помогут.

Как начать разрабатывать игры или написать свой игровой движок?

Создайте папку в любом удобном для вас месте на компьютере с названием "мой игровой" движок, по желанию можно еще туда положить readme файлик. Готово - вы начали писать движок. Теперь нужно двигаться к его завершению. По мере движения у вас появится множество новых более конкретных вопросов, на которые уже проще будет найти конкретный ответ.

Несложно представить игровой движок для написания которого не нужно знать физику абсолютно. (движок для крестиков-ноликов, кроссвордов, судоку, текстовых квестов или уже серьезный движок для игр в стиле Diablo, Fallout (1-2-T) и т.д.).

Сложнее представить движок без математики, как в прочем и все программирование. Однако, часто бывает достаточно классов 5-8 математики чтобы писать что-то вполне серьезное, если оно не требует этой математики. Простенький платформер или скролл шутер не потребует от вас знания тригонометрии, например.

Довольно ожидаемо, что если под своим движком вы подразумеваете продукт уровня UE, Unity или чего-то отдаленно сопоставимого, или даже простейший 3д движок написанный с нуля, то остается пожелать вам удачи.

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

Почему бы не перенести HP в класс Enemy?

Я создал класс объектов, (например теплообменник) он имеет свойства на основании которых производится расчёт (например КПД) . И свойства на основании которых происходит отрисовака ( например положение при отображение (коардинаты x, y)) не уверен, что я сделал корректно.

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

подгрузить библиотеку для работы с экселем вроде Excel.Application или как то так, указываешь путь к книги/файл, указываешь лист, читаешь ячейку. list.cells[1,1].value или как то так

Читайте Перельмана штоль тогда.
Якова, конечно.

клиент как только обновит страницу, у него больше не показывалась старая информация, а показывалась новая.

Неправильный ответ - прописать заголовки кеширования на короткое время, магия, чистка кэша и вот это все

Правильный ответ - не использовать файлы с одинаковыми именами для динамически меняющегося контента.
Поясню: файлы js, css, изображения и прочие элементы дизайна и функционала должны кешироваться, они не являются динамической информацией и не должны часто меняться. Отключать кеширование для них - глупо и чаще всего бесполезно(вы же не храните прайс в js файле надеюсь?). Информация же динамическая (в вашем случае прайс) либо в виде текста лежит(что вообще не кешируется по умолчанию), либо лежит у вас в виде файла типа price.xls. И вот во втором случае уже будут проблемы. И тут есть 2 нормальных решения: первое - делать уникальные имена для прайсов(например добавлять дату изменения, что логично и удобно как вам так и клиенту), либо после ссылки на файл добавлять уникальный гет параметр, в итоге ссылка файла будет выглядеть как price.xls?date=220519. Тоже приемлемый вариант, но уникальное имя лучше/удобнее.

Если у вас в таблице 500к записей, то нет абсолютно никакого смысла скачивать ее всю на телефон за исключением одной ситуации - режима работы оффлайн. В данном случае просто делается актуальный слепок, архивируется и отправляется к клиенту. Скачать 100 МБ с телефона сейчас не проблема. При наличии интернета гораздо проще делать запросы через API.

Если подобный вариант не устраивает, то делается все очень просто - на сервере данные никогда не удаляются, но хранится признак их удаления. Помимо этого признака хранится признак последнего обновления записи.
На клиенте хранятся специальные мета-данные с информацией о последнем обновлении (timestamp).
При подключении клиент запрашивает обновление со временем последнего обновления и локальным временем (видел неправильно настроенные часы миллион раз), сервер отвечает обновленными данными. Для сохранения трафика данные приходят в сжатом формате, а удаленные записи передаются отдельным фрагментом с минимальной идентфицирующей строки информацией (поля: первичный ключ или уникальный индекс). Это обеспечивает минимальный объем трафика, но работает только в одну сторону.

Для работы в обе стороны нужен полный лог операций и система разрешения конфликтов. В целом решение так себе, для баз работающих с большим рассинхроном или высокой частотой обнолений, не решается (OT не спасет) без участия человека.

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

1) клиент хранит дату последней репликации с сервером.
2) сервер при каждом обновлении строки обновляет столбец changetAt у строки.
3) клиент при подключении отправляет на сервер дату своей последней репликации с сервером.
4) сервер делает выборку по дате и отправляет id строк клиенту
5) клиент смотрит какие id ему нужны и делает запрос на их обновление

Добро пожаловать в мир конструирования компиляторов :)
Если кратко и просто, то основные стадии работы компилятора такие:

1. Лексический анализ (разделение строки на лексемы - числа и операции)
   
2. Синтаксический анализ (скобки, приоритет операций - в общем, перевод потока лексем во внутреннее представление
   
3. Дальше уже не компилятор а интерпретатор начинается: вычисление значений выражений.
   

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