mayton2019

Посмотри вот в этой табличке https://ru.wikipedia.org/wiki/%D0%A1%D1%80%D0%B0%D...

По теме. Я думаю что тебе не стоит думать в таких категориях. Все равно хорошую игру в 2К ты не втолкаешь. Шахматы в 5К втолкнули ну и что? Это слабые шахматы. Если у тебя есть хорошая игра то лучше положить ее в хостинг и в QR код добавить просто ссылку.

Никак. Как же ее парсить, когда ее нигде нет?

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

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

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

Обычно механика исключений хорошо приживается в языках с Garbage Collectors.

Поэтому, подытоживая - да. Ошибки не равны исключениям. Исключения - это более высокоуровневый мехнизм.

Вопрос такой что отвечая на него можно новую книгу написать. Тут даже С не причем. А причем - архитектура процессора x86. Кстати тут еще надо кеш-линии рассмотреть. Это фокус такой. Что если тебе надо 1 байт прочитать
из произвольного адреса, современная архитектура этого не умеет. Она читает (обычно) кусок памяти шириной в 64 байта. Это обзывается кеш-линия. И уже из нее будет прочитан нужный байт. Отвечающие верно сказали выше. Еще можно добавить такое (условное правило) что тип данных должен лежать в сегменте данных по адресу кратному самому размеру типа. Тоесть int должен лежат на адресах кратных 4, long - 8 байт и так далее. Вот насчет MMX/SSE не знаю.

Из сбивчивых жалоб и стенаний автора можно только то что нет опыта и есть признаки выгорания от учёбы. У меня тоже такое было. Я выгорал. И самое лучшее в этот момент - бросить самообучение и заняться другим делом за которое платят и которое вполне осязаемо. Самая большая беда новичка - это амбиции. Это желание сразу сходу делать своё где есть все фичи в мире и можно грабить корованы и прочее. Это ошибка. Ошибка которая как раз приводит к выгоранию. Лучше написать морской бой в браузере который работает чем писать 3д шутер 10 лет и потом выкинуть его на свалку просто потому что он морально устарел. Одиночки вообще никакой игры не могут написать. Игра сегодня - это как съемки сериала. Требует слишком много разных знаний из разных областей и 1 чел никогда все не охватит.

По поводу мотивации и геймдева. Лучше всего наверное влиться в команду которая уже делает игры. Влиться самым младшим подмастерьем и хотя-бы пол-годика поработать и понаблюдать как идет процесс разработки. Да. Надо будет приглушить амбиции. Но ничего не поделать. Я думаю что это единственный верный путь где не будет выгорания. Эмоциональный контакт с командой очень важен.

С практической точки зрения удобнее задать вид форматирования (например 4 знака после запятой) и любое значение float при выводе на печать форматировать.

Вот эту сигнатуру ты сам придумал.

def add_time(self, h=0, m=0, d=0, dw=0, mh=0, y=0):

и дальше уже пошли все остальные беды отсюда. А прикинь еще будет 20 методов которые делают сравнение времени, разность в днях или календарные расчеты и везде-везде у тебя будет это ужасное векторизованное представление времени. Хотя на самом деле время - это просто вещественная точка на оси истории. Одно число. Например для unix-time достаточно целого числа 32х бит чтобы хранить любую дату с 1970 года.

С проверками условий тут ничего не поделать. Все они будут как ты и написал в полном объеме. С проверкой типов можно извернуться и свалить их хотя-бы на type hints.

Посмотри как python3 рекомендует работать с временем https://docs.python.org/3/library/datetime.html

Если очень хочешь создавать свой класс Clock - создавай. Только опиши хотя-бы для себя какой у него SingleResponcibility. Что он делает. Что хранит. Может окажется что тебе его делать не надо. Есть альтернативы.

Можно поискать так называемые экстракторы ресурсов. В 2000е издавались целые диски этого софта.
По названиям утилит можно здесь посмотреть https://wiki.xentax.com/index.php/Extraction_tools
Будь осторожен. Многие эти тулзы были с "сюрпризом" внутри. Я-бы их ставил только на виртуалку и после одноразового исопльзования удалял.

Иногда можно просто догадаться что ресурсы игры - это по сути архив приаттаченый к экзешнику.
Например Quake3 просто использовал zip для упаковки своих ресурсов. А в игре Mortal Kombat я находил звуки просто просматривая байты как 8-битные амплитуды на wave-редакторе. Находил довольно быстро. Звук видно визуально. Так-же с текстурами.

Дело в том что нельзя решать проблемы TCP находясь выше уровня TCP.

Сами потери пакетов этот протокол решает повторной пересылкой (TCP Retransmission).
Тоесть технически это уже решено в самом протоколе. Разумеется не безплатно и ценой
потери времени. Когда у вас примерно 50% теряется - это ситуация "очень плохо".

Так работать нельзя и нужно решать эту проблему именно в том месте где она возникает. Если
это физический уровень то надо менять кабели (антены) или если это работа шейперов и firewalls
то решать это соотв там.

По поводу удвоения трафика и избыточности. Можно использовать различные коды Хемминга и РидаСоломона
но они требуют буфера. Причем если единица потери у вас это TCP-пакет то для удачного восстановления
надо хотя-бы передать 1000 пакетов оснащённых кодами восстановления (и при этом гарантировать
что ретрансмиссий не будет ибо они не нужны) и на выходе где-то (интересно где?) их всех собрать
в один массив и быстринько проверить что инфы для восстановления уже достаточно чтоб пролечить
потерянный пакет. Как это сделать - ума не приложу. Но это полюбому будет на уровне IP/UDP
и это совершенно новый протокол. Крайне ресурсоёмкий по памяти и с длинным лагом по TTFB.

Вобщем схема очень напоминает скачивание большого торрент-файла по UDP в условиях рандомного порядка
следования чанков этого самого файла. Кому такая схема нужна? Это нединамично и неотзывчиво. Никаких онлайн
игр и стриминга тут нельзя построить.

Вот например CPU вырос в два раза, а чем при этом занимается наше Java-приложение, какие запросы отрабатывает, непонятно.

Так не бывает. Если вы разрабатываете этот софт - то вы соотв. знаете какие changes заходили в последнем релизе.

Если вы прям вообще-вообще невкурсе где у вас нагрузка или bottleneck - то это плохо, друзья. Вы не знаете свой код. И почему случилось так что вы раньше этого не знали - непонятно. Вобщем главный совет - будьте familiar to your code. И вам не понадобиться бегать и в день релиза искать профилировщики.

+1 к тому что написал Владимир. Все верно.

Думаю что вся игровая логика описывается орграфом из трех вершин и 3 ребер.

from enum import Enum

class Game(Enum):
     STONE    = 1
     SCISSORS = 2
     PAPER    = 3

winners = { Game.STONE : Game.SCISSORS, 
            Game.SCISSORS : Game.PAPER, 
						Game.PAPER : Game.STONE }

Тут - непонятно.

using Stream stream = File.Open(filePath, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

читающий поток разрешает другим одновременно запись. Это к чему. Чтобы разрушить файл?

А в пишущем потоке какие-то непонятные лишние действия совершаются. Зачем файл дваждый открывать-создавать?

Первая линка возвращает

$ curl --head https://vm.tiktok.com/ZMNv1gmUj/
HTTP/1.1 301 Moved Permanently
Server: nginx
Content-Type: text/html; charset=utf-8

Во всех языках программирования есть библиотека поддержки дат. И во всех этих библиотеках есть функция расчета количества дней между двумя датами. Например

days(currentDate() - date('0001-01-01'))

Далее - четность-нечетность.

Тоесть от Рождества Христова до текущего дня. Вот такая вот декомпозиция задачи на простые функции.
А автору - жирный минус за то что он не может нормально постановку сделать. Какая-то гумнанитращина.
Нельзя-же так! Инженер должен уметь владеть языком функций.

И еще забыл указать какую футболку он одевает в условно первый день.

Словами решать эту задачу - категорически не интересно. Смотрите фунции работы с датами. Там есть свои нюансы. Есть разные календари и прочее.

Лет 10 назад мне попала в руки база абонентов мобильного оператора. Как раз в формате Cronos. Но открыть я ее не смог приложением. Дело в том что этот формат использует симметричное шифрование данных. Как архиватор RAR. Без знания пароля - безнадёжное дело.

Поэтому Python здесь не поможет. Надо первым делом понять с чем мы имеем дело. Открыть файл приложением клиентом и убедится что он хотя-бы не шифрован.